idnits 2.17.1 draft-so-ipsecme-ikev2-cpext-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 : ---------------------------------------------------------------------------- ** 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 602: '...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 (June 14, 2012) is 4326 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 657, but not defined ** Obsolete undefined reference: RFC 5996 (Obsoleted by RFC 7296) == Missing Reference: 'RFC5389' is mentioned on line 421, but not defined ** Obsolete undefined reference: RFC 5389 (Obsoleted by RFC 8489) == Missing Reference: 'CERTREQ' is mentioned on line 524, but not defined == Missing Reference: 'CERT' is mentioned on line 530, but not defined == Missing Reference: 'IDr' is mentioned on line 524, but not defined == Unused Reference: 'RFC 5996' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC 5389' is defined on line 669, 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: December 2012 Ericsson 5 June 14, 2012 7 IKEv2 Configuration Payload Extension 8 for Private IPv4 Support for Fixed Mobile Convergence 9 draft-so-ipsecme-ikev2-cpext-02.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 December 14, 2012. 80 Copyright Notice 82 Copyright (c) 2012 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. Terminology...............................................5 96 FAP...............................................................5 97 1.2. Requirement for FAP location verification.................6 98 1.3. Requirement for FAP's identification for the attached mobile 99 UE.............................................................7 100 2. Problem statements.............................................9 101 2.1. Considerations of STUN support for FMC interworking with FAP 102 ..............................................................10 103 3. Proposed Solution - Extension to IKEv2 Configuration Payload..11 104 3.1. Details of proposed changes to RFC 5996 [RFC5996] for IKEv2 105 CP............................................................13 106 4. Security Considerations.......................................15 107 5. IANA Considerations...........................................15 108 6. Conclusions...................................................16 109 7. References....................................................16 110 7.1. Normative References.....................................16 111 7.2. Informative References...................................16 112 8. Acknowledgments...............................................16 114 Table of Figures 116 Figure 1: Femto-AP (FAP) E2E Configuration ...................... 5 118 Figure 2: Example of the typical IP Addressing used across the BBF 119 and Mobile Network for Femto-cell deployment with IPSec Tunneling 8 121 Figure 3: Example of the IKEv2 Configuration Payload solution to 122 carry the public IPv4 address and port number of the UDP header for 123 the encapsulated IPSec tunnel....................................13 125 1. Introduction 127 Today many network solutions leverage the IPSec IKEv2 to provide the 128 secure transport as well as some form remote configuration support 129 for their network elements over third party infrastructure (e.g. 130 ADSL, Cable etc.). 132 The standardized Femtocell architecture from Femto Forum as well as 133 from many mobile standards (e.g. 3GPP, 3GPP2 and WiMAX) are good 134 examples that all have common architecture to leverage the IPSec 135 IKEv2 to interconnect the Femtocell AP (FAP) with the Security 136 Gateway (SeGW) over the broadband fixed (BBF) network (e.g. ADSL, 137 Cable networks etc.). Both the Femtocell AP (FAP) and the SeGW are 138 managed by the mobile operator which may be a different operator for 139 the BBF network. 141 Most BBF networks today operate on the private IPv4 addressing plan 142 within their networks and rely NA(P)T for external communication. 143 For the FMC scenario, a given BBF network may require to be able to 144 interwork with more than one mobile network which may also deploy its 145 own private IPv4 addressing plan. 147 Given each operator manages their own private IPv4 addressing plan 148 within their network domains and they need to support inter-operators 149 subscribers policy exchange, this introduces a major challenge on how 150 to coordinate the private and public addressing across the operators' 151 domains so that the mobile network can locate the serving BBF access 152 network that its mobile user equipment (UE) is attached to and the 153 mobile user's identity, so that the BBF network can provide the 154 appropriate FMC interworking policy and bearer control on its UE, and 155 also to enable the remote network management, when required. 157 The following presents an example of typical Femtocell network 158 configuration. 160 /---------------------------\ 161 | +----+ +--------+ +----+ | B-----------B M-------------------M 162 | | UE | | Stand- |<=|====|=|===|===========|==|=>o--o o--o | 163 | +----+ | alone | | RG | | | | | | | | | Mobile | 164 | | FAP | +----+ | | | | |S | |F | Network| 165 | +--------+ (NAPT) | | Broadband | | |e | |A | | 166 \---------------------------/ | Fixed | | |G |-|P | c-----c| 167 | Network | | |W | |G |-| Core|| 168 /---------------------------\ | (BBF) | | | | |W | | Ntwk|| 169 | +----+ +------------+ | | | | | | | | c-----c| 170 | | UE | | Integrated |<====|===|===========|==|=>o--o o--o / \ | 171 | +----+ | FAP (NAPT) | | B-----------B M-------------------M 172 | +------------+ | / \ 173 \---------------------------/ I-------I p----p 174 |Inter- | |PSTN| 175 Legends: | net | p----p 176 <=====> - IPSec Tunnel I-------I 177 CoreNtwk - Core Network 178 FAPGW - FAP Gateway 179 NAPT - Network Address & Port Translation 180 RG - Routing Gateway 181 SeGW - Security Gateway 182 UE - User Entity 184 Figure 1 : Typical Femto-AP (FAP) E2E Configuration 186 1.1. Terminology 188 FAP 190 Femtocell Access Point, a FAP is typically designed in home or 191 enterprise environment. 193 Femtocell 195 Femtocell is a low-powered wireless access point that operates in 196 licensed spectrum to connect standard mobile devices to a mobile 197 operator's networking using residential broadband connections. 199 Femto GW 201 Femtocell Gateway, is the concentrate point of multiple FAPs. 203 Femto Management 204 Femto Management is the management system used to manage FAP. 206 SeGW 208 A Security Gateway provides secure termination and aggregation for 209 users and signaling traffic to reach the mobile operator's core 210 network. Examples of functions provided by Security Gateway are IPSec 211 Encryption, DoS Mitigation, Dynamic Session Security and Real-time 212 Bandwidth management to provide security for mobile operators' 213 networks and their users. 215 H(e)NB 217 Home (evolved) Node B, the FAP defined by 3GPP, supports second or 218 third generation radio mode or LTE radio mode. It's called HNB when 219 it supports second or third generation radio mode, and HeNB when it 220 supports LTE radio mode. 222 H(e)NB GW 224 H(e)NB GW is the concentrate point of H(e)NBs, it controls the 225 H(e)NB registration, and handles 3GPP specific signaling. 227 H(e)MS 229 H(e)NB management system, the H(e)MS is used to send configuration 230 parameters to the H(e)NB and to manage the H(e)NB by the mobile 231 operator. 233 UE 235 User equipment, it's a mobile terminal defined by 3GPP. 237 1.2. Requirement for FAP location verification 239 FAP is designed to support plug and play, however, given it is 240 operating on the license band frequency spectrum to support the 241 mobile devices, the FAP is required to support location verification 242 to ensure its legitimacy to operate on the license spectrum for a 243 given mobile operator prior to the FAP be ready to serve its mobile 244 devices. 246 There are several recommendations from today mobile standards that 247 provide possible solutions, but all with limitations: 249 1. GPS 251 o Limitation: may not be feasible due to poor indoor signal 253 2. Overlay Macro cell 255 o Limitation: not always feasible, especially in rural area 257 3. Femto-AP's IP address 259 o Limitation: private IPv4 addressing and NA(P)T 261 4. Etc. 263 Option 1. and 2. above are very much limited by the physical 264 environment where the FAP is installed which may be beyond the 265 control of the mobile operator; whereas, Option 3. could be resolved 266 by operators' deployment strategy and network solution on the private 267 IPv4 addressing and the NAPT issue. Hence, Option 3. is considered 268 as the more desirable option to address this FAP location 269 verification requirement. 271 Once the location of the FAP is identified (e.g. based on IP 272 address), the corresponding BBF access network which assigns the 273 public IPv4 address to the given FAP can also be known to the mobile 274 network, and hence, the location of the FAP could be verified. 276 1.3. Requirement for FAP's identification for the attached mobile UE 278 As part of the FMC interworking, the policy associated with the 279 mobile UE is required to be provided by the policy function of the 280 mobile network, that serves the UE, to the policy function of the BBF 281 network that serves the same UE. In the case of the private IPv4 282 addressing plan is employed at the BBF network, the identity of its 283 mobile UE and the corresponding mapping between the private IPv4 284 address and the public IPv4 address of the FAP with the port number 285 (in the case of the NAPT) are needed to be known by the policy 286 function of the mobile network so that it can inform the appropriate 287 policy function of the BBF network based on the BBF local 288 identification of the FAP that the mobile UE is attached. As a 289 result, the BBF network can provide the policy enforcement to apply 290 the QoS policy on the FAP's traffic originated by and targeted to the 291 UE. 293 The following figure describes the scenario of the mobile UE's IPv4 294 address-mapping relationship in typical Femtocell deployment over the 295 BBF and mobile networks with IPSec tunneling. 297 +--------+ +-------------------------+ 298 | | | |------------------| | 299 (Mobile Network +--------+ | | | | 300 Assigned) | /----\ | | /----\ /----------\ | | 301 Inner | |BPCF|--------|PCRF|--| MME/SGW |- | | 302 IP@ | \----/ | | \----/ \----------/| | | 303 | | | | | |. .... | | | 304 | | | | | |. . | | | 305 | | /----\ | | /----\ /------\ . | | | 306 +---+ | +--+ | |BNG | | | |SeGW| | . | . | | | 307 +--+ | <===v===|==|===|=|====|=|====|=> |---| . | . | | | 308 |UE|..|FAP|.......|RG|...|.|....|.|....|.|....|...|.... | . | | | 309 +--+ | <=======|==|===|=|====|=|====|=> | |FAP-GW| . | | | 310 +---+ +--+^ | \----/ | | \----/ \------/ . | | | 311 ^ | | | | . | | | 312 | | | BBF | | /------\ . | | | 313 Private | | Network| | Mobile |PGW ..|---| | | 314 IP@ Public +--------+ | Network \------/-----| | 315 (BBF IP@+Port# | . | 316 Assigned) (NAPT) +-------------------------+ 317 (BBF Assigned) . 318 *--------* 319 Legends: |Internet| 320 BPCF - Broadband Policy Control Function *--------* 321 BNG - Broadband Network Gateway 322 PCRF - Policy Charging Rule Function 323 PGW - PDN Gateway 324 <===> - IPSec Tunnel 325 <===> 326 ..... - UE's IP packets 328 Figure 2 : Example of the typical IP Addressing used across the BBF 329 and Mobile Network for Femto-cell deployment with IPSec Tunneling 331 As shown in the Figure 2 above, the mobile network identifies the UE 332 based on the inner-IPv4 address that it assigned to the UE. When the 333 UE attaches to the FAP, all UE's traffic is encapsulated into FAP's 334 IPSec tunnel. The outer-IPv4 address of the FAP's IPSec tunnel is 335 assigned by the BBF network and the IPSec tunnel is terminated at the 336 FAP and at the SeGW. 338 If NA(P)T is deployed at the RG, the IPSec tunnel will be 339 encapsulated by the UDP header in the case of the Tunnel-Mode as 340 specified in RFC 5996 [RFC5996] operation is applied, the private 341 outer-IPv4 address of the FAP's UDP encapsulated IPSec tunnel will be 342 replaced by a public outer-IPv4 address with a possible new port 343 number which are assigned by BBF's NA(P)T. 345 The BPCF/BNG will be based on the public outer-IPv4 address and the 346 port number of the UDP encapsulated IPSec tunnel, to perform the 347 admission control and policy enforcement on the FAP's traffic which 348 is also the UEs' traffic. 350 2. Problem statements 352 Based on the discussions in the previous section, for the FMC 353 interworking deployment with FAP that involves two different 354 operators (i.e. fixed and mobile operators), using private IPv4 355 addressing with NA(P)T enabled in BBF network, one can recognize the 356 important requirement for the BBF and the mobile networks to 357 determine the IPv4 address mapping as described in the followings: 359 - Determine the UE attached FAP's public IPv4 address together 360 with the translated port number of the UDP header of the 361 encapsulated IPSec tunnel between the FAP and the SeGW which 362 are assigned by the BBF. The FAP's public IPv4 address is: 364 o used for identifying the location of the FAP 366 o used for identifying the UE's traffic at the BBF network 368 - Determine the corresponding FAP's public IPv4 address's 369 association with the UE's inner-IPv4 address which is assigned 370 by the mobile network. The association is: 372 o used for identifying the mobile UE that is attached to the 373 FAP in order to allow the PCRF to retrieve the UE's policy 374 to be passed onto the BPCF at the BBF network 376 Based on the typical FAP architecture as described in Figure 1 above, 377 the only network element that would have the full knowledge of such 378 mapping is the SeGW. 380 Unfortunately, in today generic FAP architecture, SeGW has no direct 381 or indirect interface to the mobile network's policy function or 382 management function in order to pass on its knowledge of the mapping. 383 One of the main reasons is because SeGW is not specific designed for 384 FAP deployment and hence, there is no justification to define 385 specific interface to the mobile network's policy function or 386 management function. Never-the-less, it is outside the scope of this 387 document to discuss the motivation behind such architecture decision. 389 Besides, given the existing deployment for FAP for mobile operator, 390 it is too late to change the existing architecture which will 391 introduce backward incompatibility. 393 Another solution consideration which is based on existing RFC 5389 394 [RFC5389] - Session Traversal Utilities for NAT (STUN) was examined 395 to resolve the issue. Unfortunately, it is determined that STUN is 396 not a good fit given the consideration of the FMC interworking 397 deployment scenario with FAP. The issues for using STUN for the FMC 398 interworking deployment with FAP are discussed in the following 399 section. 401 2.1. Considerations of STUN support for FMC interworking with FAP 403 RFC 5389 [RFC5389] STUN client/server solution is not suitable for 404 FMC interworking deployment with FAP because of the following 405 reasons. 407 Assuming the STUN client is implemented at the FAP, there are two 408 options for the STUN server to be deployed and implemented: 410 Option-1: STUN server is deployed by the BBF operator at the egress 411 of the BNG towards the SeGW based on the generic FAP architecture. 413 There are two main technical challenges with this option: 415 - Since FAP is a plug and play device, and FAP is not managed by 416 the BBF operator, an additional solution is required to the 417 existing RFCs to determine how to support inter-operator STUN 418 client server discovery. 420 - The security authentication between the STUN client and server 421 according to RFC 5389 [RFC5389] is based on either long-term 422 credential or short-term credential mechanisms. The mechanism 423 requires either a prior pre-configuration or out-of-band 424 signaling which would be extremely difficult to implement when 425 the two network elements are managed by different operators. 427 The conclusion of this option imposes more technical issues than to 428 solve the original problem itself. Hence, Option-1 is not 429 acceptable. 431 Option-2: STUN server is deployed by the mobile operator 433 There are two further sub-options considered by this Option-2. 435 a) Integrate the STUN server into the SeGW - this option requires 436 the STUN server to share the same data path and socket within 437 the IPSec and IKE processing which is a significant change to 438 many existing SeGW implementation, backward compatibility is a 439 major issue. 441 b) Deploy STUN server as the standalone element at the ingress of 442 the SeGW - this option requires architecture and procedure 443 changes to the existing FAP related specification which is 444 also another major backward incompatibility issue to the 445 existing architecture. 447 3. Proposed Solution - Extension to IKEv2 Configuration Payload 449 After examining many different design options, one particular 450 solution stands out. The solution requires only minimum changes to 451 the existing RFC 5996 [RFC5996] - Internet Key Exchange Protocol 452 Version 2 (IKEv2), and it does not introduce any backward 453 incompatibility issue to the existing RFC, the existing 454 specification, the existing architecture and the existing 455 implementation. 457 The proposed solution is to leverage the existing IKE Configuration 458 Payload (CP) that has been supported by many FAP deployments to allow 459 the IKE-responder (i.e. SeGW) to insert the UDP encapsulated source- 460 IPv4 address and the optional UDP port number of the UDP encapsulated 461 IPSec tunnel into the CP, if the IKE-initiator (i.e. FAP) and the 462 IKE-responder (i.e. SeGW) detect the presence of NA(P)T between them, 463 and after they are successfully mutually authenticated. 465 The major advantages of this proposal are as follows: 467 - Simple extension to the existing IKEv2 RFC 5996 [RFC5996] 468 o only a new code point is required to be defined for the CP 469 to indicate the carriage of the source IPv4 address and 470 port number in the UDP header of the IPSec tunnel. 472 - Fully compatibility to the existing architecture and procedures 474 o FAP (i.e. IKE-initiator) has signaling path with the 475 policy function, the management function as well as with 476 the network gateway of the mobile network (e.g. PDN 477 Gateway) 479 o CP is part of the IKEv2 parameters which is generally 480 supported by existing FAP-SeGW IPSec/IKEv2 authentication 481 procedures 483 o Each CP is designed to be standalone and orthogonal to 484 each other, and hence, no concern for backward 485 incompatibility to the existing IKEv2 procedures that are 486 supported by the FAP 488 - Built-in dynamic update with the existing FAP authentication 489 procedure to adapt to the changes of the IPv4 address 491 o Each IPv4 address, even for the network translated IPv4 492 address will have limited life-span. When the life-span 493 expires for the given IPv4 address, the IPSec/IKEv2 494 authentication will be renewed and the same procedures are 495 executed to enable the IKEv2 peers to obtain the newly 496 renewed and translated IPv4 address. 498 - No impact to the existing security mechanisms for the end-to- 499 end system and the existing protocols 501 o the new added code point has no impact to the IKEv2 502 Configuration Payload to continue the use of the existing 503 IKEv2 security mechanism. 505 The following Figure 3 describes the high-level control flows on how 506 the IKEv2 CP is used to carry the public IPv4 address of the UDP 507 header for encapsulated the IPSec Tunnel. 509 +-------+ +------+ +----------+ 510 | IKE- | |NA(P)T| | IKE- | 511 |Client | +------+ | Gateway | 512 +-------+ +----------+ 513 IKE-Initiator IKE-Responder 514 (e.g FAP) (e.g SeGW) 516 IKEv2 Message 1 ---------------------------> 517 (HDR, SAi1, Kei, Ni) 519 <--------------------------- IKEv2 Message 2 520 (HDR, SAr1, KEr, Nr, [CERTREQ]) 522 IKEv2 Message 3 ---------------------------> 523 (HDR, SK{IDi, [CERT], 524 [CERTREQ][IDr]CP(CFG_REQUEST), 525 SAi2, TSi, TSr}) : 526 :...> CFG_REQUEST: If NA(P)T is detected, 527 => EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info 529 <--------------------------- IKEv2 Message 4 530 (HDR, SK{IDr, [CERT], Auth, 531 CP(CFG_REPLY), SAr2, TSi, TSr}) 532 : 533 CFG_REPLY: If successful authentication <..: 534 EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info <= 536 NOTE: EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4 Info includes 537 Both source IPv4 address and port number that have been 538 translated by the NA(P)T. 540 Figure 3 : Example of the IKEv2 Configuration Payload solution to 541 carry the public IPv4 address and port number of the UDP header for 542 the encapsulated IPSec tunnel 544 The details of the proposed changes are described in the following 545 section. 547 3.1. Details of proposed changes to RFC 5996 [RFC5996] for IKEv2 CP 549 New code point and the corresponding descriptions to be added to RFC 550 5996 [RFC5996], section 3.15, are shown as follows: 552 NOTE: The new code point is highlighted in a different color. 554 Attribute Type Value Multi-Valued Length 556 ------------------------------------------------------------------- 558 INTERNAL_IP4_ADDRESS 1 YES 0 or 4 octets 560 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets 562 INTERNAL_IP4_DNS 3 YES 0 or 4 octets 564 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets 566 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets 568 APPLICATION_VERSION 7 NO 0 or more 570 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets 572 INTERNAL_IP6_DNS 10 YES 0 or 16 octets 574 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets 576 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets 578 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 580 INTERNAL_IP6_SUBNET 15 YES 17 octets 582 EXTERNAL Source_IPv4_NAT_Info 584 16 NO 0 or 6 octets 586 * These attributes may be multi-valued on return only if multiple 587 values were requested. 589 : 591 : 593 EXTERNAL_Source_IPv4_NAT_Info - The translated external source IPv4 594 address and the optional port number of the UDP encapsulated packet 595 sent by the initiator is requested by initiator in CFG_REQUEST once 596 the IKE peers detect the presence of NA(P)T in between. If both the 597 initiator and responder are mutually authenticated, the initiator's 598 source IP address and the optional UDP port number of the UDP 599 encapsulated packet will be retrieved by responder and to be included 600 in CFG_REPLY. This attribute is made up of two fields: the first 601 being an IPv4 address and optionally, the second being an IPv4 UDP 602 port number. The responder MAY respond with zero or one attribute to 603 initiator. This is discussed in more detail in Section 3.15.4. 605 : 607 : 609 3.15.4 Configuration Payloads for EXTERNAL_Source_IPv4_NAT_Info 611 The Configuration payloads is used by the IKE initiator to request 612 its corresponding IKE responder via the CFG_REQUEST to return its 613 source IPv4 NAT information, which is composed of the IPv4 address 614 and the optional IPv4 UDP port number, via the CFG_REPLY. 616 The IKE initiator will request such information from its 617 corresponding IKE responder if the presence of NA(P)T is detected via 618 the NAT traversal procedures in between itself and its corresponding 619 responder. 621 If the initiator and the responder are mutually authenticated, the 622 responder will respond to initiator for the translated initiator's 623 source IPv4 address and the optional translated source UDP port 624 number information. 626 A minimal exchange might look like this: 628 CP(CFG_REQUEST) = EXTERNAL_Source_IPv4_NAT_Info() 630 CP(CFG_REPLY) = EXTERNAL Source_IPv4_NAT_Info(198.51.100.234, 233) 632 4. Security Considerations 634 The proposed solution is to add a new code point to the already 635 defined IKEv2 Configuration Payload with no change to the existing 636 IKEv2 security mechanism that has been used to protect the CP. 638 5. IANA Considerations 640 A new code point for IKEv2 Configuration Payload that indicates the 641 new contents containing the source IPv4 address and source port 642 number of the IKE-initiator which is assigned by the NA(P)T is 643 required to be registered with IANA. 645 6. Conclusions 647 This document explains the issues of the lack of the support in the 648 FMC architecture to retrieve the mapping of the FAP's public IPv4 649 address and port number with the inner IP address of the mobile UE 650 that is attached to the FAP in order to support the FMC interworking 651 deployment with FAP. 653 This document discusses the requirements and the solution 654 considerations to resolve the issue as described above. One solution 655 is eventually selected as the final proposal which only requires 656 simple extension to the IKEv2 Configuration Payload as defined in RFC 657 5996 [RFC5996] to carry the mapping information inserted by the SeGW 658 (i.e. IKE-responder) and to be passed onto the FAP (i.e. IKE- 659 initiator). In addition, the solution is backward compatible to the 660 existing FAP system architecture and signaling procedures. 662 7. References 664 7.1. Normative References 666 [RFC 5996] Internet Key Exchange Version 2, C. Kaulman et al 667 http://www.rfc-editor.org/rfc/rfc5996.txt 669 [RFC 5389] Session Traversal Utility for NAT, J. Rosenberg et al, 670 http://www.rfc-editor.org/rfc/rfc5389.txt 672 7.2. Informative References 674 8. Acknowledgments 676 TBD 678 Authors' Addresses 680 Tricci So 681 ZTE USA 682 9920 Pacific Heights Blvd., STE 400, San Diego, CA, 92121 684 Email: tso@zteusa.com