FYI, detailed analysis used when unreliable transport was originally chosen to carry EAP is available at:
http://www.panasec.org/docs/sequence-number.txt Basically two sequence numbers (tseq and rseq) were required in PANA header to carry EAP over an unreliable transport, in order to support orderly delivery and to deal with DoS attack on sequence numbers. As Alper mentioned, PANA messages that do not carry EAP needs reliability, but we realized that supporting only one transport mode (i.e., reliable mode) is much easier than supporting unreliable and reliable modes. Yoshihiro Ohba On Sat, Feb 10, 2007 at 01:56:49AM +0200, Alper Yegin wrote: > > 1. With the exception of EAP Success and Failure messages, there is no > > need to provide for reliable delivery (overlapping reliability in layers > > is generally considered a bad idea as well). In light of this, I wonder > > how PANA was ever designed to have reliability included for every > > message type? One suspect optimization, almost as an afterthought in the > > text, PANA allows "piggybacking" of EAP on a PANA answer message. This > > comes closer to the ideal attributes of an EAP transport as I read RFC > > 3748, but seems a bit kludged. Why not an unreliable PANA-Auth message > > type for all EAP messages except Success and Failure? > > > Further, why not let EAP do the retransmission for you? > > Let the PANA session start be, if you will, a slave to the EAP method > > and its handshake. Only until success or failure do you need to bring in > > retransmission to PANA. > > > We had originally started with an unreliable transport. We had resisted to > upgrading to a reliable transport for a while. But at some point keeping the > EAP transport unreliable became harder than letting it be reliable as well. > > Sorry, I cannot reconstruct detailed the history right now (maybe someone > else can), but looking at where we are I can say this -- a bit reverse > engineering: all the messages except EAP ones (PAR) expect a response. So, > they need retransmission anyways. Disabling reliable transport only for some > portion of the protocol (EAP payloaded) is trickier than letting the whole > protocol run reliably. > > RFC 3748 says: > > [1] Unreliable transport. In EAP, the authenticator retransmits > Requests that have not yet received Responses so that EAP does > not assume that lower layers are reliable. Since EAP defines its > own retransmission behavior, it is possible (though undesirable) > for retransmission to occur both in the lower layer and the EAP > layer when EAP is run over a reliable lower layer. > > ... > > When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as > within [PIC]), the authenticator retransmission timer SHOULD be set > to an infinite value, so that retransmissions do not occur at the EAP > layer. The peer may still maintain a timeout value so as to avoid > waiting indefinitely for a Request. > > > Alper > > > > _______________________________________________ > Pana mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
