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