Seamoby Working Group                                       Ram Gopal L.
INTERNET DRAFT                                         Vijay Devarapalli
12 November  2001                                   Govind Krishnamurthi
Category:  Standards Track                                 Rajeev Koodli
                                                        Senthil Sengodan
                                                      Charles E. Perkins
                                                   Nokia Research Center

                         IPsec Context Transfer
               draft-gopal-seamoby-ipsec-relocate-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.

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.

This document is an individual submission for the Seamoby Working Group
of the Internet Engineering Task Force (IETF).  Comments should be
submitted to the seamoby@diameter:org  mailing list.

Distribution of this memo is unlimited.


Abstract

Seamless offering of security to a Mobile Node (MN) during handovers is
crucial for enabling a variety of application services in the Mobile
Internet.  Handovers also imply that a terminal such as a MN may perform
network access authentication in order to obtain connectivity and access
to network features such as QoS, header compression etc.  Security
context associated with several Security Associations (SA) may need to
be transferred in order to achieve this.  This enables the MN to regain
authenticated connectivity and establish new SAs without having to
reinitiate time-consuming operations.  In this document, we define the






Gopal et.al.                Expires 12 May  2002                [Page i]


Internet Draft         IPSec Context Transfer          12 November  2001


IPSec security context and show how they could be transferred to enable
seamless security operation during handovers.  We also illustrate how
these contexts may be transferred using a context transfer framework.
We define some initial Security Profile Types (SPT) and specify how the
associated Security Profiles can be transferred along-with handover
signaling.

                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology                                                        3

 3. Security Profile Types                                             4

 4. Security Context Transfer with Handover Signaling                  8

 5. Message Formats                                                    9
     5.1. Sub-option to transfer security context from PR to NR . .    9
     5.2. Sub-option used by a MN to request security context . . .   10
     5.3. Sub-option used to update a MN  . . . . . . . . . . . . .   12
     5.4. Sub-option to convey status to the MN . . . . . . . . . .   13

 6. Examples of Security Profiles                                     14

 7. Security Considerations                                           15

 8. IANA Considerations                                               15

Addresses                                                             18


1. Introduction

Context transfer between access routers (AR) is critical for seamless
session continuity during handover.  It has the benefits of reduced
latency and improved handover quality.  An alternative to transferring
security state from the previous router to the new router would be for
the mobile node to reestablish a security association.  However, this
would typically mean high latency.   [2] provides the problem statement
for this aspect.

In many IP networks, authentication of network nodes by the access
network is crucial to prevent abuse by unauthorized users, before



Gopal et.al.                Expires 12 May  2002                [Page 1]


Internet Draft         IPSec Context Transfer          12 November  2001


the network can offer connectivity and features such as QoS, header
compression etc.  (see [7]).  As a result of successful authentication,
the terminal may establish a security association with its Access Router
in order to secure its communication.  Examples of communication that
requires secure channel are mobile-initiated context transfer and fast
handovers.  In context transfers [4] [3], a Mobile Node authorizes its
AR to transfer feature contexts to its new AR. In fast handovers, a
MN authorizes its AR to start forwarding its packets towards its new
AR [1].  One protocol which may be used to provide secure communication
between the current access router and the mobile node is IPsec [8].
An IPsec security association is expected to be established between a
mobile node and its current access router, for at least the purpose
of fast handoffs and context transfer.  Transferring this security
association from the previous access router to the new access router
would alleviate the need for performing elaborate authentication during
handovers and re-establishing the security association between the MN
and its new AR. For instance, a token containing the MN's identity,
a local challenge issued by the new AR and the session key (obtained
while the MN first establishes connectivity at previous access router)
may be verified by the new AR itself when it has the appropriate
security context.  Such local improvements are crucial especially in
wireless networks characterized by slower link speeds, where support for
real-time applications, such as VoIP, during handovers places additional
burden on the system.  The requirement and issues in transferring such
security associations is described in [4].

