idnits 2.17.1 draft-gundavelli-ipsecme-3gpp-ims-options-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 243, but not defined == Missing Reference: 'IDr' is mentioned on line 243, but not defined ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME WG A. Noble 3 Internet-Draft S. Gundavelli 4 Intended status: Informational Cisco 5 Expires: January 5, 2015 J. Korhonen 6 F. Baboescu 7 Broadcom Corporation 8 B. Weis 9 Cisco 10 July 4, 2014 12 3GPP IMS Option for IKEv2 13 draft-gundavelli-ipsecme-3gpp-ims-options-02.txt 15 Abstract 17 This document defines two new configuration attributes for Internet 18 Key Exchange Protocol version 2 (IKEv2). These attributes can be 19 used for carrying the IPv4 and IPv6 address of the Proxy-Call Control 20 and Service function (P-CSCF). When an IPSec gateway delivers these 21 attributes to an IPsec client, it can obtain the IPv4 and/or IPv6 22 address of the P-CSCF server located in the home network. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 4 60 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. P-CSCF_IP4_ADDRESS Configuration Attribute . . . . . . . . . . 4 63 4. P-CSCF_IP6_ADDRESS Configuration Attribute . . . . . . . . . . 5 64 5. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 The Third Generation Partnership Project (3GPP) S2b reference point 76 [TS23402], specified by the 3GPP system architecture defines a 77 mechanism for allowing a mobile node (MN) attached in an untrusted 78 non-3GPP IP Access Network to securely connect to the 3GPP home 79 network and access IP services. In this scenario, the mobile node 80 establishes an IPsec ESP tunnel [RFC4303] to the security gateway 81 called evolved packet data gateway (ePDG) and which in turn 82 establishes a Proxy Mobile IPv6 (PMIPv6) [RFC5213] or GPRS Tunneling 83 Protocol (GTP) [TS23402] tunnel to the packet data gateway (PGW) 84 [TS23402] where the mobile node's session is anchored. 86 The below figure shows the interworking option for non-3GPP access 87 over an untrusted-access network. The mobile access gateway (MAG) 88 and the local mobility anchor (LMA) functions are defined in 89 [RFC5213]. The ePDG and PGW functions are defined in [TS23402]. 90 IPSec ESP tunnel is between the MN and the ePDG and PMIP or GTP 91 tunnel between the ePDG and the PGW. 93 +------------+ 94 | ePDG | 95 | +--------+ | 96 +------+ _----_ | | IPsec | | _----_ +-----+ 97 | MN | _( )_ | | Module | | _( )_ | LMA | 98 | |<====( Internet )=====| +--------+ |===( Operator )===|(PGW)| 99 +------+ (_ _) | : | (_Network_) +-----+ 100 '----' | +--------+ | '----' 101 IPsec Tunnel | | PMIPv6 | | PMIPv6/GTP Tunnel 102 | | MAG | | 103 | +--------+ | 104 +------------+ 106 |<------------ IKEv2/IPsec ------> | <-------------PMIPv6/GTP-->| 108 Figure 1: Exchange of IPv4 Traffic Offload Selectors 110 A mobile node in this scenario may potentially need to access the IP 111 Multimedia Subsystem (IMS) services in the home network. Currently, 112 there are no attributes in IKEv2 [RFC5996] that can be used for 113 carrying these information elements. In the absence of these 114 attributes the mobile node needs to be statically configured with 115 this information and this is proving to be an operational challenge. 117 This specification therefore defines two new IKEv2 attributes 119 [RFC5996] that allows an IPsec gateway to provide the IPv4 and/or 120 IPv6 address of the P-CSCF server. These attributes can be exchanged 121 by IKEv2 peers as part of the configuration payload exchange. The 122 attributes follow the configuration attribute format defined in 123 Section 3.15.1 of [RFC5996]. 125 2. Conventions and Terminology 127 2.1. Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2.2. Terminology 135 All the IKEv2 related terms used in this document are to be 136 interpreted as defined in [RFC5996] and [RFC5739]. All the mobility 137 related terms are to interpreted as defined in [RFC5213] and 138 [RFC5844]. Additionally, this document uses the following terms: 140 Proxy-Call Session Control Function (P-CSCF) 142 The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia 143 Subsystem) domain and serves as the outbound proxy server for the 144 mobile node. The mobile node attaches to the P-CSCF prior to 145 performing IMS registrations and initiating SIP sessions. 147 Evolved Packet Data Gateway (ePDG) 149 Its is a security gateway defined by the 3GPP system architecture. 150 The protocol interfaces it supports include IKEv2 [RFC5996]. 152 3. P-CSCF_IP4_ADDRESS Configuration Attribute 154 The P-CSCF_IP4_ADDRESS configuration attribute is formatted as 155 follows: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 |R| Attribute Type | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | IPv4 Address | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 2: IPv4 Address of P-CSCF 166 Reserved (1 bit) 167 Refer to IKEv2 specification 169 Attribute Type (15 bits) 170 172 Length (2 octets) 173 Length of the IPv4 address field that follows. Possible values 174 are (0) and (4). A value of (4) indicates the size of the 4-octet 175 IPv4 address that follows. A value of (0) indicates that its a 176 empty attribute with zero-length IPv4 address field, primarily 177 used as a request indicator. 179 IPv4 Address (4 octets) 180 An IPv4 address of the P-CSCF server. 182 The P-CSCF_IP4_ADDRESS configuration attribute provides an IPv4 183 address of a P-CSCF server within the network. Multiple P-CSCF 184 servers MAY be requested by including a single instance of an empty 185 P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field. 186 The responder MAY respond with zero or more P-CSCF_IP4_ADDRESS 187 attributes, and there is no implied order in the response. 189 4. P-CSCF_IP6_ADDRESS Configuration Attribute 191 The P-CSCF_IP4_ADDRESS configuration attribute is formatted as 192 follows: 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 |R| Attribute Type | Length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 | | 201 | IPv6 Address | 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 3: IPv6 Address of P-CSCF 207 Reserved (1 bit) 208 Refer to IKEv2 specification 210 Attribute Type (15 bits) 211 213 Length (2 octets) 214 Length of the IPv6 address field that follows. Possible values 215 are (0) and (16). A value is (16) indicates the size of the 16- 216 octet IPv6 address that follows. A value of (0) indicates that 217 its a empty attribute with zero-length IPv6 address field, 218 primarily used as a request indicator. 220 IPv6 Address (16 octets) 221 An IPv6 address of the P-CSCF server. 223 The P-CSCF_IP6_ADDRESS configuration attribute provides an IPv6 224 address of a P-CSCF server within the network. Multiple P-CSCF 225 servers MAY be requested by including a single instance of an empty 226 P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address field. 227 The responder MAY respond with zero or more P-CSCF_IP6_ADDRESS 228 attributes, and there is no implied order in the response. 230 5. Example Scenario 232 The mobile node MAY request the IP address of an P-CSCF server as 233 shown below. 235 Client Gateway 236 -------- --------- 238 HDR(IKE_SA_INIT), SAi1, KEi, Ni --> 240 <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] 242 HDR(IKE_AUTH), 243 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 244 CP(CFG_REQUEST) = 245 { INTERNAL_IP4_ADDRESS(), 246 INTERNAL_IP4_DNS(), 247 P-CSCF_IP4_ADDRESS() }, SAi2, 248 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), 249 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } --> 251 <-- HDR(IKE_AUTH), 252 SK { IDr, CERT, AUTH, 253 CP(CFG_REPLY) = 254 { INTERNAL_IP4_ADDRESS(192.0.2.234), 255 P-CSCF_IP4_ADDRESS(192.0.2.1), 256 P-CSCF_IP4_ADDRESS(192.0.2.4), 257 INTERNAL_IP4_DNS(198.51.100.33) }, 258 SAr2, 259 TSi = (0, 0-65535, 192.0.2.234-192.0.2.234), 260 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } 262 Figure 4: P-CSCF Attribute Exchange 264 6. IANA Considerations 266 This document requires the following two IANA actions. 268 o Action-1: This specification defines a new IKEv2 attribute for 269 carrying the IPv4 address of P-CSCF server. This attribute is 270 defined in Section 3. The Type value for this Attribute needs to 271 be assigned from the IKEv2 Configuration Payload Attribute Types 272 namespace defined in [RFC5996]. 274 o Action-2: This specification defines a new IKEv2 attribute for 275 carrying the IPv6 address of P-CSCF server. This attribute is 276 defined in Section 4. The Type value for this Attribute needs to 277 be assigned from the IKEv2 Configuration Payload Attribute Types 278 namespace defined in [RFC5996]. 280 7. Security Considerations 282 This document is an extension to IKEv2 [RFC5996] and therefore it 283 inherits all the security properties of IKEv2. 285 The two new IKEv2 attributes defined in this specification are for 286 carrying the IPv4 and IPv6 address of the P-CSCF server. These 287 attributes can be exchanged by IKE peers as part of the configuration 288 payload and the currently defined IKEv2 security framework provides 289 the needed integrity and privacy protection for these attributes. 290 Therefore this specification does not introduce any new security 291 vulnerabilities. 293 8. Acknowledgements 295 The Authors would like to specially thank Tero Kivinen for the 296 detailed reviews. Authors would also like to thank Vojislav Vucetic, 297 Heather Sze, Sebastian Speicher and Maulik Vaidya for all the 298 discussions related to this topic. 300 9. References 302 9.1. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 308 RFC 4303, December 2005. 310 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 311 "Internet Key Exchange Protocol Version 2 (IKEv2)", 312 RFC 5996, September 2010. 314 9.2. Informative References 316 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 317 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 319 [RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 320 Configuration in Internet Key Exchange Protocol Version 2 321 (IKEv2)", RFC 5739, February 2010. 323 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 324 Mobile IPv6", RFC 5844, May 2010. 326 [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 327 2012. 329 Authors' Addresses 331 Aeneas Noble 332 Cisco 333 30 International Pl 334 TEWKSBURY, MASSACHUSETTS 95134 335 USA 337 Email: noblea@cisco.com 339 Sri Gundavelli 340 Cisco 341 170 West Tasman Drive 342 San Jose, CA 95134 343 USA 345 Email: sgundave@cisco.com 347 Jouni Korhonen 348 Broadcom Corporation 349 Porkkalankatu 24 350 Helsinki FIN-00180 351 Finland 353 Email: jouni.nospam@gmail.com 355 Florin Baboescu 356 Broadcom Corporation 357 100 Mathilda Place 358 Sunnyvale, CA 94086 359 USA 361 Email: baboescu@broadcom.com> 362 Brian Weis 363 Cisco 364 170 West Tasman Drive 365 San Jose, CA 95134 366 USA 368 Email: bew@cisco.com