idnits 2.17.1 draft-so-ipsecme-ikev2-cpext-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([RFC5996]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 547: '...r. The responder MAY respond with zero...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 28, 2011) is 4501 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5996' is mentioned on line 602, but not defined ** Obsolete undefined reference: RFC 5996 (Obsoleted by RFC 7296) == Missing Reference: 'RFC5389' is mentioned on line 366, but not defined ** Obsolete undefined reference: RFC 5389 (Obsoleted by RFC 8489) == Missing Reference: 'CERTREQ' is mentioned on line 469, but not defined == Missing Reference: 'CERT' is mentioned on line 475, but not defined == Missing Reference: 'IDr' is mentioned on line 469, but not defined == Unused Reference: 'RFC 5996' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC 5389' is defined on line 614, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSECME T. So 2 Internet Draft ZTE USA 3 Intended status: standard Z. Qiang 4 Expires: June 2012 Ericsson 5 December 28, 2011 7 Problem Statement and Proposed Solution 8 for Private IPv4 Support for Fixed Mobile Convergence 9 draft-so-ipsecme-ikev2-cpext-00.txt 11 Abstract 13 IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many 14 standardized network solutions to provide the secure transport 15 between network elements over third party's infrastructure. For 16 example, the emerging Fixed Mobile Convergence (FMC) network solution 17 that involves Femtocell deployment requires the mobile operator's 18 Femtocell AP to leverage the IPSec IKEv2 to support mutual 19 authentication and remote IP address configuration as well as other 20 auto configuration support over the broadband fixed network (BBF) of 21 which the mobile and fixed networks may be operated by two different 22 operators. 24 Most of today broadband fixed networks are still relying on the IPv4 25 private addressing plan to support its attached devices including the 26 mobile operator's Femtocell AP. Hence, the private IPv4 addressing 27 and Network Address and Port Translation (NA(P)T) support mostly 28 likely stays for many years to come. 30 In FMC interworking scenario, there is a need for the mobile network 31 to pass on it mobile subscribers' policies to the broadband fixed 32 network (BBF) to maintain the service level agreement (SLA) and to 33 support remote network management. In addition, a broadband fixed 34 network (BBF) may partnership with more than one mobile operator. 35 Therefore it is important for the BBF and the mobile network to be 36 able to overcome the limitation of the private IPv4 addressing and to 37 be able to identify the user's subscription as well as to determine 38 the location of the Femtocell AP that serves its mobile user over the 39 BBF network. 41 This document presents the problems for the IPSec tunneling support 42 with private IPv4 addressing for FMC interworking and proposes a 43 simple extension to the IKEv2 to resolve the issues. 45 Status of this Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF), its areas, and its working groups. Note that 64 other groups may also distribute working documents as Internet- 65 Drafts. 67 Internet-Drafts are draft documents valid for a maximum of six months 68 and may be updated, replaced, or obsoleted by other documents at any 69 time. It is inappropriate to use Internet-Drafts as reference 70 material or to cite them other than as "work in progress." 72 The list of current Internet-Drafts can be accessed at 73 http://www.ietf.org/ietf/1id-abstracts.txt 75 The list of Internet-Draft Shadow Directories can be accessed at 76 http://www.ietf.org/shadow.html 78 This Internet-Draft will expire on June 28, 2012. 80 Copyright Notice 82 Copyright (c) 2011 IETF Trust and the persons identified as the 83 document authors. All rights reserved. 85 This document is subject to BCP 78 and the IETF Trust's Legal 86 Provisions Relating to IETF Documents 87 (http://trustee.ietf.org/license-info) in effect on the date of 88 publication of this document. Please review these documents 89 carefully, as they describe your rights and restrictions with respect 90 to this document. 92 Table of Contents 94 1. Introduction...................................................4 95 1.1. Requirement for FAP location verification.................5 96 1.2. Requirement for FAP's identification for the attached mobile 97 UE.............................................................6 98 2. Problem statements.............................................8 99 2.1. Considerations of STUN support for FMC interworking with FAP 100 ...............................................................9 101 3. Proposed Solution - Extension to IKEv2 Configuration Payload..10 102 3.1. Details of proposed changes to RFC 5996 for IKEv2 CP.....12 103 4. Security Considerations.......................................14 104 5. IANA Considerations...........................................14 105 6. Conclusions...................................................15 106 7. References....................................................15 107 7.1. Normative References.....................................15 108 7.2. Informative References...................................15 109 8. Acknowledgments...............................................15 111 Table of Figures 113 Figure 1: Femto-AP (FAP) E2E Configuration ...................... 5 115 Figure 2: Example of the typical IP Addressing used across the BBF 116 and Mobile Network for Femto-cell deployment with IPSec Tunneling 7 118 Figure 3: Example of the IKEv2 Configuration Payload solution to 119 carry the public IPv4 address and port number of the UDP header for 120 the encapsulated IPSec tunnel....................................12 122 1. Introduction 124 Today many network solutions leverage the IPSec IKEv2 to provide the 125 secure transport as well as some form remote configuration support 126 for their network elements over third party infrastructure (e.g. 127 ADSL, Cable etc.). 129 The standardized Femtocell architecture from Femto Forum as well as 130 from many mobile standards (e.g. 3GPP, 3GPP2 and WiMAX) are good 131 examples that all have common architecture to leverage the IPSec 132 IKEv2 to interconnect the Femtocell AP (FAP) with the Security 133 Gateway (SeGW) over the broadband fixed (BBF) network (e.g. ADSL, 134 Cable networks etc.). Both the Femtocell AP (FAP) and the SeGW are 135 managed by the mobile operator which may be a different operator for 136 the BBF network. 138 Most BBF networks today operate on the private IPv4 addressing plan 139 within their networks and rely NA(P)T for external communication. 140 For the FMC scenario, a given BBF network may require to be able to 141 interwork with more than one mobile network which may also deploy its 142 own private IPv4 addressing plan. 144 Given each operator manages their own private IPv4 addressing plan 145 within their network domains and they need to support inter-operators 146 subscribers policy exchange, this introduces a major challenge on how 147 to coordinate the private and public addressing across the operators' 148 domains so that the mobile network can locate the serving BBF access 149 network that its mobile user equipment (UE) is attached to and the 150 mobile user's identity, so that the BBF network can provide the 151 appropriate FMC interworking policy and bearer control on its UE, and 152 also to enable the remote network management, when required. 154 The following presents an example of typical Femtocell network 155 configuration. 157 /---------------------------\ 158 | +----+ +--------+ +----+ | B-----------B M-------------------M 159 | | UE | | Stand- |<=|====|=|===|===========|==|=>o--o o--o | 160 | +----+ | alone | | RG | | | | | | | | | Mobile | 161 | | FAP | +----+ | | | | |S | |F | Network| 162 | +--------+ (NAPT) | | Broadband | | |e | |A | | 163 \---------------------------/ | Fixed | | |G |-|P | c-----c| 164 | Network | | |W | |G |-| Core|| 165 /---------------------------\ | (BBF) | | | | |W | | Ntwk|| 166 | +----+ +------------+ | | | | | | | | c-----c| 167 | | UE | | Integrated |<====|===|===========|==|=>o--o o--o / \ | 168 | +----+ | FAP (NAPT) | | B-----------B M-------------------M 169 | +------------+ | / \ 170 \---------------------------/ I-------I p----p 171 |Inter- | |PSTN| 172 Legends: | net | p----p 173 <=====> - IPSec Tunnel I-------I 174 CoreNtwk - Core Network 175 FAPGW - FAP Gateway 176 NAPT - Network Address & Port Translation 177 RG - Routing Gateway 178 SeGW - Security Gateway 179 UE - User Entity 181 Figure 1 : Typical Femto-AP (FAP) E2E Configuration 183 1.1. Requirement for FAP location verification 185 FAP is designed to support plug and play, however, given it is 186 operating on the license band frequency spectrum to support the 187 mobile devices, the FAP is required to support location verification 188 to ensure its legitimacy to operate on the license spectrum for a 189 given mobile operator prior to the FAP be ready to serve its mobile 190 devices. 192 There are several recommendations from today mobile standards that 193 provide possible solutions, but all with limitations: 195 1. GPS 197 o Limitation: may not be feasible due to poor indoor signal 199 2. Overlay Macro cell 200 o Limitation: not always feasible, especially in rural area 202 3. Femto-AP's IP address 204 o Limitation: private IPv4 addressing and NA(P)T 206 4. Etc. 208 Option 1. and 2. above are very much limited by the physical 209 environment where the FAP is installed which may be beyond the 210 control of the mobile operator; whereas, Option 3. could be resolved 211 by operators' deployment strategy and network solution on the private 212 IPv4 addressing and the NAPT issue. Hence, Option 3. is considered 213 as the more desirable option to address this FAP location 214 verification requirement. 216 Once the location of the FAP is identified (e.g. based on IP 217 address), the corresponding BBF access network which assigns the 218 public IPv4 address to the given FAP can also be known to the mobile 219 network, and hence, the location of the FAP could be verified. 221 1.2. Requirement for FAP's identification for the attached mobile UE 223 As part of the FMC interworking, the policy associated with the 224 mobile UE is required to be provided by the policy function of the 225 mobile network, that serves the UE, to the policy function of the BBF 226 network that serves the same UE. In the case of the private IPv4 227 addressing plan is employed at the BBF network, the identity of its 228 mobile UE and the corresponding mapping between the private IPv4 229 address and the public IPv4 address of the FAP with the port number 230 (in the case of the NAPT) are needed to be known by the policy 231 function of the mobile network so that it can inform the appropriate 232 policy function of the BBF network based on the BBF local 233 identification of the FAP that the mobile UE is attached. As a 234 result, the BBF network can provide the policy enforcement to apply 235 the QoS policy on the FAP's traffic originated by and targeted to the 236 UE. 238 The following figure describes the scenario of the mobile UE's IPv4 239 address-mapping relationship in typical Femtocell deployment over the 240 BBF and mobile networks with IPSec tunneling. 242 +--------+ +-------------------------+ 243 | | | |------------------| | 244 (Mobile Network +--------+ | | | | 245 Assigned) | /----\ | | /----\ /----------\ | | 246 Inner | |BPCF|--------|PCRF|--| MME/SGW |- | | 247 IP@ | \----/ | | \----/ \----------/| | | 248 | | | | | |. .... | | | 249 | | | | | |. . | | | 250 | | /----\ | | /----\ /------\ . | | | 251 +---+ | +--+ | |BNG | | | |SeGW| | . | . | | | 252 +--+ | <===v===|==|===|=|====|=|====|=> |---| . | . | | | 253 |UE|..|FAP|.......|RG|...|.|....|.|....|.|....|...|.... | . | | | 254 +--+ | <=======|==|===|=|====|=|====|=> | |FAP-GW| . | | | 255 +---+ +--+^ | \----/ | | \----/ \------/ . | | | 256 ^ | | | | . | | | 257 | | | BBF | | /------\ . | | | 258 Private | | Network| | Mobile |PGW ..|---| | | 259 IP@ Public +--------+ | Network \------/-----| | 260 (BBF IP@+Port# | . | 261 Assigned) (NAPT) +-------------------------+ 262 (BBF Assigned) . 263 *--------* 264 Legends: |Internet| 265 BPCF - Broadband Policy Control Function *--------* 266 BNG - Broadband Network Gateway 267 PCRF - Policy Charging Rule Function 268 PGW - PDN Gateway 269 <===> - IPSec Tunnel 270 <===> 271 ..... - UE's IP packets 273 Figure 2 : Example of the typical IP Addressing used across the BBF 274 and Mobile Network for Femto-cell deployment with IPSec Tunneling 276 As shown in the Figure 2 above, the mobile network identifies the UE 277 based on the inner-IPv4 address that it assigned to the UE. When the 278 UE attaches to the FAP, all UE's traffic is encapsulated into FAP's 279 IPSec tunnel. The outer-IPv4 address of the FAP's IPSec tunnel is 280 assigned by the BBF network and the IPSec tunnel is terminated at the 281 FAP and at the SeGW. 283 If NA(P)T is deployed at the RG, the IPSec tunnel will be 284 encapsulated by the UDP header in the case of the Tunnel-Mode as 285 specified in RFC 5996 [RFC5996] operation is applied, the private 286 outer-IPv4 address of the FAP's UDP encapsulated IPSec tunnel will be 287 replaced by a public outer-IPv4 address with a possible new port 288 number which are assigned by BBF's NA(P)T. 290 The BPCF/BNG will be based on the public outer-IPv4 address and the 291 port number of the UDP encapsulated IPSec tunnel, to perform the 292 admission control and policy enforcement on the FAP's traffic which 293 is also the UEs' traffic. 295 2. Problem statements 297 Based on the discussions in the previous section, for the FMC 298 interworking deployment with FAP that involves two different 299 operators (i.e. fixed and mobile operators), using private IPv4 300 addressing with NA(P)T enabled in BBF network, one can recognize the 301 important requirement for the BBF and the mobile networks to 302 determine the IPv4 address mapping as described in the followings: 304 - Determine the UE attached FAP's public IPv4 address together 305 with the translated port number of the UDP header of the 306 encapsulated IPSec tunnel between the FAP and the SeGW which 307 are assigned by the BBF. The FAP's public IPv4 address is: 309 o used for identifying the location of the FAP 311 o used for identifying the UE's traffic at the BBF network 313 - Determine the corresponding FAP's public IPv4 address's 314 association with the UE's inner-IPv4 address which is assigned 315 by the mobile network. The association is: 317 o used for identifying the mobile UE that is attached to the 318 FAP in order to allow the PCRF to retrieve the UE's policy 319 to be passed onto the BPCF at the BBF network 321 Based on the typical FAP architecture as described in Figure 1 above, 322 the only network element that would have the full knowledge of such 323 mapping is the SeGW. 325 Unfortunately, in today generic FAP architecture, SeGW has no direct 326 or indirect interface to the mobile network's policy function or 327 management function in order to pass on its knowledge of the mapping. 328 One of the main reasons is because SeGW is not specific designed for 329 FAP deployment and hence, there is no justification to define 330 specific interface to the mobile network's policy function or 331 management function. Never-the-less, it is outside the scope of this 332 document to discuss the motivation behind such architecture decision. 334 Besides, given the existing deployment for FAP for mobile operator, 335 it is too late to change the existing architecture which will 336 introduce backward incompatibility. 338 Another solution consideration which is based on existing RFC 5389 339 [RFC5389] - Session Traversal Utilities for NAT (STUN) was examined 340 to resolve the issue. Unfortunately, it is determined that STUN is 341 not a good fit given the consideration of the FMC interworking 342 deployment scenario with FAP. The issues for using STUN for the FMC 343 interworking deployment with FAP are discussed in the following 344 section. 346 2.1. Considerations of STUN support for FMC interworking with FAP 348 RFC 5389 [RFC5389] STUN client/server solution is not suitable for 349 FMC interworking deployment with FAP because of the following 350 reasons. 352 Assuming the STUN client is implemented at the FAP, there are two 353 options for the STUN server to be deployed and implemented: 355 Option-1: STUN server is deployed by the BBF operator at the egress 356 of the BNG towards the SeGW based on the generic FAP architecture. 358 There are two main technical challenges with this option: 360 - Since FAP is a plug and play device, and FAP is not managed by 361 the BBF operator, an additional solution is required to the 362 existing RFCs to determine how to support inter-operator STUN 363 client server discovery. 365 - The security authentication between the STUN client and server 366 according to RFC 5389 [RFC5389] is based on either long-term 367 credential or short-term credential mechanisms. The mechanism 368 requires either a prior pre-configuration or out-of-band 369 signaling which would be extremely difficult to implement when 370 the two network elements are managed by different operators. 372 The conclusion of this option imposes more technical issues than to 373 solve the original problem itself. Hence, Option-1 is not 374 acceptable. 376 Option-2: STUN server is deployed by the mobile operator 378 There are two further sub-options considered by this Option-2. 380 a) Integrate the STUN server into the SeGW - this option requires 381 the STUN server to share the same data path and socket within 382 the IPSec and IKE processing which is a significant change to 383 many existing SeGW implementation, backward compatibility is a 384 major issue. 386 b) Deploy STUN server as the standalone element at the ingress of 387 the SeGW - this option requires architecture and procedure 388 changes to the existing FAP related specification which is 389 also another major backward incompatibility issue to the 390 existing architecture. 392 3. Proposed Solution - Extension to IKEv2 Configuration Payload 394 After examining many different design options, one particular 395 solution stands out. The solution requires only minimum changes to 396 the existing RFC 5996 [RFC5996] - Internet Key Exchange Protocol 397 Version 2 (IKEv2), and it does not introduce any backward 398 incompatibility issue to the existing RFC, the existing 399 specification, the existing architecture and the existing 400 implementation. 402 The proposed solution is to leverage the existing IKE Configuration 403 Payload (CP) that has been supported by many FAP deployments to allow 404 the IKE-responder (i.e. SeGW) to insert the UDP encapsulated source- 405 IPv4 address and the optional UDP port number of the UDP encapsulated 406 IPSec tunnel into the CP, if the IKE-initiator (i.e. FAP) and the 407 IKE-responder (i.e. SeGW) detect the presence of NA(P)T between them, 408 and after they are successfully mutually authenticated. 410 The major advantages of this proposal are as follows: 412 - Simple extension to the existing IKEv2 RFC 5996 [RFC5996] 414 o only a new code point is required to be defined for the CP 415 to indicate the carriage of the source IPv4 address and 416 port number in the UDP header of the IPSec tunnel. 418 - Fully compatibility to the existing architecture and procedures 419 o FAP (i.e. IKE-initiator) has signaling path with the 420 policy function, the management function as well as with 421 the network gateway of the mobile network (e.g. PDN 422 Gateway) 424 o CP is part of the IKEv2 parameters which is generally 425 supported by existing FAP-SeGW IPSec/IKEv2 authentication 426 procedures 428 o Each CP is designed to be standalone and orthogonal to 429 each other, and hence, no concern for backward 430 incompatibility to the existing IKEv2 procedures that are 431 supported by the FAP 433 - Built-in dynamic update with the existing FAP authentication 434 procedure to adapt to the changes of the IPv4 address 436 o Each IPv4 address, even for the network translated IPv4 437 address will have limited life-span. When the life-span 438 expires for the given IPv4 address, the IPSec/IKEv2 439 authentication will be renewed and the same procedures are 440 executed to enable the IKEv2 peers to obtain the newly 441 renewed and translated IPv4 address. 443 - No impact to the existing security mechanisms for the end-to- 444 end system and the existing protocols 446 o the new added code point has no impact to the IKEv2 447 Configuration Payload to continue the use of the existing 448 IKEv2 security mechanism. 450 The following Figure 3 describes the high-level control flows on how 451 the IKEv2 CP is used to carry the public IPv4 address of the UDP 452 header for encapsulated the IPSec Tunnel. 454 +-------+ +------+ +----------+ 455 | IKE- | |NA(P)T| | IKE- | 456 |Client | +------+ | Gateway | 457 +-------+ +----------+ 458 IKE-Initiator IKE-Responder 459 (e.g FAP) (e.g SeGW) 461 IKEv2 Message 1 ---------------------------> 462 (HDR, SAi1, Kei, Ni) 464 <--------------------------- IKEv2 Message 2 465 (HDR, SAr1, KEr, Nr, [CERTREQ]) 467 IKEv2 Message 3 ---------------------------> 468 (HDR, SK{IDi, [CERT], 469 [CERTREQ][IDr]CP(CFG_REQUEST), 470 SAi2, TSi, TSr}) : 471 :...> CFG_REQUEST: If NA(P)T is detected, 472 => EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info 474 <--------------------------- IKEv2 Message 4 475 (HDR, SK{IDr, [CERT], Auth, 476 CP(CFG_REPLY), SAr2, TSi, TSr}) 477 : 478 CFG_REPLY: If successful authentication <..: 479 EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info <= 481 NOTE: EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4 Info includes 482 Both source IPv4 address and port number that have been 483 translated by the NA(P)T. 485 Figure 3 : Example of the IKEv2 Configuration Payload solution to 486 carry the public IPv4 address and port number of the UDP header for 487 the encapsulated IPSec tunnel 489 The details of the proposed changes are described in the following 490 section. 492 3.1. Details of proposed changes to RFC 5996 [RFC5996] for IKEv2 CP 494 New code point and the corresponding descriptions to be added to RFC 495 5996 [RFC5996], section 3.15, are shown as follows: 497 NOTE: The new code point is highlighted in a different color. 499 Attribute Type Value Multi-Valued Length 501 ------------------------------------------------------------------- 503 INTERNAL_IP4_ADDRESS 1 YES 0 or 4 octets 505 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 507 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 509 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 511 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 513 APPLICATION_VERSION 7 NO 0 or more 515 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 517 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 519 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 521 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 523 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 525 INTERNAL_IP6_SUBNET 15 YES 17 octets 527 EXTERNAL Source_IPv4_NAT_Info 529 16 NO 0 or 6 octets 531 * These attributes may be multi-valued on return only if multiple 532 values were requested. 534 : 536 : 538 EXTERNAL_Source_IPv4_NAT_Info - The translated external source IPv4 539 address and the optional port number of the UDP encapsulated packet 540 sent by the initiator is requested by initiator in CFG_REQUEST once 541 the IKE peers detect the presence of NA(P)T in between. If both the 542 initiator and responder are mutually authenticated, the initiator's 543 source IP address and the optional UDP port number of the UDP 544 encapsulated packet will be retrieved by responder and to be included 545 in CFG_REPLY. This attribute is made up of two fields: the first 546 being an IPv4 address and optionally, the second being an IPv4 UDP 547 port number. The responder MAY respond with zero or one attribute to 548 initiator. This is discussed in more detail in Section 3.15.4. 550 : 552 : 554 3.15.4 Configuration Payloads for EXTERNAL_Source_IPv4_NAT_Info 556 The Configuration payloads is used by the IKE initiator to request 557 its corresponding IKE responder via the CFG_REQUEST to return its 558 source IPv4 NAT information, which is composed of the IPv4 address 559 and the optional IPv4 UDP port number, via the CFG_REPLY. 561 The IKE initiator will request such information from its 562 corresponding IKE responder if the presence of NA(P)T is detected via 563 the NAT traversal procedures in between itself and its corresponding 564 responder. 566 If the initiator and the responder are mutually authenticated, the 567 responder will respond to initiator for the translated initiator's 568 source IPv4 address and the optional translated source UDP port 569 number information. 571 A minimal exchange might look like this: 573 CP(CFG_REQUEST) = EXTERNAL_Source_IPv4_NAT_Info() 575 CP(CFG_REPLY) = EXTERNAL Source_IPv4_NAT_Info(198.51.100.234, 233) 577 4. Security Considerations 579 The proposed solution is to add a new code point to the already 580 defined IKEv2 Configuration Payload with no change to the existing 581 IKEv2 security mechanism that has been used to protect the CP. 583 5. IANA Considerations 585 A new code point for IKEv2 Configuration Payload that indicates the 586 new contents containing the source IPv4 address and source port 587 number of the IKE-initiator which is assigned by the NA(P)T is 588 required to be registered with IANA. 590 6. Conclusions 592 This document explains the issues of the lack of the support in the 593 FMC architecture to retrieve the mapping of the FAP's public IPv4 594 address and port number with the inner IP address of the mobile UE 595 that is attached to the FAP in order to support the FMC interworking 596 deployment with FAP. 598 This document discusses the requirements and the solution 599 considerations to resolve the issue as described above. One solution 600 is eventually selected as the final proposal which only requires 601 simple extension to the IKEv2 Configuration Payload as defined in RFC 602 5996 [RFC5996] to carry the mapping information inserted by the SeGW 603 (i.e. IKE-responder) and to be passed onto the FAP (i.e. IKE- 604 initiator). In addition, the solution is backward compatible to the 605 existing FAP system architecture and signaling procedures. 607 7. References 609 7.1. Normative References 611 [RFC 5996] Internet Key Exchange Version 2, C. Kaulman et al 612 http://www.rfc-editor.org/rfc/rfc5996.txt 614 [RFC 5389] Session Traversal Utility for NAT, J. Rosenberg et al, 615 http://www.rfc-editor.org/rfc/rfc5389.txt 617 7.2. Informative References 619 8. Acknowledgments 621 TBD 623 Authors' Addresses 625 Tricci So 626 ZTE USA 627 9920 Pacific Heights Blvd., STE 400, San Diego, CA, 92121 629 Email: tso@zteusa.com