In addition to dealing with security context associated with SAs
protecting control messages between the MN and AR, security context
associated with SAs used to protect several types of messages - control,
user and management.  Moreover, the SA endpoints may be those other
than the MN and the AR. For instance, an SA may be present between
the MN and a Security Gateway (SG), an entity other than the AR. The
security context transfer being discussed in this draft is applicable
irrespective of the nature of the message being protected by the SA
or the terminating endpoints of the SA. The requirement and issues in
transferring such security associations is described in [6].  This
draft assumes that the ARs have prior knowledge of the SGs and security
context is collected at some time prior to handovers.  Similarly it
is assumed, that NR has the required knowledge to re-distribute the
security contexts to SGs in its domain when needed.  This draft does not
address issues regarding issues involved in fetching and re-distribution
of contexts prior to and after the handover.

In this document, we describe the structure and mechanisms for
transferring IPSec context between access routers.  We introduce the
notion of Security Profile Types for ensuring inter-operability between
participating access routers.  A security profile type describes a
specific security profile (IPsec protocol, cipher algorithm, protocol




Gopal et.al.                Expires 12 May  2002                [Page 2]


Internet Draft         IPSec Context Transfer          12 November  2001


mode, etc.).  In the rest of this document, we use Figure  1 as the
reference for discussion.


             v            +------------+
           +-+            |  Previous  |        <
           | | ---------- |   Router   | ------ > ----\
           +-+            |   (PR)     |        <      \
               MN         |            |                \
            |             +------------+            +---------------+
    Handover|                   ^            IP     | Correspondent |
            |                   |         Network   |  Node (CN)    |
            V                   |                   +---------------+
                                v                        /
             v            +------------+                /
           +-+            |    New     |        <      /
           | | ---------- |   Router   | ------ > ----/
           +-+            |   (NR)     |        <
              MN          |            |
                          +------------+


                      Figure 1: Reference Scenario



2. Terminology

      HAck Message      The ICMP Handover Acknowledgment message, sent
                        from the New Router to the Previous Router, and
                        defined in [1].

      HI Message        The ICMP Handover Initiate message, sent from
                        the Previous Router to the New Router, and
                        defined in [1].

      New Router (NR)
                        The router to which the MN attaches after
                        handover.

      Previous Router (PR)
                        The MN's default router prior to handover.

      New access address (Naddr)
                        The access IP address of the Mobile Node (MN)
                        when attached to the link served by the New
                        Router.





Gopal et.al.                Expires 12 May  2002                [Page 3]


Internet Draft         IPSec Context Transfer          12 November  2001


      Previous access address (Paddr)
                        The access IP Address of the Mobile Node (MN)
                        when attached to the link served by the Previous
                        Router.

      Security Profile Type (SPT)
                        A 16-bit unsigned integer that indicates the
                        type of Security profile (see section 3).

      SHAK Message      Any IPv6 message received by the mobile node
                        containing the SHAK Destination Option defined
                        in  [3].

      SHIN Message      Any IPv6 message sent by the mobile node
                        containing the SHIN Destination Option defined
                        in [3].

      SHREP Message     The ICMP Smooth Handover Reply message, sent
                        between access routers, and defined in [3].

      SHREQ Message     The ICMP Smooth Handover Request message, sent
                        between access routers, and defined in [3].


3. Security Profile Types

A Security Profile Type (SPT) describes the IPsec protocol, the
protocol mode and the cipher algorithm to use for a particular security
association.  The associated security profile describes the state
variables or treatment fields used by the IPsec stack to transform or
process the packets, once it has been determined that they must be
processed by IPsec.  These state variables contain enough information
so that a node which receives this information can instantiate a
security association between itself and a mobile node.  This is
better illustrated in Figure  2.  The SPT field is a 16 bit value and
specifies a particular security profile type.  The variables that follow
constitute the security profile and specify the state variables which
contain information regarding the security association.

If there is a need for additional selectors for using a particular
security association, they are present in the form of <type, value>
pairs in the additional security data part of the security profile.  The
Length field gives the length of the security profile, including the
additional security data.  Similarly if there are additional transform
fields needed by certain cryptographic algorithms they are listed in the
additional security data part of the security profile.  The transform
fields MUST be before the additional selector fields.





Gopal et.al.                Expires 12 May  2002                [Page 4]


