Seamoby Working Group Ram Gopal.L INTERNET DRAFT Govind Krishnamurthi November 2001 Senthil Sengodan Expires May 2002 Nokia Issues in IPSec Context Transfer draft-gopal-seamoby-ipsecctxt-issues-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 [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 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 1. Abstract The reasons and the motivation for transferring context have been described in [1]. The requirements for a context transfer protocol can be found in [2]. In this document, we describe issues that need to be considered for transferring security (specifically IPsec) related context between access routers. While [3] has addressed issues involved in IPSec feature context transfer, the scope and aspects included here are broader than in [3]. Some of the aspects that are addressed here but not in [3] are the various types of SAs Gopal, Krishnamurthi, Sengodan [Page 1] Internet Draft Issues in IPSec Context Transfer Nov 2001 whose context may be transferred, utilizing the user's static profile when available at the new access router, etc. 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]. 3. Terminology In addition to the terms used in [1],[2],[3], we define the following terms: o MN - Mobile Node o PR - Previous AR. o NR - New AR. o FP - Forwarding Path. The path traversed by packets when they go from their source to destination. FP may correspond to the control, data or management plane. o PFP - Previous FP. The FP when the access router that the MN is connected to is PR. o NFP - New FP. The FP when the access router that the MN is connected to is NR. The destination itself may be different along the NFP compared to that along the PFP. o Data FP - The FP for packets in the data plane. o Control FP - The FP for packets in the control plane. o Management FP - The FP for packets in the management plane. o G - Gateway. This is an entity from which point onwards the FP to the CN remains unchanged. o SA - Security Association. This may be either a Data SA, a Control SA or a Management SA. o Data SA - SA that provides security services to packets in the Data FP. Such an SA may be between any two entities along the Data FP. Gopal, Krishnamurthi, Sengodan [Page 2] Internet Draft Issues in IPSec Context Transfer Nov 2001 o Control SA - SA that provides security services to packets in the Control FP. Such an SA may be between any two entities along the Control FP. o Management SA - SA that provides security services to packets in the Management FP. Such an SA may be between any two entities along the Management FP. 4. Introduction The purpose of this document is to describe issues that need to be considered for IPSec security context transfer. While [3] has addressed issues involved in IPSec feature context transfer, the scope and aspects included here are broader than in [3]. Some of the aspects that are addressed here but not in [3] are the various types of SAs whose context may be transferred, utilizing the user's static profile when available at the new access router, etc. The organization of the document is as follows. Section 5 describes several types of Security Associations (SA) and a model for illustrating where/how these SAs fit in. The coverage in this section is illustrative, and is not meant to be exhaustive. Irrespective of the type of SA (whether it is described in Section 5 or not), Section 6 describes the issues involved in IPSec security context for this SA. 5. Illustrating Various Types of SAs While discussing IPSec context transfer between ARs, in order to describe several types of IPSec SAs for which the IPSec context needs to be transferred, the following model is illustrative: +- Access Network -+ +--------------+ +--------+ | +-----+ | | +----+ | +--------------+ | Mobile |===|=====| PR |======|==|=======| G |=|===| | | Node | | +-----+ | | +----+ | | Remote | | (MN) | | | | Internet * | | Node | | | | | | * | | (RN) | | | | +-----+ | | * | | | | |***|*****| NR |******|**|*********** | | | | | | +-----+ | | | | | +--------+ +------------------+ +--------------+ +--------------+ Figure 1: Model for Problem Statement Gopal, Krishnamurthi, Sengodan [Page 3] Internet Draft Issues in IPSec Context Transfer Nov 2001 In Figure 1, the line from an MN to RN denoted using "=" represents the previous forwarding path (PFP), while the line from the MN to RN denoted using "*" represents the new forwarding path (NFP). "G" denotes the network entity beyond which the forwarding path to RN remains unchanged. The case of RN representing different physical nodes along PFP and NFP is also subsumed by the above model. It may be noted that when the AR changes from PR to NR, the change in the forwarding path (FP) may either be marginal or significant. At one extreme (marginal case), G is collocated with PR, while at the other extreme (significant case), G is collocated with RN. The FP may correspond to Data, Control or Management FP. When the Data FP is being considered, RN corresponds to the correspondent node (CN). When the Control FP is being considered, RN corresponds to an entity with which MN exchanges control messages. Similarly, when the Management FP is being considered, RN corresponds to an entity with which MN exchanges messages in the Management plane. Note: 1. The model has been generalized to accommodate data, control and management plane messages between the MN and a remote node. While it may be the case that management plane messages between MN-RN may either not exist or may not be of interest, the framework covers such aspects as well should they be deemed necessary in certain scenarios. 2. The model may be extended to cover the case of data, control and management plane messages between any two entities, and not restricting itself to the case where one of the entities is MN. It may be reiterated that the model is not meant to be exhaustive, but is merely intended to illustrate many types of SAs whose context may be transferred. 5.1 Types of SAs For the scenario depicted in Figure 1, several types of SAs are possible: (1) Type 1 SA: Each endpoint of such an SA lies between G (inclusive) and RN (inclusive). There is no change in such SAs when the FP changes from PFP to NFP. (2) Type 2 SA: One endpoint of such an SA is at MN, while the other endpoint is between G (inclusive) and RN (inclusive). There is no change in such an SA when the FP changes from PFP to NFP. (3) Type 3 SA: One endpoint of such an SA is between PR (inclusive) and G (exclusive), while the other endpoint is between G (inclusive) and RN (inclusive). Gopal, Krishnamurthi, Sengodan [Page 4] Internet Draft Issues in IPSec Context Transfer Nov 2001 (4) Type 4 SA: Each endpoint of such an SA lies between PR (inclusive) and G (exclusive). When the FP changes from PFP to NFP, then both endpoints of such SAs change. (5) Type 5 SA: One endpoint of such an SA is at MN, while the other lies between PR (inclusive) and G (exclusive). When the FP changes from PFP to NFP, then one endpoint of such SAs change. Along any data FP, control FP or management FP, there may be zero, one or more SAs of any given SA type. While the SAs discussed here are with respect to the PFP, it may be noted that an SA type may only be known after the NFP is determined and any SGs along this NFP are discovered. A reason for this is that "G" is not known until the NFP is known. 5.2 Illustrating SA types The notation used in the illustrations below is as follows. S1 represents one endpoint of the SA, while S2 represents the other. It is immaterial if the SA itself is directed from S1 towards S2, or vice versa. When an endpoint of the SA (either S1 or S2) may not be collocated within a certain entity (i.e., exclusive case) then this is indicated by lines with "%". For example, in Figure 4, since S1 or S1' may not be collocated with G, two sides of the box have a "%" Type 1 SA: As illustrated in Figure 2, the two endpoints of the SA (S1 and S2) lie between G (inclusive) and RN (inclusive). Action: No security context needs to be transferred for such SAs during context transfer. +--------+ +----+ +---+ +--+ +--+ +--+ | Mobile |==| PR |=====| G |====|S1|======|S2|======|RN| | Node | +----+ +---+ +--+ +--+ +--+ | (MN) | * | | * | | +-----+ * | |**| NR |******* | | +-----+ +--------+ Figure 2: Type 1 SA between S1 and S2 Type 2 SA: As illustrated in Figure 3, S1 is collocated with MN, while S2 lies between G (inclusive) and RN (inclusive). Action: No security context needs to be transferred for such SAs during context transfer. Gopal, Krishnamurthi, Sengodan [Page 5] Internet Draft Issues in IPSec Context Transfer Nov 2001 +--------+ +----+ +---+ +--+ +--+ | Mobile |==| PR |=====| G |==========|S2|======|RN| | Node | +----+ +---+ +--+ +--+ | (MN) | * | | * | | +-----+ * | S1 |**| NR |******* | | +-----+ +--------+ Figure 3: Type 2 SA between S1 and S2 Type 3 SA: As illustrated in Figure 4, S1 lies between PR (inclusive) and G (exclusive), while S2 lies between G (inclusive) and RN (inclusive). Action: In this case, S1' may represent the new entity to which context at S1 is moved. Note that one special case of Type 3 SAs is the case where S1 is collocated with PR, while S1' is collocated with NR. +--------+ +----+ +--+ %---+ +--+ +--+ | Mobile |==| PR |====|S1|======% G |=====|S2|======|RN| | Node | +----+ +--+ %%%%% +--+ +--+ | (MN) | * | | * | | +----+ +---+ * | |**| NR |****|S1'|******** | | +----+ +---+ +--------+ Figure 4: Type 3 SA between S1 and S2 Type 4 SA: As illustrated in Figure 5, both S1 and S2 lie between PR (inclusive) and G (exclusive). Action: In this case, S1' may represent the new entity to which context at S1 is moved, while S2' may represent the new entity to which context at S2 is moved. Note that one special case of Type 4 SAs is the case where S1 is collocated with PR, while S1' is collocated with NR. +--------+ +----+ +--+ +--+ %---+ +--+ | Mobile |==| PR |====|S1|====|S2|=====% G |==========|RN| | Node | +----+ +--+ +--+ %%%%% +--+ | (MN) | * | | * | | +----+ +---+ +---+ * | |**| NR |****|S1'|***|S2'|******* | | +----+ +---+ +---+ +--------+ Figure 5: Type 4 SA between S1 and S2 Gopal, Krishnamurthi, Sengodan [Page 6] Internet Draft Issues in IPSec Context Transfer Nov 2001 Type 5 SA: As illustrated in Figure 6, S1 is collocated with MN, while S2 lies between PR (inclusive) and G (exclusive). Action: In this case, S2' may represent the new entity to which context at S2 is moved. +--------+ +----+ +--+ %---+ +--+ | Mobile |==| PR |====|S2|======% G |===========|RN| | Node | +----+ +--+ %%%%% +--+ | (MN) | * | | * | (S1) | +----+ +---+ * | |**| NR |****|S2'|******** | | +----+ +---+ +--------+ Figure 6: Type 5 SA between S1 and S2 5.3 Grouping SA types: Multi-lateral and Multi-level SAs The five SA types may be grouped in a variety of fashions within the actual topology. These are illustrated below: o SAs may be grouped in a multi-lateral fashion, such that one or more of the same or different types of SAs are present in a sequential fashion. Figure 7 illustrates this scenario, where S1- S2 represents one SA, while Sa-Sb represents another. +--------+ +----+ +--+ +--+ %---+ +--+ | Mobile |==| PR |====|Sa|====|Sb|=====% G |==========|RN| | Node | |(S2)| +--+ +--+ %%%%% +--+ | (MN) | +----+ * | | * | | +-----+ +---+ +---+ * | (S1) |**| NR |***|Sa'|***|Sb'|******* | | |(S2')| +---+ +---+ +--------+ +-----+ Figure 7: Illustrating multi-lateral SAs o SAs may be grouped in a multi-level fashion, such that one or more of the same or different types of SAs are stacked one upon the other. Figure 8 illustrates this scenario, where S1-S2 represents one SA, while Sa-Sb represents another. Gopal, Krishnamurthi, Sengodan [Page 7] Internet Draft Issues in IPSec Context Transfer Nov 2001 +--------+ +----+ +--+ +--+ %----+ +--+ | Mobile |==| PR |====|Sa|====|Sb|=====% G |==========|RN| | Node | | | +--+ +--+ %(S2)| +--+ | (MN) | +----+ %%%%%% | | * | | +-----+ +---+ +---+ * | (S1) |**| NR |***|Sa'|***|Sb'|******** | | | | +---+ +---+ +--------+ +-----+ Figure 8: Illustrating multi-level SAs 5.4 Some Specific Scenarios Some typical scenarios where security context needs to be transferred are now discussed. 5.4.1 MN-PR control FP SA Figure 9 illustrates the case where a control SA that exists between MN-PR is replaced by a control SA that exists between MN-NR. +--------+ +----+ | Mobile |==| PR | | Node | |(S2)| | (MN) | +----+ | | | | +-----+ | (S1) |**| NR | | | |(S2')| +--------+ +-----+ Figure 9: Illustrating MN-PR Control FP SA 5.4.2 MN-SG data FP SA Figure 10 illustrates the case where a data SA that exists between MN-SG1 is replaced by a data SA that exists between MN-SG2. Gopal, Krishnamurthi, Sengodan [Page 8] Internet Draft Issues in IPSec Context Transfer Nov 2001 +--------+ +----+ +-----+ %---+ +--+ | Mobile |==| PR |====| SG1 |=========% G |==========|RN| | Node | |(S2)| |(S2) | %---+ +--+ | (MN) | +----+ +-----+ * | | * | | +-----+ +-----+ * | (S1) |**| NR |***| SG2 |************ | | |(S2')| |(S2')| +--------+ +-----+ +-----+ Figure 10: Illustrating MN-SG Data FP SA 6. Context Transfer Requirements 6.1 Entities involved in context transfer It was seen that no security context needs to be moved for Type 1 or Type 2 SAs, but security context may need to be moved for Type 3, 4 or 5 SAs. Irrespective of the type of SA (Type 3, 4 or 5) whose context needs to be transferred or the number of such SAs for which context needs to be transferred, the context is always transferred from the PR to the NR. This has the following implications: o All IPSec security context for any SA in the PFP may need to be made available to the PR. o After the IPSec security context for one or more SAs in the PFP has been transferred from PR to NR, a mechanism is needed to move these contexts to the appropriate SA endpoint in the NFP. As an illustration of this approach, consider a Type 4 SA in Figure 5, where context at S1 needs to be moved to S1', and context at S2 needs to be moved to S2'. In this case, the contexts at S1 and S2 are made available at PR, which then transfers them to NR, and NR subsequently moves these contexts to S1' and S2' respectively. For the case where the security context already exists at PR and where the new location of the security context is NR (for instance, the case of Section 4.4.1), no context needs to be moved either from a different entity to PR along PFP or from NR to a different entity along NFP. 6.2 Discovery of SGs along FP Along any FP (PFP or NFP), the SGs have to be discovered and the SAs that need to be established have to be identified. When the FP changes from PFP to NFP, there exists two possibilities: o One or more security contexts associated with SAs along the PFP, may be transferred from PR to NR "prior" to discovering either the NFP and/or SGs along the NFP. Gopal, Krishnamurthi, Sengodan [Page 9] Internet Draft Issues in IPSec Context Transfer Nov 2001 o One or more security contexts associated with SAs along the PFP, are transferred from PR to NR "only after" the NFP is known and the SGs along the NFP have been discovered. There are trade-offs to each of these two approaches. In the former case, the knowledge of the PFP, SGs and their associated security context along the PFP at the NR may help in establishing the NFP. The NFP, of course, would still have to be in conformance with the user's static profile. In the latter case, knowing the NFP, the NR may selectively request security context transfer (or may even not have to request any security context transfer) from PR. Such discovery of SGs along any FP is not within the scope of this document. 6.3 IPv4 and IPv6 address support This requirement fits within the framework of general context transfer requirements. Context transfer should be possible irrespective of whether one or both ARs have either an IPv4 or an IPv6 address. 6.4 Private Addressing support This requirement fits within the framework of general context transfer requirements. Context transfer should be possible irrespective of whether one or both ARs have a private IPv4 address. One mechanism that may be used to handle the case of private addresses is as described in [9]. 7. IPSec Security Context The IPSec feature context itself is comprised of several components: o Part or whole of the static profile associated with the 'user'. o Selector fields of an SA o SPI value o The static attributes of an SA o The dynamic attributes of an SA o Replay window parameters Each of these is discussed in greater detail below. 7.1 User's static profile Security requirements pertaining to a user are stored within the user's static profile. Among other things, such a profile may specify the range of security mechanisms, security algorithms, key lengths etc. that may be used for security associations pertaining to the user. The various options provided in the profile may also be in a certain preferred order, so that a certain option is only chosen if Gopal, Krishnamurthi, Sengodan [Page 10] Internet Draft Issues in IPSec Context Transfer Nov 2001 an option of higher preference is not available. For instance, a decreasing order of preference for encryption algorithms could be "AES, 3-DES, DES", implying that 3-DES is to be used only if AES is cannot be used, and that DES is to be used only if both AES and 3- DES cannot be used. Similarly, a decreasing order of preference for key lengths used within AES could be "256, 192, 128", implying that a 192-bit key is to be used only when a 256-bit key cannot be used, and that a 128-bit key is to be used only when both 256-bit and 192-bit keys cannot be used. The reason that the user's static profile may have to be known at the NR is that along the NFP, it may be possible to use a certain option in the static profile that has a higher preference than which is used within an SA along the PFP. For instance, if we consider a Type 5 SA (as shown in Figure 6), it may be possible that 3-DES is used between S1-S2 because S2 does not support AES, but that S2' supports AES. In this case, although not always, it may be desirable to support the more preferred option along the NFP. If the user's static profile is not sent, then the NR would not have this choice. 7.2 Selector fields of an SA Selector fields are used to determine which packets are provided the services of a particular SA. While some selector fields are always sent, others are optional. Selectors that are always sent are the source IP address and the destination IP address. Optional selectors are the source port, destination port, TOS byte etc. 7.3 SPI value The SPI value is sent so that it could be reused at the endpoint of the SA along the NFP. 7.4 Static attributes of an SA Static attributes of an SA refer to those attributes that are instantiated at the time of SA establishment, and which do not change with time. Examples of such attributes include: o Authentication/encryption algorithm o Key length o Block size o Algorithm mode 7.5 Dynamic attributes of an SA Dynamic attributes of an SA refer to those attributes that change with time. Examples of such attributes include: o SA duration (in terms of seconds or bytes transmitted) before key refresh Gopal, Krishnamurthi, Sengodan [Page 11] Internet Draft Issues in IPSec Context Transfer Nov 2001 7.6 Replay window parameters A receiver of an IPSec SA may decide to activate anti-replay protection. Parameters relevant to anti-replay protection are: o window size o highest sequence number of an authenticated packet o indication of whether packets within window have been successfully received or not When the IPSec security context is transparently sent from PR to NR, the replay window parameters are also sent. Using these parameters, the entity that receives this security context from the NR in the NFP, may transparently start providing anti-replay protection. 8. Security Considerations The IPSec security feature context that is to be transferred from AR to PR involves several security considerations: o Discovery of SGs along a forwarding path needs to be done in a secure fashion. o Transmission of security context from an endpoint of an SA to the PR needs to be done in a secure fashion. o Transmission of security context from PR to NR needs to be secure. o Transmission of security context from NR to the endpoint of the SA along the NFP needs to be secure. 9. References [1] Levkowetz et al., "Context transfer: problem statement", draft-ietf-seamoby-context-transfer-problem-stat- 00.txt. [2] Syed et al., "General Requirements for a Context Transfer Framework", draft-ietf-seamoby-ct-reqs-00.txt. [3] L-N. Hamer, B. Kosinski, "IPSec Context Transfer," work-in- progress, draft-hk-seamoby-ct-ipsec-00.txt, May 2001. [4] S. Bradner, "keywords for use in RFCs to Indicate Requirement Levels", RFC2119 (BCP), IETF, March 1997. [5] S. Kent et. Al., "Security Architecture for the Internet Protocol" RFC-2401, November 1998 [6] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [7] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. Gopal, Krishnamurthi, Sengodan [Page 12] Internet Draft Issues in IPSec Context Transfer Nov 2001 [8] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [9] D. Trossen et. al., "Protocol for Anticipated Candidate Access Router Discovery for Seamless IP-level Handovers," draft- trossen-seamoby-CARdiscovery-anticipated-00.txt, Aug 2001. 10. Author's Addresses Ram Gopal.L Govind Krishnamurthi Senthil Sengodan Nokia Research Center 5 Wayside Road Burlington, MA 01803 USA email: {ram.gopal,govind.krishnamurthi,senthil.sengodan}@nokia.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.