Port Control Protocol (PCP) Proxy Function
draft-ietf-pcp-proxy-04

PCP Working Group                                           M. Boucadair
Internet-Draft                                            France Telecom
Intended status: Standards Track                                R. Penno
Expires: January 30, 2014                                        D. Wing
                                                                   Cisco
                                                           July 29, 2013

               Port Control Protocol (PCP) Proxy Function
                        draft-ietf-pcp-proxy-04

Abstract

   This document specifies a new PCP functional element denoted as a PCP
   Proxy.  The PCP Proxy relays PCP requests received from PCP clients
   to upstream PCP server(s).  A typical deployment usage of this
   function is to help establish successful PCP communications for PCP
   clients that can not be configured with the address of a PCP server
   located more than one hop away.

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 January 30, 2014.

Copyright Notice

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

Boucadair, et al.       Expires January 30, 2014                [Page 1]
Internet-Draft                  PCP Proxy                      July 2013

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  PCP Server Discovery and Provisioning . . . . . . . . . . . .   3
   4.  PCP Proxy as a PCP Server . . . . . . . . . . . . . . . . . .   3
   5.  Control of the Firewall . . . . . . . . . . . . . . . . . . .   4
   6.  No NAT is Co-located with the PCP Proxy . . . . . . . . . . .   4
   7.  PCP Proxy Co-located with a NAT Function  . . . . . . . . . .   4
   8.  MAP/PEER Handling . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Mapping Repair  . . . . . . . . . . . . . . . . . . . . . . .   7
   10. Advanced Functions  . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Multiple PCP Servers . . . . . . . . . . . . . . . . . .   8
     10.2.  Epoch Handling . . . . . . . . . . . . . . . . . . . . .   8
     10.3.  Request/Response Caching . . . . . . . . . . . . . . . .   9
     10.4.  Retransmission Handling  . . . . . . . . . . . . . . . .   9
     10.5.  Full State . . . . . . . . . . . . . . . . . . . . . . .   9
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   12. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     14.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document defines a new PCP [RFC6887] functional element, called
   PCP Proxy, which is meant to facilitate communication between a PCP
   client and upstream PCP server(s).  The PCP Proxy acts as a PCP
   server receiving PCP requests on internal interfaces, and as a PCP
   client forwarding accepted PCP requests on an external interface to a
   PCP server.  The PCP server in turn sends PCP responses to the PCP
   Proxy external interface which are finally forwarded to PCP clients.
   A reference architecture is depicted in Figure 1.

   A PCP Proxy can be for instance embedded in a CP (Customer Premises)
   router while the PCP server is located in a network operated by an
   ISP (Internet Service Provider).  It is out of scope of this document
   to list all deployment scenarios requiring a PCP Proxy to be
   involved.

   The PCP Proxy can be simple (i.e., a single-homed entity which
   implements as transparent/minimal processing as possible) or it can

Boucadair, et al.       Expires January 30, 2014                [Page 2]
Internet-Draft                  PCP Proxy                      July 2013

   support advanced features (see Section 10).  A PCP Proxy can be co-
   located with UPnP IGD [RFC6970].

            +----------+          +---------+         +----------+
            |PCP client|----------|         |         |          |
            | (Host 1) | Internal |         |         |          |
            +----------+ interface|         |External |          |
                                  |PCP Proxy|interface|PCP server|
                                  |         |---------|          |
            +----------+          |         |         |          |
            |PCP client|----------|         |         |          |
            |(Host 2)  | Internal |         |         |          |
            +----------+ interface|         |         |          |
                                  +---------+         +----------+
          Internal PCP clients

                     Figure 1: Reference Architecture

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  PCP Server Discovery and Provisioning

   The PCP Proxy MUST follow the procedure defined in Section 8.1 of
   [RFC6887] to discover its PCP server.

   The address of the PCP Proxy is provisioned to internal PCP clients
   (see Figure 1) as their default PCP server: if the PCP DHCP option
   [RFC6887] is supported by an internal PCP client, it will retrieve
   the PCP server IP address to use from its local DHCP server;
   otherwise internal PCP clients will assume their default router being
   the PCP server.

4.  PCP Proxy as a PCP Server

   The PCP Proxy acts as a PCP server for internal hosts and accepts PCP
   requests on the interface(s) facing them.  The PCP Proxy SHOULD be
   configured with the interface(s) on which it acts as a PCP server.
   Such configuration may be automatic (e.g., the private interfaces of
   a NAT44 when the PCP Proxy is collocated with a NAT44).

   When the topology makes a routing loop possible, the PCP Proxy MUST
   check it is not the source of a PCP message it received.

Boucadair, et al.       Expires January 30, 2014                [Page 3]
Internet-Draft                  PCP Proxy                      July 2013

