Subject: Re: [Pana] Re: Reliable delivery (AD comment)

From: Mark Townsley <[email-masked]>
Date: Mon, 05 Mar 2007 12:06:40 +0100

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-masked]
>> https://www1.ietf.org/mailman/listinfo/pana
>>
>>     
>
>   

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Mark Townsley <[email-masked]>
Date: Mon, 05 Mar 2007 17:43:05 +0100

Bernard Aboba wrote:
>> enabled). 
> I know of at least one  L2TP implementation that does check sequence 
> numbers when EAP is being used. 
>   
I know of many that *can* by configuration. I also know that this is 
commonly turned off in deployment. Sad, but true.
>   
>> I suspect that 802.1x makes the same assumption that EAP
> Yes, IEEE 802.1X assumes that IEEE 802 ordering guarantees are provided 
> (e.g. no reordering within an 802.1p priority).  
>   
Thanks for the confirmation.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Thu, 08 Mar 2007 17:31:44 +0100

Bernard Aboba wrote:
> After some substantial discussion on the EAP and RADEXT WG lists, I think 
> we have concluded that since EAP is an ACK/NAK protocol, if the lower 
> layer transport provides for duplicate detection then it will also 
> provide for in-order delivery of EAP packets. 
>   
Thank you, this is rather significant. In fact, perhaps it should be a 
part of an update to RFC3748.

- Mark
> For example, RADIUS meets the ordering requirement even though it offers 
> only simple minded UDP transport, assuming that the RADIUS server 
> implements a duplicate detection cache as described in RFC 2865. 
>
>

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 8 Mar 2007 20:19:58 -0800

Mark Townsley (townsley) <> allegedly scribbled on Thursday, March 08,
2007 8:32 AM:

> Bernard Aboba wrote:
>>>>> 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.
>>>>> 
>> 
>> After some substantial discussion on the EAP and RADEXT WG lists, I
>> think we have concluded that since EAP is an ACK/NAK protocol, if the
>> lower layer transport provides for duplicate detection then it will
>> also provide for in-order delivery of EAP packets.
>> 

Hmm, that's not at all the conclusion that I have reached.  My
conclusion (based upon the actual text of the relevant RFCs rather than
anecdotal evidence regarding "well-behaved" RADIUS implementations) is
that "well-behaved" EAP implementations do NOT require duplicate
detection in the transport any more than do "well-behaved" RADIUS
implementations.  If I understand the pathological case used to justify
the "MUST" requirement for transport layer duplicate detection in RFC
3738, one simple scenario that satisfies the case looks like this:

Peer                                           Authenticator
----                                           -------------
                                    <--        Send: Request1,
Identifier=0
                                    <--        Send: Request2,
Identifier=0 (retransmission)
Recv: Request2, Identifier=0
Send: Response, Identifier=0       -->  
                                               Recv: Response,
Identifier=0
                                    <--        Send: Request,
Identifier=1
Recv: Request, Identifier=1   
Send: Response, Identifier=1        -->
                                               Recv: Response,
Identifier=1
Recv: Request1, Identifier=0
                                    
If you like, replace "peer" with "client" and "authenticator" with
"server" & apply this same scenario to RADIUS, since  UDP doesn't
guarantee in order delivery any more than RADIUS does.  As Bernard has
pointed out, RADIUS works fine if an implementation obeys certain
constraints, none of which are required by the standard.  RFC 3748
mentions most of the same constraints & should exhibit the same
behavior.

> Thank you, this is rather significant. In fact, perhaps it should be
> a part of an update to RFC3748. 
> 
> - Mark
>> For example, RADIUS meets the ordering requirement even though it
>> offers only simple minded UDP transport, assuming that the RADIUS
>> server implements a duplicate detection cache as described in RFC
>> 2865. 
>> 
>> 
>

---

From: Mark Townsley <[email-masked]>
Date: Fri, 09 Mar 2007 12:44:21 +0100

