idnits 2.17.1 draft-ietf-pcp-proxy-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (January 29, 2014) is 3733 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PCP' is mentioned on line 127, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-pcp-server-selection-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Perreault, Ed. 3 Internet-Draft Viagenie 4 Intended status: Standards Track M. Boucadair 5 Expires: August 02, 2014 France Telecom 6 R. Penno 7 D. Wing 8 Cisco 9 S. Cheshire 10 Apple 11 January 29, 2014 13 Port Control Protocol (PCP) Proxy Function 14 draft-ietf-pcp-proxy-05 16 Abstract 18 This document specifies a new PCP functional element denoted as a PCP 19 Proxy. The PCP Proxy relays PCP requests received from PCP clients 20 to upstream PCP server(s). A typical deployment usage of this 21 function is to help establish successful PCP communications for PCP 22 clients that can not be configured with the address of a PCP server 23 located more than one hop away. 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 August 02, 2014. 42 Copyright Notice 44 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Use Case: the NAT Cascade . . . . . . . . . . . . . . . . 3 61 1.2. Use Case: the PCP Relay . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Operation of the PCP Proxy . . . . . . . . . . . . . . . . . 5 64 3.1. Optimized Hairpin Routing . . . . . . . . . . . . . . . . 7 65 3.2. Termination of Recursion . . . . . . . . . . . . . . . . 8 66 3.3. Source Address for PCP Requests Sent Upstream . . . . . . 8 67 3.4. Unknown OpCodes and Options . . . . . . . . . . . . . . . 9 68 3.5. Mapping Repair . . . . . . . . . . . . . . . . . . . . . 9 69 3.6. Multiple PCP Servers . . . . . . . . . . . . . . . . . . 10 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 7.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 This document defines a new PCP [RFC6887] functional element: the PCP 81 Proxy. As shown in Figure 1, the PCP proxy is logically equivalent 82 to a PCP client back-to-back with a PCP server. The "glue" between 83 the two is what is specified in this document. Other than that 84 "glue", the server and the client behave exactly like their regular 85 counterparts. 87 ................. 88 +------+ : +------+------+ : +------+ 89 |Client|-------:-|Server|Client|-:----|Server| 90 +------+ : +------+------+ : +------+ 91 : Proxy : 92 ................. 94 Figure 1: Reference Architecture 96 1.1. Use Case: the NAT Cascade 98 In today's world, with public routable IPv4 addresses becoming less 99 readily available, it is increasingly common for customers to receive 100 a private address from their ISP, and the ISP uses a NAT gateway of 101 its own to translate those packets before sending them out onto the 102 public Internet. This means that there is likely to be more than on 103 NAT on the path between client machines and the public Internet: 105 o If a residential customer receives a translated address from their 106 ISP, and then installs their own residential NAT gateway to share 107 that address between multiple client devices in their home, then 108 there are at least two NAT gateways on the path between client 109 devices and the public Internet. 111 o If a mobile phone customer receives a translated address from 112 their mobile phone carrier, and uses "Personal Hotspot" or 113 "Internet Sharing" software on their mobile phone to make Wi-Fi 114 Internet access available to other client devices, then there are 115 at least two NAT gateways on the path between those client devices 116 and the public Internet. 118 o If a hotel guest connects a portable Wi-Fi gateway, such as an 119 Apple AirPort Express, to their hotel room Ethernet port to share 120 their room's Internet connection between their phone, their iPad, 121 and their laptop computer, then packets from the client devices 122 may traverse the hotel guest's portable NAT, the hotel network's 123 NAT, and the ISP's NAT before reaching the public Internet. 125 While it is possible, in theory, that client devices could somehow 126 discover all the NATs on the path, and communicate with each one 127 separately using Port Control Protocol [PCP] (NAT-PMP's IETF 128 Standards Track successor), in practice it's not clear how client 129 devices would reliably learn this information. Since the NAT 130 gateways are installed and operated by different individuals and 131 organizations, no single entity has knowledge of all the NATs on the 132 path. Also, even if a client device could somehow know all the NATs 133 on the path, requiring a client device to communicate separately with 134 all of them imposes unreasonable complexity on PCP clients, many of 135 which are expected to be simple low-cost devices. 137 In addition, this goes against the spirit of NAT gateways. The main 138 purpose of a NAT gateway is to make multiple downstream client 139 devices making outgoing TCP connections to appear, from the point of 140 view of everything upstream of the NAT gateway, to be a single client 141 device making outgoing TCP connections. In the same spirit, it makes 142 sense for a PCP-capable NAT gateway to make multiple downstream 143 client devices requesting port mappings to appear, from the point of 144 view of everything upstream of the NAT gateway, to be a single client 145 device requesting port mappings. 147 1.2. Use Case: the PCP Relay 149 Another envisioned use case of the PCP Proxy is to help establish 150 successful PCP communications for PCP clients that can not be 151 configured with the address of a PCP server located more than one hop 152 away. A PCP Proxy can be for instance embedded in a CPE (Customer 153 Premises Equipment) while the PCP server is located in a network 154 operated by an ISP (Internet Service Provider). This is illustrated 155 in Figure 2. 157 | 158 +------+ | 159 |Client|--+ 160 +------+ | +-----+ +------+ 161 +--|Proxy|------------------|Server| 162 +------+ | +-----+ +------+ 163 |Client|--+ CPE 164 +------+ | 165 | 166 LAN 168 Figure 2: PCP Relay Use Case 170 This works because the proxy's server side is listening on the 171 address used as a default gateway by the clients. The clients use 172 that address as a fallback when discovering the PCP server's address. 173 The proxy picks up the requests and forwards them upstream to the 174 ISP's PCP server, with whose address it has been provisioned through 175 regular PCP client provioning means. 177 This particular use case assumes that provisioning the server's 178 address on the CPE is feasible while doing it on the clients in the 179 LAN is not, which is what makes the PCP proxy valuable. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 Where this document uses the terms "upstream" and "downstream", the 188 term "upstream" refers to the direction outbound packets travel 189 towards the public Internet, and the term "downstream" refers to the 190 direction inbound packets travel from the public Internet towards 191 client systems. Typically when a home user views a web site, their 192 computer sends an outbound TCP SYN packet upstream towards the public 193 Internet, and an inbound downstream TCP SYN ACK reply comes back from 194 the public Internet. 196 3. Operation of the PCP Proxy 198 Upon receipt of a PCP mapping-creation request from a downstream PCP 199 client, a PCP proxy first examines its local mapping table to see if 200 it already has a valid active mapping matching the Internal Address 201 and Internal Port (and in the case of PEER requests, remote peer) 202 given in the request. 204 If the PCP proxy does not already have a valid active mapping for 205 this mapping-creation request, then it allocates an available port on 206 its external interface. We assume for the sake of this description 207 that the address of its external interface is itself a private 208 address, subject to translation by an upstream NAT. The PCP proxy 209 then constructs an appropriate corresponding PCP request of its own 210 (described below), and sends it to its upstream NAT, and the newly- 211 created local mapping is considered temporary until a confirming 212 reply is received from the upstream PCP server. 214 If the PCP proxy does already have a valid active mapping for this 215 mapping-creation request, and the lifetime remaining on the local 216 mapping is at least 3/4 of the lifetime requested by the PCP client, 217 then the PCP proxy SHOULD send an immediate reply giving the 218 outermost External Address and Port (previously learned using PCP 219 recursively, as described below), and the actual lifetime remaining 220 for this mapping. If the lifetime remaining on the local mapping is 221 less than 3/4 of the lifetime requested by the PCP client, then the 222 PCP proxy MUST generate an upstream request as described below. 224 For mapping-deletion requests (Lifetime = 0), the local mapping, if 225 any, is deleted, and then (regardless of whether a local mapping 226 existed) a corresponding upstream request is generated. 228 The PCP proxy knows the destination IP address for its upstream PCP 229 request using the same means that are available for provisioning a 230 PCP client. In particular, the PCP proxy MUST follow the procedure 231 defined in Section 8.1 of [RFC6887] to discover its PCP server. This 232 does not preclude other means from being used in addition. 234 In the upstream PCP request: 236 o The PCP Client's IP Address and Internal Port are the PCP proxy's 237 own external address and port just allocated for this mapping. 239 o The Suggested External Address and Port in the upstream PCP 240 request SHOULD be copied from the original PCP request. 242 o The Requested Lifetime is as requested by the client if it falls 243 within the acceptable range for this PCP server; otherwise it 244 SHOULD be capped to appropriate minimum and maximum values 245 configured for this PCP server. 247 o The Mapping Nonce is copied from the original PCP request. 249 o For PEER requests, the Remote Peer IP Address and Port are copied 250 from the original PCP request. 252 Upon receipt of a PCP reply giving the outermost (i.e. publicly 253 routable) External Address, Port and Lifetime, the PCP proxy records 254 this information in its own mapping table and relays the information 255 to the requesting downstream PCP client in a PCP reply. The PCP 256 proxy therefore records, among other things, the following 257 information in its mapping table: 259 o Client's Internal Address and Port. 261 o External Address and Port allocated by this PCP proxy. 263 o Outermost External Address and Port allocated by the upstream PCP 264 server. 266 o Mapping lifetime (also dictated by the upstream PCP server). 268 o Mapping nonce. 270 In the downstream PCP reply: 272 o The Lifetime is as granted by the upstream PCP server, or less, if 273 the granted lifetime exceeds the maximum lifetime this PCP server 274 is configured to grant. If the downstream Lifetime is more than 275 the Lifetime granted by the upstream PCP server (which is NOT 276 RECOMMENDED) then this PCP proxy MUST take responsibility for 277 renewing the upstream mapping itself. 279 o The Epoch Time is *this* PCP proxy's Epoch Time, not the Epoch 280 Time of the upstream PCP server. Each PCP server has its own 281 independent Epoch Time. However, if the Epoch Time received from 282 the upstream PCP server indicates a loss of state in that PCP 283 server, the PCP proxy can either recreate the lost mappings 284 itself, or it can reset its own Epoch Time to cause its downstream 285 clients to perform such state repairs themselves. A PCP proxy 286 MUST NOT simply copy the upstream PCP server's Epoch Time into its 287 downstream PCP replies, since if it suffers its own state loss it 288 needs the ability to communicate that state loss to clients. Thus 289 each PCP server has its own independent Epoch Time. However, as a 290 convenience, a downstream PCP proxy may simply choose to reset its 291 own Epoch Time whenever it detects that its upstream PCP server 292 has lost state. Thus, in this case, the PCP proxy's Epoch Time 293 always resets whenever its upstream PCP server loses state; it may 294 also reset at other times too. 296 o The Mapping Nonce is copied from the reply received from the 297 upstream PCP server. 299 o The Assigned External Port and Assigned External IP Address are 300 copied from the reply received from the upstream PCP server. 301 (I.e. they are the outermost External IP Address and Port, not 302 the locally-assigned external address and port.) 304 o For PEER requests, the Remote Peer IP Address and Port are copied 305 from the reply received from the upstream PCP server. 307 3.1. Optimized Hairpin Routing 309 A PCP proxy SHOULD implement Optimized Hairpin Routing. What this 310 means is the following: 312 o If a PCP proxy observes an outgoing packet arriving on its 313 internal interface that is addressed to an External Address and 314 Port appearing in the NAT gateway's own mapping table, then the 315 NAT gateway SHOULD (after creating a new outbound mapping if one 316 does not already exist) rewrite the packet appropriately and 317 deliver it to the internal client currently allocated that 318 External Address and Port. 320 o If a PCP proxy observes an outgoing packet arriving on its 321 internal interface which is addressed to an Outermost External 322 Address and Port appearing in the NAT gateway's own mapping table, 323 then the NAT gateway SHOULD do likewise: create a new outbound 324 mapping if one does not already exist, and then rewrite the packet 325 appropriately and deliver it to the internal client currently 326 allocated that Outermost External Address and Port. This is not 327 necessary for successful communication, but for efficiency. 328 Without this Optimized Hairpin Routing, the packet will be 329 delivered all the way to the outermost NAT gateway, which will 330 then perform standard hairpin translation and send it back. Using 331 knowledge of the Outermost External Address and Port, this 332 rewriting can be anticipated and performed locally, which will 333 typically offer higher throughput and lower latency than sending 334 it all the way to the outermost NAT gateway and back. 336 3.2. Termination of Recursion 338 Any recursive algorithm needs a mechanism to terminate the recursion 339 at the appropriate point. This termination of recursion can be 340 achieved in a variety of ways: 342 o An ISP's NAT gateway could be configured to know that it is the 343 outermost NAT gateway, and consequently does not need to relay PCP 344 requests upstream. In fact, it may be the case that many large- 345 scale NATs of the kind used by ISPs may simply not implement 346 Recursive PCP, thereby naturally terminating the recursion at that 347 point. 349 o A NAT gateway could determine automatically that if its external 350 address is not one of the known private addresses 351 [RFC1918][RFC6598] then its external address is a public routable 352 IP address, and consequently it does not need to relay PCP 353 requests upstream. 355 3.3. Source Address for PCP Requests Sent Upstream 357 As with a regular PCP server, the PCP-controlled device can be a NAT, 358 a firewall, or even some sort of hybrid. In particular, a PCP proxy 359 that simply relays all requests upstream can be thought of as the 360 degenerate case of a PCP server controlling a wide-open firewall 361 back-to-back with a regular PCP client. 363 One important property of the PCP-controlled device will affect the 364 PCP proxy's behaviour: when the proxy's server part instructs the 365 device to create a mapping, that mapping's external address may or 366 may not be one that belongs to the proxy node. 368 o When the mapping's external address belongs to the proxy node, as 369 would presumably be the case for a NAT, then the proxy's client 370 side sends out an upstream PCP request using the mapping's 371 external IP address as source. 373 o When the mapping's external address does not belong to the proxy 374 node, as would presumably be the case for a firewall, then the 375 proxy's client side needs to install upstream mappings on behalf 376 of its downstream clients. To do this, it MUST insert a 377 THIRD_PARTY Option in its upstream PCP request carrying the 378 mapping's external address. 380 Note that hybrid PCP-controlled devices may create NAT-like mappings 381 in some circumstances and firewall-like mappings in others. A proxy 382 controlling such a device would adjust its behavior dynamically 383 depending on the kind of mapping created. 385 3.4. Unknown OpCodes and Options 387 [Editor's note: I think this section is severely broken. I'll leave 388 it as-is for this revision and will start discussion on the list.] 390 By default, the proxy MUST relay unknown OpCodes and mandatory-to- 391 process unknown Options. Rejecting unknown Options and OpCodes has 392 the drawback of preventing a PCP client to make use of new 393 capabilities offered by the PCP server but not supported by the PCP 394 Proxy even if no IP address and/or port is included in the Option/ 395 OpCode. 397 Because PCP messages with an unknown OpCode or mandatory-to-process 398 unknown Options can carry a hidden internal address or internal port 399 that will not be translated, a PCP Proxy MUST be configurable to 400 disable relaying unknown OpCodes and mandatory-to-process unknown 401 Options. If the PCP Proxy is configured to disable relaying unknown 402 OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST 403 behave as follows: 405 o It returns an UNSUPP_OPCODE error response when it receives a 406 request with an unknown OpCode. 408 o It returns an UNSUPP_OPTION error response when it receives a 409 request with a mandatory-to-process unknown Option. 411 3.5. Mapping Repair 413 ANNOUNCE requests received from PCP clients are handled locally; as 414 such these requests MUST NOT be relayed to the provisioned PCP 415 server. 417 Upon receipt of an unsolicited ANNOUNCE response from a PCP server, 418 the PCP Proxy proceeds to renew the mappings and checks whether there 419 are changes compared to a local cache if it is maintained by the PCP 420 Proxy. If no change is detected, no unsolicited ANNOUNCE is 421 generated towards PCP clients. If a change is detected, the PCP 422 Proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate 423 PCP clients. If the PCP Proxy does not maintain a local cache for 424 the mappings, unsolicited multicast ANNOUNCE messages are sent to PCP 425 clients. 427 Upon change of its external IP address, the PCP Proxy SHOULD renew 428 the mappings it maintained. If the PCP server assigns a different 429 external port, the PCP Proxy SHOULD follow the mapping repair 430 procedure defined in [RFC6887]. This can be achieved only if a full 431 state table is maintained by the PCP Proxy. 433 3.6. Multiple PCP Servers 435 A PCP Proxy MAY handle multiple PCP servers at the same time. Each 436 PCP server is associated with its own epoch value. PCP clients are 437 not aware of the presence of multiple PCP servers. 439 According to [I-D.ietf-pcp-server-selection], if several PCP Names 440 are configured to the PCP Proxy, it will contact in parallel all 441 these PCP servers. 443 In some contexts (e.g., PCP-controlled CGNs), the PCP Proxy MAY load 444 balance the PCP clients among available PCP servers. The PCP Proxy 445 MUST ensure requests of a given PCP client are relayed to the same 446 PCP server. 448 The PCP Proxy MAY rely on some fields (e.g., Zone ID 449 [I-D.penno-pcp-zones]) in the PCP request to redirect the request to 450 a given PCP server. 452 4. IANA Considerations 454 This document makes no request of IANA. 456 5. Security Considerations 458 The PCP Proxy MUST follow the security considerations elaborated in 459 [RFC6887] for both the client and server side. 461 Section 3.3 specifies the cases where a THIRD_PARTY option is 462 inserted the PCP Proxy. In those cases, means to prevent a malicious 463 user from creating mappings on behalf of a third party must be 464 enabled as discussed in Section 13.1 of [RFC6887]. In particular, 465 THIRD_PARTY option MUST NOT be enabled unless the network on which 466 the PCP messages are to be sent is fully trusted. For example if 467 access control lists (ACLs) are installed on the PCP Proxy, PCP 468 server, and the network between them, so those ACLs allow only 469 communications from a trusted PCP Proxy to the PCP server. 471 A received request carrying an unknown OpCode or Option SHOULD be 472 dropped (or in the case of an unknown Option which is not mandatory- 473 to-process the Option be removed) if it is not compatible with 474 security controls provisionned to the PCP Proxy. 476 The device embedding the PCP Proxy MAY block PCP requests directly 477 sent to the PCP server. This can be enforced using access control 478 lists. 480 6. Acknowledgements 482 Many thanks to C. Zhou, T. Reddy, and D. Thaler for their review and 483 comments. 485 Special thanks to F. Dupont who contributed to this document. 487 7. References 489 7.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 495 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 496 2013. 498 7.2. Informative References 500 [I-D.ietf-pcp-server-selection] 501 Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 502 Reddy, "PCP Server Selection", draft-ietf-pcp-server- 503 selection-02 (work in progress), January 2014. 505 [I-D.penno-pcp-zones] 506 Penno, R., "PCP Support for Multi-Zone Environments", 507 draft-penno-pcp-zones-01 (work in progress), October 2011. 509 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 510 E. Lear, "Address Allocation for Private Internets", BCP 511 5, RFC 1918, February 1996. 513 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 514 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 515 Space", BCP 153, RFC 6598, April 2012. 517 Authors' Addresses 519 Simon Perreault (editor) 520 Viagenie 521 246 Aberdeen 522 Quebec, QC G1R 2E1 523 Canada 525 Phone: +1 418 656 9254 526 Email: simon.perreault@viagenie.ca 527 URI: http://viagenie.ca 528 Mohamed Boucadair 529 France Telecom 530 Rennes 35000 531 France 533 Email: mohamed.boucadair@orange.com 535 Reinaldo Penno 536 Cisco 537 USA 539 Email: repenno@cisco.com 541 Dan Wing 542 Cisco Systems, Inc. 543 170 West Tasman Drive 544 San Jose, California 95134 545 USA 547 Email: dwing@cisco.com 549 Stuart Cheshire 550 Apple Inc. 551 1 Infinite Loop 552 Cupertino, California 95014 553 USA 555 Phone: +1 408 974 3207 556 Email: cheshire@apple.com