Internet Draft         IPSec Context Transfer          12 November  2001


    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             SPT               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |  Reserved     |    Protocol   |  Window Size  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source IP Identity                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination IP Identity                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SPI                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Current Sequence Number                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Lifetime                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Anti Replay Window                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Source Port            |     Destination Port          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Key Length  |                Key....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Additional Security Data.....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             MN's static profile relevant to this SA           ~
   ~                           (optional)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Figure 2: Generic SPT



      SPT                    This 16 bit field determines the SPT
                             value.This field defines the way the
                             rest of the SA is to be interpreted.
                             Each SPT value needs to be allocated by
                             IANA.We have identified the following
                             possible Security Profile Types.  These
                             SPT definitions assume non site-local
                             IPv6 based SA end-points.  Similar SPTs
                             have to be defined for SAs one or both of
                             whose end-points are IPv4 based, SAs one
                             or both of whose end-points may belong to
                             private or site-local address spaces or
                             combinations of the above.  SPT should
                             also specify whether IPComp is present




Gopal et.al.                Expires 12 May  2002                [Page 5]


Internet Draft         IPSec Context Transfer          12 November  2001


                             rather than ESP or AH. A few examples are
                             specified below

                             1: AH-TRANSPORT-HMACMD5-V4
                             2: AH-TRANSPORT-HMACSHA1-V4
                             3: AH-TUNNEL-HMACMD5-V6
                             4: AH-TUNNEL-HMACSHA1-V6
                             5: ESP-TRANSPORT-DES-CBC-V6
                             6: ESP-TUNNEL-DES-CBC-V6
                             7: ESP-TRANSPORT-3DES-CBC-V6
                             8: ESP-TUNNEL-3DES-CBC-V6
                             9: ESP-TRANSPORT-AES-CBC-V6
                             10: ESP-TUNNEL-AES-CBC-V6


      Length                 8 bit field denoting the length of the
                             security profile in bytes.

      Reserved               MUST be set to zero.

      Protocol               8 bit field denotes the transport protocol
                             used.

      Window Size            8 bit field is a pre allocated state
                             variable maintained at PR indicating the
                             Anti-replay window size.

      Source IP Identity     128 (v6) or 32 (v4) bit source IP address
                             followed by an optional 32 bit private ID
                             if the IP address is a private or site-
                             local address.  Whether the Identity
                             belongs to a private space or is globally
                             routable is determined by an appropriate
                             SPT value.

      Dest.  IP Identity     128 (v6) or 32 (v4) bit destination IP
                             address followed by an 32 bit private ID if
                             the IP address is a private or site- local
                             address.  Whether the Identity belongs to
                             a private space or is globally routable is
                             determined by an appropriate SPT value.

      SPI                    This 32 bit field is the SPI value
                             associated with the SA.

      Current Sequence Number This 32 bit field is a state variable
                             maintained at PR for processing packets.
                             This value defines the currently received




Gopal et.al.                Expires 12 May  2002                [Page 6]


Internet Draft         IPSec Context Transfer          12 November  2001


                             maximum sequence number in the anti-replay
                             window.

      Lifetime               This 32-bit field denotes the lifetime of
                             the Security Association.  Depending on the
                             SPT, the Lifetime is interpreted either in
                             seconds or bytes.

      Anti Replay Window     This variable length field contains
                             a sequence of flags, where each bit
                             represents whether the corresponding packet
                             has been successfully received or not.  1:
                             packet received successfully by the IPsec
                             layer 0:  packet is not yet received.  The
                             size of this field is determined by the
                             "Window Size" field.  This field is padded
                             with zeros to make multiple of 8 bits.

      Source Port            16 bit field designating the source port.
                             If it is not needed as part of the security
                             profile, it MUST be set to 0 and ignored by
                             the NR.

      Destination Port       16 bit field designating the destination
                             port.  If it is not needed as part of the
                             security profile, it MUST be set to 0 and
                             ignored by the NR.

      Key Length             8 bit field representing the length of key
                             used in the cryptographic algorithm used.

      Key                    Variable length field to represent the key
                             used.

      Additional Security Data This variable length field is used to
                             denote additional selectors and transform
                             definitions.  The data in the field is
                             determined by an appropriate SPT value.

      MN's static profile    This optional variable-length field, if
                             present (indicated by an appropriate SPT),
                             contains the portion of the MN's static
                             profile that is relevant to this SA. This
                             field may be included if the transform (or
                             its associated parameters) used within the
                             SA is not the most preferred transform
                             (or most desired associated parameters)
                             specified within the MN's static profile.




