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

From: <[email-masked]>
Date: Fri, 11 Apr 2003 13:58:37 +0300

Hi Yoshi,

Your comments are good. The main question is if it would be benefical enough to use Diameter message formatting. Small comments inline.

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 10 April, 2003 21:10
> To: Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: Proposal for message formatting (sec. 9).
> 
> 
> Hi Dan,
> 
> On Wed, Apr 09, 2003 at 06:54:48PM +0300, 
> [email-masked] wrote:
> > 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)).
> 
> 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.

Yes two identifiers because two fields in the header, but it's similar to the case with one identifier. 

> > 
> > 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.
> 
> 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.
> 
> > 
> > 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.
> 
> 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.
> 

That's right. Because PaC and PAA are both able to do retransmissions (sending requests and waiting answers), both of them need to maintain their own ids. The difference with the dual seq case is acks.

> Yoshihiro Ohba
> 
> > 
> > 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: Yoshihiro Ohba <[email-masked]>
Date: Mon, 14 Apr 2003 17:33:05 -0400

Hi Dan,

> Your comments are good. The main question is if it would be benefical enough to use Diameter message formatting. Small comments inline.

I basically agree on using Diameter formats for PANA.  However, I
think we need to resolve assignment policies for AVP Code, Command
Code and Command Flags and AVP flags.

For example, is the AVP Code space shared between Diameter and PANA,
or unique to each protocol, or partially shared between the two?  In
other words, if PANA defines a new AVP that is specific to PANA with
AVP Code = X, then does it mean Diameter cannot assign X for a new AVP
for Diameter?  The same issue exists for Command Code, Command Flags
and AVP flags.

Yoshihiro Ohba