tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6887

 
 
 

Port Control Protocol (PCP)

Part 4 of 4, p. 77 to 88
Prev RFC Part

 


prevText      Top      Up      ToC       Page 77 
17.  Deployment Considerations

17.1.  Ingress Filtering

   As with implicit dynamic mappings created by outgoing TCP SYN
   packets, explicit dynamic mappings created via PCP use the source IP
   address of the packet as the internal address for the mappings.
   Therefore, ingress filtering [RFC2827] SHOULD be used on the path
   between the internal host and the PCP server to prevent the injection
   of spoofed packets onto that path.

17.2.  Mapping Quota

   On PCP-controlled devices that create state when a mapping is created
   (e.g., NAT), the PCP server SHOULD maintain per-host and/or per-
   subscriber quotas for mappings.  It is implementation specific
   whether the PCP server uses a separate quotas for implicit, explicit,
   and static mappings, a combined quota for all of them, or some other
   policy.

Top      Up      ToC       Page 78 
18.  Security Considerations

   The goal of the PCP protocol is to improve the ability of end nodes
   to control their associated NAT state, and to improve the efficiency
   and error handling of NAT mappings when compared to existing implicit
   mapping mechanisms in NAT boxes and stateful firewalls.  It is the
   security goal of the PCP protocol to limit any new denial-of-service
   opportunities, and to avoid introducing new attacks that can result
   in unauthorized changes to mapping state.  One of the most serious
   consequences of unauthorized changes in mapping state is traffic
   theft.  All mappings that could be created by a specific host using
   implicit mapping mechanisms are inherently considered to be
   authorized.  Confidentiality of mappings is not a requirement, even
   in cases where the PCP messages may transit paths that would not be
   traveled by the mapped traffic.

18.1.  Simple Threat Model

   PCP servers are secure against off-path attackers who cannot spoof a
   packet that the PCP server will view as a packet received from the
   internal network.  PCP clients are secure against off-path attackers
   who can spoof the PCP server's IP address.

   Defending against attackers who can modify or drop packets between
   the internal network and the PCP server, or who can inject spoofed
   packets that appear to come from the internal network is out of
   scope.  Such an attacker can redirect traffic to a host of their
   choosing.

   A PCP server is secure under this threat model if the PCP server is
   constrained so that it does not configure any explicit mapping that
   it would not configure implicitly.  In most cases, this means that
   PCP servers running on NAT boxes or stateful firewalls that support
   the PEER and MAP Opcodes can be secure under this threat model if
   (1) all of their hosts are within a single administrative domain (or
   if the internal hosts can be securely partitioned into separate
   administrative domains, as in the DS-Lite B4 case), (2) explicit
   mappings are created with the same lifetime as implicit mappings, and
   (3) the THIRD_PARTY option is not supported.  PCP servers can also
   securely support the MAP Opcode under this threat model if the
   security policy on the device running the PCP server would permit
   endpoint-independent filtering of implicit mappings.

   PCP servers that comply with the Simple Threat Model and do not
   implement a PCP security mechanism described in Section 18.2 MUST
   enforce the constraints described in the paragraph above.

Top      Up      ToC       Page 79 
18.1.1.  Attacks Considered

   o  If you allow multiple administrative domains to send PCP requests
      to a single PCP server that does not enforce a boundary between
      the domains, it is possible for a node in one domain to perform a
      denial-of-service attack on other domains or to capture traffic
      that is intended for a node in another domain.

   o  If explicit mappings have longer lifetimes than implicit mappings,
      it makes it easier to perpetrate a denial-of-service attack than
      it would be if the PCP server was not present.

   o  If the PCP server supports deleting or reducing the lifetime of
      existing mappings, this allows an attacking node to steal an
      existing mapping and receive traffic that was intended for another
      node.

   o  If the THIRD_PARTY option is supported, this also allows an
      attacker to open a window for an external node to attack an
      internal node, allows an attacker to steal traffic that was
      intended for another node, or may facilitate a denial-of-service
      attack.  One example of how the THIRD_PARTY option could grant an
      attacker more capability than a spoofed implicit mapping is that
      the PCP server (especially if it is running in a service
      provider's network) may not be aware of internal filtering that
      would prevent spoofing an equivalent implicit mapping, such as
      filtering between a guest and corporate network.

   o  If the MAP Opcode is supported by the PCP server in cases where
      the security policy would not support endpoint-independent
      filtering of implicit mappings, then the MAP Opcode changes the
      security properties of the device running the PCP server by
      allowing explicit mappings that violate the security policy.

18.1.2.  Deployment Examples Supporting the Simple Threat Model

   This section offers two examples of how the Simple Threat Model can
   be supported in real-world deployment scenarios.

18.1.2.1.  Residential Gateway Deployment

   Parity with many currently deployed residential gateways can be
   achieved using a PCP server that is constrained as described in
   Section 18.1 above.

Top      Up      ToC       Page 80 
18.2.  Advanced Threat Model

   In the Advanced Threat Model, the PCP protocol ensures that attackers
   (on- or off-path) cannot create unauthorized mappings or make
   unauthorized changes to existing mappings.  The protocol must also
   limit the opportunity for on- or off-path attackers to perpetrate
   denial-of-service attacks.

   The Advanced Threat Model security model will be needed in the
   following cases:

   o  Security infrastructure equipment, such as corporate firewalls,
      that does not create implicit mappings.

   o  Equipment (such as CGNs or service provider firewalls) that serves
      multiple administrative domains and does not have a mechanism to
      securely partition traffic from those domains.

   o  Any implementation that wants to be more permissive in authorizing
      explicit mappings than it is in authorizing implicit mappings.

   o  Implementations that wish to support any deployment scenario that
      does not meet the constraints described in Section 18.1.

   To protect against attacks under this threat model, a PCP security
   mechanism that provides an authenticated, integrity-protected
   signaling channel would need to be specified.

   PCP servers that implement a PCP security mechanism MAY accept
   unauthenticated requests.  In their default configuration, PCP
   servers implementing the PCP security mechanism MUST still enforce
   the constraints described in Section 18.1 when processing
   unauthenticated requests.

18.3.  Residual Threats

   This section describes some threats that are not addressed in either
   of the above threat models and recommends appropriate mitigation
   strategies.

18.3.1.  Denial of Service

   Because of the state created in a NAT or firewall, a per-host and/or
   per-subscriber quota will likely exist for both implicit dynamic
   mappings and explicit dynamic mappings.  A host might make an
   excessive number of implicit or explicit dynamic mappings, consuming

Top      Up      ToC       Page 81 
   an inordinate number of ports, causing a denial of service to other
   hosts.  Thus, Section 17.2 recommends that hosts be limited to a
   reasonable number of explicit dynamic mappings.

   An attacker, on the path between the PCP client and PCP server, can
   drop PCP requests, drop PCP responses, or spoof a PCP error, all of
   which will effectively deny service.  Through such actions, the PCP
   client might not be aware the PCP server might have actually
   processed the PCP request.  An attacker sending a NO_RESOURCES error
   can cause the PCP client to not send messages to that server for a
   while.  There is no mitigation to this on-path attacker.

18.3.2.  Ingress Filtering

   It is important to prevent a host from fraudulently creating,
   deleting, or refreshing a mapping (or filtering) for another host,
   because this can expose the other host to unwanted traffic, prevent
   it from receiving wanted traffic, or consume the other host's mapping
   quota.  Both implicit and explicit dynamic mappings are created based
   on the source IP address in the packet, and hence depend on ingress
   filtering to guard against spoof source IP addresses.

18.3.3.  Mapping Theft

   In the time between when a PCP server loses state and the PCP client
   notices the lower-than-expected Epoch Time value, it is possible that
   the PCP client's mapping will be acquired by another host (via an
   explicit dynamic mapping or implicit dynamic mapping).  This means
   incoming traffic will be sent to a different host ("theft").  Rapid
   recovery reduces this interval, but does not completely eliminate
   this threat.  The PCP client can reduce this interval by using a
   relatively short lifetime; however, this increases the amount of PCP
   chatter.  This threat is reduced by using persistent storage of
   explicit dynamic mappings in the PCP server (so it does not lose
   explicit dynamic mapping state), or by ensuring that the previous
   external IP address, protocol, and port cannot be used by another
   host (e.g., by using a different IP address pool).

18.3.4.  Attacks against Server Discovery

   This document does not specify server discovery, beyond contacting
   the default gateway.

Top      Up      ToC       Page 82 
19.  IANA Considerations

   IANA has performed the following actions.

19.1.  Port Number

   PCP uses ports 5350 and 5351, previously assigned by IANA to NAT-PMP
   [RFC6886].  IANA has reassigned those ports to PCP.

19.2.  Opcodes

   IANA has created a new protocol registry for PCP Opcodes, numbered
   0-127, initially populated with the values:

           Value            Opcode
           -----            -------------------------
           0                ANNOUNCE
           1                MAP
           2                PEER
           3-31             Standards Action [RFC5226]
           32-63            Specification Required [RFC5226]
           96-126           Reserved for Private Use [RFC5226]
           127              Reserved, Standards Action [RFC5226]

   The value 127 is Reserved and may be assigned via Standards Action
   [RFC5226].  The values in the range 3-31 can be assigned via
   Standards Action [RFC5226], 32-63 via Specification Required
   [RFC5226], and the range 96-126 is for Private Use [RFC5226].

19.3.  Result Codes

   IANA has created a new registry for PCP result codes, numbered 0-255,
   initially populated with the result codes from Section 7.4.  The
   value 255 is Reserved and may be assigned via Standards Action
   [RFC5226].

   The values in the range 14-127 can be assigned via Standards Action
   [RFC5226], 128-191 via Specification Required [RFC5226], and the
   range 191-254 is for Private Use [RFC5226].

19.4.  Options

   IANA has created a new registry for PCP options, numbered 0-255, each
   with an associated mnemonic.  The values 0-127 are mandatory to
   process, and 128-255 are optional to process.  The initial registry
   contains the options described in Section 13.  The option values 0,
   127, and 255 are Reserved and may be assigned via Standards Action
   [RFC5226].

Top      Up      ToC       Page 83 
   Additional PCP option codes in the ranges 4-63 and 128-191 can be
   created via Standards Action [RFC5226], the ranges 64-95 and 192-223
   are for Specification Required [RFC5226], and the ranges 96-126 and
   224-254 are for Private Use [RFC5226].

   Documents describing an option should describe the processing for
   both the PCP client and server, and the information below:

      Option Name: <mnemonic>
      Number: <value>
      Purpose: <textual description>
      Valid for Opcodes: <list of Opcodes>
      Length: <rules for length>
      May appear in: <requests/responses/both>
      Maximum occurrences: <count>

20.  Acknowledgments

   Thanks to Xiaohong Deng, Alain Durand, Christian Jacquenet, Jacni
   Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU), Felipe Miranda
   Costa, James Woodyatt, Dave Thaler, Masataka Ohta, Vijay K. Gurbani,
   Loa Andersson, Richard Barnes, Russ Housley, Adrian Farrel, Pete
   Resnick, Pasi Sarolahti, Robert Sparks, Wesley Eddy, Dan Harkins,
   Peter Saint-Andre, Stephen Farrell, Ralph Droms, Felipe Miranda
   Costa, Amit Jain, and Wim Henderickx for their comments and review.

   Thanks to Simon Perreault for highlighting the interaction of dynamic
   connections with PCP-created mappings and for many other review
   comments.

   Thanks to Francis Dupont for his several thorough reviews of the
   specification, which improved the protocol significantly.

   Thanks to T. S. Ranganathan for the state diagram.

   Thanks to Peter Lothberg for clock skew information, which guided the
   choice of tolerance levels for deciding when an Epoch time should be
   considered to be anomalous.

   Thanks to Margaret Wasserman and Sam Hartman for writing the Security
   Considerations section.

   Thanks to authors of DHCPv6 for retransmission text.

Top      Up      ToC       Page 84 
21.  References

