Internet DRAFT - draft-gopal-seamoby-ipsec-relocate
draft-gopal-seamoby-ipsec-relocate
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]
