The Port Control Protocol in Dual-Stack Lite environments
Internet Systems Consortium
fdupont@isc.org
Huawei Technologies
2330 Central Expressway
Santa Clara
USA
+1-408-330-4424
tina.tsou.zouting@huawei.com
ZTE Corporation
Shanghai
P.R.China
jacni@jacni.com
Painless Security
356 Abbott Street
North Andover MA
01845
USA
+1 781 405 7464
mrw@painless-security.com
http://www.painless-security.com
Huawei
Beijing
China
zhangdacheng@huawei.com
PCP Working Group
PCP, DS-Lite
This document specifies the so-called "plain mode" for
the use of the Port Control Protocol (PCP) in Dual-Stack
Lite (DS-Lite) environments.
Dual-Stack Lite (DS-Lite, )
is a technology which enables a broadband service provider to
share IPv4 addresses among customers by combining two well-known
technologies: IP in IP (IPv4-in-IPv6) and Network Address
Translation (NAT).
Typically, the home gateway embeds a Basic Bridging BroadBand
(B4) capability that encapsulates IPv4 traffic into a IPv6
tunnel to the carrier-grade NAT, named the Address Family
Transition Router (AFTR). AFTRs are run by service
providers.
The Port Control Protocol (PCP, allows customer applications
to create mappings in a NAT for new inbound communications
destined to machines located behind a NAT. In a DS-Lite
environment, PCP servers control AFTR devices.
Two different modes of operations have been proposed: the
plain and the encapsulation modes. This document recommends
use of the plain mode.
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.
In the plain mode the B4, the customer end-point of
the DS-Lite IPv6 tunnel, implements a PCP proxy
() function
and uses UDP over IPv6 with the AFTR to send PCP requests
and receive PCP responses.
The B4 MUST source PCP requests with the IPv6 address
of its DS-Lite tunnel end-point and MUST use a THIRD PARTY
option either empty or carrying the IPv4 internal address
of the mappings.
In the plain mode the PCP discovery ( section 7.1 "General PCP Client:
Generating a Request") is changed into:
if a PCP server is configured (e.g., in a configuration
file or via DHCPv6), that single configuration source is used as
the list of PCP Server(s), else;
use the IPv6 address of the AFTR.
To summarize, the first rule remains the same with the precision
that DHCP is DHCPv6, in the second rule the default router list
is replaced by the AFTR.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on
publication as an RFC.
A DS-Lite PCP deployment could be secure under the Simple
Threat Model described in the Security Considerations of the
base PCP specification, even though the B4 device makes PCP
mapping requests on behalf of internal clients using the
THIRD_PARTY option.
To meet the requirements of the Simple Threat Model the
DS-Lite PCP server MUST be configured to only allow the B4
device to make THIRD_PARTY requests, and only on behalf of
other Internal Hosts sharing the same DS-Lite IPv6 tunnel.
The B4 must ensure that the internal IP address in the
THIRD_PARTY option corresponds to the IP source address in the
IP Header of the PCP request (or proxied UPnP request) that
triggered the THIRD_PARTY request. The B4 device MUST guard
against spoofed packets being injected into the IPv6 tunnel
using the B4 device's IPv4 source address, so the DS-Lite PCP
Server can trust that packets received over the DS-Lite IPv6
tunnel with the B4 device's source IPv4 address do in fact
originate from the B4 device. The B4 device is in a position
to enforce this requirement, because it is the DS-Lite IPv6
tunnel endpoint.
Allowing the B4 device to use the THIRD_PARTY option to create
mappings for hosts reached via the IPv6 tunnel terminated by
the B4 device is acceptable, because the B4 device is capable
of creating these mappings implicitly and can prevent others
from spoofing these mappings.
If the conditions described above cannot be ensured, a
PCP Authentication mechanism must be implemented to meet
the requirements of the Advanced Security Model, as
discussed in the PCP specification.
The plain mode provides a control point inside the home
network where any policy on PCP requests can be applied, e.g.:
restrict the use of THIRD PARTY options to the B4
apply an access-list on internal addresses and/or ports
Therefore, use of the PCP Simple Security model will generally
be acceptable within plain mode implementations.
On the other hand, the encapsulation mode
defaults to being fully transparent for
the B4: PCP requests are blindly encapsulated as any other IPv4
packets to the Internet. This makes it more difficult to apply
policy to PCP requests, and will generally require
implementation of a PCP authentication protocol to meet the
Security Considerations of the base PCP specification.
Reinaldo Penno who checks the validity of the argument
about the relative complexity of the encapsulation mode
at the AFTR side.
Christian Jacquenet and Mohammed Boucadair who proposed
improvements to the document, including the PCP server
discovery by Mohammed.
Sam Hartman for his help with the Security Considerations
text.
The encapsulation mode deals at the B4 side with PCP traffic
as any IPv4 traffic: it is encapsulated to and decapsulated from
the AFTR over the DS-Lite IPv4 over IPv6 tunnel.
At the AFTR side things are a bit more complex because
the PCP server needs the context, here the source IPv6 address,
for both to manage mappings and to send back response.
So the AFTR MUST tag PCP requests with the source IPv6 address
after decapsulation and before forwarding them to the PCP server,
and use the same tag to encapsulate PCP responses to correct B4s.
(the term "tag" is used to describe the private convention between
the AFTR and the PCP server).
We believe most customers will run a PCP proxy on the B4
because:
they want a control point where to apply security
()
they run an InterWorking Function (IWF) for other
protocols ()
on the B4 so the proxy is just part of a bigger system
BTW when the home network has only one node (dual-stack capable
with embedded B4 element) attached, it is the PCP client.
For a PCP proxy to use IPv4 (encapsulation mode) or
IPv6 (plain mode) does not make a sensible difference,
so from an implementation point of view the real difference
is on the PCP server / AFTR side: the encapsulation mode
require an Application Level Gateway (ALG) to tag PCP request
with the corresponding customer after decapsulation,
when the plain mode is fully transparent.