Gopal et.al.                Expires 12 May  2002                [Page 7]


Internet Draft         IPSec Context Transfer          12 November  2001


4. Security Context Transfer with Handover Signaling

In this section we describe how the Security Profile Type and security
profiles defined in the previous section are transferred from the PR to
NR. We use Fast Handover [1] signaling messages to transfer the security
context from the PR to the NR.

The Previous Router, in response to either a network-initiated handover
or the mobile-initiated handover, sends a HI message to the New Router.
In this HI message, it includes the Unsolicited Seamless Handover Reply
(U-SHREP) option defined in [3], which carries the appropriate security
contexts.  The U-SHREP MUST be protected by a security association
between the PR and the NR. If Data confidentiality is required ESP [10]
SHOULD be used to protect the U-SHREP. The NR SHOULD acknowledge the
receipt of the security context by including a SHREP-ACK [3] message in
the HACK message.

When fast handovers is not feasible and the mobile node moves to
the NR, it sends a SHIN [3] to the NR. The SHIN message contains a
request from the mobile node to the PR to transfer the corresponding
security associations to the NR. This request is authenticated by an
existing security association between the PR and the mobile node as
described in [3].  When the NR receives a SHIN message, it transmits a
SHREQ message to PR in which it includes the MN's request for context
transfer.  The PR then sends the security context for the mobile node
in a SHREP message to the NR. The SHREP MUST be protected by a security
association between the PR and NR.

Upon processing the SHIN message received at the NR, the NR may send a
SHAK message with a Status sub-option.  Similarly, upon receiving the
SHREQ message at the PR, the PR may send a SHAK message with a coveying
the status.  Similarly, upon receiving a SHREP or U-SHREP message with a
Reply sub-option, a SHREP-ACK message may be sent conveying the status
of the operation.

When the NR receives the security context, it initializes the security
associations in its database.  The NR also modifies each SA to reflect
the new source and destination address.  It is possible that the SPI
values in the transferred security associations could already be in use
at the NR. In such a case the NR computes a different SPI value using
the transferred key, the NR's IP address and the mobile node's New IP
address.  The NR MUST then inform the mobile node through the SHAK
message that a new SPI value has to be used.  The new SPI value however
is not included in the SHAK message.  The mobile node recomputes the SPI
using the key from the corresponding SA, the mobile node's Naddr and the
NR's address.  The SHAK message MUST be protected using the transferred
SA. The mobile node also modifies the SAs, replacing the PR's address
with NR's address.




Gopal et.al.                Expires 12 May  2002                [Page 8]


Internet Draft         IPSec Context Transfer          12 November  2001


Changes to the security context are updated at the MN by the NR using
the SHAK message.  It is also possible that re-negotiation of the
Security Association may need to be done.


5. Message Formats

Security context transfer options and suboptions are defined for use in
several different protocol message types:

    -  as an option or a sub option to a HI, HAck, SHREQ, or SHREP
       ICMPv6 messages.

    -  as a sub-option of an IPv6 destination option.

    -  as an extension to a Mobile IPv4 registration request to be
       processed by a Foreign Agent.

    -  as an extension to some other seamless handover message to be
       defined in the future for mobile nodes using IPv4.

The general format for the data structures is the same in all cases, as
shown in Figure 3.


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SecCT Type  |   SecCT Len   |   SecCT Data..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Figure 3: Security CT Options, Sub-options and Extension Format



5.1. Sub-option to transfer security context from PR to NR

This Security Context Transfer Reply suboption (SecCT-rep) is included
in the SHREP or the U-SHREP message from the PR to the NR to transfer
the security context as set of security profiles.  Figure 4 illustrates
this suboption.

The suboption type and length are followed by the Security Profile
Type and the associated security profile state variables.  The state
variables contain enough information for the NR to instantiate the
received security association and offer seamless mobility to the MN
without requiring the MN to reestablish SAs with the NR.






Gopal et.al.                Expires 12 May  2002                [Page 9]


Internet Draft         IPSec Context Transfer          12 November  2001


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SecCT-rep   |  Length       |  SPTs and Associate profiles
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Figure 4: Sub-option to transfer security context from PR to NR



5.2. Sub-option used by a MN to request security context

The suboption (Figure 5) to request transfer of security
context(SecCT-req) is included in the SHIN message sent by the
mobile node to the NR. The NR copies this suboption onto the SHREQ
message that it sends to the PR. The SecCT-req suboption is request by
the MN to transfer the corresponding security state stored on the PR
to the NR. This request triggers a reply in the form of SecCT-rep in
the SHREP message.  The SHREQ message is sent from the NR to the PR,
requesting the PR to transfer context specific to a mobile node.

The mobile node could either request the PR to transfer the entire
or partial security state.  By partial security state, we mean a few
specific security associations as against transferring all the security
associations.

      SecCT-req         8 bit field contains an IANA defined value
                        that indicates that the TLV structure contains
                        details of the security context being requested.

      Length            8 bit unsigned integer.  Defines the length
                        of the option (including the type and length
                        fields) in units of octets.

      Req-SPT           This 8 bit field defines the way the request
                        for security context is conveyed to PR. Some of
                        typical requests that we have identified for
                        which Req-SPT values need to be assigned are:

                         R1 All SAs between the MN and PR need to be
                            transferred.  In this case the fields
                            following the Req-SPT field MUST NOT be
                            sent.

                         R2 SAs identified by the sequence of triples
                            comprising of Destination IP Identity (other
                            than that of the PR), Protocol bits, SPI




Gopal et.al.               Expires 12 May  2002                [Page 10]


Internet Draft         IPSec Context Transfer          12 November  2001


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SecCT-req    |   Length      |    Reserved   |    Req-SPT    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Source  IP Identity                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Destination IP Identity                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Protocol Bit Flags                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           SPI Sequence                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Ports       |           Port ID             | Port ID ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Figure 5: Sub-option to request transfer of security context



                            need to be transferred.  Port IDs MUST not
                            be sent.  Ports field MUST be set to zero.

                         R3 SAs between the MN and PR identified by
                            the sequence of tuples comprising of the
                            Protocol bits and SPI fields need to be
                            transferred.  Port IDs MUST not be sent.
                            Ports field MUST be set to zero.

                        .

      Source IP Identity 128 (v6) or 32 (v4) bit source IP ( determined
                        by an appropriate Req-SPT value) address
                        followed by a 32 bit private ID if the IP
                        address of the source is a private or site-local
                        address.  Whether the source node belongs to
                        a private space or is globally routable is
                        determined by an appropriate Req-SPT value.  The
                        presence of the field is decided by the Req-SPT
                        value.

      Destination IP Identity 128 (v6) or 32 (v4) bit destination IP
                        ( determined by an appropriate Req-SPT value)
                        address followed by a 32 bit private ID if the



Gopal et.al.               Expires 12 May  2002                [Page 11]


Internet Draft         IPSec Context Transfer          12 November  2001


                        IP address of the destination is a private or
                        site-local address.  Whether the destination
                        node belongs to a private space or is globally
                        routable is determined by an appropriate Req-SPT
                        value.  The presence of the field is decided by
                        the Req-SPT value.

      Protocol Bit Flags Sequence of 1 bit flags whose number is deduced
                        from the Length field.  If flag value is set to
                        1 then the protocol is ESP. If set to 0 then the
                        protocol is AH. If the number of flags is not a
                        multiple of 32 bits then suitable padding (value
                        = 0) is added.  The presence of the field is
                        decided by the Req-SPT value.

      SPI Sequence      Sequence of 32 bit SPI values the number which
                        is the same as the number of protocol bit
                        flags.  The number of values in the sequence is
                        specified by the Protocols field.  The presence
                        of the field is decided by the Req-SPT value.

      Ports             8 bit field to define the number of ports
                        for which the security context has to be
                        transferred.  If this field is set to zero then
                        all the context applicable to Destination IP
                        is transferred.  The presence of the field is
                        decided by the Req-SPT value.

      Port ID           16 bit field defines the specific ports for
                        which the context has to be transferred.  This
                        field is not present if the Ports field is set
                        to 0.  The presence of the field is decided by
                        the Req-SPT value.


5.3. Sub-option used to update a MN