Bernard Aboba wrote:
>> Thank you, this is rather significant. In fact, perhaps it should be a part of
>> an update to RFC3748.
>>     
>
> I am not seeing a clamour for an update to RFC 3748, frankly.  Or do I 
> sense a hidden agenda?
>   
No hidden agenda. Just that RFC3748 makes some statements about what EAP 
needs in terms of its transport, and since we see EAP over UDP/IP, 
IKE/TCP, Ethernet, PPP, etc...  those statements should be as accurate 
as possible lest people needlessly over-design their protocols. We may 
find that PANA is a case in point.

- Mark

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 09 Mar 2007 11:24:46 -0500

On Fri, Mar 09, 2007 at 08:00:34AM -0800, Bernard Aboba wrote:
> > No hidden agenda. Just that RFC3748 makes some statements about what EAP needs
> > in terms of its transport, and since we see EAP over UDP/IP, IKE/TCP,
> > Ethernet, PPP, etc...  those statements should be as accurate as possible lest
> > people needlessly over-design their protocols. We may find that PANA is a case
> > in point.
> 
> Based on the discussion, if PANA were to implement a transport providing 
> for duplicate detection within a window, then this would also provide an 
> ordering guarantee for EAP packets, since EAP is an ACK/NAK protocol.
> 

But lower layer still needs to be a ACK/NAK protocol like RADIUS, right?

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 9 Mar 2007 19:37:15 -0800

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on
Thursday, March 08, 2007 10:26 PM:

>> My conclusion (based upon the actual text of the relevant RFCs rather
>> than anecdotal evidence regarding "well-behaved" RADIUS
>> implementations)
> 
> RFC 2865 already recommends behavior that prevents out-of-order
> delivery. 

Actually, it doesn't.  As I have pointed out repeatedly , the semantics
of the Identifier in RADIUS & EAP are identical.  

> A proposal to strengthen that to a MUST is on the table.  From what I
> can tell, this resolves the issue for RADIUS. 
> 
>> implementations.
> The difference between RFC 3748 and 2865 is that 3748 does not
> recommend a duplicate cache of substantial duration.  

Hmm.  I don't really consider "a short period of time" to convey any
meaningful sense of duration; in any case, see below.

> That makes a
> difference if a duplicate is intermingled with a new packet.  

I believe that the packet flow which I gave in an earlier message
illustrated that a timer-based algorithm is insufficient for duplicate
detection in both RADIUS and EAP if the identifier is allowed to simply
"change" between exchanges.  In fact, I think that timers are
unnecessary: all that is needed to solve the problem is to specify the
semantics of the Identifier to be those of a sequence number with
roll-over.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 9 Mar 2007 23:44:50 -0500

> semantics of the Identifier to be those of a sequence number with

I agree, and that is what PANA is doing with sequence number.

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 9 Mar 2007 20:57:03 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Friday, March 09, 2007 8:45 PM:

>> illustrated that a timer-based algorithm is insufficient for
>> duplicate detection in both RADIUS and EAP if the identifier is
>> allowed to simply "change" between exchanges.  In fact, I think that
>> timers are unnecessary: all that is needed to solve the problem is
>> to specify the semantics of the Identifier to be those of a sequence
>> number with roll-over. 
>> 
> 

That's fine, but personally I think that it's just good protocol design
to reduce the coupling between layers to the bare minimum required.  RFC
3748 has to its credit the fact that it made explicit the dependency of
EAP upon the delivery characteristics of PPP that were implicit in RFC
2284; unfortunately, it leaves that dependency in place even though a
fix is easy enough.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 9 Mar 2007 23:35:01 -0800

Mark Townsley (townsley) <> allegedly scribbled on Friday, March 09,
2007 3:44 AM:

>> I am not seeing a clamour for an update to RFC 3748, frankly.  Or do
>> I sense a hidden agenda? 

I don't think that it's really necessary to revise RFC 3748; however, I
would like very much to see a BCP on EAP implementation guidelines
describing these issues & recommending solutions.  

...