Internet DRAFT - draft-hk-seamoby-ct-ipsec
draft-hk-seamoby-ct-ipsec
SeaMoby Working Group L-N. Hamer
Internet Draft B. Kosinski
Document: draft-hk-seamoby-ct-ipsec-00.txt
Nortel Networks
May 28, 2001
IPSec Context Transfer
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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
The distribution of this memo is unlimited. This memo is filed as
<draft-hk-seamoby-ct-ipsec-00.txt>, and expires November 2001.
Please send comments to the authors.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
1. Abstract
There are a large number of IP access networks where one may wish to
provide security for end user traffic, or secure the access network
from unauthorized traffic. One protocol which may be used to
provide these services is IPSec, which requires a node to establish
a security association with the access network in order to obtain
these services. Traditionally, such an association is considered
static, however, there are many situations in which the ability to
move an IPSec security association (SA) from one security gateway
(SG) to another within the access network may be beneficial.
Examples of this include IPSec handover in mobile LANs and PANs,
load-balancing between IPSec SGs, and fail-over applications where
high-availability is required. Currently, in order to perform this
Hamer,Kosinski Expires November 2001 [Page 1]
Internet Draft IPSec context transfer
transfer, it would be necessary to terminate the existing SA and re-
negotiate a new SA at the new SG. However, this approach may be
inappropriate in cases where high performance is required. Thus, in
such cases, the ability to directly transfer an SA from one SG to
another would be useful.
The intent of this draft is to describe the unique requirements for
transfer of IPSec context and to detail the specific data which must
be transferred in order to move an IPSec SA. In addition, a number
of unique issues regarding IPSec context transfer will be addressed,
and some potential solutions discussed.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
Hamer,Kosinski Expires November 2001 [Page 2]
Internet Draft IPSec context transfer
3. Introduction
There are a large number of IP access networks where one may wish to
provide security for end user traffic, or secure the access network
from unauthorized traffic. One protocol which may be used to
provide these services is IPSec, which requires a node to establish
a security association with the access network in order to obtain
these services. Traditionally, such an association is considered
static, however, there are many situations in which the ability to
move an IPSec security association (SA) from one security gateway
(SG) to another within the access network may be beneficial.
Examples of this include IPSec handover in mobile LANs and PANs,
load-balancing between IPSec SGs, and fail-over applications where
high-availability is required. Currently, in order to perform this
transfer, it would be necessary to terminate the existing SA and re-
negotiate a new SA at the new SG. However, this approach may be
inappropriate in cases where high performance is required. Thus, in
such cases, the ability to directly transfer an SA from one SG to
another would be useful.
Much of the work in establishing a generic context transfer
framework has already begun [2][3]. These documents focus on the
generic requirements and framework for context transfer. However,
one must identify, for each feature to which context transfer is
applicable, the data which must be transferred, and any unique
requirements which are relevant. This document attempts to define
the contents of the IPSec feature context and the specific
requirements applicable to IPSec. In addition, a number of unique
issues regarding the transfer of IPSec context will be discussed,
along with potential solutions.
4. Terminology
Much of the terminology used in this document is the same as that
found in [2]. However, a number of additional definitions are
provided below:
o SA - Security association. Defined in [4] as a "simplex
ęconnectionĘ that affords security services to the traffic
carried by it."
o SG - Security gateway. A network entity with which a node
may establish one or more security associations, either from
the node to the gateway or vice versa.
Hamer,Kosinski Expires November 2001 [Page 3]
Internet Draft IPSec context transfer
5. Reasons for IPSec CT
Currently, the only approaches for re-establishing an IPSec session
involve tearing down the old IPSec SAs and establishing new SAs with
the aid of a key exchange protocol such as IKE [7] or KINK.
Unfortunately there are many problems with this approach, the main
ones being long latency and excessive signalling during handover.
This document addresses another approach, where access routers
exchange state information directly. This approach has many
advantages, such as reduced latency during handover and minimal
signalling from the mobile node.
6. Network Model
When discussing IPSec context transfer between SGs, the following
network model will be assumed:
+- Access Network -+
+--------+ | +-----+ | +----------+ +------+
| Mobile |===|=====| SG1 |------|--|----------|---| End |
| Node | | +-----+ | | | | |
+--------+ | | | Internet | | Host |
| ... | | | +------+
| +-----+ | +----------+
| | SGm | |
| +-----+ |
+------------------+
Where context transfer may occur between any two SGs in the access
network. It is assumed that the SA between the MN and SG is an IPSec
SA in tunnel mode. Either AH [5] or ESP [6] may be used depending
upon whether or not encryption is required.
7. Context Transfer Requirements
All of the specific requirements defined in [3] are applicable to
the transfer of IPSec context. In addition, one of the primary
requirements of IPSec is that the identity of the security gateway
MUST be known to the mobile node, in order to properly encapsulate
packets for transmission.
7.1 Discovery and Update of SG Identity at MN
Due to the peer to peer nature of the IPSec architecture, it is
necessary for the nodes participating in an SA to know the identity
of each other. Under normal circumstances, this is not an issue.
However, in the case of context transfer, the identity of the SG may
change on-the-fly. As a result, there must be some way to ensure
Hamer,Kosinski Expires November 2001 [Page 4]
Internet Draft IPSec context transfer
that the mobile node transmits packets to the correct SG, even after
a context transfer. There are two primary solutions to this issue:
Direct SG Communication:
Direct SG communication requires that the node be able to
discover the address of the initial SG through some means
(DHCP, DNS, etc). In addition, during handover to a new SG,
the node must be notified of the new SG address through some
form of signaling so that the local SAD in the MN may be
updated to reflect the address of the new SG.
Indirect SG Communication:
This form of communication requires some form of tunnel to be
set up from the node to a virtual SG. This is achieved with
the use of a virtual address for the SG. The node must somehow
retrieve (via DHCP, DNS, etc) the virtual address necessary to
communicate to the SG currently serving the MN. Then, during
handover, the network takes care of correctly re-directing
traffic destined to the new SG, making the process transparent
to the mobile node.
Each method has its pros and cons. Direct communication reduces the
complexity in the network but requires additional signaling, and
thus added latency. The indirect form requires added complexity at
the network, but is transparent to the node. One must weigh these
factors when considering an appropriate mechanism for solving this
problem.
7.2 PMTU Rediscovery
The IPSec architecture, as defined in [4], requires that the nodes
participating in an SA be aware of the Path MTU over which the
treated packets are traveling. However, if a context transfer
occurs, and the new SG is in another location in the network, it is
possible for the PMTU of the underlying network to change. This is
not a problem if the PMTU of the new path is greater than that of
the old path. However, if the PMTU decreases, this may cause
problems for applications which rely on knowledge of the PMTU.
Possible solutions to this problem may include PMTU rediscovery, or
even network engineering to avoid the problem entirely. However,
this issue is really one of general context transfer, and thus will
not be discussed here.
7.3 SA Conflict Resolution
During a context transfer, it is possible that the new SG which has
been targeted as the candidate for context transfer may not be able
to support the SAs being transferred (i.e., unavailability of
ciphering algorithms, etc). The method for dealing with this
Hamer,Kosinski Expires November 2001 [Page 5]
Internet Draft IPSec context transfer
situation is beyond the scope of this document, but may include
selection of a new candidate SG, or the termination of the IPSec
SAs, forcing the mobile node to establish a new SA pair with the new
SG, allowing for re-negotiation of the SA parameters.
8. IPSec Feature Context
When determining the contents of the IPSec feature context, one must
examine all the state, which is maintained at the SG. The actual
data, which is stored in the gateway is collected in the Security
Policy Database (SPD) and the Security Association Database (SAD)
[5].
The security policy database contains some static entries,
containing general policies, which are established by the operator
of the access network, and should not be transferred. Generally,
these SPD entries are the same on all SGs within the operator
domain.
The SPD also contains selector parameters used to support SA
management to facilitate control of SA granularity. In fact, an SA
may be fine-grained or coarse-grained, depending on the selectors
used to define the set of traffic for the SA. The selectors used to
define the SA MUST be context transferred.
Selector Fields:
Source and Destination IP Address
Source and Destination Port
Transport Layer Protocol
Name
Sensitivity Level
These fields are used by the gateway to identify packets for inbound
and outbound processing. Note, fields not used to match packets
against this SA MAY be omitted. Therefore, if, for example, only
the source and destination IP addresses are used as a selector, the
other fields MAY be excluded.
For inbound processing, the following packet fields are used to look
up the SA in the SAD:
Outer HeaderĘs Destination IP address.
IPSec Protocol (AH or ESP)
SPI: the 32-bit value used to distinguish among different SAs
terminating at the same destination and using the same IPSec
protocol.
These fields are used by a gateway to look up the SA in the SAD.
Therefore, they MUST be context transferred.
Hamer,Kosinski Expires November 2001 [Page 6]
Internet Draft IPSec context transfer
Treatment Fields:
Sequence Number
Sequence Number Overflow Flag
Antireplay Window
AH Algorithm, keys, etc
ESP Encryption Algorithm, keys, IV Mode, IV, etc
ESP Authentication Algorithm, keys, etc
Lifetime
Protocol Mode
Path MTU
Treatment fields are used by the IPSec stack in actually processing
the packets, once it has been determined that they must be treated.
Again, fields which are not applicable to this SA MAY be omitted.
For example, depending on the protocol mode, either the ESP or AH
fields need not be transferred. Others may not need to be
transferred depending on the IPSec implementation (for example, some
IPSec stacks allow disabling of sequence number checking, thus these
fields may not need to be transferred).
Note, there are a number of fields in the IPSec context which are
used to identify replay attacks in real time. These include the
anti-replay window and the sequence number. These fields may
initially cause concern, as they must be updated in real time, and
should reflect the current state of the IPSec SA. The concern is
that these fields may not be entirely accurate after context
transfer because of the loss of some user packets. Careful
considerations reveal this is not a problem. In fact, IPSec anti-
replay functionalities were designed to accommodate minor packet
loss [4].
The only major problem that may occur during the context transfer of
an IPSec SA is when the SPI value of an IPSec SA to be transferred
is already in use at the new SG. In this scenario, three possible
solutions are to be considered:
-Deny the context transfer.
-Accept the context transfer but force re-negotiation of the
IPSec SA.
-Assign a new SPI entry unused at the new SG and signal this
information back to the mobile node. This operation MUST be
secure since it may open up some security holes.
9. Security Considerations
Careful consideration needs to be taken to ensure that the context
transfer of an IPSec SA is secure, especially when transferring SA
information such as keys. In fact, as defined in [3], context
transfer MUST be secure. How to secure the context transfer is
Hamer,Kosinski Expires November 2001 [Page 7]
Internet Draft IPSec context transfer
dependent on the network environment. In a trusted environment, no
additional security mechanism is needed. But in an un-trusted
environment, a security mechanism MUST be utilized.
In order to keep the context transfer protocol simple, re-use of
existing security technologies is recommended. All security
requirements MAY be provided at the network layer with IPSec or at
the transport layer with TLS.
10. References
[1] S. Bradner, "keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997.
[2] The seamoby CT design team, "Context transfer: problem
statement", draft-ietf-seamoby-context-transfer-problem-stat-
00.txt.
[3] The seamoby CT design team, "General Requirements for a Context
Transfer Framework", draft-ietf-seamoby-ct-reqs-00.txt.
[4] S. Kent et. Al., "Security Architecture for the Internet
Protocol" RFC-2401, November 1998
[5] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[6] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[7] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
11. Acknowledgments
The authors would like to thank to following people for their useful
comments and suggestions related to this draft: Hamid Syed, Gary
Kenward, Jerry Chow and Bill Gage.
12. Author's Addresses
Louis-Nicolas Hamer
Nortel Networks
Ottawa, ON
CANADA
Email: nhamer@nortelnetworks.com
Hamer,Kosinski Expires November 2001 [Page 8]
Internet Draft IPSec context transfer
Brett Kosinski
Nortel Networks
Ottawa, ON
CANADA
Email: brettk@nortelnetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organisations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into.
Expiration Date
This memo is filed as <draft-hk-seamoby-ct-ipsec-00.txt>, and
expires November 2001.
Hamer,Kosinski Expires November 2001 [Page 9]