21.1.  Normative References

   [RFC0768]        Postel, J., "User Datagram Protocol", STD 6,
                    RFC 768, August 1980.

   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2827]        Ferguson, P. and D. Senie, "Network Ingress
                    Filtering: Defeating Denial of Service Attacks which
                    employ IP Source Address Spoofing", BCP 38,
                    RFC 2827, May 2000.

   [RFC4086]        Eastlake, D., Schiller, J., and S. Crocker,
                    "Randomness Requirements for Security", BCP 106,
                    RFC 4086, June 2005.

   [RFC4193]        Hinden, R. and B. Haberman, "Unique Local IPv6
                    Unicast Addresses", RFC 4193, October 2005.

   [RFC4291]        Hinden, R. and S. Deering, "IP Version 6 Addressing
                    Architecture", RFC 4291, February 2006.

   [RFC5226]        Narten, T. and H. Alvestrand, "Guidelines for
                    Writing an IANA Considerations Section in RFCs",
                    BCP 26, RFC 5226, May 2008.

   [RFC6056]        Larsen, M. and F. Gont, "Recommendations for
                    Transport-Protocol Port Randomization", BCP 156,
                    RFC 6056, January 2011.

   [proto_numbers]  IANA, "Protocol Numbers", 2011,
                    <http://www.iana.org/assignments/protocol-numbers>.

21.2.  Informative References

   [IGDv1]          UPnP Gateway Committee, "WANIPConnection:1",
                    November 2001, <http://upnp.org/specs/gw/
                    UPnP-gw-WANIPConnection-v1-Service.pdf>.

   [L2NAT]          Miles, D. and M. Townsley, "Layer2-Aware NAT", Work
                    in Progress, March 2009.

   [PCP-FAIL]       Boucadair, M., Dupont, F., and R. Penno, "Port
                    Control Protocol (PCP) Failure Scenarios", Work
                    in Progress, August 2012.

Top      Up      ToC       Page 85 
   [PNP-IGD-PCP]    Boucadair, M., Penno, R., and D. Wing, "Universal
                    Plug and Play (UPnP) Internet Gateway Device (IGD)-
                    Port Control Protocol (PCP) Interworking Function",
                    Work in Progress, December 2012.

   [RFC0793]        Postel, J., "Transmission Control Protocol", STD 7,
                    RFC 793, September 1981.

   [RFC1918]        Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
                    G., and E. Lear, "Address Allocation for Private
                    Internets", BCP 5, RFC 1918, February 1996.

   [RFC2136]        Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
                    "Dynamic Updates in the Domain Name System (DNS
                    UPDATE)", RFC 2136, April 1997.

   [RFC3007]        Wellington, B., "Secure Domain Name System (DNS)
                    Dynamic Update", RFC 3007, November 2000.

   [RFC3022]        Srisuresh, P. and K. Egevang, "Traditional IP
                    Network Address Translator (Traditional NAT)",
                    RFC 3022, January 2001.

   [RFC3581]        Rosenberg, J. and H. Schulzrinne, "An Extension to
                    the Session Initiation Protocol (SIP) for Symmetric
                    Response Routing", RFC 3581, August 2003.

   [RFC3587]        Hinden, R., Deering, S., and E. Nordmark, "IPv6
                    Global Unicast Address Format", RFC 3587,
                    August 2003.

   [RFC4303]        Kent, S., "IP Encapsulating Security Payload (ESP)",
                    RFC 4303, December 2005.

   [RFC4340]        Kohler, E., Handley, M., and S. Floyd, "Datagram
                    Congestion Control Protocol (DCCP)", RFC 4340,
                    March 2006.

   [RFC4787]        Audet, F. and C. Jennings, "Network Address
                    Translation (NAT) Behavioral Requirements for
                    Unicast UDP", BCP 127, RFC 4787, January 2007.

   [RFC4941]        Narten, T., Draves, R., and S. Krishnan, "Privacy
                    Extensions for Stateless Address Autoconfiguration
                    in IPv6", RFC 4941, September 2007.

   [RFC4960]        Stewart, R., "Stream Control Transmission Protocol",
                    RFC 4960, September 2007.

