idnits 2.17.1 draft-ietf-pcp-proxy-02.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 (February 13, 2013) is 4089 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 (-06) exists of draft-boucadair-pcp-failure-04 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-05 == Outdated reference: A later version (-10) exists of draft-ietf-pcp-upnp-igd-interworking-06 Summary: 0 errors (**), 0 flaws (~~), 4 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. Penno 5 Expires: August 17, 2013 D. Wing 6 Cisco 7 February 13, 2013 9 Port Control Protocol (PCP) Proxy Function 10 draft-ietf-pcp-proxy-02 12 Abstract 14 This document specifies a new PCP functional element denoted as PCP 15 Proxy. The PCP Proxy relays PCP requests received from PCP Clients 16 to upstream PCP Server(s). This function is mandatory when PCP 17 Clients can not be configured with the address of the PCP Server 18 located more than one hop. 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 August 17, 2013. 37 Copyright Notice 39 Copyright (c) 2013 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. PCP Server Discovery and Provisioning . . . . . . . . . . . . 4 57 4. PCP Proxy as a PCP Server . . . . . . . . . . . . . . . . . . 4 58 5. Control of the Firewall . . . . . . . . . . . . . . . . . . . 4 59 6. No NAT is Co-located with the PCP Proxy . . . . . . . . . . . 4 60 7. PCP Proxy Co-located with a NAT Function . . . . . . . . . . . 5 61 8. MAP/PEER Handling . . . . . . . . . . . . . . . . . . . . . . 6 62 9. Mapping Repair . . . . . . . . . . . . . . . . . . . . . . . . 7 63 10. Advanced Functions . . . . . . . . . . . . . . . . . . . . . . 8 64 10.1. Multiple PCP Servers . . . . . . . . . . . . . . . . . . 8 65 10.2. Epoch Handling . . . . . . . . . . . . . . . . . . . . . 8 66 10.3. Request/Response Caching . . . . . . . . . . . . . . . . 9 67 10.4. Retransmission Handling . . . . . . . . . . . . . . . . . 9 68 10.5. Full State . . . . . . . . . . . . . . . . . . . . . . . 9 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 14.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 This document defines a new PCP [I-D.ietf-pcp-base] function element, 80 called PCP Proxy, which is meant to facilitate the communication 81 between a PCP Client and upstream PCP Server(s). The PCP Proxy acts 82 as a PCP Server receiving PCP requests on internal interfaces, and as 83 a PCP Client forwarding accepted PCP requests on an external 84 interface to a PCP Server. The PCP Server in turn sends PCP 85 responses to the PCP Proxy external interface which are finally 86 forwarded to PCP Clients. A reference architecture is depicted in 87 Figure 1. 89 A PCP Proxy can be for instance embedded in a CP (Customer Premises) 90 router while the PCP Server is located in a network operated by an 91 ISP (Internet Service Provider). It is out of scope of this document 92 to list all deployment scenarios requiring a PCP Proxy to be 93 involved. 95 The PCP Proxy can be simple (i.e., a single-homed entity which 96 implement as transparent/minimal processing as possible) or it can 97 support advanced features (see Section 10). A Proxy can be co- 98 located with UPnP IGD [I-D.ietf-pcp-upnp-igd-interworking] or/and 99 NAT-PMP [I-D.bpw-pcp-nat-pmp-interworking] Interworking Function 100 (IWF). 102 +------------+ 103 | PCP Client |-----+ 104 +--(Host 1)--+ | +-----------+ +----------+ 105 +---| | | | 106 | PCP Proxy |-------|PCP Server| 107 +---| | | | 108 +------------+ | +-----------+ +----------+ 109 | PCP Client |-----+ 110 +--(Host 2)--+ 112 Internal PCP Clients 114 Figure 1: Reference Architecture 116 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 3. PCP Server Discovery and Provisioning 124 The PCP Proxy MUST follow the procedure defined in Section 8.1 of 125 [I-D.ietf-pcp-base] to discover its PCP Server. 127 The address of the PCP Proxy is provisioned to internal PCP Clients 128 (see Figure 1) as their default PCP Server: If the PCP DHCP option 129 [I-D.ietf-pcp-dhcp] is supported by an internal PCP Client, it will 130 retrieve the PCP Server IP address to use from its local DHCP server; 131 otherwise internal PCP Clients will assume their default router being 132 the PCP Server. 134 4. PCP Proxy as a PCP Server 136 The PCP Proxy acts as a PCP Server for internal hosts and accepts PCP 137 requests on the interface(s) facing them. 139 When the topology makes a routing loop possible, the PCP Proxy MAY 140 check it is not the source of a PCP message it received. 142 5. Control of the Firewall 144 A security policy to accept PCP messages from the provisioned PCP 145 Server(s) is to be enabled on the device embedding the PCP Proxy. 146 This policy can be for instance triggered by DHCP configuration or by 147 outbound PCP requests issued from the PCP Proxy to the provisioned 148 PCP Server. 150 In order to accept inbound and outbound traffic associated with PCP 151 mappings instantiated in the upstream PCP Server, appropriate 152 security policies are to be configured on the firewall. 154 For instance if the firewall rules have a lifetime, PCP response can 155 be snooped in order to instantiate the corresponding firewall rules 156 with the same lifetime. If they have no lifetime, an explicit 157 dynamic mapping table can be kept in the PCP Proxy state in order to 158 instantiate and remove corresponding firewall rules. 160 FILTER Options can be installed into the local firewall, forwarded to 161 the PCP Server so installed into the remote NAT/firewall or both. 163 6. No NAT is Co-located with the PCP Proxy 165 When no NAT is co-located with the PCP Proxy, the port numbers 166 included in received PCP messages (from the PCP Server or PCP 167 Client(s)) are not altered by the PCP Proxy. Nevertheless, the PCP 168 Client IP Address MUST be changed to the address of the PCP Proxy and 169 a THIRD_PARTY Option inserted to carry the IP address of the source 170 PCP Client. 172 Because no NAT is invoked, there is no reachability failure risk to 173 relay to the PCP Server unknown Options and OpCodes which carry an IP 174 address. 176 7. PCP Proxy Co-located with a NAT Function 178 When the PCP Proxy is co-located with a NAT function, it MUST update 179 the content of received requests with the mapped port number and the 180 address belonging to the external interface of the PCP Proxy (i.e., 181 after the NAT operation) and not as initially positioned by the PCP 182 Client. For the reverse path, PCP responses MUST be updated by the 183 PCP Proxy to replace the internal port number to what has been 184 initially positioned by the PCP Client. For this purpose the PCP 185 Proxy MUST have an access to the local NAT state maintained locally. 186 Because PCP messages with an unknown OpCode or Option can carry a 187 hidden internal address or internal port which will not be 188 translated: 190 o a PCP Proxy co-located with a NAT SHOULD reject by an 191 UNSUPP_OPCODE error response a received request with an unknown 192 OpCode; 194 o a PCP Proxy co-located with a NAT SHOULD reject by an 195 UNSUPP_OPTION error response a received request with a mandatory- 196 to-process unknown Option; 198 o a PCP Proxy co-located with a NAT MAY remove any optional-to- 199 process unknown Options from received requests before forwarding 200 them. 202 Rejecting unknown Options and OpCodes has the drawback of preventing 203 a PCP Client to make use of new capabilities offered by the PCP 204 Server but not supported by the PCP Proxy even if no IP address 205 and/or port is included in the Option/OpCode. 207 When a PCP request is received and accepted by the PCP Proxy the 208 corresponding mapping (explicit dynamic mapping for a MAP request, 209 implicit dynamic mapping for a PEER request) is looked for in the 210 local NAT state and temporary created if it does not exist. 211 "Temporary" means it is deleted if no SUCCESS response is received, 212 either explicitly or because of its short lifetime at creation. 214 If the local NAT associates explicit dynamic mappings to a lifetime, 215 the requested lifetime in MAP requests SHOULD be adjusted to be in 216 the accepted range of the local NAT, and the assigned lifetime copied 217 from MAP responses to the corresponding mapping in the local NAT. 218 The same processing applies to implicit dynamic mappings and PEER 219 requests/responses. 221 Otherwise explicit dynamic mappings have an undefined lifetime in the 222 local NAT and the PCP Proxy SHOULD maintain an explicit dynamic 223 mapping table and SHOULD delete corresponding explicit dynamic 224 mappings in the local NAT when they expire or are deleted by the MAP 225 request with a zero requested lifetime. 227 8. MAP/PEER Handling 229 A simple PCP Proxy performs minimal modifications to PCP requests and 230 responses, in particular it does not change the Nonce value in 231 requests and the Epoch value in responses. A simple PCP Proxy is 232 assumed to handle only one PCP Server. 234 For handling THIRD_PARTY option, the PCP Proxy MUST follow the PCP 235 Server behavior specified in Section 13.1 of [I-D.ietf-pcp-base]. 237 The detailed behavior at the reception of a PCP request on an 238 internal interface is as follows: 240 o Check if the source IP address and the PCP Client IP Address are 241 the same. 243 o Apply security controls (e.g., THIRD_PARTY filtering). 245 o If the request is rejected, build a synthetic error response and 246 send it back to the PCP Client. 248 o If the request is accepted, adjust it (e.g., adding a THIRD_PARTY 249 Option, updating the PCP Client IP Address and Internal Port to 250 their translated values as specified in Section 7 and forward it 251 on a fresh UDP socket connected to the PCP Server). 253 o Wait for the response during a reasonable delay. 255 o When the response is received from the PCP Server, adjust it back 256 (e.g., removing the THIRD_PARTY Option added previously, updating 257 the PCP Client IP Address and Internal Port to their initial 258 values as specified in Section 7), forward it to the source PCP 259 Client and close the socket to the PCP Server. 261 o On a hard error on the UDP socket, build a synthetic ICMP error 262 and send it to the source PCP Client. 264 The reasonable delay minimum value is 20 seconds, request 265 retransmission is handled by PCP clients. 267 For each pending request, the proxy MUST maintain in a data record: 269 o the request payload 271 o the interface where the request was received 273 o the source IP address of the request 275 o the source UDP port of the request 277 o the UDP socket connected to the PCP server 279 o an expire timeout 281 Receiving interfaces can be implemented by a set of servicing 282 sockets, each socket bound to an address of an internal interface. 283 Interface, source address and port are used to send back packets to 284 the source PCP Client. The request payload is used to generate 285 synthetic ICMP. Responses are received on the UDP socket. 287 Too large requests SHOULD be forwarded to the PCP Server in order to 288 relay back the error response, i.e., the PCP Proxy is not in charge 289 to enforce the message size limit and in general the PCP Proxy SHOULD 290 NOT generate error response for a reason other than security 291 controls. No behavior is specified in the case the PCP Proxy 292 processing (e.g., adding a THIRD_PARTY Option) makes a valid request 293 too large when it is sent to the PCP Server. 295 9. Mapping Repair 297 ANNOUNCE requests received from PCP Clients are handled locally; as 298 such these requests MUST NOT be relayed to the provisioned PCP 299 Server. 301 Upon receipt of an unsolicited ANNOUNCE response from a PCP Server, 302 the PCP Proxy proceeds to renewing the mappings and checks whether 303 there are changes compared to a local cache if it is maintained by 304 the PCP Proxy. If no change is detected, no unsolicited ANNOUNCE is 305 generated towards PCP Clients. If a change is detected, the PCP 306 Proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate 307 PCP Clients. If the PCP Proxy does not maintain a local cache for 308 the mappings, unsolicited ANNOUNCE messages are relayed to PCP 309 Clients. 311 Unsolicited PCP MAP/PEER responses received from a PCP Server are 312 handled as any normal MAP/PEER response. To handle unsolicited PCP 313 MAP/PEER responses, the PCP Proxy is required to maintain a local 314 cache of instantiated mappings in the PCP Server (Section 10.5). 316 Upon change of its external IP address, the PCP Proxy SHOULD renew 317 the mappings it maintained. If the PCP Server assigns a different 318 external port, the PCP Proxy SHOULD follow the mapping repair 319 procedure defined in [I-D.ietf-pcp-base]. This can be achieved only 320 if a full state table is maintained by the PCP Proxy. 322 10. Advanced Functions 324 Below are listed a set of advanced features which may be supported by 325 the PCP Proxy. 327 10.1. Multiple PCP Servers 329 A PCP Proxy MAY handle multiple PCP Servers at the same time, each 330 PCP Server is associated to each own handled Epoch value according to 331 Section 10.2. PCP Clients are not aware of the presence of multiple 332 PCP Servers. 334 According to [I-D.ietf-pcp-dhcp], if several PCP Names are configured 335 to the PCP Proxy, it will contact in parallel all these PCP Servers. 337 In some contexts (e.g., PCP-controlled CGNs), the PCP Proxy MAY load 338 balance the PCP Client among available PCP Servers. The PCP Proxy 339 MUST ensure requests of a given PCP Client are relayed to the same 340 PCP Server. 342 In other deployment scenarios (e.g., presence of multiple PCP- 343 controlled firewalls), the PCP Proxy MUST relay PCP requests to all 344 these PCP Servers. 346 The PCP Proxy MAY rely on some fields (e.g., Zone ID 347 [I-D.penno-pcp-zones]) in the PCP request to redirect the request to 348 a given PCP Server. 350 10.2. Epoch Handling 352 A PCP Proxy MAY use its own internal timers and not blindly copy them 353 from PCP responses. There should be no advantages to have more than 354 one managed Epoch per PCP Server. 356 The Epoch MUST be reset when explicit dynamic mappings are lost, 357 i.e.: 359 o at startup if the PCP Proxy can't recover the state. 361 o when the WAN address is changed or any similar events which show 362 any previous state is no longer valid. 364 o when the Epoch value in a PCP response is too small (cf. Epoch 365 value validation rules in [I-D.ietf-pcp-base]). 367 o when the External IP Address has changed. 369 The last two rules are per PCP Server, a PCP Proxy MAY check these 370 conditions in all received responses for a PCP Server. 372 10.3. Request/Response Caching 374 A PCP Proxy providing request/response caching checks each time it 375 receives a PCP request if it has already seen the same request 376 recently and got the corresponding PCP response. In this case, it 377 sends back directly the cached response with the proper Epoch value 378 and not forward the request to the PCP Server. 380 10.4. Retransmission Handling 382 An extension of the previous service is to manage the retransmission 383 of pending requests to the PCP Server internally, i.e., no longer 384 driven by the PCP Client. A cache entry SHOULD be expired after a 385 delay short enough to keep it easy to distinguish it from a replay. 387 10.5. Full State 389 A PCP Proxy MAY keep the full state, i.e., an image of all active 390 explicit dynamic mappings is kept in memory. When this service is 391 supported the state SHOULD be recovered in case of failures (e.g., 392 according to [I-D.boucadair-pcp-failure]). 394 11. IANA Considerations 396 This document makes no request of IANA. 398 12. Security Considerations 400 The PCP Proxy MUST follow the security considerations elaborated in 401 [I-D.ietf-pcp-base] for both the client and server side. 403 A received request carrying an unknown OpCode or Option SHOULD be 404 dropped (or in the case of an unknown Option which is not mandatory- 405 to-process the Option be removed) if it is not a priori compatible 406 with security controls or correct processing. 408 The device embedding the PCP Proxy MAY block PCP requests directly 409 sent to the PCP Server. This can be enforced using access control 410 lists (ACLs). 412 13. Acknowledgements 414 Many thanks to C. Zhou and T. Reddy for their review and comments. 416 Special thanks to F. Dupont who contributed to this document. 418 14. References 420 14.1. Normative References 422 [I-D.ietf-pcp-base] 423 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 424 Selkirk, "Port Control Protocol (PCP)", 425 draft-ietf-pcp-base-29 (work in progress), November 2012. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 14.2. Informative References 432 [I-D.boucadair-pcp-failure] 433 Boucadair, M., Dupont, F., and R. Penno, "Port Control 434 Protocol (PCP) Failure Scenarios", 435 draft-boucadair-pcp-failure-04 (work in progress), 436 August 2012. 438 [I-D.bpw-pcp-nat-pmp-interworking] 439 Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port 440 Control Protocol (PCP) NAT-PMP Interworking Function", 441 draft-bpw-pcp-nat-pmp-interworking-00 (work in progress), 442 March 2011. 444 [I-D.ietf-pcp-dhcp] 445 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 446 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-05 447 (work in progress), September 2012. 449 [I-D.ietf-pcp-upnp-igd-interworking] 450 Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 451 Play (UPnP) Internet Gateway Device (IGD)-Port Control 452 Protocol (PCP) Interworking Function", 453 draft-ietf-pcp-upnp-igd-interworking-06 (work in 454 progress), December 2012. 456 [I-D.penno-pcp-zones] 457 Penno, R., "PCP Support for Multi-Zone Environments", 458 draft-penno-pcp-zones-01 (work in progress), October 2011. 460 Authors' Addresses 462 Mohamed Boucadair 463 France Telecom 464 Rennes 35000 465 France 467 Email: mohamed.boucadair@orange.com 469 Reinaldo Penno 470 Cisco 471 USA 473 Email: repenno@cisco.com 475 Dan Wing 476 Cisco Systems, Inc. 477 170 West Tasman Drive 478 San Jose, California 95134 479 USA 481 Email: dwing@cisco.com