5.  Control of the Firewall

   Security policies can be managed by a firewall co-located with the
   PCP Proxy.

   A security policy to accept PCP messages from the provisioned PCP
   server(s) is to be enabled on the device embedding the PCP Proxy.
   This policy can be for instance triggered by DHCP configuration or by
   outbound PCP requests issued from the PCP Proxy to the provisioned
   PCP server.

   In order to accept inbound and outbound traffic associated with PCP
   mappings instantiated in the upstream PCP server, appropriate
   security policies are to be configured on the firewall.

   For instance if the firewall rules have a lifetime, PCP responses can
   be snooped on in order to instantiate the corresponding firewall
   rules with the same lifetime as the one of those PCP responses.  If
   they have no lifetime, an explicit dynamic mapping table can be kept
   in the PCP Proxy state in order to instantiate and remove
   corresponding firewall rules.

   FILTER Options can be installed into the firewall co-located with the
   PCP Proxy, forwarded to the PCP server and so installed into the
   remote PCP-controlled device.

6.  No NAT is Co-located with the PCP Proxy

   When no NAT is co-located with the PCP Proxy, the port numbers
   included in received PCP messages (from the PCP server or PCP
   client(s)) are not altered by the PCP Proxy.  Nevertheless, the PCP
   client IP Address MUST be changed to the address used by the PCP
   Proxy to send PCP messages to the next PCP server, and a THIRD_PARTY
   Option inserted to carry the IP address of the source PCP client.

   Because no NAT is invoked, there is no reachability failure risk to
   relay to the PCP server unknown Options and OpCodes that carry an IP
   address.

7.  PCP Proxy Co-located with a NAT Function

   When the PCP Proxy is co-located with a NAT function, it MUST update
   the content of received requests with the mapped port number and the
   address belonging to the external interface of the PCP Proxy (i.e.,
   after the NAT operation) and not as initially conveyed by the PCP
   client.  For the reverse path, PCP responses MUST be updated by the
   PCP Proxy to replace the NAT's external port number assigned to the
   PCP client with the PCP client's own internal port number.  For this

Boucadair, et al.       Expires January 30, 2014                [Page 4]
Internet-Draft                  PCP Proxy                      July 2013

   purpose the PCP Proxy MUST have access to the local NAT state
   maintained locally.

   If the NAT assigns an external IP address which is not the one used
   by the PCP Proxy to contact its PCP server, the PCP Proxy MUST insert
   a THIRD_PARTY Option to carry the NAT's external IP address assigned
   to the PCP client.  A typical use case is when the NAT is configured
   with more than one external IP address.

   By default, the PCP Proxy MUST relay unknown OpCodes and mandatory-
   to-process unknown Options.  Rejecting unknown Options and OpCodes
   has the drawback of preventing a PCP client to make use of new
   capabilities offered by the PCP server but not supported by the PCP
   Proxy even if no IP address and/or port is included in the Option/
   OpCode.

   Because PCP messages with an unknown OpCode or mandatory-to-process
   unknown Options can carry a hidden internal address or internal port
   that will not be translated, a PCP Proxy MUST be configurable to
   disable relaying unknown OpCodes and mandatory-to-process unknown
   Options.  If the PCP Proxy is configured to disable relaying unknown
   OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST
   behave as follows:

   o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE
      error response a received request with an unknown OpCode.

   o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPTION
      error response a received request with a mandatory-to-process
      unknown Option.

   When a PCP request is received and accepted by the PCP Proxy the
   corresponding mapping (explicit dynamic mapping for a MAP request,
   implicit dynamic mapping for a PEER request) is looked for in the
   local NAT state and temporarily created if it does not exist.
   "Temporarily" means it is deleted if no SUCCESS response is received,
   either explicitly or because of its short lifetime at creation.

   If the local NAT associates explicit dynamic mappings with a
   lifetime, the requested lifetime in MAP requests sent to the PCP
   server SHOULD be adjusted to be in the accepted range of the local
   NAT, and the assigned lifetime copied from MAP responses to the
   corresponding mapping in the local NAT.  The same processing applies
   to implicit dynamic mappings and PEER requests/responses.

   Otherwise explicit dynamic mappings have an undefined lifetime in the
   local NAT and the PCP Proxy SHOULD maintain an explicit dynamic
   mapping table and SHOULD delete corresponding explicit dynamic

Boucadair, et al.       Expires January 30, 2014                [Page 5]
Internet-Draft                  PCP Proxy                      July 2013

   mappings in the local NAT when they expire or are deleted by the MAP
   request with a zero requested lifetime.

8.  MAP/PEER Handling

   A simple PCP Proxy performs minimal modifications to PCP requests and
   responses.  In particular, it does not change the Nonce value in
   requests and the Epoch value in responses.  A simple PCP Proxy is
   assumed to handle only one PCP server.

   For handling the THIRD_PARTY option, the PCP Proxy MUST follow the
   PCP server behavior specified in Section 13.1 of [RFC6887].

   The detailed behavior at the reception of a PCP request on an
   internal interface is as follows:

   o  Check if the source IP address and the PCP client IP Address are
      the same.  If a mismatch is detected, the behavior specified in
      [RFC6887] must be followed.

   o  Apply security controls (e.g., THIRD_PARTY filtering).

   o  If the request is rejected, build an error response and send it
      back to the PCP client.  The error status code is set to
      NOT_AUTHORIZED.

   o  If the request is accepted, adjust it (e.g., adding a THIRD_PARTY
      Option, updating the PCP client IP Address and Internal Port to
      their translated values as specified in Section 7 and forward it
      from a fresh UDP port).

   o  Wait for the response during a reasonable delay.  The reasonable
      delay minimum value is 20 seconds.

   o  When the response is received from the PCP server, adjust it back
      (e.g., removing the THIRD_PARTY Option added previously, updating
      the PCP client IP Address and Internal Port to their initial
      values as specified in Section 7), forward it to the source PCP
      client.

   o  On a hard error on the UDP socket, build an ICMP Destination
      Unreachable message with code 3 (Destination Port Unreachable) and
      send it to the source PCP client.

   For each pending request, the proxy MUST maintain in a data record:

   o  the payload of the request received from the PCP client

Boucadair, et al.       Expires January 30, 2014                [Page 6]
Internet-Draft                  PCP Proxy                      July 2013

   o  the interface where the request was received

   o  the source IP address of the request

   o  the source UDP port of the request

   o  the UDP socket connected to the PCP server

   o  an expire timeout

   Receiving interfaces can be implemented by a set of servicing
   sockets, each socket bound to an address of an internal interface.
   The interface, source address and port are used to send back packets
   to the source PCP client.  The request payload is used to generate an
   ICMP error message.  Responses are received on the UDP socket.

   The PCP Proxy is in charge to enforce the message size limit as
   specified in Section 8.2 of [RFC6887].

   If the PCP Proxy processing (e.g., adding a THIRD_PARTY Option) makes
   a request that exceeds 1100 octets, a MALFORMED_REQUEST response is
   sent to the PCP client.

9.  Mapping Repair

   ANNOUNCE requests received from PCP clients are handled locally; as
   such these requests MUST NOT be relayed to the provisioned PCP
   server.

   Upon receipt of an unsolicited ANNOUNCE response from a PCP server,
   the PCP Proxy proceeds to renew the mappings and checks whether there
   are changes compared to a local cache if it is maintained by the PCP
   Proxy.  If no change is detected, no unsolicited ANNOUNCE is
   generated towards PCP clients.  If a change is detected, the PCP
   Proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate
   PCP clients.  If the PCP Proxy does not maintain a local cache for
   the mappings, unsolicited multicast ANNOUNCE messages are sent to PCP
   clients.

   Unsolicited PCP MAP/PEER responses received from a PCP server are
   handled as any normal MAP/PEER response.  To handle unsolicited PCP
   MAP/PEER responses, the PCP Proxy is required to maintain a local
   cache of instantiated mappings in the PCP server (Section 10.5).

Boucadair, et al.       Expires January 30, 2014                [Page 7]
Internet-Draft                  PCP Proxy                      July 2013

   Upon change of its external IP address, the PCP Proxy SHOULD renew
   the mappings it maintained.  If the PCP server assigns a different
   external port, the PCP Proxy SHOULD follow the mapping repair
   procedure defined in [RFC6887].  This can be achieved only if a full
   state table is maintained by the PCP Proxy.

10.  Advanced Functions

   Below are listed a set of advanced features that MAY be supported by
   the PCP Proxy.

10.1.  Multiple PCP Servers

   A PCP Proxy MAY handle multiple PCP servers at the same time.  Each
   PCP server is associated with its own handled Epoch value according
   to Section 10.2.  PCP clients are not aware of the presence of
   multiple PCP servers.

   According to [I-D.ietf-pcp-server-selection], if several PCP Names
   are configured to the PCP Proxy, it will contact in parallel all
   these PCP servers.

   In some contexts (e.g., PCP-controlled CGNs), the PCP Proxy MAY load
   balance the PCP clients among available PCP servers.  The PCP Proxy
   MUST ensure requests of a given PCP client are relayed to the same
   PCP server.

   The PCP Proxy MAY rely on some fields (e.g., Zone ID
   [I-D.penno-pcp-zones]) in the PCP request to redirect the request to
   a given PCP server.

