Re: [Mobopts] [Fwd: Agenda for Mobopts]

Hi James, Mobopts folks,

Thank you for your comment.
I'm very interested in MOBIKE WG, and going to attend the 
meeting too, if I can.

Here is my draft.
I submitted our draft to IETF administrator, but it was 
rejected because it was after "cutoff date". I am going to 
re-submit it after Mar. 1st.

I would appreciate it if I hear your advice.
Thaks in advance.

Best regards,

 -Takeshi

"James Kempf" <kempf@docomolabs-usa.com> wrote:

> Right, that is one issue with CTP and why we need a unified handover
> protocol that covers all the functions with a minimum amount of signaling
> but is customizable for particular link types, like Neighbor Discovery is
> customizable for serial/NBMA/Ethernet-type links. Which is going to be the
> topic of my short talk.
> 
> There's another issue with transferring IPsec SA context, though. Typically
> the security types get very uncomfortable with this, because it now means
> that there are two entities who know the DH established secret shared key -
> the PAR and NAR. If the context is transferred further, then it makes the
> security even more subject to compromise. So, at best, context transfer for
> IPsec SA context probably should only be used for exactly as long as it
> takes the MN to do another DH key exchange on the NAR.
> 
> The MOBIKE WG is talking about how to move IPsec SAs, though I believe they
> are only considering the case when one end of the SA moves. The case of
> moving the SA between ARs is really concerned with both ends moving, since
> the MN will be obtaining a new CoA as well.
> 
> If I have time, I will try to read your draft.
> 
>             jak

   MOBOPTS Research Group                                               
   Internet Draft                                              T. Ogawa 
                                                             H. Ohnishi 
                                                           H. Yoshitake 
   Document: draft-ogawa-security-association-          NTT Corporation 
             fmipv6-00.txt 
   Expires: August 21, 2004                           February 20, 2004 

                  Security Association for FMIP Messages 
             <draft-ogawa-security-association-fmipv6-00.txt> 

Status of this Memo 

   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [RFC2026].  

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as Internet-Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 

Abstract 

   Fast Handovers for Mobile IP (FMIP) v6 [FMIP] is a key technology for 
   IP mobility service networks. With FMIP, a Previous Access Router 
   (PAR) redirects a mobile node (MN) traffic to a New Care-of 
   Address (NCoA) during a handover in order to reduce handover latency 
   and packet loss. To prevent service stealing or redirection of 
   traffic to a dubious node, FMIP messages must be authenticated by 
   IPsec. The question of how to establish IPsec security associations 
   (SAs) for FMIP messages between MNs and Access Routers (ARs), however, 
   has not yet been addressed in the current FMIP v6 effort. 
   This draft introduces a new SA establishment method for FMIP between 
   MNs and ARs. In this method, the first time an MN attaches itself to 
   an access network, it employs IKE to negotiate with the AR and define 
   a set of ISAKMP SA and IPsec SA parameters (static profile) for FMIP 

Ogawa, et. al.            Expires - August 2004                [Page 1] 
                Security Association for FMIP Messages   February 2004 

   messages. When a handover is initiated, the AR transfers the SA 
   parameters to the NAR by utilizing the new FMIP messages introduced 
   in this draft. As a result, the MN and NAR do not have to negotiate 
   SAs during the handover. 
   The new FMIP message format is based on the [IKE] and [ISAKMP] packet 
   formats, so it can be used to transfer various SA parameters 
   according to the security policies of the MN and the network; this 
   also makes it easy to keep the format current with changes and 
   enhancements to [IKE] and [ISAKMP]. 
   Furthermore, the message format is designed to carry extra static 
   profiles for the MN. 

Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC2119 [RFC2119]. 

Table of Contents 

   1. Introduction...................................................2 
   2. Terminology....................................................4 
   3. Protocol Overview..............................................5 
   4. IPsec and IKE requirements.....................................7 
   5. Protocol Details...............................................7 
      5.1 Access authentication and IKE..............................7 
      5.2 RtSolPr, CT, CTACK, and PrRtAdv............................7 
      5.3 FBU, HI, HACK, and FBACK...................................8 
      5.4 Re-keying..................................................9 
   6. Message format.................................................9 
      6.1 CT message.................................................9 
      6.2 Context Data block........................................10 
      6.3 CTACK.....................................................11 
      6.4 Context Data..............................................12 
   7. Configurable Parameters.......................................15 
   8. Security Considerations.......................................15 
   References.......................................................15 
   Author's Addresses...............................................16 

