Subject: Re: [eap] Ordered delivery of EAP message

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 08 Mar 2007 22:53:13 -0800

Glen Zorn said:

"I expect that any implementation that would fall prey to Pasi's 
pathological example would be badly behaved."

Please remember that the original EAP implementations were created for PPP, 
which provides for in-order delivery.  As a result, those implementations 
did not have a need to keep a duplicate cache as recommended in RFC 2865.  
Given this, you cannot conclude that an implementation that would not detect 
a duplicate mingled with a new transmission would be badly behaved.  Those 
implementations were legal under RFC 2284, and they remain legal within RFC 
3748, which is why there is no language in RFC 3748 indicating that they 
would be "badly behaved".

This is not an accident, and it is not something that should be "fixed".  It 
was a decision made by the EAP WG after very extensive discussion documented 
on the mailing list.

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

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

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Fri, 9 Mar 2007 20:50:46 -0800

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on
Thursday, March 08, 2007 10:53 PM:

> Please remember that the original EAP implementations were created
> for PPP, which provides for in-order delivery.  

I remember that quite well.  I'm also aware that PPP is, unfortunately,
all but obsolete.

> As a result, those
> implementations did not have a need to keep a duplicate cache as
> recommended in RFC 2865. 

But duplicate detection is also recommended in RFC 3568, no?  It doesn't
specify _how_ to do it, but neither does RFC 2865.  The point I've been
trying to make for the past three days or so & which I would think would
be uncontroversial is that from a specification point of view, EAP &
RADIUS are virtually identical WRT duplicate detection & in-order
delivery.  Apparently, RADIUS (mostly) works because of widely adopted
implementation decisions.  

> Given this, you cannot conclude that an implementation that would not
> detect a duplicate mingled with a new transmission would be badly
> behaved.  Those implementations were legal under RFC 2284, and they
> remain legal within RFC 3748, which is why there is no language in
> RFC 3748 indicating that they would be "badly behaved".    

"Legal" and "well-behaved" are two entirely different things.  Again, it
is possible to create a legal RADIUS implementation having _exactly_ the
same behavior as that ascribed to EAP, but it would hardly be considered
well-behaved.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap