One document matched: draft-cheshire-pcp-unsupp-family-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-cheshire-pcp-unsupp-family-05" ipr="trust200902" updates="6887">
<front>
<title abbrev="PCP Update">Updates to the PCP specification</title>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization abbrev="Apple">Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>California</region>
<code>95014</code>
<country>USA</country>
</postal>
<phone>+1 408 974 3207</phone>
<email>cheshire@apple.com</email>
</address>
</author>
<author initials="S." surname="Perreault" fullname="Simon Perreault">
<organization>Viagénie</organization>
<address>
<postal>
<street>246 Aberdeen</street>
<city>Québec</city>
<region>QC</region>
<code>G1R 2E1</code>
<country>Canada</country>
</postal>
<phone>+1 418 656 9254</phone>
<email>simon.perreault@viagenie.ca</email>
<uri>http://viagenie.ca</uri>
</address>
</author>
<date day='14' month='July' year='2013'/>
<workgroup>PCP working group</workgroup>
<abstract>
<t>The Port Control Protocol (PCP) allows clients to request mappings in NAT
gateways and firewalls. This document specifies the PCP UNSUPP_FAMILY
error code, which enables PCP servers to inform clients when the
requested external address family is not supported. This document also
removes the requirement for the PCP server to validate the mapping
nonce, which proved to be unhelpful in practice. </t>
</abstract>
</front>
<middle>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119">"Key words for use in RFCs to Indicate Requirement Levels"</xref>.</t>
</section>
<?rfc needLines="8" ?>
<section anchor="UNSUPP_FAMILY" title="PCP Unsupported Family Error">
<t><xref target="RFC6887">Port Control Protocol</xref> MAP requests allow
clients to request inbound mappings in NAT gateways and firewalls.
A client can request a MAP mapping to an external IPv6 address or
to an external IPv4 address. The client signifies which family of
external address it desires by the type of address it puts into
the Suggested External Address field.</t>
<t>If the client wants an external IPv6 address, then it populates
the Suggested External Address field with a native IPv6 address.
In the overwhelmingly common case where the client doesn't know the
external address when it makes its initial request, this will be the
all-zeros IPv6 address (::).</t>
<t>If the client wants an external IPv4 address, then it populates
the Suggested External Address field with an IPv4-mapped IPv6
address (the first 80 bits set to zero, the next 16 set to one).
In the overwhelmingly common case where the client doesn't know the NAT's
external address when it makes its initial request, this will be the
all-zeros IPv4 address (::ffff:0:0).</t>
<t>The <xref target="RFC6887">PCP specification</xref> is somewhat vague
about whether the address family is a firm requirement, or merely a hint
that the PCP server is free to ignore. This update clarifies that issue:
The specific address placed in the Suggested
External Address field is merely a suggestion that the PCP server
is free to ignore, but the address family is not. If the specific suggested
address cannot be provided, another address of the same family
SHOULD be provided if possible, but if the suggested address *family*
cannot be provided by this PCP server, it MUST return a PCP error
reply containing the UNSUPP_FAMILY error code.</t>
<t>Many gateway devices, particularly early ones, may not be able to provide
both external address families. For example, an IPv4-only NAT cannot
provide an external IPv6 address.</t>
<t>Even with gateway devices that can support both external address families,
the ability to provide an external address of the requested family may depend
on the family of the client's internal address. For example, a gateway that
supports native IPv6, and traditional NAT44, but not NAT64, can provide
mappings from an internal IPv6 address to an external IPv6 address (typically
the same address when no address translation is being performed), and can provide
mappings from an internal IPv4 address to an external IPv4 address, but not
mappings from an internal IPv6 address to an external IPv4 address.
When such a gateway receives a request to map an internal IPv6 address
to an external IPv4 address it MUST return the UNSUPP_FAMILY error code.</t>
<t>Note that it is possible and valid for a given internal address
and port to have two mappings simultaneously, one to an external
IPv4 address and one to an external IPv6 address. The handling of
outbound packets is determined by the outbound destination address;
for example, an outbound IPv6 packet addressed to an IPv6 address
in the NAT64 gateway's IPv6 address pool is translated to the
corresponding IPv4 packet before forwarding; an outbound IPv6 packet
addressed to some other routable IPv6 address is forwarded unmodified.</t>
<t>A client that can handle both IPv6 and IPv4 external addresses MAY send
two requests, and then determine its behavior based on the responses it receives.
For example, if the client requests and receives an IPv6 external address,
it might create a DNS AAAA record giving that IPv6 address.
If the client requests and receives an IPv4 external address,
it might create a DNS address record giving that IPv4 address.
If the client requests and receives both families of external address,
it might create both DNS records.
Or, if one external address is sufficient for the client, then it MAY
first request its preferred address family, and only if that fails
with an UNSUPP_FAMILY error, request the other family.</t>
<?rfc needLines="16" ?>
<section anchor="update" title="Implications for RFC 6887">
<t>Various sections of the <xref target="RFC6887">PCP specification</xref>
describe clients and servers identifying a MAP mapping by examining the three-tuple of
{ protocol, internal address, internal port }
in a request or reply. For example:
<list style="hanging">
<t>If the internal port, protocol, and internal address match an
existing static mapping (which will have no nonce), then a PCP
reply is sent giving the external address and port of that static
mapping, using the nonce from the PCP request. The server does not
record the nonce.</t>
<t>It is possible that a mapping might already exist for a
requested internal address, protocol, and port. If so, the PCP
server takes the following actions...</t>
<t>If no mapping exists for the internal address, protocol, and
port, and the PCP server is able to create a mapping using the
suggested external address and port, it SHOULD do so.</t>
<t>After performing common PCP response processing, the response is
further matched with a previously sent MAP request by comparing the
internal IP address (the destination IP address of the PCP response,
or other IP address specified via the THIRD_PARTY option), the
protocol, the internal port, and the mapping nonce. Other fields
are not compared, because the PCP server sets those fields.</t>
</list>
</t>
<t>Everywhere that the <xref target="RFC6887">PCP specification</xref>
refers to using the "protocol, internal address, and internal port," to identify
a particular inbound mapping, it should be read to mean the four-tuple of
{ protocol, internal address, internal port,
external address family }.</t>
<t>PCP clients and servers that only support one external
address family can continue to use the previous three-tuple
{ protocol, internal address, internal port }
to identify inbound mappings, since they only support one external address
family, and unilaterally reject MAP requests and responses containing the
unsupported family. For PCP servers this means rejecting MAP requests
containing the unsupported address family via the UNSUPP_FAMILY error code.
For PCP clients this should be a non-issue because
a PCP client should never receive a reply containing an external address
family it didn't request, but should a client receive such a reply from a
misbehaving PCP server offering an external address family the client did
not request, the client MUST silently ignore the erroneous reply.</t>
<t>An implication of this update to the PCP specification is that when
renewing a MAP mapping, a PCP client MUST include a suggested external
address of the correct family, so that the gateway device can identify
which mapping is being renewed. Ideally a PCP client SHOULD record the
previously-granted external address and use that as the suggested
external address in its renewal request, to facilitate recovery in the
event of gateway state loss, but at the very least a PCP client MUST
provide an all-zeroes suggested external address of the correct family
(just as it must have indicated the desired address family in its
initial request that created the mapping).</t>
<t>These considerations apply only to MAP requests.
With PEER requests, the five-tuple of
{ protocol, internal address, internal port,
remote peer address, remote peer port }
uniquely identifies the intended mapping.
When technologies like NAT64 are used the external address family
need not be the same as the remote peer address family, but the
external address family is still uniquely determined by the remote
peer address, and does not need to be specified separately.</t>
</section>
</section>
<?rfc needLines="47" ?>
<section anchor="nonce" title="New Nonce Check Behavior">
<t>The <xref target="RFC6887">PCP specification</xref> states that if a
client requests a mapping (or renews a mapping, which is the same thing,
from the server's point of view) and the requested mapping already
exists, but with a different nonce, then the server returns a
NOT_AUTHORIZED error.</t>
<t>This has proved to be problematic. The nonce exists to guard against
off-path attackers. It helps a client have confidence that the PCP responses
it receives are really from the server that processed its PCP request.
And it helps a PCP server validate that a client requesting a mapping is
the same client that previously requested a mapping for that internal
address and port. In some circumstances a legitimate client may not know
the correct nonce to renew its own mappings.</t>
<t>For example, if a host reboots or otherwise suffers a loss of state,
it may not have a record of nonces it previously used. Suppose this host
then requests a mapping from an external IPv4 address to its internal
IP address at TCP port 22, so that it can receive ssh logins. If the same
internal host had previously requested such a mapping using a different
nonce, then the new request will fail with a NOT_AUTHORIZED error.
This is unhelpful and misleading. The client does in fact have a mapping.
Incoming connection requests to its external address and port will in
fact be forwarded to it at port 22. The PCP server is simply refusing to
tell the client what the external address and port are, hindering the
client's ability to use the mapping that it actually already has.</t>
<t>The same scenario also exists in the case where
(i) a different internal host had previously requested a mapping to its
internal port 22,
(ii) that host then left the network, and
(iii) the newly vacated internal IP address is then assigned to new host.
When this happens, the new host will be unable to usefully request
a mapping to its internal port 22 until the old mapping expires, or
is deleted through some other means (e.g. via the DHCP server informing
the PCP server that the IP address has been reassigned, or via manual
intervention by an administrator, or via some other out-of-band mechanism).
Note that the new host will actually have a working mapping to its internal
port 22, and will actually receive incoming connection requests arriving at
the external address and port, but the PCP server will refuse to tell the
client what the external address and port are, thereby hindering the
new host from communicating that external address and port to the peer
it wishes to receive connections from. This is not helpful.</t>
<t>This PCP security check does not prevent the new host from learning
the external address and port by other circuitous means. For example,
the new host could discover the external address and port by sending
outbound traffic a destination it controls, and having that destination
report back the source address and port.</t>
<t>Furthermore, this PCP security check is inconsistent with other PCP
behavior. It makes PCP behave differently for explicit dynamic versus
other kinds of mappings. Indeed, requests matching static mappings
are not subjected to the nonce check and will result in a response
containing the static mapping's current state. There is no reason that
MAP requests matching a dynamic mapping should return less information.</t>
<t>Therefore, the nonce check behavior described below MUST be
implemented instead.</t>
<section anchor="MAP" title="Nonce Check for MAP Requests">
<t>If operating in the Simple Threat Model
(Section 18.1 of the <xref target="RFC6887">PCP specification</xref>),
and the internal port, protocol, internal address, and external
address family match an existing explicit dynamic mapping, but the
mapping nonce does not match, then the existing mapping
<!--nonce is
updated to the new nonce, the lifetime is updated (subject to the PCP
server policy for maximum and minimum lifetimes) and an appropriate
PCP reply is sent, using the new nonce and assigned lifetime.-->
is not modified in any way, and a valid PCP reply is returned to
the client, using the client-specified nonce, reporting the external
address, port, and remaining lifetime of the existing mapping.</t>
<t>This specification makes no statement about mapping nonce with the
Advanced Threat Model.</t>
</section>
<section anchor="PEER" title="Nonce Check for PEER Requests">
<t>If operating in the Simple Threat Model
(Section 18.1 of the <xref target="RFC6887">PCP specification</xref>),
and the protocol, internal address, internal port, remote peer address,
and remote peer port match a mapping that already exists, but the mapping
nonce does not match (that is, a previous PEER request was processed),
then the existing mapping
<!--nonce is updated to the new nonce, the
lifetime is updated (subject to the PCP server policy for maximum and
minimum lifetimes) and an appropriate PCP reply is sent, using the new
nonce and assigned lifetime.-->
is not modified in any way, and a valid PCP reply is returned to
the client, using the client-specified nonce, reporting the external
address, port, and remaining lifetime of the existing mapping.</t>
<t>This specification makes no statement about mapping nonce with the
Advanced Threat Model.</t>
</section>
<?rfc needLines="7" ?>
<section anchor="NOT_AUTHORIZED" title="Returning NOT_AUTHORIZED error">
<t>A NOT_AUTHORIZED error should still be returned, as described in
Section 15.1 of the <xref target="RFC6887">PCP specification</xref>, when
a PCP client attempts to delete a static mapping (i.e., a mapping
created outside of PCP itself) or an outbound (implicit or
PEER-created) mapping.</t>
</section>
<section anchor="Discussion" title="Discussion">
<t>The behavior described above in Sections
<xref target="MAP" format="counter"/> and
<xref target="PEER" format="counter"/>
is what is currently being considered by the working group.
An implication of this behavior is that if a client forgets its
previous nonce (through reboot or similar lost of state), then
when it tries to recreate its previous mappings, it will learn
about its existing mappings, but it will be unable to extend
their lifetimes. This means that a mapping with a one-hour
lifetime will be renewed after roughly half an hour, at which
point its remaining lifetime will be about half an hour. It will
then be renewed after roughly fifteen minutes, then seven
minutes, then three minutes, and so on, increasingly rapidly,
until the old mapping finally expires and is immediately
replaced with a new one with a new nonce.</t>
</section>
</section>
<?rfc needLines="13" ?>
<section anchor="iana" title="IANA Considerations">
<t>IANA should allocate the following PCP Result Code:
<list style="hanging">
<t hangText="14">UNSUPP_FAMILY: Unsupported external address
family, e.g., IPv6 in a NAT that handles only IPv4. This is a
long lifetime error.</t>
</list>
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>The UNSUPP_FAMILY error code leaks no sensitive information and
creates no new security vulnerabilities.</t>
<t>Allowing a client to learn the parameters of an existing
mapping without knowing the mapping nonce used to create it
could leak mapping information to an on-path attacker.</t>
<t>Having the PCP server refuse to renew or delete mappings if the
request nonce doesn't match the existing nonce allows an off-path
attacker to preemptively poison a NAT gateway with bogus mappings,
which the legitimate holder of the internal address will then be
unable to renew or delete because it doesn't know the nonce the
attacker used when creating the bogus mappings.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6887"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:03:16 |