Top      Up      ToC       Page 86 
   [RFC4961]        Wing, D., "Symmetric RTP / RTP Control Protocol
                    (RTCP)", BCP 131, RFC 4961, July 2007.

   [RFC5382]        Guha, S., Biswas, K., Ford, B., Sivakumar, S., and
                    P. Srisuresh, "NAT Behavioral Requirements for TCP",
                    BCP 142, RFC 5382, October 2008.

   [RFC6092]        Woodyatt, J., "Recommended Simple Security
                    Capabilities in Customer Premises Equipment (CPE)
                    for Providing Residential IPv6 Internet Service",
                    RFC 6092, January 2011.

   [RFC6145]        Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
                    Algorithm", RFC 6145, April 2011.

   [RFC6146]        Bagnulo, M., Matthews, P., and I. van Beijnum,
                    "Stateful NAT64: Network Address and Protocol
                    Translation from IPv6 Clients to IPv4 Servers",
                    RFC 6146, April 2011.

   [RFC6296]        Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network
                    Prefix Translation", RFC 6296, June 2011.

   [RFC6333]        Durand, A., Droms, R., Woodyatt, J., and Y. Lee,
                    "Dual-Stack Lite Broadband Deployments Following
                    IPv4 Exhaustion", RFC 6333, August 2011.

   [RFC6619]        Arkko, J., Eggert, L., and M. Townsley, "Scalable
                    Operation of Address Translators with Per-Interface
                    Bindings", RFC 6619, June 2012.

   [RFC6763]        Cheshire, S. and M. Krochmal, "DNS-Based Service
                    Discovery", RFC 6763, February 2013.

   [RFC6886]        Cheshire, S. and M. Krochmal, "NAT Port Mapping
                    Protocol (NAT-PMP)", RFC 6886, April 2013.

   [RFC6888]        Perreault, S., Ed., Yamagata, I., Miyakawa, S.,
                    Nakagawa, A., and H. Ashida, "Common Requirements
                    for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888,
                    April 2013.

   [SCTPNAT]        Stewart, R., Tuexen, M., and I. Ruengeler, "Stream
                    Control Transmission Protocol (SCTP) Network Address
                    Translation", Work in Progress, February 2013.

Top      Up      ToC       Page 87 
Appendix A.  NAT-PMP Transition

   The Port Control Protocol (PCP) is a successor to the NAT Port
   Mapping Protocol, NAT-PMP [RFC6886], and shares similar semantics,
   concepts, and packet formats.  Because of this, NAT-PMP and PCP both
   use the same port and use NAT-PMP and PCP's version negotiation
   capabilities to determine which version to use.  This section
   describes how an orderly transition from NAT-PMP to PCP may be
   achieved.

   A client supporting both NAT-PMP and PCP SHOULD send its request
   using the PCP packet format.  This will be received by a NAT-PMP
   server or a PCP server.  If received by a NAT-PMP server, the
   response will be UNSUPP_VERSION, as indicated by the NAT-PMP
   specification [RFC6886], which will cause the client to downgrade to
   NAT-PMP and resend its request in NAT-PMP format.  If received by a
   PCP server, the response will be as described by this document and
   processing continues as expected.

   A PCP server supporting both NAT-PMP and PCP can handle requests in
   either format.  The first octet of the packet indicates if it is
   NAT-PMP (first octet zero) or PCP (first octet non-zero).

   A PCP-only gateway receiving a NAT-PMP request (identified by the
   first octet being zero) will interpret the request as a version
   mismatch.  Normal PCP processing will emit a PCP response that is
   compatible with NAT-PMP, without any special handling by the PCP
   server.

Top      Up      ToC       Page 88 
Authors' Addresses

   Dan Wing (editor)
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   EMail: dwing@cisco.com


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

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


   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   EMail: mohamed.boucadair@orange.com


   Reinaldo Penno
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   EMail: repenno@cisco.com


   Paul Selkirk
   Internet Systems Consortium
   950 Charter Street
   Redwood City, California  94063
   USA

   EMail: pselkirk@isc.org