RFC 7648

Port Control Protocol (PCP) Proxy Function

📅 published September 2015, from ietf

Port Control Protocol (PCP) Proxy Function 🦋

Abstract ✨

okay so this doc is RFC 7648, "Port Control Protocol (PCP) Proxy Function" 🎀 It's a Standards Track document from September 2015 (ISSN 2070-1721), written by S. Perreault (Jive Communications), M. Boucadair (France Telecom), R. Penno and D. Wing (Cisco), and S. Cheshire (Apple). The header doesn't list any Obsoletes or Updates, so it's not replacing or changing anything else. 💅

The big idea: this doc adds a brand new PCP functional element called the PCP proxy 💖 It takes PCP requests from PCP clients and relays them up to upstream PCP server(s). The main job is helping PCP clients get PCP working when they can't be set up with the address of a PCP server that's more than one hop away. Iconic. 🧚

Status of This Memo

This is an Internet Standards Track document. 🌸

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. More info on Internet Standards is in Section 2 of RFC 5741. ✨

You can check the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7648. 🔥

Copyright (c) 2015 IETF Trust and the people listed as the document authors. All rights reserved. 🌈

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read those, because they spell out what you're allowed to do (and not do) with this doc. 🙈 Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says. 💜

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Use Case: The NAT Cascade . . . . . . . . . . . . . . . .   4
  1.2.  Use Case: The PCP Relay . . . . . . . . . . . . . . . . .   5
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
3.  Operation of the PCP Proxy  . . . . . . . . . . . . . . . . .   6
  3.1.  Optimized Hairpin Routing . . . . . . . . . . . . . . . .   8
  3.2.  Termination of Recursion  . . . . . . . . . . . . . . . .   9
  3.3.  Source Address for PCP Requests Sent Upstream . . . . . .  10
  3.4.  Unknown Opcodes and Options . . . . . . . . . . . . . . .  10
    3.4.1.  No NAT Is Co-located with the PCP Proxy . . . . . . .  10
    3.4.2.  PCP Proxy Co-located with a NAT Function  . . . . . .  10
  3.5.  Mapping Repair  . . . . . . . . . . . . . . . . . . . . .  11
  3.6.  Multiple PCP Servers  . . . . . . . . . . . . . . . . . .  11
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
  5.2.  Informative References  . . . . . . . . . . . . . . . . .  13
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction 🧚

This doc defines a new Port Control Protocol (PCP) [RFC6887] functional element: the PCP proxy. As Figure 1 shows, the PCP proxy is basically a PCP client back-to-back with a PCP server. ✨ The "glue" in the middle is the only part this doc specifies. Other than that glue, the server and the client act exactly like their regular versions. 💅

The PCP proxy is responsible for relaying PCP messages from PCP clients up to upstream PCP servers, and back down again. 🫶

Whether or not the PCP proxy sits next to a flow-aware function (like a NAT or a firewall) depends on the deployment. 🌸

                  .................
  +------+       : +------+------+ :    +------+
  |Client|-------:-|Server|Client|-:----|Server|
  +------+       : +------+------+ :    +------+
                 :      Proxy      :
                  .................

         Figure 1: Reference Architecture

This doc assumes a hop-by-hop PCP authentication scheme. 🔐 So, looking at Figure 1, the leftmost PCP client authenticates with the PCP proxy, and the PCP proxy authenticates with the upstream server. Heads up: in some deployments, PCP authentication might only happen between the PCP proxy and an upstream PCP server. For example, a customer premises host might not authenticate with the PCP proxy, while the PCP proxy still authenticates with the PCP server. The hop-by-hop approach is just easier to deploy. 🙌 It also lets implementations easily support a PCP proxy that changes PCP messages, like stripping a PCP option or modifying a PCP field. 🍓

1.1. Use Case: The NAT Cascade 🌈