1. 
  Introduction 
   There is increasing demand for a ubiquitous, next-generation IP 
   service, where IP communication will be possible anytime, anywhere, 
   and with anybody. In a ubiquitous network, IP addresses will be 
   assigned to various devices (nodes) which are able to move seamlessly 
   throughout the network. 

Ogawa, et. al.            Expires - August 2004                [Page 2] 
                Security Association for FMIP Messages   February 2004 

   To achieve mobility at the IP layer, the Internet Engineering Task 
   Force (IETF) has been developing Mobile IPv6 (MIPv6) technology 
   [MIPv6], which allows nodes to maintain connectivity while moving. 

   Unfortunately, the handover latency and packet loss during handover 
   according to standard MIPv6 procedures are often unacceptable for 
   real-time traffic, such as Voice over IP (VoIP) and throughput-
   sensitive applications. 

   To reduce the handover latency and packet loss, Fast Handovers for 
   Mobile IP (FMIP) v6 [FMIP] is being studied within the IETF. With 
   FMIP, a Previous Access Router (PAR) redirects a mobile node痴 (MN痴) 
   traffic to a New Care-of Address (NCoA) during a handover. To prevent 
   service stealing or redirection of traffic to a dubious node, FMIP 
   messages must be authenticated by IPsec. The question of how to 
   establish IPsec security associations (SAs) for FMIP messages between 
   MNs and Access Routers (ARs), however, has not yet been addressed in 
   the current FMIP v6 effort. 

   The longer an individual SA is in use, the greater the risk of a key 
   being stolen. Therefore, an IPsec SA should usually be negotiated by 
   using IKE when communication starts, and when its lifetime ends, a 
   new SA should be re-keyed. In the case of FMIP, however, the AR with 
   which an MN communicates changes when it moves. If it has to 
   negotiate an SA with a new AR (NAR) for each handover, handovers will 
   take longer, and the quality of communication between the MN and its 
   correspondent node (CN) could deteriorate. 

   There are two alternatives that require no negotiation between the MN 
   and NAR to establish SAs when the MN moves. 

   - Distribution Method 
    The first time an MN attaches to the access network, it negotiates a 
   set of SA parameters for FMIP messages with the network, which then 
   distributes the parameters to all ARs before the handover. 

   - Transfer Method 
    The first time an MN attaches to the access network, it negotiates a 
   set of SA parameters for FMIP messages with an AR, and the AR 
   transfers the SA parameters to potential NARs when a handover is 
   initiated. 

   In a large-scale network, such as a public network, the number of 
   messages distributed via the Distribution Method will be huge, so we 
   propose that the Transfer Method should be used instead. 

   In the remainder of this document, a new SA establishment method for 
   FMIP messages, based on the Transfer Method, is described. 
   This method includes three main features. 

Ogawa, et. al.            Expires - August 2004                [Page 3] 
                Security Association for FMIP Messages   February 2004 

   o  IKE is used to establish SAs the first time an MN attaches to the 
   access network, and to re-key the SAs when the lifetimes of the 
   initial SAs expire. It is assumed that the proposed SA attributes 
   depend on the MNs but are independent of the ARs, and that the SA 
   attributes supported by an AR are commonly supported by other ARs. 

   o  The PAR sends a set of SA parameters to the NAR as it receives 
   RtSolPr message, instead of FBU message, because an FNA may be sent 
   to the NAR before the PAR receives the FBU in a "reactive" fast 
   handover. 

   o  The message format introduced in this document is based on [CT], 
   [IKE] and [ISAKMP]. This enables the PAR to transfer various SA 
   parameters according to the security policies of the MN and the 
   network, as well as making it easy to stay current with [IKE] and 
   [ISAKMP] when they are enhanced or changed. 
   Furthermore, the message format is designed to carry extra static 
   profiles for the MN. 

2. 
  Terminology 
   The following terminology and abbreviations are used in this document, 
   based on [FMIP]. 

    Mobile Node (MN) 
             A Mobile IPv6 host. 

    Access Point (AP) 
             A layer-2 device connected to a subnet offering 
             wireless connectivity to an MN. 

    Access Router (AR) 
             An MN's default router. 
    Previous Access Router (PAR) 
             An MN's default router prior to a handover. 

    New Access Router (NAR) 
             An MN's anticipated default router subsequent to a 
             handover. 

    Previous CoA (PCoA) 
             An MN's Care-of Address valid in its PAR. The MN may reuse 
             this address while attached to the NAR, until it finishes 
             its Mobile IP operations. 

    New CoA (NCoA) 
             An MN's Care of Address valid in an NAR. 
    Handover (HO) 
             The process of terminating existing connectivity and 

Ogawa, et. al.            Expires - August 2004                [Page 4] 
                Security Association for FMIP Messages   February 2004 

             establishing new IP connectivity. 

    Router Solicitation for Proxy (RtSolPr) 
             A message from an MN to its PAR requesting information 
             for a potential handover. 

    Proxy Router Advertisement (PrRtAdv) 
             A message from a PAR indicating that an MN may undergo 
             a handover. 

    Fast Binding Update (FBU) 
             A message from an MN instructing its PAR to redirect its 
             traffic (towards its NAR). 

    Fast Binding Acknowledgment (FBACK) 
             A message from a PAR in response to an FBU. 

    Fast Neighbor Advertisement (FNA) 
             A message from an MN to an NAR to announce attachment 
             and confirm the use of an NCoA when the MN has not received 
             an FBACK. 

    Handover Initiate (HI) 
             A message from a PAR to an NAR to initiate handover. 

    Handover Acknowledge (HACK) 
             A message from an NAR to a PAR in response to an HI. 

    The following terminology and abbreviations are introduced and used 
   in this document. 

    Context Transfer (CT) message 
             A message from a PAR to an NAR, containing SA parameters  
             generated by IKE phase 1 and phase 2. It may contain  
             a further static profile for the MN. 

    Context Transfer Acknowledgment (CTACK) 
             A message from an NAR to a PAR in response to a CT. 

3. 
  Protocol Overview 
   In this method, the transfer of SA parameters between ARs is achieved 
   by utilizing new FMIP messages, instead of other, existing protocols. 
   The reason is that if an existing protocol, such as context transfer 
   [CT], were combined with FMIP, some functions would be duplicated, 
   while some essential functions would not be defined. For example, in 
   the context transfer protocol, an MN sends a CTAR [CT] message to a 
   PAR or NAR to activate the protocol. This can be replaced by using 
   existing FMIP messages. Furthermore, the SA establishment method for 
   CTAR has not been specified.   

Ogawa, et. al.            Expires - August 2004                [Page 5] 
                Security Association for FMIP Messages   February 2004 

   Figure 1 shows a sequence example for the proposed method.  

   MN                PAR                  NAR 
   |<==========access authentication======>| 
   | (beyond the scope of this document) | 
   |                   |                   | 
   |                   |                   | 
   |<======IKE ph1====>|                   | 
   |<======IKE ph2====>|                   | 
   |                   |                   | 
   (MN detects HO trigger)                 | 
   |                   |                   | 
   |-----RtSolPr------>|---(*)CT---------->| 
   |<----PrRtAdv-------|                   | 
   |                   |<-(*)CTACK---------| 
   |                   |                   | 
   |-----FBU---------->|------HI---------->| 
   |<-----FBACK--------|<----HACK----------| 
   |                   |                   | 
   |                   |                   | 
   ====attach to NAR====== 
   |                   |                   | 
   |---------------FNA-------------------->| 
   |<--------------NAACK-------------------| 
   |                   |                   | 

            (*): new FMIP message  

          Figure 1: Sequence example for the proposed method. 

   The first time an MN attaches itself to the access network, it 
   processes access authentication with the network, by a method such as 
   802.1x or a Protocol for carrying Authentication for Network Access 
   (PANA), or other method. These protocols are out of the scope of this 
   document. Then, the MN starts [IKE] phase 1 to negotiate an ISAKMP SA 
   between itself and a PAR, and it processes [IKE] phase2 to negotiate 
   an IPsec SA with the PAR. 

   The new messages, CT and CTACK, are then introduced. 
   When a PAR receives an RtSolPr message, it MUST send a CT to the 
   NAR(s) corresponding to the RtSolPr.  
   If the PrRtAdv contains multiple IP addresses for NARs, the PAR MUST 
   send CTs to those NARs. 
   The CT message contains the SA parameters generated in IKE phase 1 
   and phase 2. For example, it includes an encryption algorithm, hush 
   algorithm, authentication method, generated keys, SA lifetime, SPIs, 
   etc. If a pre-shared key is used in IKE phase 1, it may also be 

Ogawa, et. al.            Expires - August 2004                [Page 6] 
                Security Association for FMIP Messages   February 2004 

   transferred. The data to be transferred are described in section 4 of 
   this draft. Furthermore, the CT message may contain extra static 
   profiles for the MN. 

   The NAR(s) send CTACK messages in response to CT messages, and 
   it/they build an SA database from the CT messages. 
   When the soft-timer for the SA lifetime expires, the initiator, which 
   is usually the MN, starts re-keying according to the IKE protocol. 
   In addition, if the handover trigger occurs during re-keying between 
   the MN and the PAR, the MN SHOULD stop the re-keying process and 
   start the handover process (i.e, send RtSolPr), then restart re-
   keying with the NAR after receiving an NAACK from the NAR. 

4. 
  IPsec and IKE requirements 

   The following requirements apply to both ARs and MNs: 

   o  Automatic key management via IKE [5] MUST be supported.  Only 
      IKEv1 is discussed in this document. 

   o  ESP encapsulation of FBUs, FBACKs, FNAs, and NAACKs between 
      MNs and ARs MUST be supported and MUST be used.  

   o  ESP encapsulation of RtSolPr and PrRtAdv between MNs and ARs MUST 
      be supported and SHOULD be used. 

5. 
  Protocol Details 
   All descriptions here make use of Figure 1 as a reference. 

5.1 
    Access authentication and IKE 
   After the first time an MN attaches to the access network, it MUST 
   start the IKE process with an AR belonging to the same subnet and 
   establish ISAKMP and IPsec SAs for FMIP messages. The question of how 
   to find the first PAR is beyond the scope of this document. 

5.2 
   RtSolPr, CT, CTACK, and PrRtAdv 
   After discovering a nearby access point, the MN produces an RtSolPr 
   message containing new attachment point(s), and it SHOULD apply ESP 
   in transport mode to the message and send it to the PAR. 

   When the PAR receives the RtsolPr message, it produces a PrRtAdv 
   message, and it SHOULD apply ESP in transport mode to the message and 
   send it to the MN. 
   If the new attachment point(s) are known and the PAR has information 
   about them, it MUST send a CT message to them (one or more NARs).  
   The CT message contains the SA parameters negotiated by IKE, 
   including the encryption algorithm, hush algorithm, authentication 
   method, generated keys, SA lifetime, SPIs, etc. 

Ogawa, et. al.            Expires - August 2004                [Page 7] 
                Security Association for FMIP Messages   February 2004 

   The same SPI value MUST be used continually after the handover. One 
   peer of the SA, the AR, changes, so the value of the SPI in an SA 
   between an MN and an AR MUST be unique for each AR. 
   The value of the SPI may be determined from a unique identifier of 
   the MN. 
   In contrast, the other peer of the SA, the MN, does not change, so it 
   is good if the value of the SPI in an SA between an AR and an MN is 
   unique to the MN. 

   When the NAR receives the CT message, it MUST prepare ISAKMP and 
   IPsec SAs between itself and the MN by using the available NCoA. The 
   available NCoA may be the one in the CT message, or it may be an 
   alternative NCoA defined by the NAR. 
   The NAR MUST also maintain the SAs for CT_life_time seconds. The 
   CT_life_time MUST be longer than the available period of information 
   in the PrRtAdv. 
   Note that the available period of the PrRtAdv is not currently 
   defined in [FMIP]. 
   In addition, if the NAR receives or sends a packet via the SA, it 
   ignores the CT_life_time.  
   In response to the CT, the NAR MUST produce a CTACK message 
   containing the available NCoA. It also MUST apply ESP in transport 
   mode to the message and send it to the PAR. If the NAR can not 
   receive the CT successfully, the CTACK indicates "CT failed". 

   When the PAR receives a CTACK indicating that the CT was received 
   successfully, it MUST prepare SAs between itself and the MN by using 
   the available NCoA according to the information transferred in the CT 
   message, and it MUST maintain the SAs for CT_life_time seconds. These 
   SAs are necessary in order to receive an FBU from the new link. The 
   CT_life_time MUST be longer than the available period of information 
   in the PrRtAdv. Moreover, if the PAR receives or sends a packet via 
   the SA, it MUST ignore the CT_life_time. 
   If the PAR does not receive a CTACK, it SHOULD re-send the CT message 
   up to CT_RETRIES times by using a short retransmission timer with a 
   value no less than twice the round-trip time (RTT) between the source 
   and destination, or a value of 100 ms if the RTT is not known. 

   When the MN receives the PrRtAdv, it MUST prepare ISAKMP and IPsec 
   SAs between itself and the NAR by using the NCoA.  

5.3 
   FBU, HI, HACK, and FBACK 
   Sometime after the PrRtAdv message is received, the MN produces an 
   FBU message, and it MUST apply ESP in transport mode to the message 
   and send it to the PAR. 
   If it does not send an FBU to the PAR while the information in the 
   PrRtAdv is available, it MUST re-send the RtSolPr to get updated 
   information and ensure that the PAR and NAR maintain the 
   corresponding SAs. 

Ogawa, et. al.            Expires - August 2004                [Page 8] 
                Security Association for FMIP Messages   February 2004 

   When either the PAR receives an FBU, or the HI retry timer expires, 
   the PAR provides one of the following responses: 
   1. If the PAR has not yet received a CTACK from an NAR corresponding 
   to the FBU yet, it MUST not send an HI message to the NAR.  
   2. If the PAR has received a CTACK indicating that the NAR 
   corresponding to an FBU did not receive the CT successfully, it sends 
   an FBACK containing the new status code, 127 "CT failed", as a 
   response to the FBU. 
   3. Otherwise, the PART MUST send an HI to the NAR. 

   The NAR then sends a HACK message as a response to the HI. If the CT 
   was not received successfully, the NAR MUST send an HI containing the 
   new status code, 127 "CT failed". 

   As a response to the FBU, the NAR produces an FBACK message, and it 
   MUST apply ESP in transport mode to the message and send it to the MN. 
   If the HACK contains the new status code, 127, then the status code 
   of the FBACK is also 127. 
   After the binding lifetime expires, the PAR clears the SAs used for 
   FMIP messages between itself and the MN. 

   If the FBACK contains an alternative NCoA, the MN MUST change the IP 
   address for the SAs between itself and the NAR. 
   When the MN receives the FBACK, or when it retries sending the FBU 
   FBU_RETRIES[FMIP] times but does not receive an FBACK until the FBU 
   retry timer expires, it SHOULD clear the SAs used for FMIP messages 
   between the PCoA and the PAR. 
   After attaching to a new link, the MN produces an FNA message. It 
   MUST apply ESP in transport mode to the message and send it to the 
   NAR. 

   As a response to the FNA, the NAR produces an NAACK message, and it 
   MUST apply ESP in transport mode to the message and send it to the MN. 

   If the NAACK contains an alternative NCoA, the MN MUST change the IP 
   address for the SAs between itself and the NAR. 

5.4 
   Re-keying 
   When the soft-timer for the SA lifetime expires, the initiator, 
   usually the MN, starts re-keying according to the IKE protocol. 
   In addition, if the handover trigger occurs during re-keying, the 
   initiator stops the re-keying process and starts the handover process 
   (i.e, sends an RtSolPr), and then restarts the re-keying after 
   receiving an NAACK from the NAR. 

6. 
   Message format 
6.1 
   CT message 
   The CT message is based on the PCTD message in [CT]. 

Ogawa, et. al.            Expires - August 2004                [Page 9] 
                Security Association for FMIP Messages   February 2004 

   It is sent from the PAR to the NAR and includes Context Data blocks.  

      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         |     Length    | V |A|   Reserved              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             Reserved                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |             Mobile Node's Previous Care-of Address            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |             Mobile Node's New Care-of Address                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              Reserved           |            Reserved         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             Reserved                          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                   First Context Data Block                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                    Next Context Data Block                    | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           ........                            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

          Type                 4 

          'V' flag             00 

          'A' bit              Reserved.  

          Length               The message length in octets. 

          Reserved             Reserved for future use. Must be set to 
                               zero by the PAR. 

          MN's Prev CoA        An IPv6 address as defined in [RFC 2373]. 

          MN's New CoA         An IPv6 address as defined in [RFC 2373]. 

6.2 
   Context Data block 
   The Context Data block is based on the "Context Data Block" in [CT]. 
   It is sent from the PAR to the NAR and includes Context Data.  

Ogawa, et. al.            Expires - August 2004               [Page 10] 
                Security Association for FMIP Messages   February 2004 

      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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |   Cxt-Type    |    Length     |P| Feature Profile Type (FPT)  |        
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               | 
     +                       Context Data                            + 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        Cxt-Type             A single octet. Depends on the Context Data. 

        Length               The message length in octets. 

        'P' bit              Reserved (0). 

        FPT                  A 16-bit integer, giving the feature 
                            profile type contained in the data field. 
                             Depends on the Context Data. 

        Context Data         Context type-dependent data, whose length 
                            is defined by the Length field.  If the 
                            data is not 64-bit aligned, the Context 
                            Data field is padded with zeros. 

6.3 
    CTACK 
   The CTACK message is based on the CTDR message in [CT]. 

     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      |     Length    | V |S|       Reserved          | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |             Mobile Node's Previous IP Address                 | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |        FPT                    | Status Code   |  Reserved     | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | .......                                                       | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        Type                 5 

        Length               The message length in octets. 

        'V' flag             00 

Ogawa, et. al.            Expires - August 2004               [Page 11] 
                Security Association for FMIP Messages   February 2004 

        'S' bit              When set to one, this bit indicates that    
                            all the feature contexts sent in the CT 
                            were received successfully. 

        Reserved             Reserved for future use. Must be set to 
                            zero by the MN. 

        MN's Prev IP          
        Address Field        An IPv6 Address as defined in [RFC 2373]. 

        Status Code          A context-specific return value, present 
                             when 'S' is not set to one. 

        FPT                  A 16-bit integer, listing the FPT that is 
                            being acknowledged. 

        Status Code          0 = not successfully transferred 
                             1 = successfully transferred 

6.4 
    Context Data 
(1) IKE Ph1 Context Data 
   The IKE Ph1 Context Data format is based on the ISAKMP message format. 
   The ISAKMP header, SA payload, proposal payload, and transform 
   payload MUST exist in IKE Ph1 Context Data. In addition, the new 
   payload, MN-ID payload, and Ph1 Key payload MUST also exist in IKE 
   Ph1 Context Data. 

   The Cxt-Type and FPT of IKE Ph1 Context Data are TBD. 
   o ISAKMP header  
   See [ISAKMP] section 3.1. 

   o SA payload 
   See [ISAKMP] section 3.4. 

   o Proposal payload 
   See [ISAKMP] section 3.5. 

   o Transform payload 
   See [ISAKMP] section 3.6. 

   o ID payload 
   See [ISAKMP] section 3.8. 
   In this case, this payload contains information about the PAR. 

   o MN-ID payload (new) 
     This payload contains information about the MN. 
   Payload Type = 129. The other parameters are the same as for the ID 
   payload. 

Ogawa, et. al.            Expires - August 2004               [Page 12] 
                Security Association for FMIP Messages   February 2004 

   o Ph1 Key payload (new) 
     Payload Type = 130.  
   This payload contains various keys used or generated in IKE Ph1. 

      The Key Payload fields are defined as follows: 

    o Next Payload (1 octet) - An identifier for the payload type of the 
      next payload in the message.  If the current payload is the last 
      in the message, then this field will be 0. 

    o RESERVED (1 octet) - Unused, set to 0. 

    o Payload Length (2 octets) - The length in octets of the current 
      payload, including the generic payload header. 

    o Key type        Pre-shared key        1 
                      SKEYID_d              2 
                      SKEYID_d              3 
                      SKEYID_d              4 
                      ISAKMP SA past time   5 

                         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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | Next Payload  |   RESERVED    |         Payload Length        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |   Key Type    | Length        |              Reserved         | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                      Key Information                          | 
    ~                                                               ~ 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |   Key Type    | Length        |              Reserved         | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                      Key Information                          | 
    ~                                                               ~ 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   (2) IKE Ph2 Context Data format 
   The IKE Ph2 Context Data format is based on the ISAKMP message format. 
   The ISAKMP header, SA payload, proposal payload, and transform 
   payload MUST be present in the IKE Ph2 Context Data. The new payload, 
   MN-ID payload, and Ph2 Key payload MUST also be present in the IKE 
   Ph2 Context Data. 

   The Cxt-Type and FPT of IKE Ph2 Context Data are TBD. 

Ogawa, et. al.            Expires - August 2004               [Page 13] 
                Security Association for FMIP Messages   February 2004 

   o ISAKMP header  
   See [ISAKMP] section 3.1. 

   o SA payload 
   See [ISAKMP] section 3.4. 

   o Proposal payload 
   See [ISAKMP] section 3.5. 

   o Transform payload 
   See [ISAKMP] section 3.6 and [IPsec DOI] section 4.5.  

   o ID payload 
   See [ISAKMP] section 3.8. 
   In this case, this payload contains information about the PAR. 

   o MN-ID payload (new) 
     This payload contains information about the MN. 
   Payload Type = 129. The other parameters are the same as for the ID 
   payload. 

   o Ph2 Key payload (new) 
     Payload Type = 131.  
   This payload contains various keys used or generated in IKE Ph2. 

    The Ph2 Key Payload fields are defined as follows: 

    o Next Payload (1 octet) - An identifier for the payload type of the 
      next payload in the message.  If the current payload is the last 
      in the message, then this field will be 0. 

    o RESERVED (1 octet) - Unused, set to 0. 

    o Payload Length (2 octets) - The length in octets of the current 
      payload, including the generic payload header. 

    o Key type 
                       Authentication key         1 
                       Encryption key             2 
                       IPsec past time            3 

Ogawa, et. al.            Expires - August 2004               [Page 14] 
                Security Association for FMIP Messages   February 2004 

                         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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | Next Payload  |   RESERVED    |         Payload Length        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |   Key Type    | Length        |              Reserved         | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                      Key Information                          | 
    ~                                                               ~ 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |   Key Type    | Length        |              Reserved         | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                      Key Information                          | 
    ~                                                               ~ 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

7. 
  Configurable Parameters 

     Parameter Name       Default Value            Definition 
    -------------------  ----------------------   ------- 
     CT_life_time                TBD              Section 4 
     CT_RETRIES                  4                Section 4 

8. 
   Security Considerations 
   This draft introduces a new SA establishment method for FMIP between 
   MNs and ARs. 
   SAs for FMIP messages, CT, CTAR, HI and HACK between ARs are beyond 
   the scope of this document. However SAs must exist between the ARs as 
   mentioned in [FMIP]. IKE protocol may be used for them.   

References 

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision  
   3", BCP 9, RFC 2026, October 1996.     
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate  
   Requirement Levels", BCP 14, RFC 2119, March 1997 
   [MIPv6] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 
   IPv6", draft-ietf-mobileip-ipv6-24.txt, June 30, 2003. 
   [FMIP] Koodli, R., Editor, "Fast Handovers for Mobile IPv6", draft-
   ietf-mipshop-fast-mipv6-01.txt, January 30, 2004. 

Ogawa, et. al.            Expires - August 2004               [Page 15] 
                Security Association for FMIP Messages   February 2004 

   [CT] Loughney, J., et al., "Context Transfer Protocol", draft-ietf-
   seamoby-ctp-05.txt, October 25, 2003. 
   [ARCH] Kent, S., and  Atkinson, R., "Security Architecture for the 
   Internet Protocol", RFC 2401, November 1998. 
   [IKE] Harkins, D., and Carrel, D., "The Internet Key Exchange (IKE)", 
   RFC 2409, November 1998. 
   [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 
   "Internet Security Association and Key Management Protocol (ISAKMP)", 
   RFC 2408, November 1998. 

Author's Addresses 

          Takeshi Ogawa 
          Hiroyuki Ohnishi 
          Hideto Yoshitake 

          NTT Network Systems Laboratories, NTT Corporation 
          9-11 Midori-Cho 3-Chome 
          Musashino-Shi, Tokyo 180-8585, Japan 

          Phone: +81 422 59 4053 
          Email: ogawa.takeshi@lab.ntt.co.jp 
                 hiroyuki.ohnishi@lab.ntt.co.jp 
                 yoshitake.hideto@lab.ntt.co.jp 

Ogawa, et. al.                Expires - August 2004               [Page 16] 

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts