idnits 2.17.1 draft-ietf-tsvwg-behave-requirements-update-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 (August 14, 2015) is 3178 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-09 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG R. Penno 3 Internet-Draft Cisco 4 Intended status: Best Current Practice S. Perreault 5 Expires: February 15, 2016 Jive Communications 6 M. Boucadair 7 France Telecom 8 S. Sivakumar 9 Cisco 10 K. Naito 11 NTT 12 August 14, 2015 14 Network Address Translation (NAT) Behavioral Requirements Updates 15 draft-ietf-tsvwg-behave-requirements-update-04 17 Abstract 19 This document clarifies and updates several requirements of RFC4787, 20 RFC5382 and RFC5508 based on operational and development experience. 21 The focus of this document is NAT44. 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 February 15, 2016. 40 Copyright Notice 42 Copyright (c) 2015 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 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. TCP Session Tracking . . . . . . . . . . . . . . . . . . . . 3 61 2.1. TCP Transitory Connection Idle-Timeout . . . . . . . . . 4 62 2.2. TCP RST . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Port Overlapping Behavior . . . . . . . . . . . . . . . . . . 5 64 4. Address Pooling Paired (APP) . . . . . . . . . . . . . . . . 6 65 5. EIF Protocol Independence . . . . . . . . . . . . . . . . . . 6 66 6. EIF Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Outbound Mapping Refresh and Error Packets . . . . . . . 7 68 7. EIM Protocol Independence . . . . . . . . . . . . . . . . . . 7 69 8. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9. Port Randomization . . . . . . . . . . . . . . . . . . . . . 8 71 10. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 8 72 11. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 8 73 12. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 9 74 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 14. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 15.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 15.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 80 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 [RFC4787], [RFC5382] and [RFC5508] greatly advanced NAT 86 interoperability and conformance. But with widespread deployment and 87 evolution of Network Address Translation (NAT) more development and 88 operational experience was acquired some areas of the original 89 documents need further clarification or updates. This document 90 provides such clarifications and updates. 92 1.1. Scope 94 The goal of this document is to clarify and update the set of 95 requirements listed in [RFC4787], [RFC5382] and [RFC5508]. The 96 document focuses exclusively on NAT44. 98 The scope of this document has been set so that it does not create 99 new requirements beyond those specified in the documents cited above. 100 Carrier-Grade NAT (CGN) related requirements are defined in 101 [RFC6888]. 103 1.2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 The reader is assumed to be familiar withe terminology defined in: 110 [RFC2663],[RFC4787],[RFC5382], and [RFC5508]. 112 In this document, the term "NAT" refers to both "Basic NAT" and 113 "Network Address/Port Translator (NAPT)" (see Section 3 of 114 [RFC4787]). As a reminder, Basic NAT and NAPT are two variations of 115 traditional NAT, in that translation in Basic NAT is limited to IP 116 addresses alone, whereas translation in NAPT is extended to include 117 IP address and Transport identifier (such as TCP/UDP port or ICMP 118 query ID) (refer to Section 2 of [RFC3022]). 120 2. TCP Session Tracking 122 [RFC5382] specifies TCP timers associated with various connection 123 states but does not specify the TCP state machine a NAT44 should 124 follow as a basis to apply such timers. 126 Update: The TCP state machine depicted in Figure 1, adapted from 127 [RFC6146], SHOULD be implemented by a NAT for TCP session tracking 128 purposes. 130 +----------------------------+ 131 | | 132 V | 133 +------+ Client | 134 |CLOSED|-----SYN------+ | 135 +------+ | | 136 ^ | | 137 |TCP_TRANS T.O. | | 138 | V | 139 +-------+ +-------+ | 140 | TRANS | | INIT | | 141 +-------+ +-------+ | 142 | ^ | | 143 data pkt | | | 144 | Server/Client RST | | 145 | TCP_EST T.O. | | 146 V | Server SYN | 147 +--------------+ | | 148 | ESTABLISHED |<---------+ | 149 +--------------+ | 150 | | | 151 Client FIN Server FIN | 152 | | | 153 V V | 154 +---------+ +----------+ | 155 | C FIN | | S FIN | | 156 | RCV | | RCV | | 157 +---------+ +----------+ | 158 | | | 159 Server FIN Client FIN TCP_TRANS 160 | | T.O. 161 V V | 162 +----------------------+ | 163 | C FIN + S FIN RCV |-----------------+ 164 +----------------------+ 166 Legend: 167 * Messages sent to (resp. received from) the server 168 are prefixed with "Server". 169 * Messages sent to (resp. received from) the client 170 are prefixed with "Client". 171 * "C" means "Client-side" 172 * "S" means "Server-side". 173 * TCP_EST T.O: refers to the established connection 174 idle timeout as defined in [RFC5382]. 175 * TCP_TRANS T.O: refers to the transitory connection 176 idle timeout as defined in [RFC5382]. 178 Figure 1: State Machine 180 2.1. TCP Transitory Connection Idle-Timeout 182 The transitory connection idle-timeout is defined as the minimum time 183 a TCP connection in the partially open or closing phases must remain 184 idle before the NAT considers the associated session a candidate for 185 removal (REQ-5 of [RFC5382]). But [RFC5382] does not clearly state 186 whether these can be configured separately. 188 Clarification: This document clarifies that a NAT SHOULD provide 189 different configurable parameters for configuring the open and 190 closing idle timeouts. 192 To accommodate deployments that consider a partially open timeout 193 of 4 minutes as being excessive from a security standpoint, a NAT 194 MAY allow to configure the timeout to be less than 4 minutes. 195 Still, this specification recommends the default "transitory 196 connection idle-timeout" minimum value to be set to 4 minutes. 198 2.2. TCP RST 200 [RFC5382] leaves the handling of TCP RST packets unspecified. 202 Update: This document adopts a similar default behavior as in 203 [RFC6146]. Concretely, when the NAT receives a TCP RST matching 204 an existing mapping, it MUST translate the packet according the 205 NAT mapping entry. Moreover, the NAT SHOULD wait for 4 minutes 206 before deleting the session and removing any state associate with 207 it if no packets are received during that 4 minutes timeout. 209 Admittedly, the NAT has to verify whether received TCP RST packets 210 belong to a connection. These verification checks are required to 211 avoid off-path attacks. 213 If the NAT removes immediately the NAT mapping upon receipt of a 214 TCP RST message, stale connections may be maintained by endpoints 215 if the first RST message is lost between the NAT and the 216 recipient. 218 3. Port Overlapping Behavior 220 REQ-1 from [RFC4787] and REQ-1 from [RFC5382] specify a specific port 221 overlapping behavior; that is the external IP address and port can be 222 reused for connections originating from the same internal source IP 223 address and port irrespective of the destination. This is known as 224 endpoint-independent mapping (EIM). 226 Update: This document clarifies that this port overlapping behavior 227 may be extended to connections originating from different internal 228 source IP addresses and ports as long as their destinations are 229 different. 231 The following mechanism MAY be implemented by a NAT: 233 If destination addresses and ports are different for outgoing 234 connections started by local clients, a NAT MAY assign the same 235 external port as the source ports for the connections. The 236 port overlapping mechanism manages mappings between external 237 packets and internal packets by looking at and storing their 238 5-tuple (protocol, source address, source port, destination 239 address, destination port). 241 This enables concurrent use of a single NAT external port for 242 multiple transport sessions, which allows a NAT to successfully 243 process packets in an IP address resource limited network (e.g., 244 deployment with high address space multiplicative factor (refer to 245 Appendix B. of [RFC6269])). 247 4. Address Pooling Paired (APP) 249 The Address Pooling Paired (APP) behavior for a NAT was recommended 250 in REQ-2 from [RFC4787], but the behavior when a public IPv4 runs out 251 of ports was left undefined. 253 Clarification: This document clarifies that if APP is enabled, new 254 sessions from a host that already has a mapping associated with an 255 external IP that ran out of ports SHOULD be dropped. 257 The administrator MAY provide a configurable parameter that allows 258 a NAT to starting using ports from another external IP address 259 when the one that anchored the APP mapping ran out of ports. This 260 is a trade-off between service continuity and APP strict 261 enforcement. (Note, this behavior is sometimes referred as 'soft- 262 APP'.) 264 Update: This behavior SHOULD apply also for TCP. 266 5. EIF Protocol Independence 268 REQ-8 from [RFC4787] and REQ-3 from [RFC5382] do not specify whether 269 EIF mappings are protocol-independent. In other words, if an 270 outbound TCP SYN creates a mapping, it is left undefined whether 271 inbound UDP packets destined to that mapping should be forwarded. 273 Update: This document specifies that EIF mappings SHOULD be 274 protocol-independent in order allow inbound packets for protocols 275 that multiplex TCP and UDP over the same IP address and port 276 through the NAT and also maintain compatibility with stateful 277 NAT64 . The administrator MAY provide a configuration parameter to 278 make it protocol-dependent. The default value of this 279 configuration parameter is to allow for protocol-independent EIF. 281 Applications that can be transported over a variety of transport 282 protocols and/or support transport fall back schemes won't 283 experience connectivity failures as a function of the underlying 284 transport protocol or the filtering mode enabled at the NAT. 286 6. EIF Mapping Refresh 288 The NAT mapping Refresh direction may have a "NAT Inbound refresh 289 behavior" of "True" according to REQ-6 from [RFC4787], but [RFC4787] 290 does not clarify how this behavior applies to EIF mappings. The 291 issue in question is whether inbound packets that match an EIF 292 mapping but do not create a new session due to a security policy 293 should refresh the mapping timer. 295 Clarification: This document clarifies that even when a NAT has an 296 inbound refresh behavior set to 'TRUE', such packets SHOULD NOT 297 refresh the mapping. Otherwise a simple attack of a packet every 298 2 minutes can keep the mapping indefinitely. 300 Update: This behavior SHOULD apply also for TCP. 302 6.1. Outbound Mapping Refresh and Error Packets 304 Update: In the case of NAT outbound refresh behavior there are 305 certain types of packets that should not refresh the mapping even 306 if their direction is outbound. For example, if the mapping is 307 kept alive by ICMP Errors or TCP RST outbound packets sent as 308 response to inbound packets, these SHOULD NOT refresh the mapping. 310 7. EIM Protocol Independence 312 REQ-1 from [RFC4787] and REQ-1 from [RFC5382] do not specify whether 313 EIM are protocol-independent. In other words, if a outbound TCP SYN 314 creates a mapping it is left undefined whether outbound UDP can reuse 315 such mapping and create session. On the other hand, stateful NAT64 316 [RFC6146] clearly specifies three binding information bases (TCP, 317 UDP, ICMP). 319 Update: EIM mappings SHOULD be protocol-dependent. A configuration 320 parameter MAY be provided in order allow protocols that multiplex 321 TCP and UDP over the same source IP address and port number to use 322 a single mapping. 324 8. Port Parity 326 Update: A NAT MAY disable port parity preservation for all dynamic 327 mappings. Nevertheless, A NAT SHOULD support means to explicitly 328 request to preserve port parity (e.g., [I-D.ietf-pcp-port-set]). 330 Note: According to [RFC6887], dynamic mappings are said to be 331 dynamic in the sense that they are created on demand, either 332 implicitly or explicitly: 334 1. Implicit dynamic mappings refer to mappings that are created 335 as a side effect of traffic such as an outgoing TCP SYN or 336 outgoing UDP packet. Implicit dynamic mappings usually have a 337 finite lifetime, though this lifetime is generally not known 338 to the client using them. 340 2. Explicit dynamic mappings refer to mappings that are created 341 as a result, for example, of explicit PCP MAP and PEER 342 requests. Explicit dynamic mappings have a finite lifetime, 343 and this lifetime is communicated to the client. 345 9. Port Randomization 347 Update: A NAT SHOULD follow the recommendations specified in 348 Section 4 of [RFC6056], especially: 350 "A NAPT that does not implement port preservation [RFC4787] 351 [RFC5382] SHOULD obfuscate selection of the ephemeral port of a 352 packet when it is changed during translation of that packet. A 353 NAPT that does implement port preservation SHOULD obfuscate the 354 ephemeral port of a packet only if the port must be changed as 355 a result of the port being already in use for some other 356 session. A NAPT that performs parity preservation and that 357 must change the ephemeral port during translation of a packet 358 SHOULD obfuscate the ephemeral ports. The algorithms described 359 in this document could be easily adapted such that the parity 360 is preserved (i.e., force the lowest order bit of the resulting 361 port number to 0 or 1 according to whether even or odd parity 362 is desired)." 364 10. IP Identification (IP ID) 366 Update: A NAT SHOULD handle the Identification field of translated 367 IPv4 packets as specified in Section 5.3.1 of [RFC6864]. 369 11. ICMP Query Mappings Timeout 371 Section 3.1 of [RFC5508] precises that ICMP Query Mappings are to be 372 maintained by a NAT. However, the specification doesn't discuss 373 Query Mapping timeout values. Section 3.2 of [RFC5508] only 374 discusses ICMP Query Session Timeouts. 376 Update: ICMP Query Mappings MAY be deleted once the last the session 377 using the mapping is deleted. 379 12. Hairpinning Support for ICMP Packets 381 REQ-7 from [RFC5508] specifies that a NAT enforcing 'Basic NAT' must 382 support traversal of hairpinned ICMP Query sessions. 384 Clarification: This implicitly means that address mappings from 385 external address to internal address (similar to Endpoint 386 Independent Filters) must be maintained to allow inbound ICMP 387 Query sessions. If an ICMP Query is received on an external 388 address, a NAT can then translate to an internal IP. 390 REQ-7 from [RFC5508] specifies that all NATs must support the 391 traversal of hairpinned ICMP Error messages. 393 Clarification: This behavior requires a NAT to maintain address 394 mappings from external IP address to internal IP address in 395 addition to the ICMP Query Mappings described in Section 3.1 of 396 [RFC5508]. 398 13. IANA Considerations 400 This document does not require any IANA action. 402 14. Security Considerations 404 NAT behavioral considerations are discussed in [RFC4787], [RFC5382], 405 and [RFC5508]. 407 Because some of the clarifications and updates (e.g., Section 2) are 408 inspired from NAT64, the security considerations discussed in 409 Section 5 of [RFC6146] apply also for this specification. 411 The update in Section 3 allows for an optimized NAT resource usage. 412 In order to avoid service disruption, the NAT MUST invoke this 413 functionality only if packets are to be sen to distinct destination 414 addresses. 416 Some of the updates (e.g., Section 6, Section 9, and Section 11) 417 allow for an increased security compared to [RFC4787], [RFC5382], and 418 [RFC5508]. Particularly: 420 o The updates in Section 6 and Section 11 prevent an illegitimate 421 node to maintain mappings activated in the NAT while these 422 mappings should be cleared. 424 o Port randomization (Section 9) complicates tracking hosts located 425 behind a NAT. 427 Section 4 and Section 12 propose updates that increase the 428 serviceability of a host located behind a NAT. These updates do not 429 introduce any additional security concerns to [RFC4787], [RFC5382], 430 and [RFC5508]. 432 The updates in Section 5 and Section 7 allow for a better NAT 433 transparency from an application standpoint. Hosts which require a 434 restricted filtering behavior should enable security-dedicated 435 features (e.g., ACL) either locally or by soliciting a dedicated 436 security device (e.g., firewall). 438 The update in Section 8 induces security concerns that are specific 439 to the protocol used to interact with the NAT. For example, if PCP 440 is used to explicitly request parity preservation for a given 441 mapping, the security considerations discussed in [RFC6887] should be 442 taken into account. 444 The update in Section 10 may have undesired effects on the 445 performance of the NAT in environments in which fragmentation is 446 massively experienced. Such issue may be used as an attack vector 447 against NATs. 449 15. References 451 15.1. Normative References 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 459 Translation (NAT) Behavioral Requirements for Unicast 460 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 461 2007, . 463 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 464 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 465 RFC 5382, DOI 10.17487/RFC5382, October 2008, 466 . 468 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 469 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 470 DOI 10.17487/RFC5508, April 2009, 471 . 473 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 474 Protocol Port Randomization", BCP 156, RFC 6056, 475 DOI 10.17487/RFC6056, January 2011, 476 . 478 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 479 NAT64: Network Address and Protocol Translation from IPv6 480 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 481 April 2011, . 483 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 484 RFC 6864, DOI 10.17487/RFC6864, February 2013, 485 . 487 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 488 A., and H. Ashida, "Common Requirements for Carrier-Grade 489 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 490 April 2013, . 492 15.2. Informative References 494 [I-D.ietf-pcp-port-set] 495 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 496 T., and S. Perreault, "Port Control Protocol (PCP) 497 Extension for Port Set Allocation", draft-ietf-pcp-port- 498 set-09 (work in progress), May 2015. 500 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 501 Translator (NAT) Terminology and Considerations", 502 RFC 2663, DOI 10.17487/RFC2663, August 1999, 503 . 505 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 506 Address Translator (Traditional NAT)", RFC 3022, 507 DOI 10.17487/RFC3022, January 2001, 508 . 510 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 511 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 512 DOI 10.17487/RFC6269, June 2011, 513 . 515 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 516 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 517 DOI 10.17487/RFC6887, April 2013, 518 . 520 Acknowledgements 522 Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, Lars 523 Eggert, and Gorry Fairhurst for their review and discussion. 525 Contributors 527 The following individual contributed text to the document: 529 Sarat Kamiset, Insieme Networks, United States 531 Authors' Addresses 533 Reinaldo Penno 534 Cisco Systems, Inc. 535 170 West Tasman Drive 536 San Jose, California 95134 537 USA 539 Email: repenno@cisco.com 541 Simon Perreault 542 Jive Communications 543 Canada 545 Email: sperreault@jive.com 547 Mohamed Boucadair 548 France Telecom 549 Rennes 35000 550 France 552 Email: mohamed.boucadair@orange.com 554 Senthil Sivakumar 555 Cisco Systems, Inc. 556 United States 558 Email: ssenthil@cisco.com 559 Kengo Naito 560 NTT 561 Tokyo 562 Japan 564 Email: k.naito@nttv6.jp