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 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]