10.2.  Epoch Handling

   A PCP Proxy MAY use its own internal timers and not blindly copy them
   from PCP responses.  There should be no advantages to have more than
   one managed Epoch per PCP server.

   The Epoch MUST be reset when explicit dynamic mappings are lost,
   i.e.:

   o  at startup if the PCP Proxy can't recover the state.

   o  when the proxy's external address is changed or any similar events
      that show any previous state is no longer valid.

   o  when the Epoch value in a PCP response is too small (cf. Epoch
      value validation rules in [RFC6887]).

Boucadair, et al.       Expires January 30, 2014                [Page 8]
Internet-Draft                  PCP Proxy                      July 2013

   o  when the PCP server's External IP Address has changed.

   The last two rules are per PCP server, a PCP Proxy MAY check these
   conditions in all received responses for a PCP server.

10.3.  Request/Response Caching

   A PCP Proxy providing request/response caching checks each time it
   receives a PCP request if it has already seen the same request
   recently (e.g., last 30 minutes) and got the corresponding PCP
   response.  In this case, it sends back directly the cached response
   with the proper Epoch value and does not forward the request to the
   PCP server.

10.4.  Retransmission Handling

   An extension of the previous feature is to manage the retransmission
   of pending requests to the PCP server internally, i.e., no longer
   driven by the PCP client.  In such case, the PCP Proxy follows the
   retransmission procedure defined in Section 8.1.1 of [RFC6887].

10.5.  Full State

   A PCP Proxy MAY keep the full state, i.e., an image of all active
   explicit dynamic mappings is kept in memory.  When this service is
   supported the state SHOULD be recovered in case of failures inducing
   state loss (e.g., according to [I-D.boucadair-pcp-failure]).

11.  IANA Considerations

   This document makes no request of IANA.

12.  Security Considerations

   The PCP Proxy MUST follow the security considerations elaborated in
   [RFC6887] for both the client and server side.

   Section 6 and Section 7 specifies cases where a THIRD_PARTY option is
   inserted the PCP Proxy.  As such, means to prevent a malicious user
   from creating mappings on behalf of a third party must be enabled as
   discussed in Section 13.1 of [RFC6887].  In particular, THIRD_PARTY
   option MUST NOT be enabled unless the network on which the PCP
   messages are to be sent is fully trusted.  For example if access
   control lists (ACLs) are installed on the PCP Proxy, PCP server, and
   the network between them, so those ACLs allow only communications
   from a trusted PCP Proxy to the PCP server.

Boucadair, et al.       Expires January 30, 2014                [Page 9]
Internet-Draft                  PCP Proxy                      July 2013

   A received request carrying an unknown OpCode or Option SHOULD be
   dropped (or in the case of an unknown Option which is not mandatory-
   to-process the Option be removed) if it is not compatible with
   security controls provisionned to the PCP Proxy.

   The device embedding the PCP Proxy MAY block PCP requests directly
   sent to the PCP server.  This can be enforced using access control
   lists.

13.  Acknowledgements

   Many thanks to C. Zhou, T. Reddy, and D. Thaler for their review and
   comments.

   Special thanks to F. Dupont who contributed to this document.

14.  References

14.1.  Normative References

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

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

14.2.  Informative References

   [I-D.boucadair-pcp-failure]
              Boucadair, M. and R. Penno, "Analysis of Port Control
              Protocol (PCP) Failure Scenarios", draft-boucadair-pcp-
              failure-06 (work in progress), May 2013.

   [I-D.ietf-pcp-dhcp]
              Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
              the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-07
              (work in progress), March 2013.

   [I-D.ietf-pcp-server-selection]
              Boucadair, M., Penno, R., Wing, D., Patil, P., and T.
              Reddy, "PCP Server Selection", draft-ietf-pcp-server-
              selection-01 (work in progress), May 2013.

   [I-D.penno-pcp-zones]
              Penno, R., "PCP Support for Multi-Zone Environments",
              draft-penno-pcp-zones-01 (work in progress), October 2011.

Boucadair, et al.       Expires January 30, 2014               [Page 10]
Internet-Draft                  PCP Proxy                      July 2013

   [RFC6970]  Boucadair, M., Penno, R., and D. Wing, "Universal Plug and
              Play (UPnP) Internet Gateway Device - Port Control
              Protocol Interworking Function (IGD-PCP IWF)", RFC 6970,
              July 2013.

Authors' Addresses

   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com

   Reinaldo Penno
   Cisco
   USA

   Email: repenno@cisco.com

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

   Email: dwing@cisco.com

Boucadair, et al.       Expires January 30, 2014               [Page 11]