idnits 2.17.1 draft-dupont-pcp-dslite-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2013) is 4014 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-02 == Outdated reference: A later version (-10) exists of draft-ietf-pcp-upnp-igd-interworking-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group F. Dupont 3 Internet-Draft Internet Systems Consortium 4 Intended status: Standards Track T. Tsou 5 Expires: October 25, 2013 Huawei Technologies 6 J. Qin 7 ZTE Corporation 8 M. Wasserman 9 Painless Security 10 D. Zhang 11 Huawei 12 April 23, 2013 14 The Port Control Protocol in Dual-Stack Lite environments 15 draft-dupont-pcp-dslite-05 17 Abstract 19 This document specifies the so-called "plain mode" for the use of the 20 Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite) 21 environments. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 25, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 Dual-Stack Lite (DS-Lite, [RFC6333]) is a technology which enables a 58 broadband service provider to share IPv4 addresses among customers by 59 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and 60 Network Address Translation (NAT). 62 Typically, the home gateway embeds a Basic Bridging BroadBand (B4) 63 capability that encapsulates IPv4 traffic into a IPv6 tunnel to the 64 carrier-grade NAT, named the Address Family Transition Router (AFTR). 65 AFTRs are run by service providers. 67 The Port Control Protocol (PCP, [I-D.ietf-pcp-base] allows customer 68 applications to create mappings in a NAT for new inbound 69 communications destined to machines located behind a NAT. In a DS- 70 Lite environment, PCP servers control AFTR devices. 72 Two different modes of operations have been proposed: the plain and 73 the encapsulation modes. This document recommends use of the plain 74 mode. 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 2. Plain Mode 82 In the plain mode the B4, the customer end-point of the DS-Lite IPv6 83 tunnel, implements a PCP proxy ([I-D.ietf-pcp-proxy]) function and 84 uses UDP over IPv6 with the AFTR to send PCP requests and receive PCP 85 responses. 87 The B4 MUST source PCP requests with the IPv6 address of its DS-Lite 88 tunnel end-point and MUST use a THIRD PARTY option either empty or 89 carrying the IPv4 internal address of the mappings. 91 In the plain mode the PCP discovery ([I-D.ietf-pcp-base] section 7.1 92 "General PCP Client: Generating a Request") is changed into: 94 1. if a PCP server is configured (e.g., in a configuration file or 95 via DHCPv6), that single configuration source is used as the list 96 of PCP Server(s), else; 97 2. use the IPv6 address of the AFTR. 98 To summarize, the first rule remains the same with the precision that 99 DHCP is DHCPv6, in the second rule the default router list is 100 replaced by the AFTR. 102 3. IANA Considerations 104 This document makes no request of IANA. 106 Note to RFC Editor: this section may be removed on publication as an 107 RFC. 109 4. Security Considerations 111 A DS-Lite PCP deployment could be secure under the Simple Threat 112 Model described in the Security Considerations of the base PCP 113 specification, even though the B4 device makes PCP mapping requests 114 on behalf of internal clients using the THIRD_PARTY option. 116 To meet the requirements of the Simple Threat Model the DS-Lite PCP 117 server MUST be configured to only allow the B4 device to make 118 THIRD_PARTY requests, and only on behalf of other Internal Hosts 119 sharing the same DS-Lite IPv6 tunnel. The B4 must ensure that the 120 internal IP address in the THIRD_PARTY option corresponds to the IP 121 source address in the IP Header of the PCP request (or proxied UPnP 122 request) that triggered the THIRD_PARTY request. The B4 device MUST 123 guard against spoofed packets being injected into the IPv6 tunnel 124 using the B4 device's IPv4 source address, so the DS-Lite PCP Server 125 can trust that packets received over the DS-Lite IPv6 tunnel with the 126 B4 device's source IPv4 address do in fact originate from the B4 127 device. The B4 device is in a position to enforce this requirement, 128 because it is the DS-Lite IPv6 tunnel endpoint. 130 Allowing the B4 device to use the THIRD_PARTY option to create 131 mappings for hosts reached via the IPv6 tunnel terminated by the B4 132 device is acceptable, because the B4 device is capable of creating 133 these mappings implicitly and can prevent others from spoofing these 134 mappings. 136 If the conditions described above cannot be ensured, a PCP 137 Authentication mechanism must be implemented to meet the requirements 138 of the Advanced Security Model, as discussed in the PCP 139 specification. 141 The plain mode provides a control point inside the home network where 142 any policy on PCP requests can be applied, e.g.: 143 o restrict the use of THIRD PARTY options to the B4 144 o apply an access-list on internal addresses and/or ports 145 Therefore, use of the PCP Simple Security model will generally be 146 acceptable within plain mode implementations. 148 On the other hand, the encapsulation mode Appendix A defaults to 149 being fully transparent for the B4: PCP requests are blindly 150 encapsulated as any other IPv4 packets to the Internet. This makes 151 it more difficult to apply policy to PCP requests, and will generally 152 require implementation of a PCP authentication protocol to meet the 153 Security Considerations of the base PCP specification. 155 5. Acknowledgments 157 Reinaldo Penno who checks the validity of the argument about the 158 relative complexity of the encapsulation mode at the AFTR side. 160 Christian Jacquenet and Mohammed Boucadair who proposed improvements 161 to the document, including the PCP server discovery by Mohammed. 163 Sam Hartman for his help with the Security Considerations text. 165 6. References 167 6.1. Normative References 169 [I-D.ietf-pcp-base] 170 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 171 Selkirk, "Port Control Protocol (PCP)", 172 draft-ietf-pcp-base-29 (work in progress), November 2012. 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, March 1997. 177 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 178 Stack Lite Broadband Deployments Following IPv4 179 Exhaustion", RFC 6333, August 2011. 181 6.2. Informative References 183 [I-D.ietf-pcp-proxy] 184 Boucadair, M., Penno, R., and D. Wing, "Port Control 185 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-02 186 (work in progress), February 2013. 188 [I-D.ietf-pcp-upnp-igd-interworking] 189 Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 190 Play (UPnP) Internet Gateway Device (IGD)-Port Control 191 Protocol (PCP) Interworking Function", 192 draft-ietf-pcp-upnp-igd-interworking-08 (work in 193 progress), April 2013. 195 Appendix A. Encapsulation Mode 197 The encapsulation mode deals at the B4 side with PCP traffic as any 198 IPv4 traffic: it is encapsulated to and decapsulated from the AFTR 199 over the DS-Lite IPv4 over IPv6 tunnel. 201 At the AFTR side things are a bit more complex because the PCP server 202 needs the context, here the source IPv6 address, for both to manage 203 mappings and to send back response. So the AFTR MUST tag PCP 204 requests with the source IPv6 address after decapsulation and before 205 forwarding them to the PCP server, and use the same tag to 206 encapsulate PCP responses to correct B4s. (the term "tag" is used to 207 describe the private convention between the AFTR and the PCP server). 209 Appendix B. Justification 211 We believe most customers will run a PCP proxy on the B4 because: 212 o they want a control point where to apply security (Section 4) 213 o they run an InterWorking Function (IWF) for other protocols 214 ([I-D.ietf-pcp-upnp-igd-interworking]) on the B4 so the proxy is 215 just part of a bigger system 216 BTW when the home network has only one node (dual-stack capable with 217 embedded B4 element) attached, it is the PCP client. 219 For a PCP proxy to use IPv4 (encapsulation mode) or IPv6 (plain mode) 220 does not make a sensible difference, so from an implementation point 221 of view the real difference is on the PCP server / AFTR side: the 222 encapsulation mode require an Application Level Gateway (ALG) to tag 223 PCP request with the corresponding customer after decapsulation, when 224 the plain mode is fully transparent. 226 Authors' Addresses 228 Francis Dupont 229 Internet Systems Consortium 231 Email: fdupont@isc.org 232 Tina Tsou 233 Huawei Technologies 234 2330 Central Expressway 235 Santa Clara 236 USA 238 Phone: +1-408-330-4424 239 Email: tina.tsou.zouting@huawei.com 241 Jacni Qin 242 ZTE Corporation 243 Shanghai 244 P.R.China 246 Email: jacni@jacni.com 248 Margaret Wasserman 249 Painless Security 250 356 Abbott Street 251 North Andover, MA 01845 252 USA 254 Phone: +1 781 405 7464 255 Email: mrw@painless-security.com 256 URI: http://www.painless-security.com 258 Dacheng Zhang 259 Huawei 260 Beijing, 261 China 263 Phone: 264 Fax: 265 Email: zhangdacheng@huawei.com 266 URI: