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]