Re: Ordered delivery of EAP messages

Glen Zorn said:

"There are a couple of problems with this statement
that I think are 
pertinent to the question at hand.  First, RADIUS is a
"lockstep" protocol 
in almost (if not exactly) the same way that EAP is: the
semantics of the 
Identifier field in the header of RADIUS messages are
identical to that of 
the EAP version (RFC 2865 only says that the Identifier must
change on new 
requests, not how it must change -- in particular,
monotonicity is not 
assured) and requests are retransmitted.  The other problem
is that neither 
RADIUS nor the underlying UDP transport guarantees in-order
delivery of 
packets.  So, I would claim that this sentence is completely
false."

I think you are correct.  If the RADIUS retransmission timer
were 
under-estimated, RADIUS can deliver EAP messages out of
order.  That is, the 
  NAS could retransmit an Access-Request, and then could
receive an 
Access-Challenge in response to an earlier Access-Request. 
The NAS would 
then send a new Access-Request, which could cross paths with
the 
retransmitted one.

Note that if an Event-Timestamp attribute were to be
included in the RADIUS 
Access-Request, then the Identifier would change on the
retransmitted 
Access-Request.  The NAS would then be able to determine
that a False 
Retransmission (FRTO) had occurred.  But from the point of
view of the 
RADIUS server, I don't think it matters, since it won't be
checking that the 
Event-Timestamp attribute is monotonically increasing.


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

The problem scenario requires EAP-layer retransmission,
correct?
Authentication server does not perform such retransmission.
So, I don't see
equivalence between the two legs of the EAP transport.

Alper

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_abobahotmail.com]
> Sent: Tuesday, March 06, 2007 4:35 PM
> To: gwzcisco.com; Pasi.Eronennokia.com; eapfrascone.com
> Cc: radiusextops.ietf.org
> Subject: Re: [eap] Ordered delivery of EAP messages
> 
> Glen Zorn said:
> 
> "There are a couple of problems with this
statement that I think are
> pertinent to the question at hand.  First, RADIUS is a
"lockstep" protocol
> in almost (if not exactly) the same way that EAP is:
the semantics of the
> Identifier field in the header of RADIUS messages are
identical to that of
> the EAP version (RFC 2865 only says that the Identifier
must change on new
> requests, not how it must change -- in particular,
monotonicity is not
> assured) and requests are retransmitted.  The other
problem is that
> neither
> RADIUS nor the underlying UDP transport guarantees
in-order delivery of
> packets.  So, I would claim that this sentence is
completely false."
> 
> I think you are correct.  If the RADIUS retransmission
timer were
> under-estimated, RADIUS can deliver EAP messages out of
order.  That is,
> the
>   NAS could retransmit an Access-Request, and then
could receive an
> Access-Challenge in response to an earlier
Access-Request.  The NAS would
> then send a new Access-Request, which could cross paths
with the
> retransmitted one.
> 
> Note that if an Event-Timestamp attribute were to be
included in the
> RADIUS
> Access-Request, then the Identifier would change on the
retransmitted
> Access-Request.  The NAS would then be able to
determine that a False
> Retransmission (FRTO) had occurred.  But from the point
of view of the
> RADIUS server, I don't think it matters, since it won't
be checking that
> the
> Event-Timestamp attribute is monotonically increasing.
> 
> 
>
____________________________________________________________
_____
> To unsubscribe or modify your subscription options,
please visit:
> http:/
/lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.
frascone.com/pipermail/eap

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

Alper Yegin <mailto:alper.yeginyegin.org> allegedly
scribbled on
Tuesday, March 06, 2007 10:10 AM:

> The problem scenario requires EAP-layer retransmission,
correct?

Yes, I suppose so.

> Authentication server does not perform such
retransmission. 

>From the Abstract to RFC 3748 "EAP provides its own
support for
duplicate elimination and retransmission..."; the
Authenticator is
responsible for all retransmission.

> So, I
> don't see equivalence between the two legs of the EAP
transport. 

You are imagining that there are always 2 legs, which is not
true; the
quoted portion of RFC 3748 does not state that assumption,
either.  But
actually, you are right: it appears that RADIUS would
generally be in
far greater peril of the risk then EAP, especially in a
proxied network.

> 
> Alper
> 
>> -----Original Message-----
>> From: Bernard Aboba [mailto:bernard_abobahotmail.com]
>> Sent: Tuesday, March 06, 2007 4:35 PM
>> To: gwzcisco.com; Pasi.Eronennokia.com; eapfrascone.com
>> Cc: radiusextops.ietf.org
>> Subject: Re: [eap] Ordered delivery of EAP
messages
>> 
>> Glen Zorn said:
>> 
>> "There are a couple of problems with this
statement that I think are
>> pertinent to the question at hand.  First, RADIUS
is a "lockstep"
>> protocol in almost (if not exactly) the same way
that EAP is: the
>> semantics of the Identifier field in the header of
RADIUS messages
>> are identical to that of the EAP version (RFC 2865
only says that the
>> Identifier must change on new requests, not how it
must change -- in
>> particular, monotonicity is not
>> assured) and requests are retransmitted.  The other
problem is that
>> neither RADIUS nor the underlying UDP transport
guarantees in-order
>> delivery of packets.  So, I would claim that this
sentence is
>> completely false." 
>> 
>> I think you are correct.  If the RADIUS
retransmission timer were
>> under-estimated, RADIUS can deliver EAP messages
out of order.  That
>>   is, the NAS could retransmit an Access-Request,
and then could
>> receive an Access-Challenge in response to an
earlier
>> Access-Request.  The NAS would then send a new
Access-Request, which
>> could cross paths with the retransmitted one. 
>> 
>> Note that if an Event-Timestamp attribute were to
be included in the
>> RADIUS Access-Request, then the Identifier would
change on the
>> retransmitted Access-Request.  The NAS would then
be able to
>> determine that a False Retransmission (FRTO) had
occurred.  But from
>> the point of view of the RADIUS server, I don't
think it matters,
>> since it won't be checking that the Event-Timestamp
attribute is
>> monotonically increasing. 
>> 
>> 
>>
____________________________________________________________
_____
>> To unsubscribe or modify your subscription options,
please visit:
>> http:/
/lists.frascone.com/mailman/listinfo/eap
>> 
>> Arhives: http://lists.
frascone.com/pipermail/eap
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap