idnits 2.17.1 draft-ietf-pcp-proxy-00.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 (March 29, 2012) is 4411 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 (-29) exists of draft-ietf-pcp-base-24 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-02 == Outdated reference: A later version (-06) exists of draft-boucadair-pcp-failure-02 == Outdated reference: A later version (-10) exists of draft-ietf-pcp-upnp-igd-interworking-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track R. Dupont 5 Expires: September 30, 2012 Internet Systems Consortium 6 R. Penno 7 Juniper Networks 8 D. Wing 9 Cisco 10 March 29, 2012 12 Port Control Protocol (PCP) Proxy Function 13 draft-ietf-pcp-proxy-00 15 Abstract 17 This document specifies the behavior of a PCP Proxy element, for 18 instance embedded in Customer Premise routers. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 30, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. PCP Server Discovery and Provisioning . . . . . . . . . . . . 3 56 3. PCP Proxy as a PCP Server . . . . . . . . . . . . . . . . . . 4 57 4. Control of the Firewall . . . . . . . . . . . . . . . . . . . 4 58 5. Embedded NAT in the CP Router . . . . . . . . . . . . . . . . 4 59 6. Simple PCP Proxy . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Advanced Functions . . . . . . . . . . . . . . . . . . . . . . 7 61 7.1. Multiple PCP Servers . . . . . . . . . . . . . . . . . . . 7 62 7.2. Epoch Handling . . . . . . . . . . . . . . . . . . . . . . 8 63 7.3. Request/Response Caching . . . . . . . . . . . . . . . . . 8 64 7.4. Retransmission Handling . . . . . . . . . . . . . . . . . 9 65 7.5. Full State . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 PCP [I-D.ietf-pcp-base] discusses the implementation of NAT control 76 features that rely upon Carrier Grade NAT (CGN) devices such as DS- 77 Lite AFTR [RFC6333]. 79 The Customer Premise router, the B4 element in DS-Lite, is in charge 80 to enforce some security controls on PCP requests so implements a PCP 81 Proxy function: it acts as a PCP server receiving PCP requests on 82 internal interfaces, and as a PCP client forwarding accepted PCP 83 requests on an external interface to a CGN PCP server. The CGN PCP 84 server in turn send replies (PCP responses) to the PCP Proxy external 85 interface which are finally forwarded to PCP clients. 87 The PCP Proxy can be simple, i.e., implement as transparent/minimal 88 processing as possible, or it can be smart, i.e., handle multiple CGN 89 PCP servers, cache requests/responses, etc. A smart Proxy can be 90 associated with UPnP IGD [I-D.ietf-pcp-upnp-igd-interworking] or/and 91 NAT-PMP [I-D.bpw-pcp-nat-pmp-interworking] Interworking Function 92 (IWF). 94 +------------+ | 95 | PCP Client |-----+ | 96 +--(Host 1)--+ | +-----------+ | +----------+ 97 +---| | | | | 98 | PCP Proxy |-------|PCP Server| 99 +---| | | | | 100 +------------+ | +-----------+ | +----------+ 101 | PCP Client |-----+ | 102 +--(Host 2)--+ possible boundary 103 <- Home side | ISP side -> 105 Figure 1: Reference Architecture 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. PCP Server Discovery and Provisioning 113 The PCP Proxy MUST implement one of the discovery methods listed in 114 [I-D.ietf-pcp-base] (e.g., DHCP [I-D.ietf-pcp-dhcp]). 116 The address of the PCP Proxy is provisioned to local PCP Clients as 117 their default PCP Server: If the PCP DHCP option is supported by an 118 internal PCP Client, it will retrieve the PCP Server IP address to 119 use from its local DHCP server (usually embedded on the CP router); 120 otherwise internal PCP Clients will assume their default router being 121 the PCP Server. 123 3. PCP Proxy as a PCP Server 125 The PCP Proxy acts as a PCP server for internal hosts and accepts PCP 126 requests on the interface(s) facing them, e.g., it creates servicing 127 socket(s) and bound them to each address of this (these) interface(s) 128 on UDP port 44323. 130 When the topology makes a routing loop possible, the PCP Proxy MAY 131 check it is not the source of a PCP message it's received. 133 4. Control of the Firewall 135 A security policy to accept PCP messages from the provisioned PCP 136 Server is to be enabled on the CP router. This policy can be for 137 instance triggered by DHCP configuration or by outbound PCP requests 138 issued from the PCP Proxy to the provisioned PCP Server. 140 In order to accept inbound and outbound traffic associated with PCP 141 mappings instantiated in the upstream PCP Server, appropriate 142 security policies are to be configured on the firewall. 144 For instance if the firewall rules have a lifetime, PCP response can 145 be snooped in order to instantiate the corresponding firewall rules 146 with the same lifetime. If they have no lifetime, an explicit 147 dynamic mapping table can be kept in the PCP Proxy state in order to 148 instantiate and remove corresponding firewall rules. This is in fact 149 an easy subcase of Section 5. 151 REMOTE_PEER_FILTER Options can be installed into the local firewall, 152 forwarded to the PCP Server so installed into the remote NAT/firewall 153 or both. 155 [Ed. Note: should we say the firewall function is already handled 156 by the PCP controlled device so it is useless at the local level?] 158 5. Embedded NAT in the CP Router 160 When no NAT is embedded in the CP router, the port number included in 161 received PCP messages (from the PCP Server or PCP Client(s)) are not 162 altered by the PCP Proxy. 164 [Ed. Note: NAT444 seems to be the only exception?] 166 When the PCP Proxy is co-located with a NAT function in the CP 167 router, it MUST update the content of received requested messages 168 with the mapped port number and the address belonging to the external 169 interface of the CP router (i.e., after the NAT operation) and not as 170 initially positioned by the PCP Client. For the reverse path, PCP 171 response messages MUST be updated by the PCP Proxy to replace the 172 target port number to what has been initially positioned by the PCP 173 Client. For this purpose the PCP Proxy has an access to the local 174 NAT state. Note PCP messages with an unknown OpCode or Option can 175 carry a hidden target address or internal port which will not be 176 translated: 178 o a PCP Proxy co-located with a NAT SHOULD reject by an 179 UNSUPP_OPCODE error response a received request with an unknown 180 OpCode; 182 o a PCP Proxy co-located with a NAT SHOULD reject by an 183 UNSUPP_OPTION error response a received request with a mandatory- 184 to-process unknown Option; 186 o a PCP Proxy co-located with a NAT SHOULD remove any optional-to- 187 process unknown Options from received requests before forwarding 188 them. 190 When a PCP request is received and accepted by the PCP Proxy the 191 corresponding mapping (explicit dynamic mapping for a MAP request, 192 implicit dynamic mapping for a PEER request) is looked for in the 193 local NAT state and temporary created if it does not exist. 194 Temporary means it is deleted if no SUCCESS response is received, 195 either explicitly or because of its short lifetime at creation. 197 If the local NAT associates explicit dynamic mappings to a lifetime, 198 the requested lifetime in MAP requests SHOULD be adjusted to be in 199 the accepted range of the local NAT, and the assigned lifetime copied 200 from MAP responses to the corresponding mapping in the local NAT. 201 The same processing applies to implicit dynamic mappings and PEER 202 requests/responses (but the valid requested lifetime range begins by 203 zero in this case). 205 Otherwise explicit dynamic mappings have an undefined lifetime in the 206 local NAT and the PCP Proxy SHOULD maintain an explicit dynamic 207 mapping table and SHOULD delete corresponding explicit dynamic 208 mappings in the local NAT when they expire or are deleted by the MAP 209 request with a zero requested lifetime. 211 6. Simple PCP Proxy 213 A simple PCP Proxy performs minimal modifications to PCP requests and 214 responses, in particular it does not change the Epoch value in 215 responses. So it does not handle more than one PCP server. 217 The detailed behavior at the reception of a PCP request on an 218 internal interface is as follows: 220 o check if the source IP address and the PCP target address are the 221 same. 223 o apply security controls, including with the result of the previous 224 item. 226 o if the request is rejected, build a synthetic error response and 227 send it back to the PCP client. 229 o if the request is accepted, adjust it (e.g., adding a THIRD_PARTY 230 Option, updating the internal address and port to their translated 231 values as specified in Section 5 and forward it on a fresh UDP 232 socket connected to the PCP server. 234 o Wait for the response during a reasonable delay. 236 o when the response is received from the PCP server, adjust it back 237 (e.g., removing the THIRD_PARTY Option added previously, updating 238 the internal address and port to their initial values as specified 239 in Section 5), forward it to the source PCP client and close the 240 socket to the PCP server. 242 [Ed. Note: is there extra validation useful? The response 243 comes from the PCP server and the PCP client will validated it 244 anyway.] 246 o on a hard error on the UDP socket, build a synthetic ICMP error 247 and send it to the source PCP client. 249 The reasonable delay minimum value is 20 seconds, request 250 retransmission is handled by PCP clients. 252 For each pending request, the proxy MUST maintain in a data record: 254 o the request payload 256 o the interface where the request was received 257 o the source IP address of the request 259 o the source UDP port of the request 261 o the UDP socket connected to the PCP server 263 o an expire timeout 265 Receiving interfaces can be implemented by a set of servicing 266 sockets, each socket bound to an address of an internal interface. 267 Interface, source address and port are used to send back packets to 268 the source PCP client. The request payload is used to generate 269 synthetic ICMP. Responses are received on the UDP socket. 271 There is no (not yet) standardized way to build a synthetic error 272 response, in particular no way to determine which Epoch value to put 273 into it. This is why it is better to build a synthetic ICMP error 274 than a synthetic error response with NETWORK_FAILURE on a socket hard 275 error. 277 Too large requests SHOULD be forwarded to the PCP server in order to 278 relay back the error response, i.e., the PCP Proxy is not in charge 279 to enforce the message size limit and in general the PCP Proxy SHOULD 280 NOT generate error response for a reason other than security 281 controls. No behavior is specified in the case the PCP Proxy 282 processing (e.g., adding a THIRD_PARTY Option) makes a valid request 283 too large when it is sent to the PCP Server. 285 7. Advanced Functions 287 When a simple PCP Proxy uses as global variables only the CGN PCP 288 server IP address, a set of servicing sockets and a list of pending 289 request handlers, a smart PCP Proxy implements more services. 291 Even if most services rely on the Epoch handling one Section 7.2, 292 services are described below in a natural order. 294 7.1. Multiple PCP Servers 296 A smart PCP Proxy MAY offer to handle multiple PCP servers at the 297 same time, each PCP server is associated to each own handled Epoch 298 value according to Section 7.2. 300 The only constraint is to maintain a reasonable coherency as PCP 301 clients cannot be assumed to be prepared to this, i.e., this has to 302 be transparent for / hidden to them. 304 [Ed. Note: we propose to require a partition of clients, clients 305 on the same host or sharing a target address SHOULD be in the same 306 subset, i.e., the same PCP server and the same Epoch.] 308 [Ed. Note: the Proxy can get per PCP server capabilities, for 309 instance from the error responses.] 311 7.2. Epoch Handling 313 With Epoch handling the Epoch value is related to internal timers and 314 not blindly copied from PCP responses. There should be no advantages 315 to have more than one managed Epoch per PCP server. 317 The Epoch MUST be reset when explicit dynamic mappings are lost, 318 i.e.: 320 o at startup if the PCP proxy can't recover the state. 322 [Ed. Note: as it is very optional to manage state in the Proxy 323 it should be the default.] 325 o when the WAN address is changed or any similar events which show 326 any previous state is no longer valid. 328 o when the Epoch value in a PCP response is too small (cf. Epoch 329 value validation rules in [I-D.ietf-pcp-base]). 331 o when the External Address has changed 333 The last two rules are per PCP server, a PCP Proxy MAY check these 334 conditions in all received responses for a PCP server, including when 335 the PCP Proxy is a part of an IWF 336 [I-D.ietf-pcp-upnp-igd-interworking] 337 [I-D.bpw-pcp-nat-pmp-interworking]. 339 7.3. Request/Response Caching 341 A PCP Proxy providing request/response caching checks each time it 342 receives a PCP request if it has already seen the same request 343 recently and got the corresponding PCP response. In this case, it 344 sends back directly the cached response with the proper Epoch value 345 and not forward the request to the PCP server. 347 [Ed. Note: this is an easy optimization, the only difficult point 348 can be solved by the Epoch handling.] 350 7.4. Retransmission Handling 352 An extension of the previous service is to manage the retransmission 353 of pending requests to the server internally, i.e., no longer driven 354 by the PCP client. A cache entry SHOULD be expired after a delay 355 short enough to keep it easy to distinguish it from a replay. 357 [Ed. Note: this allows smart retransmission scheduling as the 358 Proxy "sees" all PCP exchanges with the PCP server.] 360 7.5. Full State 362 A smart PCP Proxy can keep the full state: an image of all active 363 explicit dynamic mappings is kept in memory. This service is not 364 interesting by itself but it can be necessary to support embedded 365 firewall or NAT Section 5 and if the PCP Proxy is integrated in an 366 IWF (e.g., to support UPnP IGD [I-D.ietf-pcp-upnp-igd-interworking]). 368 In conclusion this service MAY be supported. Note when it is 369 supported the state SHOULD be recovered in case of failures according 370 to [I-D.boucadair-pcp-failure]. 372 8. IANA Considerations 374 This document makes no request of IANA. 376 9. Security Considerations 378 The security controls are applied on PCP requests and are about: 380 o authorized target addresses, in particular in case of a third 381 party. 383 o authorized internal and external ports (note the external port is 384 in general assigned by the CGN PCP server). 386 The default policy for requests for a third party when such a policy 387 exists is be to not allow them. The exact rule is: PCP requests 388 including a THIRD_PARTY option enclosing an IP address distinct than 389 the source IP address of the request MUST be rejected (by a 390 NOT_AUTHORIZED error response). 392 When a PCP Proxy is at the boundary of two trust domains (named 393 "internal" and "external" sides), it MUST provide at least these two 394 security controls: 396 o split horizon anti-spoofing: requests from the external side and 397 responses from the internal side MUST be dropped. 399 o a policy about requests on the behalf of a third party MUST be 400 enforced. 402 A PCP Proxy MAY implement only the simple rule about third party: all 403 received requests including a THIRD_PARTY option are rejected. 405 [Ed. Note: this is stricter than the default but keeps the 406 minimal implementation as simple as possible.] 408 A received request carrying an unknown OpCode or Option SHOULD be 409 dropped (or in the case of an unknown Option which is not mandatory- 410 to-process the Option be removed) if it is not a priori compatible 411 with security controls or correct processing. This includes at least 412 all cases where received requests are scanned for elements like the 413 protocol, an address or a port. 415 [Ed. Note: magically a minimal implementation in favorable 416 environments (no embedded NAT!) MAY accept unknown Opcodes and 417 Options. There is no need for a similar rule for responses as the 418 proxy can do nothing with a "bad" response anyway...] 420 10. References 422 10.1. Normative References 424 [I-D.ietf-pcp-base] 425 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 426 Selkirk, "Port Control Protocol (PCP)", 427 draft-ietf-pcp-base-24 (work in progress), March 2012. 429 [I-D.ietf-pcp-dhcp] 430 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 431 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-02 432 (work in progress), January 2012. 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 10.2. Informative References 439 [I-D.boucadair-pcp-failure] 440 Boucadair, M., Dupont, F., and R. Penno, "Port Control 441 Protocol (PCP) Failure Scenarios", 442 draft-boucadair-pcp-failure-02 (work in progress), 443 September 2011. 445 [I-D.bpw-pcp-nat-pmp-interworking] 446 Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port 447 Control Protocol (PCP) NAT-PMP Interworking Function", 448 draft-bpw-pcp-nat-pmp-interworking-00 (work in progress), 449 March 2011. 451 [I-D.ietf-pcp-upnp-igd-interworking] 452 Boucadair, M., Dupont, F., Penno, R., and D. Wing, 453 "Universal Plug and Play (UPnP) Internet Gateway Device 454 (IGD)-Port Control Protocol (PCP) Interworking Function", 455 draft-ietf-pcp-upnp-igd-interworking-01 (work in 456 progress), March 2012. 458 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 459 Stack Lite Broadband Deployments Following IPv4 460 Exhaustion", RFC 6333, August 2011. 462 Authors' Addresses 464 Mohamed Boucadair 465 France Telecom 466 Rennes 35000 467 France 469 Email: mohamed.boucadair@orange.com 471 Francis Dupont 472 Internet Systems Consortium 474 Email: fdupont@isc.org 476 Reinaldo Penno 477 Juniper Networks 478 1194 N Mathilda Avenue 479 Sunnyvale, California 94089 480 USA 482 Email: rpenno@juniper.net 483 Dan Wing 484 Cisco Systems, Inc. 485 170 West Tasman Drive 486 San Jose, California 95134 487 USA 489 Email: dwing@cisco.com