| PCP Working Group | M. Boucadair |
| Internet-Draft | France Telecom |
| Intended status: Standards Track | R. Penno |
| Expires: January 29, 2014 | D. Wing |
| Cisco | |
| July 28, 2013 |
Port Control Protocol (PCP) Proxy Function
draft-ietf-pcp-proxy-04
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.
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 29, 2014.
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 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.
[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 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
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].
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.
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.
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.
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.
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 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:
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 mappings in the local NAT when they expire or are deleted by the MAP request with a zero requested lifetime.
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:
For each pending request, the proxy MUST maintain in a data record:
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.
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).
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.
Below are listed a set of advanced features that MAY be supported by the PCP Proxy.
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.
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.:
The last two rules are per PCP server, a PCP Proxy MAY check these conditions in all received responses for a PCP server.
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.
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].
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]).
This document makes no request of IANA.
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.
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.
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.
| [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. |
| [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. |
| [I-D.ietf-pcp-dhcp] | Boucadair, M., Penno, R. and D. Wing, "DHCP Options for the Port Control Protocol (PCP)", Internet-Draft draft-ietf-pcp-dhcp-06, February 2013. |
| [I-D.ietf-pcp-server-selection] | Boucadair, M., Penno, R., Wing, D., Patil, P. and T. Reddy, "PCP Server Selection", Internet-Draft draft-ietf-pcp-server-selection-00, November 2012. |
| [I-D.boucadair-pcp-failure] | Boucadair, M. and R. Penno, "Port Control Protocol (PCP) Failure Scenarios", Internet-Draft draft-boucadair-pcp-failure-05, February 2013. |
| [I-D.penno-pcp-zones] | Penno, R., "PCP Support for Multi-Zone Environments", Internet-Draft draft-penno-pcp-zones-01, October 2011. |