RFC 7723
Port Control Protocol (PCP) Anycast Addresses
RFC 7723: Port Control Protocol (PCP) Anycast Addresses 🎀
Okay bestie, gather round because this one is SO good. RFC 7723 is a Standards Track document from the IETF, published in January 2016 ✨. The authors are S. Kiesel from the University of Stuttgart and R. Penno from Cisco Systems, Inc. 💅 It's not obsoleting or updating anything, so it's a fresh start, no drama 🌸
The big idea: PCP clients can find their closest PCP-aware middlebox (like a NAT or firewall) by using a well-known anycast address, so they don't need to know its IP address from some external source. 🦋
Abstract
okay so the Port Control Protocol (PCP) anycast addresses let PCP clients send signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox 🧚 without needing to learn that middlebox's IP address from some external channel. This document sets up one well-known IPv4 address and one well-known IPv6 address to serve as PCP anycast addresses 💖
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 👑 For more on Internet Standards, check out Section 2 of RFC 5741 🫶
you can find the current status, any errata, and how to give feedback at http://www.rfc-editor.org/info/rfc7723 🌈
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions 📜 Code components pulled out of this document MUST include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🎀
Table of Contents
1. Introduction 🌸 2. PCP Server Discovery Based on Well-Known IP Address 🌸 3. Deployment Considerations 🌸 4. IANA Considerations 🌸 5. Security Considerations 🌸 6. References 🌸 Acknowledgements 🌸 Authors' Addresses 🌸
1. Introduction ✨
okay so the Port Control Protocol (PCP) [RFC6887] gives you a way to control how incoming packets get forwarded by upstream devices. That includes Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), Network Address Translation from IPv4 to IPv4 (NAT44), and IPv6 and IPv4 firewalls 🔥 It also helps cut down application keepalive traffic [PCP-OPTIMIZE]. The PCP base protocol document [RFC6887] defines the message formats, but the address a client sends its request to is either assumed to be the default router (fine for a typical single-link home network) or has to be configured some other way, like through a configuration file or a DHCP option [RFC7291] 🧚
this document takes a different approach: it sets up two well-known anycast addresses for the PCP server, one IPv4 and one IPv6 🦋 PCP clients usually send requests to these well-known addresses when no other PCP server addresses are known, or after attempts to reach those other addresses have failed. The anycast addresses come from pools of special-purpose IP addresses (see Section 4), following Section 3.4 of [RFC4085] 💅 Still, there SHOULD be a way to disable or override these well-known addresses in implementations, like a configuration file option 🙈
using an anycast address is especially useful in bigger network topologies 🌈 Say the PCP-enabled NAT or firewall isn't on the client's default gateway, but further upstream in a Carrier-Grade NAT (CGN). Then sending PCP requests to the default gateway's IP address won't do what you want 😭 If you use a configuration file or the DHCP option instead, that file or the DHCP server configuration MUST reflect the network topology and the router and CGN configuration, which can be a real pain to set up and maintain 💀 If there's more than one upstream CGN and traffic is routed with a dynamic routing protocol like OSPF, that approach may not work at all, because it can't give timely info about which CGN to talk to 🙅♀️ With the PCP anycast address, though, the request just travels through the network like any other packet (no special help from DNS, DHCP, other routers, or anything else) until it reaches the PCP-capable device that gets it, handles it, and sends a reply back 🦋✨ Another perk of anycast over a DHCP option is that the anycast address can be hard-coded into the application 🎀 That means there's no need for an application programming interface that passes the PCP server's address from the operating system's DHCP client to the app 👑 For more deployment talk, see Section 3 💖
2. PCP Server Discovery Based on Well-Known IP Address 🧚
2.1. PCP Discovery Client Behavior 💅
PCP clients can add the PCP anycast addresses, which are defined in Sections 4.1 and 4.2, after the default router list (for IPv4 and IPv6) to the list of PCP server(s). That's step 2 in Section 8.1 of [RFC6887] 🌸 This list then gets processed as [RFC7488] specifies 🫶
Note: If, in some specific scenario, you really wanted to use only the anycast address and skip the default router, you could do that by putting the anycast address into the configuration file or DHCP option. 🙈
2.2. PCP Discovery Server Behavior 🌈
PCP servers can be configured to listen on the anycast addresses for incoming PCP requests ✨ When a PCP server gets a PCP request aimed at an anycast address it supports, it sends the matching PCP replies back using that same anycast address as the source address 🦋 (For more on this, check the "How UDP and TCP Use Anycasting" section of [RFC1546] 💜)
3. Deployment Considerations 🌸
for general recommendations on running anycast services, see [RFC4786] 📜 The architectural side of IP anycast is covered in [RFC7094] 🧚
in some deployments, PCP anycasting might have limitations 🙅♀️ You can work around them by adding other mechanisms, or by using a different PCP server discovery method, like DHCP [RFC7291] or a configuration file 💅
one important example is a network connected to one or more upstream networks through several parallel firewalls, each one controlled by its own PCP server 🔥 Even if all of those PCP servers are set up for anycasting, only one will receive the messages from a given client, depending on the state of the routing tables 😭
as long as routing is always symmetric, meaning all upstream and downstream packets to and from that client go through the very same firewall, everything works as expected 🫶 If routing changes, a PCP client using anycasting might start talking to a different PCP server 🦋 From the client's point of view, that's the same as a PCP server reboot, and the client can spot it by checking the Epoch field in the next PCP response or ANNOUNCE message 🌈 Then the client re-establishes the firewall rules and packet flows can resume ✨
if routing is asymmetric, though, upstream packets from a client go through a different firewall than the downstream packets to that client 💀 Setting up policy rules in only one of those two firewalls through PCP anycasting won't allow bidirectional connectivity, sadly 😭 One way around this is an implementation-specific mechanism that syncs state between all firewalls at the network border, so a PEER message sent to any one of them sets up rules in all of them 💖 Another approach is a different discovery mechanism (like DHCP or a configuration file) that lets a PCP client get a list of all PCP servers controlling the parallel firewalls and configure each one individually 🎀
PCP anycast by itself only lets a PCP client talk to its closest upstream PCP server 🧚 But it can be combined with the PCP proxy function [RFC7648] to support scenarios with cascaded PCP-enabled NATs or firewalls 👑
4. IANA Considerations 🦋
4.1. Registration of an IPv4 Special-Purpose Address 💅
IANA assigned a single IPv4 address from the 192.0.0.0/24 prefix and registered it in the "IANA IPv4 Special-Purpose Address Registry" [RFC6890] 🌸
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 192.0.0.9/32 |
| Name | Port Control Protocol Anycast |
| RFC | RFC 7723 (this document) |
| Allocation Date | October 2015 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+Part 1 ends here, bestie. Part 2 is coming with the IPv6 registration, Security Considerations, References, Acknowledgements, and Authors' Addresses 💜🎀
4.2. Registration of an IPv6 Special-Purpose Address
okay so IANA handed out one IPv6 address from the 2001:0000::/23 prefix and logged it in the "IANA IPv6 Special-Purpose Address Registry" [RFC6890] 💖✨ the whole entry looks like this:
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 2001:1::1/128 |
| Name | Port Control Protocol Anycast |
| RFC | RFC 7723 (this document) |
| Allocation Date | October 2015 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+5. Security Considerations 🔐💀
bestie, this part is serious, so read it with your whole chest 😭 okay so the security stuff in [RFC6887], [RFC4786], and [RFC7094] still applies, and on top of that there are two more issues we need to talk about 🫶
5.1. Information Leakage through Anycast 🙈
picture a network with no border gateway, NAT, or firewall that knows about the PCP anycast address. In that network, outgoing PCP requests could slip out onto the external Internet and reveal info about internal devices. not cute 💀
the fix is that the IANA-assigned, well-known PCP anycast address lets border gateways block those packets on the way out 🛡️ in the default-free zone, routers should be configured to drop them too. and honestly this can happen naturally, because BGP messages can advertise that no route exists to that address 🌸
sensitive clients that don't want to leak that they're even there can set an IP TTL on their PCP requests so the packets can only travel so far toward the public Internet 🦋 how to pick a good TTL value, like based on the assumed radius of the trusted network domain, is beyond the scope of this document, so that one's on you, bestie 💅
one more move: before sending PCP requests with possibly privacy-sensitive parameters (like IP addresses and port numbers) to the PCP anycast addresses, clients can send an ANNOUNCE request (no parameters; see Section 14.1 of [RFC6887]) to check whether a PCP server actually consumes and processes requests sent to that anycast address 👀✨
5.2. Hijacking of PCP Messages Sent to Anycast Addresses 🚨
okay this one is giving main character drama. normal host operating systems treat anycast addresses as normal unicast addresses, so packets for an anycast address get sent to the default router for processing and forwarding 🧚 hijacking them in the first network segment would basically mean the attacker has to impersonate the default router, for example with ARP spoofing on an Ethernet network 🙃
once an anycast message moves closer to the core network, routing will probably be handled by dynamic routing protocols like OSPF or BGP 🌈 and then anycast messages could get hijacked by announcing counterfeit messages in those routing protocols. when you're analyzing the risk and possible consequences of these attacks in a given network, you need to weigh the impacts on PCP signaling against the impacts on other protocols like the actual application protocols ⚖️
so in addition to following best current practices in first-hop security and routing-protocol security, PCP authentication [RFC7652] may be useful in some scenarios 🔑 but the effort to set it up properly (like installing the right shared secrets or cryptographic keys on every system involved) might defeat the whole point of fully automatic configuration with PCP anycast 😩 so this approach may be less suitable where the operator of the PCP-controlled middlebox and all users have high trust (think a residential gateway used only by family members) 🏠 or where there's pretty limited trust that the middlebox will behave correctly (think the Wi-Fi in an airport lounge) ✈️
on the flip side, this scheme may be super useful with lots of users and a trusted network operator, like a large corporate network or a university campus network that uses several parallel NATs or firewalls to reach the Internet 🎓 so yeah, a thorough analysis of the benefits and costs of using PCP authentication in a given network scenario is recommended 🫶💜
6. References 📚
6.1. Normative References
[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>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.
[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>.6.2. Informative References
[PCP-OPTIMIZE]
Reddy, T., Patil, P., Isomaki, M., and D. Wing,
"Optimizing NAT and Firewall Keepalives Using Port Control
Protocol (PCP)", Work in Progress,
draft-ietf-pcp-optimize-keepalives-06, May 2015.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, DOI 10.17487/RFC1546,
November 1993, <http://www.rfc-editor.org/info/rfc1546>.
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet
Addresses Considered Harmful", BCP 105, RFC 4085,
DOI 10.17487/RFC4085, June 2005,
<http://www.rfc-editor.org/info/rfc4085>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014,
<http://www.rfc-editor.org/info/rfc7094>.
[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>.
[RFC7648] Perreault, S., Boucadair, M., Penno, R., Wing, D., and S.
Cheshire, "Port Control Protocol (PCP) Proxy Function",
RFC 7648, DOI 10.17487/RFC7648, September 2015,
<http://www.rfc-editor.org/info/rfc7648>.
[RFC7652] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port
Control Protocol (PCP) Authentication Mechanism",
RFC 7652, DOI 10.17487/RFC7652, September 2015,
<http://www.rfc-editor.org/info/rfc7652>.Acknowledgements 🫶🌸
the authors want to thank the members of the PCP working group for their contributions and feedback 💜 special shoutouts to Mohamed Boucadair, Charles Eckel, Simon Perreault, Tirumaleswar Reddy, Markus Stenberg, Dave Thaler, and Dan Wing 👑✨
Authors' Addresses 🦋
Sebastian Kiesel
University of Stuttgart Information Center
Networks and Communication Systems Department
Allmandring 30
Stuttgart 70550
Germany
Email: ietf-pcp@skiesel.de
Reinaldo Penno
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
United States
Email: repenno@cisco.com📦 where this page comes from
- ietf: rfc7723 2016-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms