On Nov 29, 2012, at 3:15 AM, Sam Hartman wrote: >>>>>> "Alper" == Alper Yegin <[email protected]> writes: > > Alper> Sam, If you search for the keyword "discard" in RFC 3748, you > Alper> see lots of instances. That's for "EAP layer discarding." > > BTW, thanks for this citation; it was useful. I had read most of the > text in question before and was in fact even aware of the behavior, but > for some reason didn't think of it as discarding.. I know, that makes no > sense at all: the spec calls it discarding. > > I think Jim's proposed fix for this is good. I just wanted to thank you > for helping me solve my confusion. >
No problem. But I don't understand how you think the text is good. Do you care to explain your views on the issues I raised below: Begin forwarded message: > From: Alper Yegin <[email protected]> > Subject: Re: [abfab] Retransmission Text for EAP applicability > Date: November 22, 2012 12:39:27 PM GMT+02:00 > To: Jim Schaad <[email protected]> > Cc: [email protected] > >>>> input, these methods discard the input rather than generating an error >>>> response. If the erroneous input was generated by an attacker, >>>> legitimate input can sometimes be received after the erroneous input. >>>> Applications MUST handle an EAP method discarding a message, although >>>> the specific way in which discarded messages will be handled depend on >>>> the characteristics of the application. >>> >>> Now, saying "MUST handle" and then leaving the way it's handled out-of >>> scope does not make sense. >> >> I think this makes perfect sense. We have just said that how it is going to >> happen - in fact what the correct response to happen - is going to be based >> on the specific application we are discussing. This means that we can't say >> what it should do. >> > > Why would the application care what happens when an EAP-layer or EAP > method-layer message is discarded? > If an EAP-layer message is discarded, it's for the EAP-layer to deal with > that. > If an EAP method-layer message is discarded, it's for the EAP method layer to > deal with that. > > If you are designing a protocol that needs to deal with what happens at 1 or > 2 layers above, then I'd say there's an issue with this design. > This is like saying, if HTTP discards a packet, then IP MUST handle this. > > >> Some applications will assume transmission error and send the fact that the >> EAP packet was not processed. (I kind of expect TEAP to do this behavior). >> >> Some applications will treat it as an Access-Fail and kill the whole >> process. >> >> We cannot dictate what the correct behavior should be. >> > > Because, that's not the business of this layer. Having a MUST w/o a clear > normative text and this explanation is the indication of the problem. Don't > you think? > >>> >>>> Options include >>>> failing the authentication at the application level >>> >>> This is problematic. If the EAP method has discarded the message, now you >>> need this be conveyed down the stack to the EAP lower-layer. This does not >>> happen today. And enforcing that requires changing existing EAP methods, >>> creating additional requirement on future methods. >> >> If I make a call to the EAP handler, it does not say that I got an >> Access-Accept or an Access-Reject, and it does not return anything for me to >> send back continuing the conversation. This sounds like a pretty good clue >> the packet was dropped on the floor given the lock-step behavior of EAP >> itself. >> > > Nope. Maybe the EAP method is awaiting an input from the user. The "EAP lower > layer" cannot know what's going on at the EAP method layer. > >> I don't see any need to change either current EAP behavior or future >> behavior. >> >>> >>>> and waiting for >>>> additional EAP input, possibly after an EAP retransmit. >>>> >>> >>> Who is retransmitting here? The EAP peer? If so, we need to clarify that. >> And >>> also described how the EAP peer decides to retransmit, and what it really >>> retransmits (the previous EAP response?). >>> >> >> That is going to be application specific behavior. In part it is going to >> depend on who dropped the message on the floor and who actually has the >> ability to even try and do the resend. Without knowing your application >> data flow, I cannot answer this question. >> > > The options provided by the text is ambiguous. > > >>> >>> Is this text meant to cover how the EAP conversation can be made reliable >>> with client-driven retransmissions? I see the implications of it, but not >> clear >>> and complete description of it. >> >> No. That may be one of the things that an application may define, but it is >> not required in any way. > > > I'd say if this text is meant to cover that possibility, then we need to make > it very clear. Otherwise, the text is rather vague… > > Alper >
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
