IPSECME T. So Internet Draft ZTE USA Intended status: standard Z. Qiang Expires: July 2012 Ericsson February 7, 2012 IKEv2 Configuration Payload Extension for Private IPv4 Support for Fixed Mobile Convergence draft-so-ipsecme-ikev2-cpext-01.txt Abstract IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many standardized network solutions to provide the secure transport between network elements over third party's infrastructure. For example, the emerging Fixed Mobile Convergence (FMC) network solution that involves Femtocell deployment requires the mobile operator's Femtocell AP to leverage the IPSec IKEv2 to support mutual authentication and remote IP address configuration as well as other auto configuration support over the broadband fixed network (BBF) of which the mobile and fixed networks may be operated by two different operators. Most of today broadband fixed networks are still relying on the IPv4 private addressing plan to support its attached devices including the mobile operator's Femtocell AP. Hence, the private IPv4 addressing and Network Address and Port Translation (NA(P)T) support mostly likely stays for many years to come. In FMC interworking scenario, there is a need for the mobile network to pass on it mobile subscribers' policies to the broadband fixed network (BBF) to maintain the service level agreement (SLA) and to support remote network management. In addition, a broadband fixed network (BBF) may partnership with more than one mobile operator. Therefore it is important for the BBF and the mobile network to be able to overcome the limitation of the private IPv4 addressing and to be able to identify the user's subscription as well as to determine the location of the Femtocell AP that serves its mobile user over the BBF network. This document presents the problems for the IPSec tunneling support with private IPv4 addressing for FMC interworking and proposes a simple extension to the IKEv2 to resolve the issues. So Expires August 7, 2012 [Page 1] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 Internet-Draft will expire on July 7, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. So Expires August 7, 2012 [Page 2] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 Table of Contents 1. Introduction...................................................4 1.1. Terminology...............................................5 FAP...............................................................5 1.2. Requirement for FAP location verification.................6 1.3. Requirement for FAP's identification for the attached mobile UE.............................................................7 2. Problem statements.............................................9 2.1. Considerations of STUN support for FMC interworking with FAP ..............................................................10 3. Proposed Solution - Extension to IKEv2 Configuration Payload..11 3.1. Details of proposed changes to RFC 5996 [RFC5996] for IKEv2 CP............................................................13 4. Security Considerations.......................................15 5. IANA Considerations...........................................15 6. Conclusions...................................................16 7. References....................................................16 7.1. Normative References.....................................16 7.2. Informative References...................................16 8. Acknowledgments...............................................16 Table of Figures Figure 1: Femto-AP (FAP) E2E Configuration ...................... 5 Figure 2: Example of the typical IP Addressing used across the BBF and Mobile Network for Femto-cell deployment with IPSec Tunneling 8 Figure 3: Example of the IKEv2 Configuration Payload solution to carry the public IPv4 address and port number of the UDP header for the encapsulated IPSec tunnel....................................13 So Expires August 7, 2012 [Page 3] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 1. Introduction Today many network solutions leverage the IPSec IKEv2 to provide the secure transport as well as some form remote configuration support for their network elements over third party infrastructure (e.g. ADSL, Cable etc.). The standardized Femtocell architecture from Femto Forum as well as from many mobile standards (e.g. 3GPP, 3GPP2 and WiMAX) are good examples that all have common architecture to leverage the IPSec IKEv2 to interconnect the Femtocell AP (FAP) with the Security Gateway (SeGW) over the broadband fixed (BBF) network (e.g. ADSL, Cable networks etc.). Both the Femtocell AP (FAP) and the SeGW are managed by the mobile operator which may be a different operator for the BBF network. Most BBF networks today operate on the private IPv4 addressing plan within their networks and rely NA(P)T for external communication. For the FMC scenario, a given BBF network may require to be able to interwork with more than one mobile network which may also deploy its own private IPv4 addressing plan. Given each operator manages their own private IPv4 addressing plan within their network domains and they need to support inter-operators subscribers policy exchange, this introduces a major challenge on how to coordinate the private and public addressing across the operators' domains so that the mobile network can locate the serving BBF access network that its mobile user equipment (UE) is attached to and the mobile user's identity, so that the BBF network can provide the appropriate FMC interworking policy and bearer control on its UE, and also to enable the remote network management, when required. The following presents an example of typical Femtocell network configuration. So Expires August 7, 2012 [Page 4] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 /---------------------------\ | +----+ +--------+ +----+ | B-----------B M-------------------M | | UE | | Stand- |<=|====|=|===|===========|==|=>o--o o--o | | +----+ | alone | | RG | | | | | | | | | Mobile | | | FAP | +----+ | | | | |S | |F | Network| | +--------+ (NAPT) | | Broadband | | |e | |A | | \---------------------------/ | Fixed | | |G |-|P | c-----c| | Network | | |W | |G |-| Core|| /---------------------------\ | (BBF) | | | | |W | | Ntwk|| | +----+ +------------+ | | | | | | | | c-----c| | | UE | | Integrated |<====|===|===========|==|=>o--o o--o / \ | | +----+ | FAP (NAPT) | | B-----------B M-------------------M | +------------+ | / \ \---------------------------/ I-------I p----p |Inter- | |PSTN| Legends: | net | p----p <=====> - IPSec Tunnel I-------I CoreNtwk - Core Network FAPGW - FAP Gateway NAPT - Network Address & Port Translation RG - Routing Gateway SeGW - Security Gateway UE - User Entity Figure 1 : Typical Femto-AP (FAP) E2E Configuration 1.1. Terminology FAP Femtocell Access Point, a FAP is typically designed in home or enterprise environment. Femtocell Femtocell is a low-powered wireless access point that operates in licensed spectrum to connect standard mobile devices to a mobile operator's networking using residential broadband connections. Femto GW Femtocell Gateway, is the concentrate point of multiple FAPs. Femto Management So Expires August 7, 2012 [Page 5] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 Femto Management is the management system used to manage FAP. SeGW A Security Gateway provides secure termination and aggregation for users and signaling traffic to reach the mobile operator's core network. Examples of functions provided by Security Gateway are IPSec Encryption, DoS Mitigation, Dynamic Session Security and Real-time Bandwidth management to provide security for mobile operators' networks and their users. H(e)NB Home (evolved) Node B, the FAP defined by 3GPP, supports second or third generation radio mode or LTE radio mode. It's called HNB when it supports second or third generation radio mode, and HeNB when it supports LTE radio mode. H(e)NB GW H(e)NB GW is the concentrate point of H(e)NBs, it controls the H(e)NB registration, and handles 3GPP specific signaling. H(e)MS H(e)NB management system, the H(e)MS is used to send configuration parameters to the H(e)NB and to manage the H(e)NB by the mobile operator. UE User equipment, it's a mobile terminal defined by 3GPP. 1.2. Requirement for FAP location verification FAP is designed to support plug and play, however, given it is operating on the license band frequency spectrum to support the mobile devices, the FAP is required to support location verification to ensure its legitimacy to operate on the license spectrum for a given mobile operator prior to the FAP be ready to serve its mobile devices. There are several recommendations from today mobile standards that provide possible solutions, but all with limitations: So Expires August 7, 2012 [Page 6] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 1. GPS o Limitation: may not be feasible due to poor indoor signal 2. Overlay Macro cell o Limitation: not always feasible, especially in rural area 3. Femto-AP's IP address o Limitation: private IPv4 addressing and NA(P)T 4. Etc. Option 1. and 2. above are very much limited by the physical environment where the FAP is installed which may be beyond the control of the mobile operator; whereas, Option 3. could be resolved by operators' deployment strategy and network solution on the private IPv4 addressing and the NAPT issue. Hence, Option 3. is considered as the more desirable option to address this FAP location verification requirement. Once the location of the FAP is identified (e.g. based on IP address), the corresponding BBF access network which assigns the public IPv4 address to the given FAP can also be known to the mobile network, and hence, the location of the FAP could be verified. 1.3. Requirement for FAP's identification for the attached mobile UE As part of the FMC interworking, the policy associated with the mobile UE is required to be provided by the policy function of the mobile network, that serves the UE, to the policy function of the BBF network that serves the same UE. In the case of the private IPv4 addressing plan is employed at the BBF network, the identity of its mobile UE and the corresponding mapping between the private IPv4 address and the public IPv4 address of the FAP with the port number (in the case of the NAPT) are needed to be known by the policy function of the mobile network so that it can inform the appropriate policy function of the BBF network based on the BBF local identification of the FAP that the mobile UE is attached. As a result, the BBF network can provide the policy enforcement to apply the QoS policy on the FAP's traffic originated by and targeted to the UE. So Expires August 7, 2012 [Page 7] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 The following figure describes the scenario of the mobile UE's IPv4 address-mapping relationship in typical Femtocell deployment over the BBF and mobile networks with IPSec tunneling. +--------+ +-------------------------+ | | | |------------------| | (Mobile Network +--------+ | | | | Assigned) | /----\ | | /----\ /----------\ | | Inner | |BPCF|--------|PCRF|--| MME/SGW |- | | IP@ | \----/ | | \----/ \----------/| | | | | | | | |. .... | | | | | | | | |. . | | | | | /----\ | | /----\ /------\ . | | | +---+ | +--+ | |BNG | | | |SeGW| | . | . | | | +--+ | <===v===|==|===|=|====|=|====|=> |---| . | . | | | |UE|..|FAP|.......|RG|...|.|....|.|....|.|....|...|.... | . | | | +--+ | <=======|==|===|=|====|=|====|=> | |FAP-GW| . | | | +---+ +--+^ | \----/ | | \----/ \------/ . | | | ^ | | | | . | | | | | | BBF | | /------\ . | | | Private | | Network| | Mobile |PGW ..|---| | | IP@ Public +--------+ | Network \------/-----| | (BBF IP@+Port# | . | Assigned) (NAPT) +-------------------------+ (BBF Assigned) . *--------* Legends: |Internet| BPCF - Broadband Policy Control Function *--------* BNG - Broadband Network Gateway PCRF - Policy Charging Rule Function PGW - PDN Gateway <===> - IPSec Tunnel <===> ..... - UE's IP packets Figure 2 : Example of the typical IP Addressing used across the BBF and Mobile Network for Femto-cell deployment with IPSec Tunneling As shown in the Figure 2 above, the mobile network identifies the UE based on the inner-IPv4 address that it assigned to the UE. When the UE attaches to the FAP, all UE's traffic is encapsulated into FAP's IPSec tunnel. The outer-IPv4 address of the FAP's IPSec tunnel is So Expires August 7, 2012 [Page 8] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 assigned by the BBF network and the IPSec tunnel is terminated at the FAP and at the SeGW. If NA(P)T is deployed at the RG, the IPSec tunnel will be encapsulated by the UDP header in the case of the Tunnel-Mode as specified in RFC 5996 [RFC5996] operation is applied, the private outer-IPv4 address of the FAP's UDP encapsulated IPSec tunnel will be replaced by a public outer-IPv4 address with a possible new port number which are assigned by BBF's NA(P)T. The BPCF/BNG will be based on the public outer-IPv4 address and the port number of the UDP encapsulated IPSec tunnel, to perform the admission control and policy enforcement on the FAP's traffic which is also the UEs' traffic. 2. Problem statements Based on the discussions in the previous section, for the FMC interworking deployment with FAP that involves two different operators (i.e. fixed and mobile operators), using private IPv4 addressing with NA(P)T enabled in BBF network, one can recognize the important requirement for the BBF and the mobile networks to determine the IPv4 address mapping as described in the followings: - Determine the UE attached FAP's public IPv4 address together with the translated port number of the UDP header of the encapsulated IPSec tunnel between the FAP and the SeGW which are assigned by the BBF. The FAP's public IPv4 address is: o used for identifying the location of the FAP o used for identifying the UE's traffic at the BBF network - Determine the corresponding FAP's public IPv4 address's association with the UE's inner-IPv4 address which is assigned by the mobile network. The association is: o used for identifying the mobile UE that is attached to the FAP in order to allow the PCRF to retrieve the UE's policy to be passed onto the BPCF at the BBF network Based on the typical FAP architecture as described in Figure 1 above, the only network element that would have the full knowledge of such mapping is the SeGW. So Expires August 7, 2012 [Page 9] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 Unfortunately, in today generic FAP architecture, SeGW has no direct or indirect interface to the mobile network's policy function or management function in order to pass on its knowledge of the mapping. One of the main reasons is because SeGW is not specific designed for FAP deployment and hence, there is no justification to define specific interface to the mobile network's policy function or management function. Never-the-less, it is outside the scope of this document to discuss the motivation behind such architecture decision. Besides, given the existing deployment for FAP for mobile operator, it is too late to change the existing architecture which will introduce backward incompatibility. Another solution consideration which is based on existing RFC 5389 [RFC5389] - Session Traversal Utilities for NAT (STUN) was examined to resolve the issue. Unfortunately, it is determined that STUN is not a good fit given the consideration of the FMC interworking deployment scenario with FAP. The issues for using STUN for the FMC interworking deployment with FAP are discussed in the following section. 2.1. Considerations of STUN support for FMC interworking with FAP RFC 5389 [RFC5389] STUN client/server solution is not suitable for FMC interworking deployment with FAP because of the following reasons. Assuming the STUN client is implemented at the FAP, there are two options for the STUN server to be deployed and implemented: Option-1: STUN server is deployed by the BBF operator at the egress of the BNG towards the SeGW based on the generic FAP architecture. There are two main technical challenges with this option: - Since FAP is a plug and play device, and FAP is not managed by the BBF operator, an additional solution is required to the existing RFCs to determine how to support inter-operator STUN client server discovery. - The security authentication between the STUN client and server according to RFC 5389 [RFC5389] is based on either long-term credential or short-term credential mechanisms. The mechanism requires either a prior pre-configuration or out-of-band So Expires August 7, 2012 [Page 10] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 signaling which would be extremely difficult to implement when the two network elements are managed by different operators. The conclusion of this option imposes more technical issues than to solve the original problem itself. Hence, Option-1 is not acceptable. Option-2: STUN server is deployed by the mobile operator There are two further sub-options considered by this Option-2. a) Integrate the STUN server into the SeGW - this option requires the STUN server to share the same data path and socket within the IPSec and IKE processing which is a significant change to many existing SeGW implementation, backward compatibility is a major issue. b) Deploy STUN server as the standalone element at the ingress of the SeGW - this option requires architecture and procedure changes to the existing FAP related specification which is also another major backward incompatibility issue to the existing architecture. 3. Proposed Solution - Extension to IKEv2 Configuration Payload After examining many different design options, one particular solution stands out. The solution requires only minimum changes to the existing RFC 5996 [RFC5996] - Internet Key Exchange Protocol Version 2 (IKEv2), and it does not introduce any backward incompatibility issue to the existing RFC, the existing specification, the existing architecture and the existing implementation. The proposed solution is to leverage the existing IKE Configuration Payload (CP) that has been supported by many FAP deployments to allow the IKE-responder (i.e. SeGW) to insert the UDP encapsulated source- IPv4 address and the optional UDP port number of the UDP encapsulated IPSec tunnel into the CP, if the IKE-initiator (i.e. FAP) and the IKE-responder (i.e. SeGW) detect the presence of NA(P)T between them, and after they are successfully mutually authenticated. The major advantages of this proposal are as follows: - Simple extension to the existing IKEv2 RFC 5996 [RFC5996] So Expires August 7, 2012 [Page 11] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 o only a new code point is required to be defined for the CP to indicate the carriage of the source IPv4 address and port number in the UDP header of the IPSec tunnel. - Fully compatibility to the existing architecture and procedures o FAP (i.e. IKE-initiator) has signaling path with the policy function, the management function as well as with the network gateway of the mobile network (e.g. PDN Gateway) o CP is part of the IKEv2 parameters which is generally supported by existing FAP-SeGW IPSec/IKEv2 authentication procedures o Each CP is designed to be standalone and orthogonal to each other, and hence, no concern for backward incompatibility to the existing IKEv2 procedures that are supported by the FAP - Built-in dynamic update with the existing FAP authentication procedure to adapt to the changes of the IPv4 address o Each IPv4 address, even for the network translated IPv4 address will have limited life-span. When the life-span expires for the given IPv4 address, the IPSec/IKEv2 authentication will be renewed and the same procedures are executed to enable the IKEv2 peers to obtain the newly renewed and translated IPv4 address. - No impact to the existing security mechanisms for the end-to- end system and the existing protocols o the new added code point has no impact to the IKEv2 Configuration Payload to continue the use of the existing IKEv2 security mechanism. The following Figure 3 describes the high-level control flows on how the IKEv2 CP is used to carry the public IPv4 address of the UDP header for encapsulated the IPSec Tunnel. So Expires August 7, 2012 [Page 12] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 +-------+ +------+ +----------+ | IKE- | |NA(P)T| | IKE- | |Client | +------+ | Gateway | +-------+ +----------+ IKE-Initiator IKE-Responder (e.g FAP) (e.g SeGW) IKEv2 Message 1 ---------------------------> (HDR, SAi1, Kei, Ni) <--------------------------- IKEv2 Message 2 (HDR, SAr1, KEr, Nr, [CERTREQ]) IKEv2 Message 3 ---------------------------> (HDR, SK{IDi, [CERT], [CERTREQ][IDr]CP(CFG_REQUEST), SAi2, TSi, TSr}) : :...> CFG_REQUEST: If NA(P)T is detected, => EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info <--------------------------- IKEv2 Message 4 (HDR, SK{IDr, [CERT], Auth, CP(CFG_REPLY), SAr2, TSi, TSr}) : CFG_REPLY: If successful authentication <..: EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info <= NOTE: EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4 Info includes Both source IPv4 address and port number that have been translated by the NA(P)T. Figure 3 : Example of the IKEv2 Configuration Payload solution to carry the public IPv4 address and port number of the UDP header for the encapsulated IPSec tunnel The details of the proposed changes are described in the following section. 3.1. Details of proposed changes to RFC 5996 [RFC5996] for IKEv2 CP New code point and the corresponding descriptions to be added to RFC 5996 [RFC5996], section 3.15, are shown as follows: NOTE: The new code point is highlighted in a different color. So Expires August 7, 2012 [Page 13] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 Attribute Type Value Multi-Valued Length ------------------------------------------------------------------- INTERNAL_IP4_ADDRESS 1 YES 0 or 4 octets INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets INTERNAL_IP4_DNS 3 YES 0 or 4 octets INTERNAL_IP4_NBNS 4 YES 0 or 4 octets INTERNAL_IP4_DHCP 6 YES 0 or 4 octets APPLICATION_VERSION 7 NO 0 or more INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets INTERNAL_IP6_DNS 10 YES 0 or 16 octets INTERNAL_IP6_DHCP 12 YES 0 or 16 octets INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 INTERNAL_IP6_SUBNET 15 YES 17 octets EXTERNAL Source_IPv4_NAT_Info 16 NO 0 or 6 octets * These attributes may be multi-valued on return only if multiple values were requested. : : EXTERNAL_Source_IPv4_NAT_Info - The translated external source IPv4 address and the optional port number of the UDP encapsulated packet sent by the initiator is requested by initiator in CFG_REQUEST once the IKE peers detect the presence of NA(P)T in between. If both the initiator and responder are mutually authenticated, the initiator's source IP address and the optional UDP port number of the UDP encapsulated packet will be retrieved by responder and to be included in CFG_REPLY. This attribute is made up of two fields: the first So Expires August 7, 2012 [Page 14] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 being an IPv4 address and optionally, the second being an IPv4 UDP port number. The responder MAY respond with zero or one attribute to initiator. This is discussed in more detail in Section 3.15.4. : : 3.15.4 Configuration Payloads for EXTERNAL_Source_IPv4_NAT_Info The Configuration payloads is used by the IKE initiator to request its corresponding IKE responder via the CFG_REQUEST to return its source IPv4 NAT information, which is composed of the IPv4 address and the optional IPv4 UDP port number, via the CFG_REPLY. The IKE initiator will request such information from its corresponding IKE responder if the presence of NA(P)T is detected via the NAT traversal procedures in between itself and its corresponding responder. If the initiator and the responder are mutually authenticated, the responder will respond to initiator for the translated initiator's source IPv4 address and the optional translated source UDP port number information. A minimal exchange might look like this: CP(CFG_REQUEST) = EXTERNAL_Source_IPv4_NAT_Info() CP(CFG_REPLY) = EXTERNAL Source_IPv4_NAT_Info(198.51.100.234, 233) 4. Security Considerations The proposed solution is to add a new code point to the already defined IKEv2 Configuration Payload with no change to the existing IKEv2 security mechanism that has been used to protect the CP. 5. IANA Considerations A new code point for IKEv2 Configuration Payload that indicates the new contents containing the source IPv4 address and source port number of the IKE-initiator which is assigned by the NA(P)T is required to be registered with IANA. So Expires August 7, 2012 [Page 15] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 6. Conclusions This document explains the issues of the lack of the support in the FMC architecture to retrieve the mapping of the FAP's public IPv4 address and port number with the inner IP address of the mobile UE that is attached to the FAP in order to support the FMC interworking deployment with FAP. This document discusses the requirements and the solution considerations to resolve the issue as described above. One solution is eventually selected as the final proposal which only requires simple extension to the IKEv2 Configuration Payload as defined in RFC 5996 [RFC5996] to carry the mapping information inserted by the SeGW (i.e. IKE-responder) and to be passed onto the FAP (i.e. IKE- initiator). In addition, the solution is backward compatible to the existing FAP system architecture and signaling procedures. 7. References 7.1. Normative References [RFC 5996] Internet Key Exchange Version 2, C. Kaulman et al http://www.rfc-editor.org/rfc/rfc5996.txt [RFC 5389] Session Traversal Utility for NAT, J. Rosenberg et al, http://www.rfc-editor.org/rfc/rfc5389.txt 7.2. Informative References 8. Acknowledgments TBD So Expires August 7, 2012 [Page 16] Internet-Draft draft-so-ipsecme-ikev2-cpext February 2012 Authors' Addresses Tricci So ZTE USA 9920 Pacific Heights Blvd., STE 400, San Diego, CA, 92121 Email: tso@zteusa.com So Expires August 7, 2012 [Page 17]