Thank you for this background.
Let me try and summarize your main points:
1. PANA must have a reliable transport option for some set of messages
2. Creating an unreliable transport with packet order preservation over
IP adds significant complexity due to the overhead needed to prevent DOS
attacks.
So, the conclusion was to simply run EAP over a reliable transport and
adjust the timers in EAP accordingly. Much like EAP over IKE/TCP, if I
may use this comparison. EAP over PPP, of course, didn't have this issue
as PPP delivers packets in order (aside of the minor complication that
EAP over PPP/L2TP/IP commonly runs with no sequence number checking
enabled). I suspect that 802.1x makes the same assumption that EAP
frames on a LAN segment will be delivered in order.
Yoshi, your comparison to SCTP is well done, but I'd like to hear from
one of the transport ADs here. Is creating an unreliable, sequenced,
transport that is resilient to DOS attacks that difficult? Are there
some tricks that we might not be aware of here?
Thanks,
- Mark
Yoshihiro Ohba wrote:
> Let me analyze the current PANA design, the old PANA design and SCTP.
>
> The current PANA design is based on reliable and sequential delivery
> for all messages except for PCI.
>
> The old PANA design was based on unreliable and sequential delivery
> for messages that carry EAP. For other messages, it was trying to
> support reliable and sequential delivery, but we switched to the
> current PANA design before investigating the complexity of supporting
> dual mode (reliable-sequential mode and unreliable-sequential mode) in
> details. Here I am trying to continue the investigation of the old
> PANA design.
>
> One issue on supporting dual mode is blind DoS attacks on sequence
> numbers. Since any such one way message can be lost, the receiving end
> should be ready to accept any incoming sequence number (as if all the
> previous ones were lost). That opens up the DoS attack. That is why
> the old PANA design had rseq (receiving sequence number) in addition
> to tseq (transmission sequence number). In fact, rseq is piggybacked
> acknowledgment for tseq. (Selective) acknowledgment functionality of
> SCTP has the same effect in term of DoS attack resilience.
>
> Another issue on supporting dual mode is that we need an additional
> sequence number ("request id") for matching requests and answers for
> supporting reliability, because tseq/rseq that is used for sequential
> delivery and has nothing to do with reliability. The "request id" is
> not incremented for retransmitted requests tseq is still incremented
> for any PANA message.
>
> In SCTP, packets that carry user data has two sequence numbers, i.e.,
> TSN (transmission sequence number) and stream sequence number (see
> also the format below). TSN is unique across multiple data streams
> whereas stream sequence number is unique within a particular data
> stream. TSN is used for reliable delivery based on selective
> acknowledgment (SACK) without taking care of sequential delivery. On
> the other hand, stream sequence number is used for sequential delivery
> without taking care of reliability. The combination of TSN and stream
> sequence number can realize combinations of reliable/unreliable and
> ordered/unordered delivery modes. SCTP-PR (partial reliability)
> extension is applied to TSN such that the sender can notify the
> receiver to advance the receiving window when outstanding messages are
> no longer important to the application.
>
> Basically the combined usage of tseq, rseq and "request id" in the old
> PANA design could be comparable to the combined usage of TSN, SACK and
> stream sequence number (role of each parameters are different between
> the two protocols). If we go down this road, then protocol complexity
> of PANA in terms reliability and sequential delivery would be similar
> to SCTP.
>
> On the other hand, if we support only reliable and sequential delivery
> for all PANA messages (the way the current specification does), then
> the design would be simpler than SCTP in terms of the number of
> control parameters (only TSN is needed). This is natural because only
> one transport mode needs to be supported. In addition, it eliminates
> the need for EAP-layer retransmission which can be end-to-end.
>
> I believe that the current PANA design is superior to the old PANA
> design in terms of both complexity and efficiency. Note also that the
> current PANA design is similar to IKEv2 from EAP transport
> perspective.
>
> Regards,
> Yoshihiro Ohba
>
>
>
> On Wed, Feb 14, 2007 at 02:32:01PM +0100, Mark Townsley wrote:
>
>> 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
>>
>>
>
>
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
