Subject: [Pana] Reliable delivery (AD comment)

From: "Alper Yegin" <[email-masked]>
Date: Sat, 10 Feb 2007 01:56:49 +0200

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 09 Feb 2007 21:00:11 -0500

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

---

From: Mark Townsley <[email-masked]>
Date: Wed, 14 Feb 2007 14:32:01 +0100

> 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.
> portion of the protocol (EAP payloaded) is trickier than letting the whole
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.
>    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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 20 Feb 2007 10:54:47 -0500

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