> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Alper Yegin > Sent: Friday, November 16, 2012 3:58 PM > To: Sam Hartman > Cc: [email protected] > Subject: Re: [abfab] Retransmission Text for EAP applicability > > 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".
The NAS can only do a retransmit if it is involved in an async protocol. If it is in a sync protocol then the token needs to be passed back to the NAS in order for it to do the retransmit. If this does not happen then you will be in a dead-lock situation. Jim > 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
