eap Mailing List: Re: Ordered delivery of EAP message

[Glen Zorn (gwz) (gwz]

Bernard Aboba <mailto:bernard_aboba [at] hotmail.com> allegedly scribbled on
Thursday, March 08, 2007 10:53 PM:

> 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.  

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.