One document matched: draft-ietf-pcp-proxy-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-pcp-proxy-04" ipr="trust200902">
<front>
<title abbrev="PCP Proxy">Port Control Protocol (PCP) Proxy
Function</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<code></code>
<country>USA</country>
</postal>
<email>repenno@cisco.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date day="29" month="July" year="2013" />
<workgroup>PCP Working Group</workgroup>
<keyword>PCP, proxy</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><?rfc subcompact="no" ?>This document defines a new PCP <xref
target="RFC6887"></xref> 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 <xref target="Reference_Architecture"></xref>.</t>
<t>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.</t>
<t>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 <xref target="advanced"></xref>). A PCP
Proxy can be co-located with UPnP IGD <xref
target="RFC6970"></xref>.</t>
<t><figure align="center" anchor="Reference_Architecture"
title="Reference Architecture">
<artwork><![CDATA[
+----------+ +---------+ +----------+
|PCP client|----------| | | |
| (Host 1) | Internal | | | |
+----------+ interface| |External | |
|PCP Proxy|interface|PCP server|
| |---------| |
+----------+ | | | |
|PCP client|----------| | | |
|(Host 2) | Internal | | | |
+----------+ interface| | | |
+---------+ +----------+
Internal PCP clients
]]></artwork>
</figure></t>
<t></t>
</section>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="PCP Server Discovery and Provisioning">
<t>The PCP Proxy MUST follow the procedure defined in Section 8.1 of
<xref target="RFC6887"></xref> to discover its PCP server.</t>
<t>The address of the PCP Proxy is provisioned to internal PCP clients
(see <xref target="Reference_Architecture"></xref>) as their default PCP
server: if the PCP DHCP option <xref target="RFC6887"></xref> 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.</t>
</section>
<section title="PCP Proxy as a PCP Server">
<t>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).</t>
<t>When the topology makes a routing loop possible, the PCP Proxy MUST
check it is not the source of a PCP message it received.</t>
</section>
<section title="Control of the Firewall">
<t>Security policies can be managed by a firewall co-located with the
PCP Proxy.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="nonat" title="No NAT is Co-located with the PCP Proxy">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="embedded_NAT"
title="PCP Proxy Co-located with a NAT Function">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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:<list style="symbols">
<t>a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE
error response a received request with an unknown OpCode.</t>
<t>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.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="proxy" title="MAP/PEER Handling">
<t>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.</t>
<t>For handling the THIRD_PARTY option, the PCP Proxy MUST follow the
PCP server behavior specified in Section 13.1 of <xref
target="RFC6887"></xref>.</t>
<t>The detailed behavior at the reception of a PCP request on an
internal interface is as follows: <list style="symbols">
<t>Check if the source IP address and the PCP client IP Address are
the same. If a mismatch is detected, the behavior specified in <xref
target="RFC6887"></xref> must be followed.</t>
<t>Apply security controls (e.g., THIRD_PARTY filtering).</t>
<t>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.</t>
<t>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 <xref
target="embedded_NAT"></xref> and forward it from a fresh UDP
port).</t>
<t>Wait for the response during a reasonable delay. The reasonable
delay minimum value is 20 seconds.</t>
<t>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 <xref target="embedded_NAT"></xref>), forward it to
the source PCP client.</t>
<t>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.</t>
</list></t>
<t></t>
<t>For each pending request, the proxy MUST maintain in a data record:
<list style="symbols">
<t>the payload of the request received from the PCP client</t>
<t>the interface where the request was received</t>
<t>the source IP address of the request</t>
<t>the source UDP port of the request</t>
<t>the UDP socket connected to the PCP server</t>
<t>an expire timeout</t>
</list></t>
<t>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.</t>
<t>The PCP Proxy is in charge to enforce the message size limit as
specified in Section 8.2 of <xref target="RFC6887"></xref>.</t>
<t>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.</t>
</section>
<section title="Mapping Repair">
<t>ANNOUNCE requests received from PCP clients are handled locally; as
such these requests MUST NOT be relayed to the provisioned PCP
server.</t>
<t>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.</t>
<t>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 (<xref
target="full"></xref>).</t>
<t>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 <xref target="RFC6887"></xref>. This can be achieved only if
a full state table is maintained by the PCP Proxy.</t>
</section>
<section anchor="advanced" title="Advanced Functions">
<t>Below are listed a set of advanced features that MAY be supported by
the PCP Proxy.</t>
<section title="Multiple PCP Servers">
<t>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
<xref target="epoch_handling"></xref>. PCP clients are not aware of
the presence of multiple PCP servers.</t>
<t>According to <xref target="I-D.ietf-pcp-server-selection"></xref>,
if several PCP Names are configured to the PCP Proxy, it will contact
in parallel all these PCP servers.</t>
<t>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.</t>
<t>The PCP Proxy MAY rely on some fields (e.g., Zone ID <xref
target="I-D.penno-pcp-zones"></xref>) in the PCP request to redirect
the request to a given PCP server.</t>
</section>
<section anchor="epoch_handling" title="Epoch Handling">
<t>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.</t>
<t>The Epoch MUST be reset when explicit dynamic mappings are lost,
i.e.: <list style="symbols">
<t>at startup if the PCP Proxy can't recover the state.</t>
<t>when the proxy's external address is changed or any similar
events that show any previous state is no longer valid.</t>
<t>when the Epoch value in a PCP response is too small (cf. Epoch
value validation rules in <xref target="RFC6887"></xref>).</t>
<t>when the PCP server's External IP Address has changed.</t>
</list>The last two rules are per PCP server, a PCP Proxy MAY check
these conditions in all received responses for a PCP server.</t>
</section>
<section title="Request/Response Caching">
<t>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.</t>
</section>
<section title="Retransmission Handling">
<t>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 <xref
target="RFC6887"></xref>.</t>
</section>
<section anchor="full" title="Full State">
<t>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 <xref
target="I-D.boucadair-pcp-failure"></xref>).</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The PCP Proxy MUST follow the security considerations elaborated in
<xref target="RFC6887"></xref> for both the client and server side.</t>
<t><xref target="nonat"></xref> and <xref target="embedded_NAT"></xref>
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 <xref
target="RFC6887"></xref>. 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.</t>
<t>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.</t>
<t>The device embedding the PCP Proxy MAY block PCP requests directly
sent to the PCP server. This can be enforced using access control
lists.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to C. Zhou, T. Reddy, and D. Thaler for their review and
comments.</t>
<t>Special thanks to F. Dupont who contributed to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6887"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6970"?>
<?rfc include="reference.I-D.ietf-pcp-dhcp"?>
<?rfc include='reference.I-D.ietf-pcp-server-selection'?>
<?rfc include="reference.I-D.boucadair-pcp-failure"?>
<?rfc include='reference.I-D.penno-pcp-zones'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:19:38 |