> 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
