Subject: [Pana] Mobility Handling in PANA

From: Giaretta Gerardo <[email-masked]>
Date: Fri, 09 Jul 2004 10:24:46 +0200

Hi all,

I'd like to bring up a discussion regarding mobility handling in PANA. 

Section 4.9 in PANA Protocol draft describes this procedure:

- PaC sends a PSA with the old session-id and a MAC AVP calculated using
the old PANA_MAC_key (shared between the PaC and the pPAA)
- nPAA retrieves the pPAA's address from the session-id 
- nPAA provides in some way (TBD) this PSA to the pPAA. 

A possibility stated by the dratf is the usage of CTP. The PANA draft
does not specify how CTP could be used. However, I think that in this
scenario the only way to trigger the context tansfer is that the nPAA
sends a CT-Req to the pPAA. There are two issues here: this CT-Req
message does not contain the previous IP address of the PaC and the
Authorization Token. 

A different approach is provided in
http://www.ietf.org/internet-drafts/draft-bournelle-pana-ctp-00.txt.
This is the procedure we propose in this draft: 

- PaC sends a PSA with a CTAR in a new PANA AVP. This PSA does not
contain any MAC AVP. The CTAR includes an authorization token calculated
with a new key (PANA-CTP-Key) and the pPAA's address. 
- nPAA sends a CT-Req (including the authorization token and the
previous PaC's IP address carried by CTAR message)
- pPAA verifies the authorization token and (if it is correct) sends the
CTD with the PANA context
- nPAA sends a PBR with the new Session-id and a nonce to derive the new
AAA-key. This message includes a MAC AVP calculated using the new
PANA_MAC_Key
- PaC replies with a PBA

Comments?

--Gerardo

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================
_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 10 Jul 2004 02:27:38 -0400

Hi Gerardo,

I have a couple of comments on draft-bournelle-pana-ctp-00.txt.

[1] In predictive mode of the proposed scheme, is a CTAR message carried
in a PANA message sent from a PaC to pPAA?  If so, which PANA message
is used and how?  

[2] I think it is also possible to run the MN-AR context transfer
protocol to carry CTAR messages between MN and nPAA (or pPAA) instead
of piggybacking CTAR messages in PANA messages.  For example something
like this in the case of non-predictive mode:

   PaC           nPAA              pPAA
   ----------------------------------------
         CTAR 
   --------------->       CT-Request 
                        ------------>
                             CTD 
                        <------------

         PSR
   <---------------
    PSA[old Session-ID, Nonce]   // MAC AVP is not needed.
    --------------->
    PBR[new Session-ID, Key-Id, Nonce, PPAC, MAC]
   <-------------
    PBA[new Session-ID, Key-Id, PPAC, MAC]
    ------------->

This has half round-trip redundancy compared to your proposal (due to
non-piggybacking CTAR), but provides better modularity between PANA
and Context Transfer Protocol.  Also this works with both
non-predictive and predictive modes.

[3] In CTD-PANA message, I think ISN-pac, ISN-paa, tseq and rseq do
not have to be defined in CTD-PANA, because sequence number contexts
are not inherited from the pPAA (i.e., new sequence number context is
established in the PSR-PBA exchange between PaC and nPAA).  Also, I
think retransmission interval does not need to be defined in CTD-PANA,
since retransmission interval can be locally determined parameter.

Regards,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 11 Jul 2004 20:11:56 -0400

Hi Gerardo,

Another comment on draft-bournelle-pana-ctp-00.txt:

I am not sure how EAP-based re-authentication can work after the PaC
has successfully established a new PANA session with nPAA based on the
mobility optimization operation, especially with NAP and ISP separated
authentications.  Since PSR-PSA exchange is omitted in the case of
EAP-based re-authentication, there is no means to negotiate on NAP and
ISP separate authentications between the PaC and nPAA.  Do you have
any thoughts on this?

BTW, in my previous comment [2], A MAC AVP was needed in PSA in the
diagram.

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 12 Jul 2004 12:18:04 +0200

Hi yoshi,

 thanks for your comments.

 see my response inline

> in a PANA message sent from a PaC to pPAA?  If so, which PANA message

basically, we had in mind to use CTAR message as specified in CTP. In
other words, for predictive handover we do not use PANA message.

> like this in the case of non-predictive mode:

The problem in this case is that the nEP will detect the CTAR message
and trigger a PANA authentication message. This means that in the same
time, we will have a PSR/PSA exchange and CT-Request/CTD. We can't
decorrelate PANA and CTP.

In my mind, when the pana module at pac receives a psr message it asks
the ctp module to provide the CTAR message. Thus we keep the
modularity.

> since retransmission interval can be locally determined parameter.

I guess you are right. We'll delete those parameters in the next
revision.

-- 
[email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Jul 2004 07:19:07 -0400

Hi Julien,

Thanks for your reply.  Please see my comment on [2].

> the ctp module to provide the CTAR message. Thus we keep the

Something like this?

    PaC           nPAA              pPAA
          PDI
     -------------->
          PSR
    <---------------
          CTAR
     --------------->

                          CT-Request 
                       -------------->
                              CTD 
                       <--------------

     PSA[old Session-ID, Nonce, MAC]
     --------------->
     PBR[new Session-ID, Key-Id, Nonce, PPAC, MAC]
    <-------------
     PBA[new Session-ID, Key-Id, PPAC, MAC]
     ------------->

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 12 Jul 2004 13:37:52 +0200

comments inline,

> > the ctp module to provide the CTAR message. Thus we keep the

if you do this, this means that the pac answers to a PANA message (PSR)
with a CTP message (CTAR). Moreover the nPAA waits for PSA message and
not for a CTP message. So at the nPAA, you receive a CTP message whereas
you are waiting for PANA message. 

This is why we propose to emebed the CTAR message in the PSR message.
Thus the pac answers with a PSA message. The PANA module at the pac aks
to the CTP module to get a valid CTAR message and embeds it in the PSA
message. The nPAA receives the PSA message that it is waiting for and
sees that it contains a CTAR message. It delivers it to its CTP module
and waits the CT-Request/CTD exchange. This why we introduce a new state
in the state machine (PANA-CTP-WAITING)

Thus we propose this:

     PaC           nPAA              pPAA
     ----------------------------------------
           PDI
      -------------->
           PSR
     <---------------
          PSA [old Session-ID, Nonce, CTAR] 
      --------------->
 
                           CT-Request 
                        -------------->
                               CTD 
                        <--------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Jul 2004 08:34:04 -0400

Hi Julien,

> you are waiting for PANA message. 

Since PANA and CTP are different protocols, I think nPAA can wait for
messages from both protocols at the same time without violating both
protocols.  But parhaps it is better in this case that CTAR is
acknowledged with CTAA and the PaC sends PSA after receiving CTAA to
provide synchronization bewteen context transfer operation and PANA
mobility optimization, something like:

PaC           nPAA              pPAA
      CTAA
 <--------------

Comparing this scheme with your scheme below, the discussion point
would be modularity (this sheme) vs optimization (your scheme).

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 12 Jul 2004 16:37:02 +0200

> mobility optimization, something like:

I think that with our solution we keep the modularity since the pana
module asks to the ctp module the CTAR message to be sent.

In your scenario, the PANA module at PaC receives the PSR message and
contacts the CTP module (saying that CTP module must sent a CTAR).
In our scenario, the PANA module asks to the CTP module the CTAR
message and embeds it. Thus I think that we keep the modularity.

Maybe I miss something, what do you mean by modularity ?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Jul 2004 18:27:45 -0400

Hi Julien,

I just meant "not piggybacking other protocol messages" by modularity.
I think both non-piggybacking and piggybacking schemes should be
allowed in the design.  Non-piggybacking scheme allows other mobility
optimization schemes also to be used by PANA, while piggybacking
scheme provides optimization for a particular mobility optimization
scheme.

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 13 Jul 2004 15:25:42 +0200

hi yoshi,

> I just meant "not piggybacking other protocol messages" by modularity.

I understand your point.
At the beginning, we thought about this approach but as the nPAA sends a
PANA message, we wanted to answer with a PSA message and not a CTAR
message.

> scheme

do you think that we could live with the 2 options running in the same
time ? 

.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 13 Jul 2004 14:28:50 -0700

>      PaC           nPAA              pPAA

This is the flow I had in my mind, but I don't see the need to have an
explicit CTAR AVP in the PSA.

Looking at the draft, CTAR carries:
- PaC's address. Why do we need this? The Pac is identified with its
session id.
- PAA's address. I don't think we need this either. Session id reveals
the ID of the pPAA. It's just a matter of mapping that to an IP address
(use DNS).
- Authorization token. MAC AVP already does the job.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Jul 2004 15:45:45 -0400

> do you think that we could live with the 2 options running in the same

If the PAA supports both methods, the 2 options should work at the
same time.  If a PaC supports non-piggybacking CTAR, then context
transfer completes before the a PAA receives a PSA.  When the PAA
receives the PSA, the PAA tries to retrieve a new AAA-Key locally from
its context transfer module to generate a PBR.  On the other hand, if
a PaC supports piggybacking CTAR, then the PAA passes the CTAR to the
context transfer module and waits for the context transfer operation
to complete.  Once the context transfer operation completes, the PAA
retrives a new AAA-Key from the context transfer module and generates
a PBR.

Yoshihiro Ohba