idnits 2.17.1 draft-gundavelli-ipsecme-3gpp-ims-options-04.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 (March 9, 2015) is 3328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 261, but not defined == Missing Reference: 'IDr' is mentioned on line 261, 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. Dodd-Noble 3 Internet-Draft S. Gundavelli 4 Intended status: Informational Cisco 5 Expires: September 10, 2015 J. Korhonen 6 F. Baboescu 7 Broadcom Corporation 8 B. Weis 9 Cisco 10 March 9, 2015 12 3GPP IMS Option for IKEv2 13 draft-gundavelli-ipsecme-3gpp-ims-options-04.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 address and IPv6 address of the Proxy-Call 20 Session Control Function (P-CSCF). When an IPSec gateway delivers 21 these attributes to an IPsec client, the IPsec client can obtain the 22 IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP 23 network. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 10, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 4 61 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. P-CSCF_IP4_ADDRESS Configuration Attribute . . . . . . . . . . 5 64 4. P-CSCF_IP6_ADDRESS Configuration Attribute . . . . . . . . . . 5 65 5. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The Third Generation Partnership Project (3GPP) S2b reference point 77 [TS23402], specified by the 3GPP system architecture defines a 78 mechanism for allowing a mobile node (MN) attached in an untrusted 79 non-3GPP IP Access Network to securely connect to a 3GPP network and 80 access IP services. In this scenario, the mobile node establishes an 81 IPsec ESP tunnel [RFC4303] to the security gateway called evolved 82 packet data gateway (ePDG) and which in turn establishes a Proxy 83 Mobile IPv6 (PMIPv6) [RFC5213] or GPRS Tunneling Protocol (GTP) 84 [TS23402] tunnel to the packet data gateway (PGW) [TS23402] where the 85 mobile node's session is anchored. 87 The below figure shows the interworking option for non-3GPP access 88 over an untrusted-access network. The mobile access gateway (MAG) 89 and the local mobility anchor (LMA) functions are defined in 90 [RFC5213]. The ePDG and PGW functions are defined in [TS23402]. 91 IPSec ESP tunnel is between the MN and the ePDG and PMIP or GTP 92 tunnel between the ePDG and the PGW. 94 +------------+ 95 | ePDG | 96 | +--------+ | 97 +------+ _----_ | | IPsec | | _----_ +-----+ 98 | MN | _( )_ | | Module | | _( )_ | LMA | 99 | |<====( Internet )=====| +--------+ |===( Operator )===|(PGW)| 100 +------+ (_ _) | : | (_Network_) +-----+ 101 '----' | +--------+ | '----' 102 IPsec Tunnel | | PMIPv6 | | PMIPv6/GTP Tunnel 103 | | MAG | | 104 | +--------+ | 105 +------------+ 107 |<------------ IKEv2/IPsec ------> | <------ PMIPv6/GTP ----->| 109 Figure 1: Exchange of IPv4 Traffic Offload Selectors 111 A mobile node in this scenario may potentially need to access the IP 112 Multimedia Subsystem (IMS) services in the 3GPP network [TS23228] and 113 [TS24229]. Currently, there are no attributes in IKEv2 [RFC5996] 114 that can be used for carrying these information elements. In the 115 absence of these attributes the mobile node needs to be statically 116 configured with this information and this is proving to be an 117 operational challenge. Any other approaches such as using DNS, or 118 DHCP for discovering these functions would result in obtaining 119 configuration in the access network and not in the home network. 120 Given that the above referenced 3GPP interface is primarily for 121 allowing the mobile node to connect to the 3GPP network through an 122 untrusted-access network, the access network may not have any 123 relation with the home network provider and may be unable to deliver 124 the mobile node's home network configuration. 126 This specification therefore defines two new IKEv2 attributes 127 [RFC5996] that allows an IPsec gateway to provide the IPv4 and/or 128 IPv6 address of the P-CSCF server. These attributes can be exchanged 129 by IKEv2 peers as part of the configuration payload exchange. The 130 attributes follow the configuration attribute format defined in 131 Section 3.15.1 of [RFC5996]. Furthermore, providing the P-CSCF 132 server address(es) in IKEv2 as standard attribute(s) enables clients 133 to directly access IMS services behind a VPN gateway without going 134 through the 3GPP specific interfaces. 136 2. Conventions and Terminology 138 2.1. Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2.2. Terminology 146 All the IKEv2 related terms used in this document are to be 147 interpreted as defined in [RFC5996] and [RFC5739]. All the mobility 148 related terms are to interpreted as defined in [RFC5213] and 149 [RFC5844]. Additionally, this document uses the following terms: 151 Proxy-Call Session Control Function (P-CSCF) 153 The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia 154 Subsystem) and serves as the SIP outbound proxy for the mobile 155 node. The mobile node performs SIP registration to 3GPP IMS and 156 initiates SIP sessions via a P-CSCF. 158 Evolved Packet Data Gateway (ePDG) 160 Its is a security gateway defined by the 3GPP system architecture. 161 The protocol interfaces it supports include IKEv2 [RFC5996]. 163 3. P-CSCF_IP4_ADDRESS Configuration Attribute 165 The P-CSCF_IP4_ADDRESS configuration attribute is formatted as 166 follows: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 |R| Attribute Type | Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | IPv4 Address | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Figure 2: IPv4 Address of P-CSCF 178 Reserved (1 bit) 179 Refer to IKEv2 specification 181 Attribute Type (15 bits) 182 184 Length (2 octets) 185 Length of the IPv4 address field that follows. Possible values 186 are (0) and (4). A value of (4) indicates the size of the 4-octet 187 IPv4 address that follows. A value of (0) indicates that its a 188 empty attribute with zero-length IPv4 address field, primarily 189 used as a request indicator. 191 IPv4 Address (4 octets) 192 An IPv4 address of the P-CSCF server. 194 The P-CSCF_IP4_ADDRESS configuration attribute provides an IPv4 195 address of a P-CSCF server within the network. If an instance of an 196 empty P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address 197 field is included by mobile node, the responder MAY respond with 198 zero, one or more P-CSCF_IP4_ADDRESS attributes. If several 199 P-CSCF_IP4_ADDRESS attributes are provided in one IKEv2 message, 200 there is no implied order among the P-CSCF_IP4_ADDRESS attributes. 201 However, a system architecture using this specification may be able 202 to enforce some order at both the peers. 204 4. P-CSCF_IP6_ADDRESS Configuration Attribute 206 The P-CSCF_IP4_ADDRESS configuration attribute is formatted as 207 follows: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 |R| Attribute Type | Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 | | 216 | IPv6 Address | 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 3: IPv6 Address of P-CSCF 222 Reserved (1 bit) 223 Refer to IKEv2 specification 225 Attribute Type (15 bits) 226 228 Length (2 octets) 229 Length of the IPv6 address field that follows. Possible values 230 are (0) and (16). A value is (16) indicates the size of the 16- 231 octet IPv6 address that follows. A value of (0) indicates that 232 its a empty attribute with zero-length IPv6 address field, 233 primarily used as a request indicator. 235 IPv6 Address (16 octets) 236 An IPv6 address of the P-CSCF server. 238 The P-CSCF_IP6_ADDRESS configuration attribute provides an IPv6 239 address of a P-CSCF server within the network. If an instance of an 240 empty P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address 241 field is included by mobile node, the responder MAY respond with 242 zero, one or more P-CSCF_IP6_ADDRESS attributes. If several 243 P-CSCF_IP6_ADDRESS attributes are provided in one IKEv2 message, 244 there is no implied order among the P-CSCF_IP6_ADDRESS attributes. 245 However, a system architecture using this specification may be able 246 to enforce some order at both the peers. 248 5. Example Scenario 250 The mobile node MAY request the IP address of an P-CSCF server as 251 shown below. 253 Client Gateway 254 -------- --------- 256 HDR(IKE_SA_INIT), SAi1, KEi, Ni --> 258 <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] 260 HDR(IKE_AUTH), 261 SK { IDi, CERT, [CERTREQ], AUTH, [IDr], 262 CP(CFG_REQUEST) = 263 { INTERNAL_IP4_ADDRESS(), 264 INTERNAL_IP4_DNS(), 265 P-CSCF_IP4_ADDRESS() }, SAi2, 266 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), 267 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } --> 269 <-- HDR(IKE_AUTH), 270 SK { IDr, CERT, AUTH, 271 CP(CFG_REPLY) = 272 { INTERNAL_IP4_ADDRESS(192.0.2.234), 273 P-CSCF_IP4_ADDRESS(192.0.2.1), 274 P-CSCF_IP4_ADDRESS(192.0.2.4), 275 INTERNAL_IP4_DNS(198.51.100.33) }, 276 SAr2, 277 TSi = (0, 0-65535, 192.0.2.234-192.0.2.234), 278 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } 280 Figure 4: P-CSCF Attribute Exchange 282 6. IANA Considerations 284 This document requires the following two IANA actions. 286 o Action-1: This specification defines a new IKEv2 attribute for 287 carrying the IPv4 address of P-CSCF server. This attribute is 288 defined in Section 3. The Type value for this Attribute needs to 289 be assigned from the IKEv2 Configuration Payload Attribute Types 290 namespace defined in [RFC5996]. 292 o Action-2: This specification defines a new IKEv2 attribute for 293 carrying the IPv6 address of P-CSCF server. This attribute is 294 defined in Section 4. The Type value for this Attribute needs to 295 be assigned from the IKEv2 Configuration Payload Attribute Types 296 namespace defined in [RFC5996]. 298 7. Security Considerations 300 This document is an extension to IKEv2 [RFC5996] and therefore it 301 inherits all the security properties of IKEv2. 303 The two new IKEv2 attributes defined in this specification are for 304 carrying the IPv4 and IPv6 address of the P-CSCF server. These 305 attributes can be exchanged by IKE peers as part of the configuration 306 payload and the currently defined IKEv2 security framework provides 307 the needed integrity and privacy protection for these attributes. 308 Therefore this specification does not introduce any new security 309 vulnerabilities. 311 8. Acknowledgements 313 The Authors would like to specially thank Tero Kivinen for the 314 detailed reviews. Authors would also like to thank Vojislav Vucetic, 315 Heather Sze, Sebastian Speicher, Maulik Vaidya, Ivo Sedlacek, 316 Pierrick Siete and Hui Deng for all the discussions related to this 317 topic. 319 9. References 321 9.1. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 327 RFC 4303, December 2005. 329 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 330 "Internet Key Exchange Protocol Version 2 (IKEv2)", 331 RFC 5996, September 2010. 333 9.2. Informative References 335 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 336 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 338 [RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 339 Configuration in Internet Key Exchange Protocol Version 2 340 (IKEv2)", RFC 5739, February 2010. 342 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 343 Mobile IPv6", RFC 5844, May 2010. 345 [TS23228] 3GPP, "Service requirements for the Internet Protocol (IP) 346 multimedia core network subsystem (IMS); Stage 1", 2014. 348 [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 349 2014. 351 [TS24229] 3GPP, "IP multimedia call control protocol based on 352 Session Initiation Protocol (SIP) and Session Description 353 Protocol (SDP); Stage 3", 2014. 355 Authors' Addresses 357 Aeneas Noble 358 Cisco 359 30 International Pl 360 TEWKSBURY, MASSACHUSETTS 95134 361 USA 363 Email: noblea@cisco.com 365 Sri Gundavelli 366 Cisco 367 170 West Tasman Drive 368 San Jose, CA 95134 369 USA 371 Email: sgundave@cisco.com 373 Jouni Korhonen 374 Broadcom Corporation 375 Porkkalankatu 24 376 Helsinki FIN-00180 377 Finland 379 Email: jouni.nospam@gmail.com 381 Florin Baboescu 382 Broadcom Corporation 383 100 Mathilda Place 384 Sunnyvale, CA 94086 385 USA 387 Email: baboescu@broadcom.com> 388 Brian Weis 389 Cisco 390 170 West Tasman Drive 391 San Jose, CA 95134 392 USA 394 Email: bew@cisco.com