Sam,

If you search for the keyword "discard" in RFC 3748, you see lots of instances. 
That's for "EAP layer discarding."

As for "EAP method discarding", Yoshi had already sent two examples on the 
mailing list: EAP-IKEv2, EAP-GPSK.

> This seems like a really bad idea in cases  where the timeout is
> infinite.

Like I explained before, this is not an issue "when EAP timeout is infinity, 
NAS performs rexmits".
It's an issue "when EAP timeout is infinity, client performs rexmits". 


Alper



On Nov 17, 2012, at 12:07 AM, Sam Hartman wrote:

>>>>>> "Alper" == Alper Yegin <[email protected]> writes:
> 
> 
> I'm not convinced it's appropriate for an EAP layer to discard when the
> 
> I'd like to see citations to discussion of discards hapeening at the EAP
> layer.
> 
> This seems like a really bad idea in cases  where the timeout is
> infinite.
> After we've reviewed any citations members can come up with I think
> we'll be in a better position to discuss whether there are any cases
> where it's appropriate for an EAP layer to discard in an application
> context.
> My inclination is that is not a good idea.
> 
> We disagree on this point.
> 
>>> Options include failing the authentication at the application
>>> level
> 
>    Alper> This is problematic. If the EAP method has discarded the
>    Alper> message, now you need this be conveyed down the stack to the
>    Alper> EAP lower-layer. This does not happen today. And enforcing
>    Alper> that requires changing existing EAP methods, creating
>    Alper> additional requirement on future methods.
> 
> As  I stated in the meeting, I claim that this does happen today with a
> number of common implementations.
> As an example, any EAP implementation designed to be used in an AAA
> server will make it quite apparent when a discard happens.
> On the peer side, you're right that you could design an EAP layer that
> did not make this clear.
> However from what I've looked at this is not an issue.
> 
> 
> 
> 
> --Sam

_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to