Subject: [Pana] Issue 143: CTP and PANA editorial clarification

From: Alper Yegin <[email-masked]>
Date: Wed, 17 Nov 2004 13:49:38 -0800

http://danforsberg.info:8080/pana-issues/issue143

The PaC DOES have an active role in PANA mobility optimization. It
conveys its desire to use CTP by including its session ID in the
PANA-Start-Answer. This is not CTAR, but this is an explicit "message".

This is a CTP (draft-ietf-seamoby-ctp-11.txt) design issue. I recommend
this be fixed in seamoby-ctp, or another simple CTP can be designed. I
don't think we shall morph PANA solution to fit the seamoby-ctp design
(which I think has some room for improvement -- as PANA example shows). 

The PANA spec states seamoby-ctp MAY be useful, it does not mandate its
use. 

Regarding CTP module vs. PANA module, I think this is an implementation
issue. One module needs to talk to the other, and there needs to be
interface between the two.

So, I recommend we reject this issue.

Alper

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 17 Nov 2004 17:34:03 -0500

Hi Alper,

There are a couple of people (including myself) who think this
mobility section can be improved to be flexibile enough to support
future CTP protocol changes and any other mobility optimization
scheme.  I will submit suggested text soon.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 17 Nov 2004 15:36:21 -0800

Yoshi,

OK, please send in the proposal.

There are various possible solutions. I prefer to have one basic
approach in the base spec, with an open door for others defined
elsewhere (base spec shall not have all possible schemes). If you can
come up with a more generic/flexible solution while keeping the
complexity well-contained, that's welcome.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Yoshihiro Ohba
> Sent: Wednesday, November 17, 2004 2:34 PM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: [Pana] Issue 143: CTP and PANA editorial clarification
> 
> Hi Alper,
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Nov 2004 02:53:59 -0500

This is the proposal for mobility section as the outcome of private
discussion (started after the PANA meeting in IETF61) among Rafa Marin
Lopez, Giaretta Gerardo, Maryline Maknavicious, Julien Bournelle and
myself.  This defines one basic framework approach that is expected to
cover any mobility optimization mechanism.

-----------------
6.2  Mobility

   A mobile PaC's network access authentication performance can be
   enhanced by deploying some sort of mobility optimization mechanism
   in order to avoid performing a full EAP authentication.  The PANA
   protocol defines a framework that provides flexibility to support
   different mobility optimization mechanisms.

   Upon changing its point of attachment, a PaC that wants to quickly
   resume its ongoing PANA session without running EAP MAY send a
   Mobility-Optimization AVP in its PANA-Start-Answer message.  The
   inclusion of the Mobility-Optimization AVP in the PANA-Start-Answer
   message signals PaC's desire to perform the mobility optimization.
   The Mobility-Optimization AVP consists of the type of mobility
   optimization mechanism and data that is used for verifying the
   PANA-Start-Answer message.  The format of the data and the
   mechanism to verify the message by using the AVP depend on the
   mobility optimization mechanism in use and are out of scope of this
   specification.  In case other fast handoff solutions do not provide
   this information to the PAA, the data in the Mobility-Optimization
   AVP may contain information (e.g., the PANA Session-Id assigned by
   the previous PAA) to be used by the current PAA to determine which
   entity the PSA message is carried to.  In the absence of a
   Mobility-Optimization AVP in this message, the PANA session takes
   its usual course (i.e., EAP-based authentication is performed).

   If the current PAA failed to verify the PANA-Start-Answer message
   with the Mobility-Optimization AVP or the PANA session has already
   expired (i.e., session lifetime is zero), the PAA MUST send the
   PANA-Auth-Request message with a new session identifier and let the
   PANA exchange take its usual course.  This action will engage
   EAP-based authentication and create a fresh PANA session from
   scratch.

   In case the current PAA has successfully verified the
   PANA-Start-Answer message that carries the Mobility-Optimization
   AVP, the PANA session continues with a PANA-Bind exchange carrying
   a new session identifier assigned by the current PAA in a
   Session-Id AVP.

   The current PAA and PaC compute the new AAA-Key by using the
   algorithm that is also specific to the mobility optimization
   mechanism in use and thus is not specified in this document.  A new
   PANA_MAC_KEY is computed based on the algorithm described in
   Section 5.6, by using the new AAA-Key and the new session
   identifier assigned by the current PAA.  The MAC AVP contained in
   the PANA-Bind-Request and PANA-Bind-Answer messages MUST be
   generated and verified by using the new PANA_MAC_KEY.  A new PANA
   session is created upon successful completion of this exchange.

8.3.X  Mobility-Optimization AVP

   The first octet (8 bits) of the Mobility-Optimization (AVP Code YY)
   AVP contains the type of the mobility optimization mechanism in
   use.  Rest of the AVP data payload contains the data that is
   specific to the used mobility optimization mechanism in network
   byte order.  The 8-bit Mobility-Optimization-Type name space is
   managed by IANA [ianaweb].  The AVP length varies depending on the
   used mobility optimization mechanism.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |           Type Specific Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      The type field indicates the type of the mobility optimization
      mechanism in use.

   Type Specific Data

      The Type Specific Data is encoded in network byte order and
      contains the data that is specific to the mobility optimization
      mechanism corresponding to the type field and used for
      authenticating the PANA-Start-Answer message with this AVP.
-----------------

Best regards,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Nov 2004 12:31:03 -0800

Hi Yoshi,

Let me understand this...

If this suggested text fully replaces the current 6.2, then the base
spec is no longer providing any mobility solution but instead just
defining an AVP, whose detailed content and usage are left to separate
documents.

Is that the intent (the current spec does not provide a solution
anymore)?

Alper

Of
> Yoshihiro Ohba
> Sent: Thursday, November 25, 2004 11:54 PM
> To: [email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 29 Nov 2004 13:30:48 -0500

> Is that the intent (the current spec does not provide a solution

Yes.  

But IMHO we could provide a solution in the base specification for a
very specific case where the PaC roams around the same PAA (i.e., no
CTP used).

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 29 Nov 2004 15:29:39 -0800

> > Is that the intent (the current spec does not provide a solution

Than I don't think we should be doing anything with respect to mobility
in the base spec. The proposed text below simply suggests:
- there may be some mobility optimizations
- when there is one, it should use Mobility-Optimization-AVP.

I don't see value in specifying these unless we are also defining one
solution in the base spec.

I don't have anything against removing the mobility specification form
the base spec, given that we'll tackle it in another spec. 

So, if we want to remove the specifics from the text, let's remove all.
Leaving some parts does not help, it only leaves more unanswered
questions behind.

Alper

> > >        0                   1                   2
3

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 29 Nov 2004 13:48:21 -0500

> Leaving some parts does not help, it only leaves more unanswered

The members who came up with the proposed text discussed this also as
an alternative.  The conclusion among them was that once we remove the
entire section, then it would be difficult to add the functionality of
mobility optimization later, since it affects the PANA protocol
behavior (it is not just adding some optional AVP, it also defines
optimized PANA message sequence).  Especially from the state machine
perspective, I think it is better to keep the framework mobility
optimization solution in the base PANA specification.

Yoshihiro Ohba