Internet DRAFT - draft-ietf-pcp-dslite
draft-ietf-pcp-dslite
PCP Working Group F. Dupont
Internet-Draft Internet Systems Consortium
Intended status: Standards Track T. Tsou
Expires: December 15, 2013 Huawei Technologies
J. Qin
ZTE Corporation
M. Wasserman
Painless Security
D. Zhang
Huawei
June 13, 2013
The Port Control Protocol in Dual-Stack Lite environments
draft-ietf-pcp-dslite-00
Abstract
This document specifies the so-called "plain mode" for the use of the
Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite)
environments.
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 December 15, 2013.
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
Dupont, et al. Expires December 15, 2013 [Page 1]
Internet-Draft PCP DS-Lite June 2013
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.
1. Introduction
Dual-Stack Lite (DS-Lite, [RFC6333]) 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, [RFC6887] 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 [RFC2119].
2. Plain Mode
In the plain mode the B4, the customer end-point of the DS-Lite IPv6
tunnel, implements a PCP proxy ([I-D.ietf-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 ([RFC6887] section 8.1 "General
PCP Client: Generating a Request") is changed into:
Dupont, et al. Expires December 15, 2013 [Page 2]
Internet-Draft PCP DS-Lite June 2013
1. 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;
2. 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.
3. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
4. Security Considerations
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.
Dupont, et al. Expires December 15, 2013 [Page 3]
Internet-Draft PCP DS-Lite June 2013
The plain mode provides a control point inside the home network where
any policy on PCP requests can be applied, e.g.:
o restrict the use of THIRD PARTY options to the B4
o 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 Appendix A 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.
5. Acknowledgments
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.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887,
April 2013.
6.2. Informative References
[I-D.ietf-pcp-proxy]
Boucadair, M., Penno, R., and D. Wing, "Port Control
Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-02
(work in progress), February 2013.
Dupont, et al. Expires December 15, 2013 [Page 4]
Internet-Draft PCP DS-Lite June 2013
[I-D.ietf-pcp-upnp-igd-interworking]
Boucadair, M., Penno, R., and D. Wing, "Universal Plug and
Play (UPnP) Internet Gateway Device (IGD)-Port Control
Protocol (PCP) Interworking Function",
draft-ietf-pcp-upnp-igd-interworking-10 (work in
progress), April 2013.
Appendix A. Encapsulation Mode
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).
Appendix B. Justification
We believe most customers will run a PCP proxy on the B4 because:
o they want a control point where to apply security (Section 4)
o they run an InterWorking Function (IWF) for other protocols
([I-D.ietf-pcp-upnp-igd-interworking]) 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.
Authors' Addresses
Francis Dupont
Internet Systems Consortium
Email: fdupont@isc.org
Dupont, et al. Expires December 15, 2013 [Page 5]
Internet-Draft PCP DS-Lite June 2013
Tina Tsou
Huawei Technologies
2330 Central Expressway
Santa Clara
USA
Phone: +1-408-330-4424
Email: tina.tsou.zouting@huawei.com
Jacni Qin
ZTE Corporation
Shanghai
P.R.China
Email: jacni@jacni.com
Margaret Wasserman
Painless Security
356 Abbott Street
North Andover, MA 01845
USA
Phone: +1 781 405 7464
Email: mrw@painless-security.com
URI: http://www.painless-security.com
Dacheng Zhang
Huawei
Beijing,
China
Phone:
Fax:
Email: zhangdacheng@huawei.com
URI:
Dupont, et al. Expires December 15, 2013 [Page 6]