idnits 2.17.1 draft-ietf-tsvwg-behave-requirements-update-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 (August 12, 2015) is 3172 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 13, 2016 Jive Communications 6 S. Kamiset 7 Insieme Networks 8 M. Boucadair 9 France Telecom 10 K. Naito 11 NTT 12 August 12, 2015 14 Network Address Translation (NAT) Behavioral Requirements Updates 15 draft-ietf-tsvwg-behave-requirements-update-02 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 13, 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 16.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 16.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 [RFC4787], [RFC5382] and [RFC5508] greatly advanced NAT 85 interoperability and conformance. But with widespread deployment and 86 evolution of Network Address Translation (NAT) more development and 87 operational experience was acquired some areas of the original 88 documents need further clarification or updates. This document 89 provides such clarifications and updates. 91 1.1. Scope 93 The goal of this document is to clarify and update the set of 94 requirements listed in [RFC4787], [RFC5382] and [RFC5508]. The 95 document focuses exclusively on NAT44. 97 The scope of this document has been set so that it does not create 98 new requirements beyond those specified in the documents cited above. 99 Carrier-Grade NAT (CGN) related requirements are defined in 100 [RFC6888]. 102 1.2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 The reader is assumed to be familiar withe terminology defined in: 109 [RFC2663],[RFC4787],[RFC5382], and [RFC5508]. 111 In this document, the term "NAT" refers to both "Basic NAT" and 112 "Network Address/Port Translator (NAPT)" (see Section 3 of 113 [RFC4787]). As a reminder, Basic NAT and NAPT are two variations of 114 traditional NAT, in that translation in Basic NAT is limited to IP 115 addresses alone, whereas translation in NAPT is extended to include 116 IP address and Transport identifier (such as TCP/UDP port or ICMP 117 query ID) (refer to Section 2 of [RFC3022]). 119 2. TCP Session Tracking 121 [RFC5382] specifies TCP timers associated with various connection 122 states but does not specify the TCP state machine a NAT44 should 123 follow as a basis to apply such timers. 125 Update: The TCP state machine depicted in Figure 1, adapted from 126 [RFC6146], SHOULD be implemented by a NAT for TCP session tracking 127 purposes. 129 +----------------------------+ 130 | | 131 V | 132 +------+ Client | 133 |CLOSED|-----SYN------+ | 134 +------+ | | 135 ^ | | 136 |TCP_TRANS T.O. | | 137 | V | 138 +-------+ +-------+ | 139 | TRANS | | INIT | | 140 +-------+ +-------+ | 141 | ^ | | 142 data pkt | | | 143 | Server/Client RST | | 144 | TCP_EST T.O. | | 145 V | Server SYN | 146 +--------------+ | | 147 | ESTABLISHED |<---------+ | 148 +--------------+ | 149 | | | 150 Client FIN Server FIN | 151 | | | 152 V V | 153 +---------+ +----------+ | 154 | C FIN | | S FIN | | 155 | RCV | | RCV | | 156 +---------+ +----------+ | 157 | | | 158 Server FIN Client FIN TCP_TRANS 159 | | T.O. 160 V V | 161 +----------------------+ | 162 | C FIN + S FIN RCV |-----------------+ 163 +----------------------+ 165 Legend: 166 * Messages sent to (resp. received from) the server 167 are prefixed with "Server". 168 * Messages sent to (resp. received from) the client 169 are prefixed with "Client". 170 * "C" means "Client-side" 171 * "S" means "Server-side". 172 * TCP_EST T.O: refers to the established connection 173 idle timeout as defined in [RFC5382]. 174 * TCP_TRANS T.O: refers to the transitory connection 175 idle timeout as defined in [RFC5382]. 177 Figure 1: State Machine 179 2.1. TCP Transitory Connection Idle-Timeout 181 The transitory connection idle-timeout is defined as the minimum time 182 a TCP connection in the partially open or closing phases must remain 183 idle before the NAT considers the associated session a candidate for 184 removal (REQ-5 of [RFC5382]). But [RFC5382] does not clearly state 185 whether these can be configured separately. 187 Clarification: This document clarifies that a NAT SHOULD provide 188 different configurable parameters for configuring the open and 189 closing idle timeouts. 191 To accommodate deployments that consider a partially open timeout 192 of 4 minutes as being excessive from a security standpoint, a NAT 193 MAY allow to configure the timeout to be less than 4 minutes. 194 Still, this specification recommends the default "transitory 195 connection idle-timeout" minimum value to be set to 4 minutes. 197 2.2. TCP RST 199 [RFC5382] leaves the handling of TCP RST packets unspecified. 201 Update: This document adopts a similar default behavior as in 202 [RFC6146]. Concretely, when the NAT receives a TCP RST matching 203 an existing mapping, it MUST translate the packet according the 204 NAT mapping entry. Moreover, the NAT SHOULD wait for 4 minutes 205 before deleting the session and removing any state associate with 206 it if no packets are received during that 4 minutes timeout. 208 Admittedly, the NAT has to verify whether received TCP RST packets 209 belong to a connection. These verification checks are required to 210 avoid off-path attacks. 212 If the NAT removes immediately the NAT mapping upon receipt of a 213 TCP RST message, stale connections may be maintained by endpoints 214 if the first RST message is lost between the NAT and the 215 recipient. 217 3. Port Overlapping Behavior 219 REQ-1 from [RFC4787] and REQ-1 from [RFC5382] specify a specific port 220 overlapping behavior; that is the external IP address and port can be 221 reused for connections originating from the same internal source IP 222 address and port irrespective of the destination. This is known as 223 endpoint-independent mapping (EIM). 225 Update: This document clarifies that this port overlapping behavior 226 may be extended to connections originating from different internal 227 source IP addresses and ports as long as their destinations are 228 different. 230 The following mechanism MAY be implemented by a NAT: 232 If destination addresses and ports are different for outgoing 233 connections started by local clients, a NAT MAY assign the same 234 external port as the source ports for the connections. The 235 port overlapping mechanism manages mappings between external 236 packets and internal packets by looking at and storing their 237 5-tuple (protocol, source address, source port, destination 238 address, destination port). 240 This enables concurrent use of a single NAT external port for 241 multiple transport sessions, which allows a NAT to successfully 242 process packets in an IP address resource limited network (e.g., 243 deployment with high address space multiplicative factor (refer to 244 Appendix B. of [RFC6269])). 246 4. Address Pooling Paired (APP) 248 The Address Pooling Paired (APP) behavior for a NAT was recommended 249 in REQ-2 from [RFC4787], but the behavior when a public IPv4 runs out 250 of ports was left undefined. 252 Clarification: This document clarifies that if APP is enabled, new 253 sessions from a host that already has a mapping associated with an 254 external IP that ran out of ports SHOULD be dropped. 256 The administrator MAY provide a configurable parameter that allows 257 a NAT to starting using ports from another external IP address 258 when the one that anchored the APP mapping ran out of ports. This 259 is a trade-off between service continuity and APP strict 260 enforcement. (Note, this behavior is sometimes referred as 'soft- 261 APP'.) 263 Update: This behavior SHOULD apply also for TCP. 265 5. EIF Protocol Independence 267 REQ-8 from [RFC4787] and REQ-3 from [RFC5382] do not specify whether 268 EIF mappings are protocol-independent. In other words, if an 269 outbound TCP SYN creates a mapping, it is left undefined whether 270 inbound UDP packets destined to that mapping should be forwarded. 272 Update: This document specifies that EIF mappings SHOULD be 273 protocol-independent in order allow inbound packets for protocols 274 that multiplex TCP and UDP over the same IP address and port 275 through the NAT and also maintain compatibility with stateful 276 NAT64 . The administrator MAY provide a configuration parameter to 277 make it protocol-dependent. The default value of this 278 configuration parameter is to allow for protocol-independent EIF. 280 Applications that can be transported over a variety of transport 281 protocols and/or support transport fall back schemes won't 282 experience connectivity failures as a function of the underlying 283 transport protocol or the filtering mode enabled at the NAT. 285 6. EIF Mapping Refresh 287 The NAT mapping Refresh direction may have a "NAT Inbound refresh 288 behavior" of "True" according to REQ-6 from [RFC4787], but [RFC4787] 289 does not clarify how this behavior applies to EIF mappings. The 290 issue in question is whether inbound packets that match an EIF 291 mapping but do not create a new session due to a security policy 292 should refresh the mapping timer. 294 Clarification: This document clarifies that even when a NAT has an 295 inbound refresh behavior set to 'TRUE', such packets SHOULD NOT 296 refresh the mapping. Otherwise a simple attack of a packet every 297 2 minutes can keep the mapping indefinitely. 299 Update: This behavior SHOULD apply also for TCP. 301 6.1. Outbound Mapping Refresh and Error Packets 303 Update: In the case of NAT outbound refresh behavior there are 304 certain types of packets that should not refresh the mapping even 305 if their direction is outbound. For example, if the mapping is 306 kept alive by ICMP Errors or TCP RST outbound packets sent as 307 response to inbound packets, these SHOULD NOT refresh the mapping. 309 7. EIM Protocol Independence 311 REQ-1 from [RFC4787] and REQ-1 from [RFC5382] do not specify whether 312 EIM are protocol-independent. In other words, if a outbound TCP SYN 313 creates a mapping it is left undefined whether outbound UDP can reuse 314 such mapping and create session. On the other hand, stateful NAT64 315 [RFC6146] clearly specifies three binding information bases (TCP, 316 UDP, ICMP). 318 Update: EIM mappings SHOULD be protocol-dependent. A configuration 319 parameter MAY be provided in order allow protocols that multiplex 320 TCP and UDP over the same source IP address and port number to use 321 a single mapping. 323 8. Port Parity 325 Update: A NAT MAY disable port parity preservation for all dynamic 326 mappings. Nevertheless, A NAT SHOULD support means to explicitly 327 request to preserve port parity (e.g., [I-D.ietf-pcp-port-set]). 329 Note: According to [RFC6887], dynamic mappings are said to be 330 dynamic in the sense that they are created on demand, either 331 implicitly or explicitly: 333 1. Implicit dynamic mappings refer to mappings that are created 334 as a side effect of traffic such as an outgoing TCP SYN or 335 outgoing UDP packet. Implicit dynamic mappings usually have a 336 finite lifetime, though this lifetime is generally not known 337 to the client using them. 339 2. Explicit dynamic mappings refer to mappings that are created 340 as a result, for example, of explicit PCP MAP and PEER 341 requests. Explicit dynamic mappings have a finite lifetime, 342 and this lifetime is communicated to the client. 344 9. Port Randomization 346 Update: A NAT SHOULD follow the recommendations specified in 347 Section 4 of [RFC6056], especially: 349 "A NAPT that does not implement port preservation [RFC4787] 350 [RFC5382] SHOULD obfuscate selection of the ephemeral port of a 351 packet when it is changed during translation of that packet. A 352 NAPT that does implement port preservation SHOULD obfuscate the 353 ephemeral port of a packet only if the port must be changed as 354 a result of the port being already in use for some other 355 session. A NAPT that performs parity preservation and that 356 must change the ephemeral port during translation of a packet 357 SHOULD obfuscate the ephemeral ports. The algorithms described 358 in this document could be easily adapted such that the parity 359 is preserved (i.e., force the lowest order bit of the resulting 360 port number to 0 or 1 according to whether even or odd parity 361 is desired)." 363 10. IP Identification (IP ID) 365 Update: A NAT SHOULD handle the Identification field of translated 366 IPv4 packets as specified in Section 5.3.1 of [RFC6864]. 368 Discussion: This recommendation may have undesired effects on the 369 performance of the NAT in environments in which fragmentation is 370 massively experienced. Such issue can be used as an attack vector 371 against NATs. 373 11. ICMP Query Mappings Timeout 375 Section 3.1 of [RFC5508] precises that ICMP Query Mappings are to be 376 maintained by a NAT. However, the specification doesn't discuss 377 Query Mapping timeout values. Section 3.2 of [RFC5508] only 378 discusses ICMP Query Session Timeouts. 380 Update: ICMP Query Mappings MAY be deleted once the last the session 381 using the mapping is deleted. 383 12. Hairpinning Support for ICMP Packets 385 REQ-7 from [RFC5508] specifies that a NAT enforcing 'Basic NAT' must 386 support traversal of hairpinned ICMP Query sessions. 388 Clarification: This implicitly means that address mappings from 389 external address to internal address (similar to Endpoint 390 Independent Filters) must be maintained to allow inbound ICMP 391 Query sessions. If an ICMP Query is received on an external 392 address, a NAT can then translate to an internal IP. 394 REQ-7 from [RFC5508] specifies that all NATs must support the 395 traversal of hairpinned ICMP Error messages. 397 Clarification: This behavior requires a NAT to maintain address 398 mappings from external IP address to internal IP address in 399 addition to the ICMP Query Mappings described in Section 3.1 of 400 [RFC5508]. 402 13. IANA Considerations 404 This document does not require any IANA action. 406 14. Security Considerations 408 NAT behavioral considerations are discussed in [RFC4787]. 410 Security considerations discussed in Section 5 of [RFC6146] apply 411 also fro NAT44. 413 In the case of EIF mappings due to high risk of resource crunch, a 414 NAT MAY provide a configurable parameter to limit the number of 415 inbound sessions spawned from a EIF mapping. 417 15. Acknowledgements 419 Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, 420 Senthil Sivamular, Lars Eggert, and Gorry Fairhurst for review and 421 discussions. 423 16. References 424 16.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 432 Translation (NAT) Behavioral Requirements for Unicast 433 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 434 2007, . 436 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 437 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 438 RFC 5382, DOI 10.17487/RFC5382, October 2008, 439 . 441 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 442 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 443 DOI 10.17487/RFC5508, April 2009, 444 . 446 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 447 Protocol Port Randomization", BCP 156, RFC 6056, 448 DOI 10.17487/RFC6056, January 2011, 449 . 451 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 452 NAT64: Network Address and Protocol Translation from IPv6 453 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 454 April 2011, . 456 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 457 RFC 6864, DOI 10.17487/RFC6864, February 2013, 458 . 460 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 461 A., and H. Ashida, "Common Requirements for Carrier-Grade 462 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 463 April 2013, . 465 16.2. Informative References 467 [I-D.ietf-pcp-port-set] 468 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 469 T., and S. Perreault, "Port Control Protocol (PCP) 470 Extension for Port Set Allocation", draft-ietf-pcp-port- 471 set-09 (work in progress), May 2015. 473 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 474 Translator (NAT) Terminology and Considerations", 475 RFC 2663, DOI 10.17487/RFC2663, August 1999, 476 . 478 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 479 Address Translator (Traditional NAT)", RFC 3022, 480 DOI 10.17487/RFC3022, January 2001, 481 . 483 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 484 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 485 DOI 10.17487/RFC6269, June 2011, 486 . 488 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 489 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 490 DOI 10.17487/RFC6887, April 2013, 491 . 493 Authors' Addresses 495 Reinaldo Penno 496 Cisco Systems, Inc. 497 170 West Tasman Drive 498 San Jose, California 95134 499 USA 501 Email: repenno@cisco.com 503 Simon Perreault 504 Jive Communications 505 Canada 507 Email: sperreault@jive.com 509 Sarat Kamiset 510 Insieme Networks 511 California 512 Mohamed Boucadair 513 France Telecom 514 Rennes 35000 515 France 517 Email: mohamed.boucadair@orange.com 519 Kengo Naito 520 NTT 521 Tokyo 522 Japan 524 Email: kengo@lab.ntt.co.jp