This sub-option, defined in the TLV format in Figure 6, is used in a
message from an AR to a MN, indicating any change in the SAs involving
the MN.

The sub-option (SecCT-ack) is included in the SHAK message sent from the
NR to a MN.

      Length            8-bit unsigned integer.  The length of the
                        option ( including the type and length fields)
                        in units of octets.





Gopal et.al.               Expires 12 May  2002                [Page 12]


Internet Draft         IPSec Context Transfer          12 November  2001


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SecCT-ack   |   Length      |  Reserved     |  Changed-SPT  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                     Changed Sec. Profiles                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 6: Sub-option to update a MN



      Changed-SPT       8 bit field indicating the modified fields in
                        the security profile.  The individual bits are
                        yet to be defined.

      Changed Sec.  Profiles This field contains the security context
                        fields that been modified.  The modified fields
                        are defined by the appropriate Changed-SPT
                        value.


5.4. Sub-option to convey status to the MN

The status of any security context transfer request is intimated to the
requesting node using the TLV data structure in Figure 7.  This data
structure may also be used to indicate the status associated with a
security context transfer response.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SecCT-Stat  |    Length     |  Reserved     |  Status-Code  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Reason....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 7: Sub-option to convey status


      SecCT-Stat        This 8 bit field contains an IANA defined value
                        that indicates that the TLV structure contains
                        the status after the security context transfer
                        request has been processed.



Gopal et.al.               Expires 12 May  2002                [Page 13]


Internet Draft         IPSec Context Transfer          12 November  2001


      Length            8 bit field denoting the length of the
                        sub-option.

      Status-Code       This is a 8 bit field that denotes the status
                        after the security context transfer request has
                        been processed.  These are defined as follows:

                          100 - Invalid source IP address
                          101 - Invalid destination IP address
                          102 - Invalid attribute value
                          103 - Invalid Src-IP-ID
                          104 - Invalid MN identity
                          105 - Invalid MN Authentication
                          106 - Unusable security context
                          200 - OK


      Reason            This variable-length field describes any
                        additional information which may be required
                        by the receiving node (NR) in order to process
                        certain errors.  This is usually a text string.
                        This field is optional.

This Security Context Transfer Status sub-option (SecCT-Stat) may be
included in one of the following messages:

    -  SHAK message sent from the NR to the MN

    -  SHREP message from the PR to the NR

    -  SHREP-ACK message sent from the NR to the PR


6. Examples of Security Profiles

In this section we describe a couple of SPT types.  Figure 8 illustrates
SPT-AH-TRANSPORT-HMACMD5-V6-Sec.  This SPT specifies that AH [9]
should be used in transport mode with HMAC_MD5-96 as the cryptographic
algorithm.  The SPT profile also specifies that IPv4 addresses are used
The variables that follow specify the security profile and the state
variables which contain information regarding the security association.
The key length is 128 bits for this SPT.

Figure 9 illustrates an example for ESP-TRANSPORT-DES-CBC- V6-Sec.  This
SPT specifies that ESP is used in transport mode with DES-CBC as the
cryptographic algorithm.  The Initialization vector (IV) and key length
is 64 bits in size.





Gopal et.al.               Expires 12 May  2002                [Page 14]


Internet Draft         IPSec Context Transfer          12 November  2001


    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  AH-TRANSPORT-HMACMD5-V4-Sec  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length       |   Reserved    |    Protocol   |  Window Size  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MN's Paddr                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AR/SG IP Identity                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            SPI                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Lifetime  (seconds)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Anti Replay Window                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Src Port               |     Destination Port          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Key Length    |               Key...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Figure 8: Security Profile for SPT-AH-TRANSPORT-HMACMD5-V4-Sec



Figure 10 illustrates an example for ESP-TRANSPORT-AES-CBC- V6-MB. This
SPT specifies that ESP is used in transport mode with AES-CBC as the
cryptographic algorithm.  In addition to the description in the previous
figure, this figure conveys the following information.  The Block Size,
Rounds and Key Length is indicated.


7. Security Considerations

All security context transfer messages MUST be protected by security
associations between the corresponding entities.  The actual transfer
of the security keys and security profile is done over the secure wired
link between the two access routers.  No additional vulnerabilities have
been introduced.


8. IANA Considerations

The Security Profile Type (SPT) and Req-SPT defined in this document
requires IANA assigned numbers.



Gopal et.al.               Expires 12 May  2002                [Page 15]


Internet Draft         IPSec Context Transfer          12 November  2001


    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |   ESP-TRANSPORT-DES-CBC-V6-Sec|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |   Reserved    |    Protocol   |  Window Size  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MN's Paddr                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    SA endpoint Identity                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            SPI                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Lifetime (seconds)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Anti Replay Window                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Src Port               |     Destination Port          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Key Length    |                Key....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Initialization Vector.....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Figure 9: Security Profile for SPT-ESP-TRANSPORT-DES-CBC-V6-Sec



References

   [1] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in
       progress). Internet Draft, Internet Engineering Task Force.
       draft-designteam-fast-mipv6-01.txt, February 2001.

   [2] J. Kempf,Editor. Problem Description:  Reasons For Performing
       Context Transfers Between Nodes in an IP Access Network (work
       in progress). Internet Draft, Internet Engineering Task Force.
       draft-ietf-seamoby-context-transfer-problem-stat-03. txt, October
       2001.

   [3] R. Koodli and C. Perkins. A Framework for Smooth Handovers
       with Mobile IPv6 (work in progress). Internet Draft, Internet
       Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt,
       November 2000.





Gopal et.al.               Expires 12 May  2002                [Page 16]


Internet Draft         IPSec Context Transfer          12 November  2001


    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   | ESP-TRANSPORT-AES-CBC-V6-MB   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |  Reserved     |    Protocol   |  Window Size  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         MN's Paddr                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     SA endpoint IP Identity                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            SPI                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Lifetime (Mbytes)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Anti Replay Window                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Src Port               |     Destination Port          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Key Length  |                   Key
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Block Size   |   Key Rounds  |     Initialization Vector....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Figure 10: Security Profile for SPT-ESP-TRANSPORT-AES-CBC-V6-MB



   [4] H.Syed, G.Kenward et al. General Requirements for a Context
       Transfer (work in progress. Internet Draft, Internet Engineering
       Task Force. draft-ietf-seamoby-ct-reqs-01.txt. September 2001

   [5] L-N. Hamer and B. Kosinski. IPSec Context Transfer (work in
       progress). Internet Draft, Internet Engineering Task Force.
       draft-hk-seamoby-ct-ipsec-00.txt. May 2001

   [6] Ram Gopal. L, G. Krishnamurthi, S. Sengodan, Issues in IPSec
       Context Transfer (work in progress). Internet Draft, Internet
       Engineering Task Force. draft-gopal-seamoby-IPSecCxt-00.txt. Nov
       2001

   [7] Patrik Flykt, C. Perkins and Thomas Eklund. AAA for IPv6 Network
       Access (work in progress). Internet Draft, Internet Engineering
       Task Force. draft-perkins-aaav6-04.txt. July 2001





Gopal et.al.               Expires 12 May  2002                [Page 17]


Internet Draft         IPSec Context Transfer          12 November  2001


   [8] S. Kent and R. Atkinson. Security Architecture for the Internet
       Protocol. RFC 2401, Internet Engineering Task Force. November
       1998.

   [9] S. Kent and R.Atkinson. IP Authentication Header. RFC 2402,
       Internet Engineering Task Force. November 1998

   [10] S. Kent and R. Atkinson. IP Encapsulating Security Payload (
       ESP). RFC 2406, Internet Engineering Task Force. November 1998


Author's Addresses


     Ram Gopal L.
     Govind Krishnamurthi
     Senthil Sengodan
     Communications Systems Lab
     Nokia
     5 Wayside Road
     Burlington, MA 01803
     USA
     Phone:  +1- 781-993-3685
     Email:  ram.gopal@nokia.com
     govind.krishnamurthi@nokia.com
     senthil.sengodan@nokia.com

     Vijay Devarapalli
     Rajeev Koodli
     Charles Perkins
     Communications Systems Lab
     Nokia Research Center
     313 Fairchild Drive
     Mountain View, CA 94043
     USA
     Email:  vijay.devarapalli@nokia.com
     rajeev.koodli@nokia.com
     charliep@iprg.nokia.com














Gopal et.al.               Expires 12 May  2002                [Page 18]