Subject: RE: Proposal for message formatting (sec. 9).

From: <[email-masked]>
Date: Wed, 9 Apr 2003 18:54:48 +0300

Julien,

You're right! As the introduction says it would be great if we could use Diamter message processing as much as possible. I thought that maybe we should make the App-Id field reserved, but then, the App-Id can actually help the Diameter stack to recognize PANA application and thus if possible to process the Hop-by-Hop and End-to-End Ids differently (tseq and rseq). Of course there is UDP protocol and port number to make a difference, but this helps in the application layer.

but I would actually like to go even further..

We could use the Diameter header as it is together with PANA layer retransmissions ALSO for PANA-Auth-Request/Answer packets. Hop-by-Hop and End-to-End Ids provide replay protection and duplicate detection together with in sequence delivery. Currently PANA does it for all other but PANA-Auth-Request/Answer messages, which makes the layer architecture not so sound (This is now a problem anyway if EAP Server doesn't do retransmissions in the backend AAA infrastructure (dependancy)).

The reason we didn't take this step during the design team lifetime was that we didn't know if EAP was truly lock-step safe (request/response protocol and only one pending request at a time). In the IETF56 EAP meeting it became clear that EAP is truly lock-step safe, even with EAP notifications, and thus the reasoning in the Appendix A of pana-pana-00 draft doesn't hold anymore. Even the EAP-Success/Failure gets a response in PANA.

Additional benefit in this approach is simplicity and a good resistance to blind DoS attacks: peer accepts only new requests that have the Hop-by-Hop Id increased by one. No need for accept windows etc. In case of a retransmission, peer gets the same packet again with exactly the same HbH Id, which means that the other peer didn't get the answer in time (can happen with user input for example) or it was lost (unrealiable link layer). 

PAA initializes its Hop-by-Hop Id in the beginning. PaC does the same when it first sends a request to PAA (PANA-Reauth-Request). In case of no MAC, PAA may want to know beforehand what Id the Request must contain (defence against DoS attack in PAA). PaC can send its initial Hop-by-Hop Id in a Initial-Hop-By-Hop-Id AVP in the PANA-Success-Answer message, for example. Or optionally in the PAA-Discover message. PAA then knows that the first PANA-Reauth-Request message from PaC must contain this Id.

Let me hear your comments.

- Dan

> -----Original Message-----
> From: ext Julien Bournelle [mailto:[email-masked]]
> Sent: 09 April, 2003 17:37
> To: Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: Proposal for message formatting (sec. 9).
> 
> 
> Hi,
> 
>  after a really quick look, I have a comment. Please see below,
> > 
> > 9.1  PANA Header
> > 
> >    A summary of the PANA header format is shown below.  The 
> fields are
> >    transmitted in network byte order.
> > 
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> 6 7 8 9 0 1
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |    Version    |                 Message Length      
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |    Flags      |                 Message Type        
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                   Application-ID                    
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                 Transmitted Sequence Number         
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                 Received Sequence Number            
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |  AVPs ...
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-
> > 
> >    Application-ID
> > 
> >       Application-ID is four octets and is used to identify to which
> >       application the message is applicable for.  The Application-ID
> >       for PANA is <TBD>.
> 
> I know that Diameter has this fields to distinguish between 
> his various
> applications but PANA doesn't need this field to work. Am I wrong ?
> 
> Do we add it just for simplify PANA/Diameter cooperation ?
> 
> --
> [email-masked]
> 
>

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 10 Apr 2003 11:08:50 +0200

Hi, 

thanks for your reply,

please see comments below,

> You're right! As the introduction says it would be great if we could use Diamter message processing as much as possible. I thought that maybe we should make the App-Id field reserved, but then, the…

I agree with you that it is a good idea to re-use Diameter Header for
PANA to ease cooperation  and that tseq and rseq fields fit well with
hoy-by-hop id and end-to-end id. Of course, it remains the App-Id field and we can
use it the way you propose but it just seems weird for me to "add" a field in 
the PANA header "just" for Diameter. Basically, I'm not against it but
I wanted to know how others (and you :-) feel about that.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 10 Apr 2003 14:09:41 -0400

Hi Dan,

> We could use the Diameter header as it is together with PANA layer retransmissions ALSO for PANA-Auth-Request/Answer packets. Hop-by-Hop and End-to-End Ids provide replay protection and duplicate d…

I guess you mention yet another scheme that uses two identifiers with
PANA layer retransmission but is not described in Appendix.  If so,
I'm not sure what "this step" in the sentence below means.

> The reason we didn't take this step during the design team lifetime was that we didn't know if EAP was truly lock-step safe (request/response protocol and only one pending request at a time). In th…

EAP is now lock-step for Request/Response exchanges, but the lock-step
characteristic does not hold for EAP Success/Failure message, i.e.,
EAP Success/Failure message may be sent from an EAP authenticator even
when the authenticator does not receive the Response to the
outstanding Request.  The following reasoning for "single sequence
number with PANA-layer retransmission" method in the Appendix A.2.2
still holds when the new EAP message is Sucess/Failure:

   Another problem occurs when a new EAP message overrides the
   outstanding EAP Request, the PaC cannot assume any more that the 
   sequence number of the next message to be accepted is the last
   accepted message + 1.  So the PaC needs to accept a range of
   sequence numbers, instead of a single sequence number. These two 
   additional things would increase the complexity of this method. 

On the other hand, the following reasoning for "single sequence number
with PANA-layer retransmission" method does not hold any more, since
the EAP-Success/Failure gets a response in PANA.

   This would require 
   timer-based retransmission not only at PaC side but also at PAA 
   side. 

I will revise the Appendix in the next version of specification.

> PAA initializes its Hop-by-Hop Id in the beginning. PaC does the same when it first sends a request to PAA (PANA-Reauth-Request). In case of no MAC, PAA may want to know beforehand what Id the Requ…

I think the scheme you mention actually needs to maintain four
identifiers: Hop-by-Hop Id and End-to-End Id for PANA requests sent by
PAA and Hop-by-Hop Id and End-to-End Id for PANA requests sent by PaC.
Is this correct?  If this is correct, the scheme seems to be no
simpler than the current scheme that maintains two identifiers.

Yoshihiro Ohba

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 14 Apr 2003 13:47:06 +0200

hi all,

i have placed some open issues on the following web page:
http://www.tschofenig.com/pana/issues_list.html

please take a look at it and send comments to the list.

i will move the open issues into dan's issue list format once he has
finished it.

ciao
hannes