Okay, so public routable IPv4 addresses are getting harder to find these days, so it's getting super common for customers to get a private address from their Internet Service Provider (ISP). Then the ISP runs its own NAT gateway to translate those packets before they go out onto the public Internet. 💀 That means there's probably more than one NAT on the path between client machines and the public Internet:

  • If a residential customer gets a translated address from their ISP, then sets up their own residential NAT gateway to share that address across multiple devices at home, there are at least two NAT gateways on the path between the client devices and the public Internet. 🏠
  • If a mobile phone customer gets a translated address from their mobile phone carrier and uses "Personal Hotspot" or "Internet Sharing" software on their phone to make Wireless LAN (WLAN) Internet access available to other client devices, there are at least two NAT gateways on the path between those client devices and the public Internet. 📱
  • If a hotel guest plugs a portable WLAN gateway into their hotel room's Ethernet port to share the room's Internet connection between their phone and their laptop, packets from the client devices may go through the hotel guest's portable NAT, the hotel network's NAT, and the ISP's NAT before reaching the public Internet. 🏨

Could client devices, in theory, find all the NATs on the path and talk to each one separately using PCP [RFC6887]? Sure. But in practice it's not clear how they'd reliably learn that info. 🤔 The NAT gateways are installed and run by different people and organizations, so no single entity knows about all the NATs on the path. Plus, even if a client device somehow knew about all of them, making it talk to each one separately would be way too complicated for PCP clients, and a lot of them are expected to be simple, low-cost devices. 😭

And honestly, this goes against the spirit of NAT gateways. ✨ The main purpose of a NAT gateway is to make multiple downstream client devices look like a single client device to everything upstream of the NAT gateway. Following that same spirit, it makes sense for a PCP-capable NAT gateway to make multiple downstream client devices that request port mappings look like a single client device requesting port mappings, from the point of view of everything upstream. Main character energy. 👑

1.2. Use Case: The PCP Relay 🎀

Another use case the PCP proxy was designed for is helping PCP clients get PCP communications working when they can't be configured with the address of a PCP server that's more than one hop away. 💖 For example, a PCP proxy can be embedded in a CPE (Customer Premises Equipment) while the PCP server lives in a network run by an ISP. Figure 2 shows this. 🦋

              |
  +------+    |
  |Client|----+
  +------+    |  +-----+                               +------+
              +--|Proxy|--------<ISP network>----------|Server|
  +------+    |  +-----+                               +------+
  |Client|----+    CPE
  +------+    |
              |
             LAN

            Figure 2: PCP Relay Use Case

This works because the proxy's server side listens on the address the clients use as their default gateway. 🧚 The clients use that address as a fallback when they're discovering the PCP server's address. The proxy picks up those requests and forwards them upstream to the ISP's PCP server, whose address was provisioned into the proxy through regular PCP client provisioning. 🫶

This particular use case assumes that provisioning the server's address on the CPE is feasible, but provisioning it on the clients in the LAN is not. That's exactly what makes the PCP proxy valuable. 💅

There's another way to contact an upstream PCP server that might be several hops away: use a well-known anycast address [PCP-ANYCAST]. But that approach can be problematic when multiple PCP servers need to be contacted [PCP-DEPLOY]. 🙈

2. Terminology 🌸

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 🔑

When this doc says "upstream" and "downstream", "upstream" means the direction outbound packets travel toward the public Internet, and "downstream" means the direction inbound packets travel from the public Internet toward client systems. 🌐 For example, when a home user loads a website, their computer sends an outbound TCP SYN packet upstream toward the public Internet, and an inbound downstream TCP SYN ACK reply comes back from the public Internet. 🍓

3. Operation of the PCP Proxy ✨

Okay so, picture this: a downstream PCP client asks for a mapping-creation, and the PCP proxy's first move is to check its own local mapping table 👀. It's looking for a valid active mapping that matches the internal address and internal port (and, for PEER requests, the remote peer too) from the request.

If the proxy doesn't already have a valid active mapping for that request, it grabs an available port on its external interface. For the sake of this explanation, we're assuming its external interface address is itself a private address, which an upstream NAT translates. The proxy then builds its own matching PCP request (more on that below) and sends it up to the upstream NAT. The brand-new local mapping is considered temporary until a confirming reply comes back from the upstream PCP server 🫣.

If the proxy does already have a valid active mapping for the request, and the lifetime left on that local mapping is at least 3/4 of the lifetime the client asked for, the proxy SHOULD send an immediate reply. That reply gives the outermost external address and port (learned earlier through PCP, recursively, as described below) plus the actual lifetime remaining for the mapping. But if the remaining lifetime is less than 3/4 of what the client requested, the proxy MUST generate an upstream request, as described below 🔄.

For mapping-deletion requests (lifetime = 0), the local mapping gets deleted if it exists. Then, whether or not a local mapping existed, a matching upstream request is generated 🗑️.

The proxy figures out where to send its upstream PCP request using the same methods available for provisioning a PCP client. Specifically, the PCP proxy MUST follow the procedure defined in Section 8.1 of the PCP specification [RFC6887] to discover its PCP server. Other methods can be used on top of that if needed 🧭.

In the upstream PCP request:

  • The PCP client's IP address and internal port are the PCP proxy's own external address and port, just allocated for this mapping.
  • The suggested external address and port in the upstream PCP request SHOULD be copied from the original PCP request. On a typical renewal, this is the outermost external address and port the client previously learned 🔁.
  • The requested lifetime is the one the client asked for, if it falls within the acceptable range for this PCP server. Otherwise, it SHOULD be capped to the appropriate minimum and maximum values configured for this PCP server.
  • The mapping nonce is copied from the original PCP request.
  • For PEER requests, the remote peer IP address and port are copied from the original PCP request.

When a PCP reply comes back with the outermost (that is, publicly routable) external address, port, and lifetime, the proxy records that info in its own mapping table and passes it along to the requesting downstream PCP client in a PCP reply 💌. So the proxy stores, among other things, the following in its mapping table:

  • Client's internal address and port.
  • External address and port allocated by this PCP proxy.
  • Outermost external address and port allocated by the upstream PCP server.
  • Mapping lifetime (also dictated by the upstream PCP server).
  • Mapping nonce.

And in the downstream PCP reply:

  • The lifetime is the one granted by the upstream PCP server, or less if the granted lifetime goes over the maximum lifetime this PCP server is configured to grant. If the proxy chooses to grant a downstream lifetime greater than what the upstream PCP server granted (which is NOT RECOMMENDED), then this PCP proxy MUST take responsibility for renewing the upstream mapping itself 😬.
  • The Epoch Time is this PCP proxy's Epoch Time, not the upstream PCP server's. Every PCP server has its own independent Epoch Time. If the Epoch Time received from the upstream PCP server signals a loss of state there, the PCP proxy can either (1) recreate the lost mappings itself, or (2) reset its own Epoch Time so its downstream clients do the state repairs themselves. A PCP proxy MUST NOT simply copy the upstream PCP server's Epoch Time into its downstream PCP replies, because if it suffers its own state loss, it needs a way to tell clients about that loss 🚨. So yes, every PCP server keeps its own independent Epoch Time. As a convenience, though, a downstream PCP proxy may simply reset its own Epoch Time whenever it notices its upstream PCP server has lost state. In that case, the proxy's Epoch Time always resets when its upstream PCP server loses state, and it may reset at other times too 🫶.
  • The mapping nonce is copied from the reply received from the upstream PCP server.
  • The assigned external port and assigned external IP address are copied from the reply received from the upstream PCP server. In other words, they're the outermost external IP address and port, not the locally assigned ones. By recursively applying this procedure, the outermost external IP address and port get relayed from the outermost NAT, through one or more intervening PCP proxies, all the way to the downstream client 🌈.
  • For PEER requests, the remote peer IP address and port are copied from the reply received from the upstream PCP server.

3.1. Optimized Hairpin Routing

A PCP proxy SHOULD implement optimized hairpin routing 🎀. Here's what that means:

  • If a PCP proxy sees an outgoing packet arriving on its internal interface that's addressed to an external address and port appearing in the NAT gateway's own mapping table, then the NAT gateway SHOULD (after creating a new outbound mapping if one doesn't already exist) rewrite the packet appropriately and deliver it to the internal client that external address and port are currently allocated to 📦.
  • Similarly, if a PCP proxy sees an outgoing packet arriving on its internal interface that's addressed to an outermost external address and port appearing in the NAT gateway's own mapping table, then the NAT gateway SHOULD do as described above. That means it creates a new outbound mapping if one doesn't already exist, then rewrites the packet and delivers it to the internal client that outermost external address and port are currently allocated to. This isn't necessary for successful communication, but it's more efficient 🏎️. Without optimized hairpin routing, the packet travels all the way to the outermost NAT gateway, which performs standard hairpin translation and sends it back. Since the proxy knows the outermost external address and port, it can anticipate that rewrite and do it locally. This technique typically gives higher throughput and lower latency than sending packets all the way out and back ⚡.

Heads up: traffic counters kept by an upstream PCP server will differ from the counters of a PCP proxy doing optimized hairpin routing 📊.

3.2. Termination of Recursion

Any recursive algorithm needs a way to stop recursing at the right point 🛑. There are a bunch of ways to do that. The following examples (not an exhaustive list) are just for illustration:

  • An ISP's PCP-controlled gateway (which may embed a NAT, firewall, or any function that can be controlled with PCP) could be configured to know that it's the outermost PCP-controlled gateway. As a result, it doesn't need to relay PCP requests upstream.
  • A PCP-controlled gateway could automatically work out that if its external address isn't one of the known private addresses [RFC1918] [RFC6598], then its external address is a publicly routable IP address. As a result, it doesn't need to relay PCP requests upstream.
  • Recursion may be terminated if there's no explicit list of PCP servers configured (manually, using DHCP [RFC7291], or otherwise), or if its default router isn't responsive to PCP requests.
  • Recursion may also be terminated if the upstream PCP-controlled device doesn't embed a PCP proxy.

3.3. Source Address for PCP Requests Sent Upstream

Just like a regular PCP server, the PCP-controlled device can be a NAT, a firewall, or even some kind of hybrid 🧁. A PCP proxy that simply relays everything upstream can be thought of as the degenerate case: a PCP server controlling a wide-open firewall, back-to-back with a regular PCP client.

One important property of the PCP-controlled device affects the PCP proxy's behavior. When the proxy's server part tells the device to create a mapping, that mapping's external address may or may not belong to the proxy node 🤔.

  • When the mapping's external address belongs to the proxy node, as would presumably be the case for a NAT, the proxy's client side sends out an upstream PCP request using the mapping's external IP address as the source.
  • When the mapping's external address does not belong to the proxy node, as would presumably be the case for a firewall, the proxy's client side needs to install upstream mappings on behalf of its downstream clients. To do this, it MUST insert a THIRD_PARTY option in its upstream PCP request, carrying the mapping's external address 🫢.

Note that hybrid PCP-controlled devices may create NAT-like mappings in some situations and firewall-like mappings in others. A proxy controlling such a device would adjust its behavior dynamically, depending on the kind of mapping created 🦋.

3.4. Unknown Opcodes and Options

3.4.1. No NAT Is Co-located with the PCP Proxy

When no NAT is co-located with the PCP proxy, the port numbers in received PCP messages (from the PCP server or PCP clients) are not altered by the PCP proxy 🙌. The PCP proxy relays unknown options and Opcodes to the PCP server, because there's no reachability failure risk. Period 💅.

3.4.2. PCP Proxy Co-located with a NAT Function ✨

okay so, by default the proxy MUST relay unknown Opcodes and mandatory-to-process unknown options 🫶 rejecting them sounds safe, but it's kinda a bummer. a PCP client can't use new stuff the PCP server offers if the proxy just says no, even when no IP address and/or port is included in the option/Opcode 😭

BUT here's the plot twist 🎀 messages with an unknown Opcode or mandatory-to-process unknown option can secretly carry a hidden internal address or internal port that never gets translated. so a PCP proxy MUST be configurable to disable relaying unknown Opcodes and mandatory-to-process unknown options. if it's set up to disable that relaying, the PCP proxy MUST behave as follows:

  • a PCP proxy co-located with a NAT MUST reject, via an UNSUPP_OPCODE error response, a received request with an unknown Opcode.
  • a PCP proxy co-located with a NAT MUST reject, via an UNSUPP_OPTION error response, a received request with a mandatory-to-process unknown option.

3.5. Mapping Repair 🦋

ANNOUNCE requests from PCP clients get handled locally, so they MUST NOT be relayed to the provisioned PCP server. they stay home, periodt 💅

when an unsolicited ANNOUNCE response shows up from a PCP server, the PCP proxy renews the mappings and checks for changes against a local cache (if it keeps one 👀). no change means no unsolicited ANNOUNCE goes to PCP clients. but if a change IS detected, the PCP proxy MUST generate unsolicited ANNOUNCE message(s) to the appropriate PCP clients. and if the proxy doesn't keep a local cache for the mappings, unsolicited multicast ANNOUNCE messages get sent to PCP clients instead 🌈

if the external IP address changes, the PCP proxy SHOULD renew the mappings it maintained. and if the PCP server assigns a different external port, the PCP proxy SHOULD follow the PCP mapping repair procedure [RFC6887]. btw this only works if the proxy keeps a full state table 🧚

3.6. Multiple PCP Servers 🍓

a PCP proxy MAY handle multiple PCP servers at the same time 💜 each PCP server gets its own epoch value. the PCP clients aren't aware there are multiple servers at all, iykyk 🙈

following the PCP Server Selection process [RFC7488], if several PCP servers are configured on the PCP proxy, it contacts all of them in parallel ✨

in some contexts (like PCP-controlled Carrier-Grade NATs (CGNs)), the PCP proxy MAY load-balance the PCP clients among the available PCP servers. but it MUST ensure that a given PCP client's requests always get relayed to the same PCP server. no bouncing around, bestie 🔥

the PCP proxy MAY rely on some fields (e.g., Zone-ID [PCP-ZONES]) in the PCP request to redirect it to a given PCP server 🦋

4. Security Considerations 🔐

the PCP proxy MUST follow the security considerations in the PCP specification [RFC6887] for both the client and server side. obviously 💀

Section 3.3 covers the cases where the PCP proxy inserts a THIRD_PARTY option. in those cases, ways to stop a malicious user from creating mappings on behalf of a third party must be employed, as discussed in Section 13.1 of the PCP specification [RFC6887]. the big one: THIRD_PARTY options MUST NOT be enabled unless the network the PCP messages travel on is fully trusted (via physical or cryptographic security, or both). for example, if access control lists (ACLs) are installed on the PCP proxy, the PCP server, and the network between them, so those ACLs only allow communications from a trusted PCP proxy to the PCP server 🚨

a received request carrying an unknown Opcode or option SHOULD be dropped (or, if it's an unknown option that's not mandatory to process, the option SHOULD be removed) when it isn't compatible with the security controls provisioned to the PCP proxy 🙅‍♀️

the device embedding the PCP proxy MAY block PCP requests sent directly to the upstream PCP server(s). this can be enforced with ACLs 🎀

5. References 📚

5.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
           P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
           DOI 10.17487/RFC6887, April 2013,
           <http://www.rfc-editor.org/info/rfc6887>.

5.2. Informative References

[PCP-ANYCAST]
           Kiesel, S., Penno, R., and S. Cheshire, "Port Control
           Protocol (PCP) Anycast Addresses", Work in Progress,
           draft-ietf-pcp-anycast-07, August 2015.

[PCP-DEPLOY]
           Boucadair, M., "Port Control Protocol (PCP) Deployment
           Models", Work in Progress,
           draft-boucadair-pcp-deployment-cases-03, July 2014.

[PCP-ZONES]
           Penno, R., "PCP Support for Multi-Zone Environments", Work
           in Progress, draft-penno-pcp-zones-01, October 2011.

[RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
           and E. Lear, "Address Allocation for Private Internets",
           BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
           <http://www.rfc-editor.org/info/rfc1918>.

[RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
           M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
           Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
           2012, <http://www.rfc-editor.org/info/rfc6598>.

[RFC7291]  Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
           the Port Control Protocol (PCP)", RFC 7291,
           DOI 10.17487/RFC7291, July 2014,
           <http://www.rfc-editor.org/info/rfc7291>.

[RFC7488]  Boucadair, M., Penno, R., Wing, D., Patil, P., and T.
           Reddy, "Port Control Protocol (PCP) Server Selection",
           RFC 7488, DOI 10.17487/RFC7488, March 2015,
           <http://www.rfc-editor.org/info/rfc7488>.

Acknowledgements 🫶

huge thanks to C. Zhou, T. Reddy, and D. Thaler for reviewing and commenting 💖

special shoutout to F. Dupont, who contributed to this document 👑

Authors' Addresses ✉️

Simon Perreault
Jive Communications
Quebec, QC
Canada

Email: sperreault@jive.com


Mohamed Boucadair
France Telecom
Rennes  35000
France

Email: mohamed.boucadair@orange.com


Reinaldo Penno
Cisco
United States

Email: repenno@cisco.com


Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California  95134
United States

Email: dwing@cisco.com


Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, California  95014
United States

Phone: +1 408 974 3207
Email: cheshire@apple.com
📦 where this page comes from