Re: Ordered delivery of EAP messages

Unless I am missing something most of the converstaion so
far has been
related to efficiency.  That is, if the transport layer
provides inorder
delivery the EAP works well.

I think we need to answer this question first:

Does EAP require to have inorder delivery to work correctly.
 By work
correctly I mean that it does not falsely authenticate
someone.

Can someone show how EAP falsely authenticate someone if
packets arrive
in arbitrary order.

If this cant be shown the inorder delivery is not a MUST but
a nice to
have feature of the transport layer and the statement in the
RFC should
be changed from a MUST to a SHOULD.

-----Original Message-----
From: Glen Zorn (gwz) [mailto:gwzcisco.com] 
Sent: Tuesday, March 06, 2007 6:45 PM
To: Alper Yegin; Bernard Aboba; Pasi.Eronennokia.com; eapfrascone.com
Cc: radiusextops.ietf.org
Subject: Re: [eap] Ordered delivery of EAP messages

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
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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

Re: Ordered delivery of EAP messages

Thread: Re: Ordered delivery of EAP messages