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.
This seems very surprising. But in any case, it is not just a matter of
it being difficult or easy, if you layer reliable protocols on top of
one another, you run into well known transport problems. Sometimes, we
let this happen and hope to mitigate the problems by tweaking
retransmission timeouts, but this is just punting the problem from the
protocol to the operator of the protocol. I can understand why something
that relies on generic TCP may have to resort to this, but since you are
building your own *custom* transport for EAP, It really should address
reliability in the most ideal manner for EAP.
I'm cc'ing the transport ADs here. There are aspects of PANA that could
probably use the help of a transport specialist.
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.
I understand it may be tricky, and if you were creating a generic
transport protocol I might agree, but you are creating a custom-built
protocol for EAP, I think you should be able to do better than this. I'm
not transport specialist, but I believe things like SCTP get this right
(a mode for reliable and unreliable delivery of packets, perhaps even
with sequencing protection for both) so I'm not sure why you could not.
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.
OK, if EAP can innately turn off reliability for all methods, and the
group considers this an acceptable burden to place on the EAP nodes,
then at least it does no harm. The PANA document should at a minimum
state this clearly, referring back to RFC3748. I would consider this a
bit of a failing though - as I said, one has an excuse when reusing a
generic transport like TCP, but when defining your own custom
transport?? Very surprising.
- Mark
Alper
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
