Subject: RE: question: pana messaging

From: <[email-masked]>
Date: Tue, 15 Apr 2003 09:42:50 +0300

Hi,

The generic message that can be sent to both directions is PANA-Reauth-Request(/Answer). PANA-Start-Request/Answer message pairs are unidirectional because of the cookie stuff. Currently, PAA initiates authentication with PANA-Auth-Request, thus the direction. It's easier to create the state machines, when message sequences are clear and simple. Current PANA draft states that PaC unicasts discovery message to PAA, even it knows the address of the PAA.

More comments inline.

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 15 April, 2003 02:42
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: question: pana messaging
> 
> 
> Hi Hannes,
> 
> On Mon, Apr 14, 2003 at 02:52:37PM +0200, Hannes Tschofenig wrote:
> > hi all,
> > 
> > the pana draft describes some messages. these messages have 
> a certain
> > semantic and are in most cases directional e.g.
> > 
> >       PANA-Start-Request       <--------
> >       PANA-Start-Answer        -------->
> > 
> >       PANA-Auth-Request        <--------
> >       PANA-Auth-Answer         -------->
> > 
> > why isn't it possible to use these messages in both 
> directions? it would be
> > good to have a generic message which can be executed from 
> both entities (pac
> > and paa) especially with respect to extensibility.
> > 
> > furthermore, if the pac is preconfigured with the address 
> of the paa then
> > there is no need for a discovery message. hence the 
> PANA-Start-Request (or
> > better the PANA-Auth-Request) could go from the pac to the 
> paa. currently
> > the cookie stuff mandates a certain direction (thank you 
> dan for pointing to
> > this issue).
> 
> Even if the PaC is preconfigured with the address of the paa,
> cookie-based 3-way handshake is needed to avoid resource consumption 
> attacks during the handshake phase.  Currently this is done by 
> discovery/start(-req)/start(-ans) message and I don't think 
> we can omit 
> these exchanges when the PAA does not have any state for the 
> PaC before 
> the handshake.
> 
> On the other hand, we can omit some of the messages at the time of
> EAP-based re-authentication in whiich the PAA already has a state for
> the PaC.  It looks like:
> 
>    PaC      PAA  Message(tseq,rseq)[AVPs] 
>    ----------------------------------------------------- 
>    // Discovery and initial handshake phase 
>       ----->     PANA_discover(0,0) 
>     
>    // Authentication phase 
>       <-----     PANA_auth(p,q)[EAP, MAC]     // or PANA-Auth-Request 
>       ----->     PANA_auth(q+1,p)[EAP, MAC]   // or PANA-Auth-Answer
>         .
>         .
> 
> where the sequence numbers continue from the previous message exchange
> instead of being started from fresh ones.  If EAP-based
> re-authentication is initiated from PAA, the first discover message is
> not needed.
> 
> We can add this optimized behavior to section 4.4.

For me this is session resumption and adds a new feature to the PANA protocol. This may be useful in some cases. In this case the SA is still alive between PaC and PAA, but the reauthentication messages are not sent anymore? Thus, the EP may be blocking traffic from PaC.. session resumption is a fast way to enable network access again, without full handshake and AAA backend involvement? Security aspects? This is similar to TLS.

> > 
> > here are my questions:
> > a) should we add a message to carry AVPs in both directions?
> 
> So far I don't see a requirement for this.

PANA-Reauth-Request.
 
> > c) should we optimize signaling if the pac is already 
> configured with the ip
> > address of the paa?
> 

Cookie stuff doesn't make life easy with this.

> I would say that we should optimize signaling when the PAA 
> has already a
> state for the PaC regardless of whether the PaC is already configured
> with the IP address of the PAA.
> 
> > 
> > please read the pana draft and verify that the signaling 
> message handling
> > works in all your  scenarios.
> > 
> > ciao
> > hannes
> > 
> > 
> 
> Yoshihiro Ohba
> 
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 16 Apr 2003 15:19:22 +0200

hi dan,

thanks for your comments.

using the PANA-Reauth-Request(/Answer) for AVPs which could be exchanged in
both directions seems to be fine for me.

eap-based re-authentication. we once mentioned that there are two possible
ways to provide re-authentication.

a) MAC-AVP. this is fine and works well for refresh messages to keep state
alive.

b) EAP-based reauth.

as yoshi said it might be good to have a possibility to trigger a
reauthentication exchange without requiring the discovery/cookie stuff todo
again.

ciao
hannes

> From: [email-masked] [mailto:[email-masked]]
> Sent: Dienstag, 15. April 2003 08:43
> To: [email-masked]; [email-masked]
> Subject: RE: question: pana messaging
>
>
> Hi,
>
> The generic message that can be sent to both directions is
> PANA-Reauth-Request(/Answer). PANA-Start-Request/Answer message
> pairs are unidirectional because of the cookie stuff. Currently,
> PAA initiates authentication with PANA-Auth-Request, thus the
> direction. It's easier to create the state machines, when message
> sequences are clear and simple. Current PANA draft states that
> PaC unicasts discovery message to PAA, even it knows the address
> of the PAA.

> For me this is session resumption and adds a new feature to the
> PANA protocol. This may be useful in some cases. In this case the
> SA is still alive between PaC and PAA, but the reauthentication
> messages are not sent anymore? Thus, the EP may be blocking
> traffic from PaC.. session resumption is a fast way to enable
> network access again, without full handshake and AAA backend
> involvement? Security aspects? This is similar to TLS.
>
>
> > >
> > > here are my questions: