summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7723.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7723.txt')
-rw-r--r--doc/rfc/rfc7723.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc7723.txt b/doc/rfc/rfc7723.txt
new file mode 100644
index 0000000..9f89d14
--- /dev/null
+++ b/doc/rfc/rfc7723.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Kiesel
+Request for Comments: 7723 University of Stuttgart
+Category: Standards Track R. Penno
+ISSN: 2070-1721 Cisco Systems, Inc.
+ January 2016
+
+
+ Port Control Protocol (PCP) Anycast Addresses
+
+Abstract
+
+ The Port Control Protocol (PCP) anycast addresses enable PCP clients
+ to transmit signaling messages to their closest PCP-aware on-path
+ NAT, firewall, or other middlebox without having to learn the IP
+ address of that middlebox via some external channel. This document
+ establishes one well-known IPv4 address and one well-known IPv6
+ address to be used as PCP anycast addresses.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained 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) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+Kiesel & Penno Standards Track [Page 1]
+
+RFC 7723 PCP Anycast Addresses January 2016
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. PCP Server Discovery Based on Well-Known IP Address . . . . . 3
+ 2.1. PCP Discovery Client Behavior . . . . . . . . . . . . . . 3
+ 2.2. PCP Discovery Server Behavior . . . . . . . . . . . . . . 3
+ 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 4
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Registration of an IPv4 Special-Purpose Address . . . . . 5
+ 4.2. Registration of an IPv6 Special-Purpose Address . . . . . 5
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
+ 5.1. Information Leakage through Anycast . . . . . . . . . . . 6
+ 5.2. Hijacking of PCP Messages Sent to Anycast Addresses . . . 6
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 7
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
+
+1. Introduction
+
+ The Port Control Protocol (PCP) [RFC6887] provides a mechanism to
+ control how incoming packets are forwarded by upstream devices such
+ as Network Address and Protocol Translation from IPv6 Clients to IPv4
+ Servers (NAT64), Network Address Translation from IPv4 to IPv4
+ (NAT44), and IPv6 and IPv4 firewall devices. Furthermore, it
+ provides a mechanism to reduce application keepalive traffic
+ [PCP-OPTIMIZE]. The PCP base protocol document [RFC6887] specifies
+ the message formats used, but the address to which a client sends its
+ request is either assumed to be the default router (which is
+ appropriate in a typical single-link residential network) or has to
+ be configured otherwise via some external mechanism, such as a
+ configuration file or a DHCP option [RFC7291].
+
+ This document follows a different approach: it establishes two well-
+ known anycast addresses for the PCP server, one IPv4 address and one
+ IPv6 address. PCP clients usually send PCP requests to these well-
+ known addresses if no other PCP server addresses are known or after
+ communication attempts to such other addresses have failed. The
+ anycast addresses are allocated from pools of special-purpose IP
+ addresses (see Section 4), in accordance with Section 3.4 of
+ [RFC4085]. Yet, a means to disable or override these well-known
+ addresses (e.g., a configuration file option) should be available in
+ implementations.
+
+
+
+
+
+
+
+Kiesel & Penno Standards Track [Page 2]
+
+RFC 7723 PCP Anycast Addresses January 2016
+
+
+ Using an anycast address is particularly useful in larger network
+ topologies. For example, if the PCP-enabled NAT/firewall function is
+ not located on the client's default gateway but further upstream in a
+ Carrier-Grade NAT (CGN), sending PCP requests to the default
+ gateway's IP address will not have the desired effect. When using a
+ configuration file or the DHCP option to learn the PCP server's IP
+ address, this file or the DHCP server configuration must reflect the
+ network topology and the router and CGN configuration. This may be
+ cumbersome to achieve and maintain. If there is more than one
+ upstream CGN and traffic is routed using a dynamic routing protocol
+ such as OSPF, this approach may not be feasible at all, as it cannot
+ provide timely information regarding which CGN to interact with. In
+ contrast, when using the PCP anycast address, the PCP request will
+ travel through the network like any other packet (i.e., without any
+ special support from DNS, DHCP, other routers, or anything else)
+ until it reaches the PCP-capable device that receives it, handles it,
+ and sends back a reply. A further advantage of using an anycast
+ address instead of a DHCP option is that the anycast address can be
+ hard-coded into the application. There is no need for an application
+ programming interface that passes the PCP server's address from the
+ operating system's DHCP client to the application. For further
+ discussion of deployment considerations, 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) (see step 2 in Section 8.1 of
+ [RFC6887]). This list is processed as specified in [RFC7488].
+
+ Note: If, in some specific scenario, it was desirable to use only the
+ anycast address (and not the default router), this could be achieved
+ 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 receives a PCP request
+ destined for an anycast address it supports, it sends the
+ corresponding PCP replies using that same anycast address as the
+ source address (see the "How UDP and TCP Use Anycasting" section of
+ [RFC1546] for further discussion).
+
+
+
+
+
+
+Kiesel & Penno Standards Track [Page 3]
+
+RFC 7723 PCP Anycast Addresses January 2016
+
+
+3. Deployment Considerations
+
+ For general recommendations regarding operation of anycast services,
+ see [RFC4786]. Architectural considerations of IP anycast are
+ discussed in [RFC7094].
+
+ In some deployment scenarios, using PCP anycasting may have certain
+ limitations that can be overcome by using additional mechanisms or by
+ using other PCP server discovery methods instead, such as DHCP
+ [RFC7291] or a configuration file.
+
+ One important example is a network topology in which a network is
+ connected to one or more upstream network(s) via several parallel
+ firewalls, each individually controlled by its own PCP server. Even
+ if all of these PCP servers are configured for anycasting, only one
+ will receive the messages sent by a given client, depending on the
+ state of the routing tables.
+
+ As long as routing is always symmetric, i.e., all upstream and
+ downstream packets from/to that client are routed through this very
+ same firewall, communication will be possible as expected. If there
+ is a routing change, a PCP client using PCP anycasting might start
+ interacting with a different PCP server. From the PCP client's point
+ of view, this would be the same as a PCP server reboot and the client
+ could detect it by examining the Epoch field during the next PCP
+ response or ANNOUNCE message. The client would re-establish the
+ firewall rules and packet flows could resume.
+
+ If, however, routing is asymmetric, upstream packets from a client
+ traverse a different firewall than the downstream packets to that
+ client. Establishing policy rules in only one of these two firewalls
+ by means of PCP anycasting will not have the desired result of
+ allowing bidirectional connectivity. One solution approach to
+ overcome this problem is an implementation-specific mechanism to
+ synchronize state between all firewalls at the border of a network,
+ i.e., a PEER message sent to any of these PCP servers would establish
+ rules in all firewalls. Another approach would be to use a different
+ discovery mechanism (e.g., DHCP or a configuration file) that allows
+ a PCP client to acquire a list of all PCP servers controlling the
+ parallel firewalls and configure each of them individually.
+
+ PCP anycast as such allows a PCP client to communicate only with its
+ closest upstream PCP server. However, it may be used in conjunction
+ with the PCP proxy function [RFC7648], in order to support scenarios
+ with cascaded PCP-enabled NATs or firewalls.
+
+
+
+
+
+
+Kiesel & Penno Standards Track [Page 4]
+
+RFC 7723 PCP Anycast Addresses January 2016
+
+
+4. IANA Considerations
+
+4.1. Registration of an IPv4 Special-Purpose Address
+
+ IANA has 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 |
+ +----------------------+-------------------------------------------+
+
+4.2. Registration of an IPv6 Special-Purpose Address
+
+ IANA has assigned a single IPv6 address from the 2001:0000::/23
+ prefix and registered it in the "IANA IPv6 Special-Purpose Address
+ Registry" [RFC6890].
+
+ +----------------------+-------------------------------------------+
+ | 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 |
+ +----------------------+-------------------------------------------+
+
+
+
+
+
+
+
+
+Kiesel & Penno Standards Track [Page 5]
+
+RFC 7723 PCP Anycast Addresses January 2016
+
+
+5. Security Considerations
+
+ In addition to the security considerations in [RFC6887], [RFC4786],
+ and [RFC7094], two further security issues are considered here.
+
+5.1. Information Leakage through Anycast
+
+ In a network without any border gateway, NAT, or firewall that is
+ aware of the PCP anycast address, outgoing PCP requests could leak
+ out onto the external Internet, possibly revealing information about
+ internal devices.
+
+ Using an IANA-assigned, well-known PCP anycast address enables border
+ gateways to block such outgoing packets. In the default-free zone,
+ routers should be configured to drop such packets. Such
+ configuration can occur naturally via BGP messages advertising that
+ no route exists to said address.
+
+ Sensitive clients that do not wish to leak information about their
+ presence can set an IP TTL on their PCP requests that limits how far
+ they can travel towards the public Internet. However, methods for
+ choosing an appropriate TTL value, e.g., based on the assumed radius
+ of the trusted network domain, is beyond the scope of this document.
+
+ Before sending PCP requests with possibly privacy-sensitive
+ parameters (e.g., IP addresses and port numbers) to the PCP anycast
+ addresses, PCP clients can send an ANNOUNCE request (without
+ parameters; see Section 14.1 of [RFC6887]) in order to probe whether
+ a PCP server consumes and processes PCP requests sent to that anycast
+ address.
+
+5.2. Hijacking of PCP Messages Sent to Anycast Addresses
+
+ The anycast addresses are treated by normal host operating systems as
+ normal unicast addresses, i.e., packets destined for an anycast
+ address are sent to the default router for processing and forwarding.
+ Hijacking such packets in the first network segment would effectively
+ require the attacker to impersonate the default router, e.g., by
+ means of ARP spoofing in an Ethernet network. Once an anycast
+ message is forwarded closer to the core network, routing will likely
+ become subject to dynamic routing protocols such as OSPF or BGP.
+ Anycast messages could be hijacked by announcing counterfeited
+ messages in these routing protocols. When analyzing the risk and
+ possible consequences of such attacks in a given network scenario,
+ the probable impacts on PCP signaling need to be put into proportion
+ with probable impacts on other protocols such as the actual
+ application protocols.
+
+
+
+
+Kiesel & Penno Standards Track [Page 6]
+
+RFC 7723 PCP Anycast Addresses January 2016
+
+
+ In addition to following best current practices in first-hop security
+ and routing-protocol security, PCP authentication [RFC7652] may be
+ useful in some scenarios. However, the effort needed for a proper
+ setup of this authentication mechanism (e.g., installing the right
+ shared secrets or cryptographic keys on all involved systems) may
+ thwart the goal of fully automatic configuration by using PCP
+ anycast. Therefore, this approach may be less suitable for scenarios
+ with high trust between the operator of the PCP-controlled middlebox
+ and all users (e.g., a residential gateway used only by family
+ members) or in scenarios in which there is rather limited trust that
+ the middlebox will behave correctly (e.g., the Wi-Fi in an airport
+ lounge). In contrast, this scheme may be highly useful in scenarios
+ with many users and a trusted network operator, such as a large
+ corporate network or a university campus network, which uses several
+ parallel NATs or firewalls to connect to the Internet. Therefore, 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>.
+
+
+
+Kiesel & Penno Standards Track [Page 7]
+
+RFC 7723 PCP Anycast Addresses January 2016
+
+
+ [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 would like to thank the members of the PCP working group
+ for contributions and feedback, in particular, Mohamed Boucadair,
+ Charles Eckel, Simon Perreault, Tirumaleswar Reddy, Markus Stenberg,
+ Dave Thaler, and Dan Wing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kiesel & Penno Standards Track [Page 8]
+
+RFC 7723 PCP Anycast Addresses January 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kiesel & Penno Standards Track [Page 9]
+