Re: Ordered delivery of EAP message

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

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

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