Skip to main content

Port Control Protocol (PCP) Anycast Addresses
draft-ietf-pcp-anycast-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7723.
Authors Sebastian Kiesel , Reinaldo Penno , Stuart Cheshire
Last updated 2015-04-29
Replaces draft-kiesel-pcp-ip-based-srv-disc, draft-cheshire-pcp-anycast
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Waiting for WG Chair Go-Ahead
Doc Shepherd Follow-up Underway, Other - see Comment Log
Document shepherd Dave Thaler
IESG IESG state Became RFC 7723 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to "Dave Thaler" <dthaler@microsoft.com>
draft-ietf-pcp-anycast-05
PCP working group                                              S. Kiesel
Internet-Draft                                   University of Stuttgart
Intended status: Standards Track                                R. Penno
Expires: October 31, 2015                            Cisco Systems, Inc.
                                                             S. Cheshire
                                                                   Apple
                                                          April 29, 2015

             Port Control Protocol (PCP) Anycast Addresses
                       draft-ietf-pcp-anycast-05

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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 31, 2015.

Copyright Notice

   Copyright (c) 2015 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

Kiesel, et al.          Expires October 31, 2015                [Page 1]
Internet-Draft            PCP Anycast Addresses               April 2015

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  PCP Server Discovery based on well-known IP Address  . . . . .  4
     2.1.  PCP Discovery Client behavior  . . . . . . . . . . . . . .  4
     2.2.  PCP Discovery Server behavior  . . . . . . . . . . . . . .  4
   3.  Deployment Considerations  . . . . . . . . . . . . . . . . . .  5
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Registration of IPv4 Special Purpose Address . . . . . . .  6
     4.2.  Registration of IPv6 Special Purpose Address . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
     5.1.  Information Leakage through Anycast  . . . . . . . . . . .  9
     5.2.  Hijacking of PCP Messages sent to Anycast Addresses  . . .  9
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

Kiesel, et al.          Expires October 31, 2015                [Page 2]
Internet-Draft            PCP Anycast Addresses               April 2015

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 Translator IPv6/IPv4 (NAT64), Network Address
   Translator IPv4/IPv4 (NAT44), and IPv6 and IPv4 firewall devices.
   Furthermore, it provides a mechanism to reduce application keep alive
   traffic [I-D.ietf-pcp-optimize-keepalives].  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.  These well-known addresses may be hard-coded into PCP
   clients.  PCP clients usually send PCP requests to these addresses if
   no other PCP server addresses are known or after communication
   attempts to such other addresses have failed.

   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 on 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, without any special
   support from DNS, DHCP, other routers, or anything else, until it
   reaches the PCP-capable device, which 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 for passing the PCP server's address from the
   operating system's DHCP client to the application.  For further
   discussion of deployment considerations see Section 3.

Kiesel, et al.          Expires October 31, 2015                [Page 3]
Internet-Draft            PCP Anycast Addresses               April 2015

2.  PCP Server Discovery based on well-known IP Address

2.1.  PCP Discovery Client behavior

   The PCP anycast addresses, as defined in Sections 4.1 and 4.2, are
   added after the default router list (for IPv4 and IPv6) to the list
   of PCP server(s) (see Section 8.1, step 2. 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, etc.

2.2.  PCP Discovery Server behavior

   A PCP Server can be configured to listen on the anycast address for
   incoming PCP requests.

   PCP responses are sent from that same IANA-assigned address (see Page
   5 of [RFC1546]).

Kiesel, et al.          Expires October 31, 2015                [Page 4]
Internet-Draft            PCP Anycast Addresses               April 2015

3.  Deployment Considerations

   There are known limitations when there is more than one PCP-capable
   NAT/firewall in a cascaded alignment, or in a parallel layout with
   asymmetric routing, or similar scenarios.  Mechanisms to deal with
   those situations, such as state synchronization between PCP servers,
   are beyond the scope of this document.

   For general recommendations regarding operation of anycast services
   see [RFC4786].

Kiesel, et al.          Expires October 31, 2015                [Page 5]
Internet-Draft            PCP Anycast Addresses               April 2015

4.  IANA Considerations

4.1.  Registration of IPv4 Special Purpose Address

   IANA is requested to register a single IPv4 address in the IANA IPv4
   Special Purpose Address Registry [RFC5736].

   [RFC5736] itemizes some information to be recorded for all
   designations:

      1.  The designated address prefix.

      Prefix: TBD by IANA.  Prefix length: /32

      2.  The RFC that called for the IANA address designation.

      This document.

      3.  The date the designation was made.

      TBD.

      4.  The date the use designation is to be terminated (if specified
      as a limited-use designation).

      Unlimited.  No termination date.

      5.  The nature of the purpose of the designated address (e.g.,
      unicast experiment or protocol service anycast).

      protocol service anycast.

      6.  For experimental unicast applications and otherwise as
      appropriate, the registry will also identify the entity and
      related contact details to whom the address designation has been
      made.

      The IETF PCP WG.

      7.  The registry will also note, for each designation, the
      intended routing scope of the address, indicating whether the
      address is intended to be routable only in scoped, local, or
      private contexts, or whether the address prefix is intended to be
      routed globally.

Kiesel, et al.          Expires October 31, 2015                [Page 6]
Internet-Draft            PCP Anycast Addresses               April 2015

      Typically used within a network operator's network domain, but in
      principle globally routable.

      8.  The date in the IANA registry is the date of the IANA action,
      i.e., the day IANA records the allocation.

      TBD.

4.2.  Registration of IPv6 Special Purpose Address

   IANA is requested to register a single IPv6 address in the IANA IPv6
   Special Purpose Address Block [RFC4773].

   [RFC4773] itemizes some information to be recorded for all
   designations:

      1.  The designated address prefix.

      Prefix: TBD by IANA.  Prefix length: /128

      2.  The RFC that called for the IANA address designation.

      This document.

      3.  The date the designation was made.

      TBD.

      4.  The date the use designation is to be terminated (if specified
      as a limited-use designation).

      Unlimited.  No termination date.

      5.  The nature of the purpose of the designated address (e.g.,
      unicast experiment or protocol service anycast).

      protocol service anycast.

      6.  For experimental unicast applications and otherwise as
      appropriate, the registry will also identify the entity and
      related contact details to whom the address designation has been
      made.

      The IETF PCP WG.

Kiesel, et al.          Expires October 31, 2015                [Page 7]
Internet-Draft            PCP Anycast Addresses               April 2015

      7.  The registry will also note, for each designation, the
      intended routing scope of the address, indicating whether the
      address is intended to be routable only in scoped, local, or
      private contexts, or whether the address prefix is intended to be
      routed globally.

      Typically used within a network operator's network domain, but in
      principle globally routable.

      8.  The date in the IANA registry is the date of the IANA action,
      i.e., the day IANA records the allocation.

      TBD.

Kiesel, et al.          Expires October 31, 2015                [Page 8]
Internet-Draft            PCP Anycast Addresses               April 2015

5.  Security Considerations

   In addition to the security considerations in [RFC6887], two
   additional 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 into the public Internet.

5.2.  Hijacking of PCP Messages sent to Anycast Addresses

   The anycast addresses are treated by normal host operating systems
   just 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 to impersonate the default router, e.g., by
   means of ARP spoofing in an Ethernet network.  If such attacks are a
   serious concern in a given scenario, much more severe consequences to
   other protocols have to be feared as well.  Therefore, adequate
   measures have to be taken to prevent spoofing attacks targeted at the
   default router.

   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.  But again, an
   attacker capable of performing these attacks could cause
   significantly more damage to other protocols and therefore adequate
   means should be taken to prevent these attacks.

   In addition to following best current practices in first hop security
   and routing protocol security, PCP authentication
   [I-D.ietf-pcp-authentication] may be useful in some scenarios,
   although it might thwart the goal of fully automatic configuration in
   other scenarios.

Kiesel, et al.          Expires October 31, 2015                [Page 9]
Internet-Draft            PCP Anycast Addresses               April 2015

6.  Acknowledgments

   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, et al.          Expires October 31, 2015               [Page 10]
Internet-Draft            PCP Anycast Addresses               April 2015

7.  References

7.1.  Normative References

   [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
              Anycasting Service", RFC 1546, November 1993.

   [RFC4773]  Huston, G., "Administration of the IANA Special Purpose
              IPv6 Address Block", RFC 4773, December 2006.

   [RFC5736]  Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special
              Purpose Address Registry", RFC 5736, January 2010.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              April 2013.

   [RFC7488]  Boucadair, M., Penno, R., Wing, D., Patil, P., and T.
              Reddy, "Port Control Protocol (PCP) Server Selection",
              RFC 7488, March 2015.

7.2.  Informative References

   [I-D.ietf-pcp-authentication]
              Wasserman, M., Hartman, S., Zhang, D., and T. Reddy, "Port
              Control Protocol (PCP) Authentication Mechanism",
              draft-ietf-pcp-authentication-07 (work in progress),
              December 2014.

   [I-D.ietf-pcp-optimize-keepalives]
              Reddy, T., Patil, P., Isomaki, M., and D. Wing,
              "Optimizing NAT and Firewall Keepalives Using Port Control
              Protocol (PCP)", draft-ietf-pcp-optimize-keepalives-05
              (work in progress), November 2014.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, December 2006.

   [RFC7291]  Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
              the Port Control Protocol (PCP)", RFC 7291, July 2014.

Kiesel, et al.          Expires October 31, 2015               [Page 11]
Internet-Draft            PCP Anycast Addresses               April 2015

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
   USA

   Email: repenno@cisco.com

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

   Phone: +1 408 974 3207
   Email: cheshire@apple.com

Kiesel, et al.          Expires October 31, 2015               [Page 12]