idnits 2.17.1 draft-ietf-pcp-proxy-04.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 (July 29, 2013) is 3896 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) == Unused Reference: 'I-D.ietf-pcp-dhcp' is defined on line 460, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-07 == Outdated reference: A later version (-10) exists of draft-ietf-pcp-server-selection-01 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: January 30, 2014 D. Wing 6 Cisco 7 July 29, 2013 9 Port Control Protocol (PCP) Proxy Function 10 draft-ietf-pcp-proxy-04 12 Abstract 14 This document specifies a new PCP functional element denoted as a PCP 15 Proxy. The PCP Proxy relays PCP requests received from PCP clients 16 to upstream PCP server(s). A typical deployment usage of this 17 function is to help establish successful PCP communications for PCP 18 clients that can not be configured with the address of a PCP server 19 located more than one hop away. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 30, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. PCP Server Discovery and Provisioning . . . . . . . . . . . . 3 58 4. PCP Proxy as a PCP Server . . . . . . . . . . . . . . . . . . 3 59 5. Control of the Firewall . . . . . . . . . . . . . . . . . . . 4 60 6. No NAT is Co-located with the PCP Proxy . . . . . . . . . . . 4 61 7. PCP Proxy Co-located with a NAT Function . . . . . . . . . . 4 62 8. MAP/PEER Handling . . . . . . . . . . . . . . . . . . . . . . 6 63 9. Mapping Repair . . . . . . . . . . . . . . . . . . . . . . . 7 64 10. Advanced Functions . . . . . . . . . . . . . . . . . . . . . 8 65 10.1. Multiple PCP Servers . . . . . . . . . . . . . . . . . . 8 66 10.2. Epoch Handling . . . . . . . . . . . . . . . . . . . . . 8 67 10.3. Request/Response Caching . . . . . . . . . . . . . . . . 9 68 10.4. Retransmission Handling . . . . . . . . . . . . . . . . 9 69 10.5. Full State . . . . . . . . . . . . . . . . . . . . . . . 9 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 14.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 This document defines a new PCP [RFC6887] functional element, called 81 PCP Proxy, which is meant to facilitate communication between a PCP 82 client and upstream PCP server(s). The PCP Proxy acts as a PCP 83 server receiving PCP requests on internal interfaces, and as a PCP 84 client forwarding accepted PCP requests on an external interface to a 85 PCP server. The PCP server in turn sends PCP responses to the PCP 86 Proxy external interface which are finally forwarded to PCP clients. 87 A reference architecture is depicted in 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 implements as transparent/minimal processing as possible) or it can 97 support advanced features (see Section 10). A PCP Proxy can be co- 98 located with UPnP IGD [RFC6970]. 100 +----------+ +---------+ +----------+ 101 |PCP client|----------| | | | 102 | (Host 1) | Internal | | | | 103 +----------+ interface| |External | | 104 |PCP Proxy|interface|PCP server| 105 | |---------| | 106 +----------+ | | | | 107 |PCP client|----------| | | | 108 |(Host 2) | Internal | | | | 109 +----------+ interface| | | | 110 +---------+ +----------+ 111 Internal PCP clients 113 Figure 1: Reference Architecture 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 3. PCP Server Discovery and Provisioning 123 The PCP Proxy MUST follow the procedure defined in Section 8.1 of 124 [RFC6887] to discover its PCP server. 126 The address of the PCP Proxy is provisioned to internal PCP clients 127 (see Figure 1) as their default PCP server: if the PCP DHCP option 128 [RFC6887] is supported by an internal PCP client, it will retrieve 129 the PCP server IP address to use from its local DHCP server; 130 otherwise internal PCP clients will assume their default router being 131 the PCP server. 133 4. PCP Proxy as a PCP Server 135 The PCP Proxy acts as a PCP server for internal hosts and accepts PCP 136 requests on the interface(s) facing them. The PCP Proxy SHOULD be 137 configured with the interface(s) on which it acts as a PCP server. 138 Such configuration may be automatic (e.g., the private interfaces of 139 a NAT44 when the PCP Proxy is collocated with a NAT44). 141 When the topology makes a routing loop possible, the PCP Proxy MUST 142 check it is not the source of a PCP message it received. 144 5. Control of the Firewall 146 Security policies can be managed by a firewall co-located with the 147 PCP Proxy. 149 A security policy to accept PCP messages from the provisioned PCP 150 server(s) is to be enabled on the device embedding the PCP Proxy. 151 This policy can be for instance triggered by DHCP configuration or by 152 outbound PCP requests issued from the PCP Proxy to the provisioned 153 PCP server. 155 In order to accept inbound and outbound traffic associated with PCP 156 mappings instantiated in the upstream PCP server, appropriate 157 security policies are to be configured on the firewall. 159 For instance if the firewall rules have a lifetime, PCP responses can 160 be snooped on in order to instantiate the corresponding firewall 161 rules with the same lifetime as the one of those PCP responses. If 162 they have no lifetime, an explicit dynamic mapping table can be kept 163 in the PCP Proxy state in order to instantiate and remove 164 corresponding firewall rules. 166 FILTER Options can be installed into the firewall co-located with the 167 PCP Proxy, forwarded to the PCP server and so installed into the 168 remote PCP-controlled device. 170 6. No NAT is Co-located with the PCP Proxy 172 When no NAT is co-located with the PCP Proxy, the port numbers 173 included in received PCP messages (from the PCP server or PCP 174 client(s)) are not altered by the PCP Proxy. Nevertheless, the PCP 175 client IP Address MUST be changed to the address used by the PCP 176 Proxy to send PCP messages to the next PCP server, and a THIRD_PARTY 177 Option inserted to carry the IP address of the source PCP client. 179 Because no NAT is invoked, there is no reachability failure risk to 180 relay to the PCP server unknown Options and OpCodes that carry an IP 181 address. 183 7. PCP Proxy Co-located with a NAT Function 185 When the PCP Proxy is co-located with a NAT function, it MUST update 186 the content of received requests with the mapped port number and the 187 address belonging to the external interface of the PCP Proxy (i.e., 188 after the NAT operation) and not as initially conveyed by the PCP 189 client. For the reverse path, PCP responses MUST be updated by the 190 PCP Proxy to replace the NAT's external port number assigned to the 191 PCP client with the PCP client's own internal port number. For this 192 purpose the PCP Proxy MUST have access to the local NAT state 193 maintained locally. 195 If the NAT assigns an external IP address which is not the one used 196 by the PCP Proxy to contact its PCP server, the PCP Proxy MUST insert 197 a THIRD_PARTY Option to carry the NAT's external IP address assigned 198 to the PCP client. A typical use case is when the NAT is configured 199 with more than one external IP address. 201 By default, the PCP Proxy MUST relay unknown OpCodes and mandatory- 202 to-process unknown Options. Rejecting unknown Options and OpCodes 203 has the drawback of preventing a PCP client to make use of new 204 capabilities offered by the PCP server but not supported by the PCP 205 Proxy even if no IP address and/or port is included in the Option/ 206 OpCode. 208 Because PCP messages with an unknown OpCode or mandatory-to-process 209 unknown Options can carry a hidden internal address or internal port 210 that will not be translated, a PCP Proxy MUST be configurable to 211 disable relaying unknown OpCodes and mandatory-to-process unknown 212 Options. If the PCP Proxy is configured to disable relaying unknown 213 OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST 214 behave as follows: 216 o a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE 217 error response a received request with an unknown OpCode. 219 o a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPTION 220 error response a received request with a mandatory-to-process 221 unknown Option. 223 When a PCP request is received and accepted by the PCP Proxy the 224 corresponding mapping (explicit dynamic mapping for a MAP request, 225 implicit dynamic mapping for a PEER request) is looked for in the 226 local NAT state and temporarily created if it does not exist. 227 "Temporarily" means it is deleted if no SUCCESS response is received, 228 either explicitly or because of its short lifetime at creation. 230 If the local NAT associates explicit dynamic mappings with a 231 lifetime, the requested lifetime in MAP requests sent to the PCP 232 server SHOULD be adjusted to be in the accepted range of the local 233 NAT, and the assigned lifetime copied from MAP responses to the 234 corresponding mapping in the local NAT. The same processing applies 235 to implicit dynamic mappings and PEER requests/responses. 237 Otherwise explicit dynamic mappings have an undefined lifetime in the 238 local NAT and the PCP Proxy SHOULD maintain an explicit dynamic 239 mapping table and SHOULD delete corresponding explicit dynamic 240 mappings in the local NAT when they expire or are deleted by the MAP 241 request with a zero requested lifetime. 243 8. MAP/PEER Handling 245 A simple PCP Proxy performs minimal modifications to PCP requests and 246 responses. In particular, it does not change the Nonce value in 247 requests and the Epoch value in responses. A simple PCP Proxy is 248 assumed to handle only one PCP server. 250 For handling the THIRD_PARTY option, the PCP Proxy MUST follow the 251 PCP server behavior specified in Section 13.1 of [RFC6887]. 253 The detailed behavior at the reception of a PCP request on an 254 internal interface is as follows: 256 o Check if the source IP address and the PCP client IP Address are 257 the same. If a mismatch is detected, the behavior specified in 258 [RFC6887] must be followed. 260 o Apply security controls (e.g., THIRD_PARTY filtering). 262 o If the request is rejected, build an error response and send it 263 back to the PCP client. The error status code is set to 264 NOT_AUTHORIZED. 266 o If the request is accepted, adjust it (e.g., adding a THIRD_PARTY 267 Option, updating the PCP client IP Address and Internal Port to 268 their translated values as specified in Section 7 and forward it 269 from a fresh UDP port). 271 o Wait for the response during a reasonable delay. The reasonable 272 delay minimum value is 20 seconds. 274 o When the response is received from the PCP server, adjust it back 275 (e.g., removing the THIRD_PARTY Option added previously, updating 276 the PCP client IP Address and Internal Port to their initial 277 values as specified in Section 7), forward it to the source PCP 278 client. 280 o On a hard error on the UDP socket, build an ICMP Destination 281 Unreachable message with code 3 (Destination Port Unreachable) and 282 send it to the source PCP client. 284 For each pending request, the proxy MUST maintain in a data record: 286 o the payload of the request received from the PCP client 287 o the interface where the request was received 289 o the source IP address of the request 291 o the source UDP port of the request 293 o the UDP socket connected to the PCP server 295 o an expire timeout 297 Receiving interfaces can be implemented by a set of servicing 298 sockets, each socket bound to an address of an internal interface. 299 The interface, source address and port are used to send back packets 300 to the source PCP client. The request payload is used to generate an 301 ICMP error message. Responses are received on the UDP socket. 303 The PCP Proxy is in charge to enforce the message size limit as 304 specified in Section 8.2 of [RFC6887]. 306 If the PCP Proxy processing (e.g., adding a THIRD_PARTY Option) makes 307 a request that exceeds 1100 octets, a MALFORMED_REQUEST response is 308 sent to the PCP client. 310 9. Mapping Repair 312 ANNOUNCE requests received from PCP clients are handled locally; as 313 such these requests MUST NOT be relayed to the provisioned PCP 314 server. 316 Upon receipt of an unsolicited ANNOUNCE response from a PCP server, 317 the PCP Proxy proceeds to renew the mappings and checks whether there 318 are changes compared to a local cache if it is maintained by the PCP 319 Proxy. If no change is detected, no unsolicited ANNOUNCE is 320 generated towards PCP clients. If a change is detected, the PCP 321 Proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate 322 PCP clients. If the PCP Proxy does not maintain a local cache for 323 the mappings, unsolicited multicast ANNOUNCE messages are sent to PCP 324 clients. 326 Unsolicited PCP MAP/PEER responses received from a PCP server are 327 handled as any normal MAP/PEER response. To handle unsolicited PCP 328 MAP/PEER responses, the PCP Proxy is required to maintain a local 329 cache of instantiated mappings in the PCP server (Section 10.5). 331 Upon change of its external IP address, the PCP Proxy SHOULD renew 332 the mappings it maintained. If the PCP server assigns a different 333 external port, the PCP Proxy SHOULD follow the mapping repair 334 procedure defined in [RFC6887]. This can be achieved only if a full 335 state table is maintained by the PCP Proxy. 337 10. Advanced Functions 339 Below are listed a set of advanced features that MAY be supported by 340 the PCP Proxy. 342 10.1. Multiple PCP Servers 344 A PCP Proxy MAY handle multiple PCP servers at the same time. Each 345 PCP server is associated with its own handled Epoch value according 346 to Section 10.2. PCP clients are not aware of the presence of 347 multiple PCP servers. 349 According to [I-D.ietf-pcp-server-selection], if several PCP Names 350 are configured to the PCP Proxy, it will contact in parallel all 351 these PCP servers. 353 In some contexts (e.g., PCP-controlled CGNs), the PCP Proxy MAY load 354 balance the PCP clients among available PCP servers. The PCP Proxy 355 MUST ensure requests of a given PCP client are relayed to the same 356 PCP server. 358 The PCP Proxy MAY rely on some fields (e.g., Zone ID 359 [I-D.penno-pcp-zones]) in the PCP request to redirect the request to 360 a given PCP server. 362 10.2. Epoch Handling 364 A PCP Proxy MAY use its own internal timers and not blindly copy them 365 from PCP responses. There should be no advantages to have more than 366 one managed Epoch per PCP server. 368 The Epoch MUST be reset when explicit dynamic mappings are lost, 369 i.e.: 371 o at startup if the PCP Proxy can't recover the state. 373 o when the proxy's external address is changed or any similar events 374 that show any previous state is no longer valid. 376 o when the Epoch value in a PCP response is too small (cf. Epoch 377 value validation rules in [RFC6887]). 379 o when the PCP server's External IP Address has changed. 381 The last two rules are per PCP server, a PCP Proxy MAY check these 382 conditions in all received responses for a PCP server. 384 10.3. Request/Response Caching 386 A PCP Proxy providing request/response caching checks each time it 387 receives a PCP request if it has already seen the same request 388 recently (e.g., last 30 minutes) and got the corresponding PCP 389 response. In this case, it sends back directly the cached response 390 with the proper Epoch value and does not forward the request to the 391 PCP server. 393 10.4. Retransmission Handling 395 An extension of the previous feature is to manage the retransmission 396 of pending requests to the PCP server internally, i.e., no longer 397 driven by the PCP client. In such case, the PCP Proxy follows the 398 retransmission procedure defined in Section 8.1.1 of [RFC6887]. 400 10.5. Full State 402 A PCP Proxy MAY keep the full state, i.e., an image of all active 403 explicit dynamic mappings is kept in memory. When this service is 404 supported the state SHOULD be recovered in case of failures inducing 405 state loss (e.g., according to [I-D.boucadair-pcp-failure]). 407 11. IANA Considerations 409 This document makes no request of IANA. 411 12. Security Considerations 413 The PCP Proxy MUST follow the security considerations elaborated in 414 [RFC6887] for both the client and server side. 416 Section 6 and Section 7 specifies cases where a THIRD_PARTY option is 417 inserted the PCP Proxy. As such, means to prevent a malicious user 418 from creating mappings on behalf of a third party must be enabled as 419 discussed in Section 13.1 of [RFC6887]. In particular, THIRD_PARTY 420 option MUST NOT be enabled unless the network on which the PCP 421 messages are to be sent is fully trusted. For example if access 422 control lists (ACLs) are installed on the PCP Proxy, PCP server, and 423 the network between them, so those ACLs allow only communications 424 from a trusted PCP Proxy to the PCP server. 426 A received request carrying an unknown OpCode or Option SHOULD be 427 dropped (or in the case of an unknown Option which is not mandatory- 428 to-process the Option be removed) if it is not compatible with 429 security controls provisionned to the PCP Proxy. 431 The device embedding the PCP Proxy MAY block PCP requests directly 432 sent to the PCP server. This can be enforced using access control 433 lists. 435 13. Acknowledgements 437 Many thanks to C. Zhou, T. Reddy, and D. Thaler for their review and 438 comments. 440 Special thanks to F. Dupont who contributed to this document. 442 14. References 444 14.1. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 450 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 451 2013. 453 14.2. Informative References 455 [I-D.boucadair-pcp-failure] 456 Boucadair, M. and R. Penno, "Analysis of Port Control 457 Protocol (PCP) Failure Scenarios", draft-boucadair-pcp- 458 failure-06 (work in progress), May 2013. 460 [I-D.ietf-pcp-dhcp] 461 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 462 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-07 463 (work in progress), March 2013. 465 [I-D.ietf-pcp-server-selection] 466 Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 467 Reddy, "PCP Server Selection", draft-ietf-pcp-server- 468 selection-01 (work in progress), May 2013. 470 [I-D.penno-pcp-zones] 471 Penno, R., "PCP Support for Multi-Zone Environments", 472 draft-penno-pcp-zones-01 (work in progress), October 2011. 474 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 475 Play (UPnP) Internet Gateway Device - Port Control 476 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 477 July 2013. 479 Authors' Addresses 481 Mohamed Boucadair 482 France Telecom 483 Rennes 35000 484 France 486 Email: mohamed.boucadair@orange.com 488 Reinaldo Penno 489 Cisco 490 USA 492 Email: repenno@cisco.com 494 Dan Wing 495 Cisco Systems, Inc. 496 170 West Tasman Drive 497 San Jose, California 95134 498 USA 500 Email: dwing@cisco.com