idnits 2.17.1 draft-gont-behave-nat-security-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5296 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) == Unused Reference: 'RFC0791' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'Bellovin2002' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'CPNI-TCP' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC3022' is defined on line 678, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Downref: Normative reference to an Informational RFC: RFC 3715 == Outdated reference: A later version (-04) exists of draft-gont-tcpm-tcp-timestamps-02 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-04 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE WG F. Gont 3 Internet-Draft UTN/FRH 4 Intended status: BCP P. Srisuresh 5 Expires: April 29, 2010 Kazeon Systems, Inc. 6 October 26, 2009 8 Security implications of Network Address Translators (NATs) 9 draft-gont-behave-nat-security-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may not be modified, 15 and derivative works of it may not be created, and it may not be 16 published except as an Internet-Draft. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 29, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document analyzes the security implications of Network Address 50 Translators (NATs). It neither deprecates nor encourages the use of 51 NATs, but rather aims to raise awareness about their security 52 implications, and possible implementation approaches to improve their 53 security. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Security Implications from IP fragmentation . . . . . . . . . 4 59 2.1. Fragment processing for inbound IP packets . . . . . . . . 4 60 2.2. Fragment processing on the outbound . . . . . . . . . . . 5 61 3. Port reservation . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Peer-to-peer Communication for the end hosts behind devices . 7 63 5. DHCP-Configured NATs . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. DHCP-Configured NATs in a Multi-Level NAT deployments . . 7 65 5.2. DHCP-Configured NATs in a Remote Access VPN operation . . 8 66 6. Secure Transport for the end hosts behind NAT Devices . . . . 8 67 7. Security considerations arising from protocol header fields . 9 68 7.1. Internet Protocol version 4 (IPv4) header fields . . . . . 9 69 7.1.1. Version . . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1.2. IHL . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1.3. Type of Service . . . . . . . . . . . . . . . . . . . 9 72 7.1.4. Total Length . . . . . . . . . . . . . . . . . . . . . 9 73 7.1.5. Identification . . . . . . . . . . . . . . . . . . . . 10 74 7.1.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1.7. Fragment Offset . . . . . . . . . . . . . . . . . . . 10 76 7.1.8. Time to Live . . . . . . . . . . . . . . . . . . . . . 10 77 7.1.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . 10 78 7.1.10. Header Checksum . . . . . . . . . . . . . . . . . . . 10 79 7.1.11. Source Address . . . . . . . . . . . . . . . . . . . . 10 80 7.1.12. Destination Address . . . . . . . . . . . . . . . . . 11 81 7.1.13. Options . . . . . . . . . . . . . . . . . . . . . . . 11 82 7.1.14. Padding . . . . . . . . . . . . . . . . . . . . . . . 11 83 7.2. Transmission Control Protocol (TCP) header fields . . . . 11 84 7.2.1. Source Port . . . . . . . . . . . . . . . . . . . . . 11 85 7.2.2. Destination Port . . . . . . . . . . . . . . . . . . . 11 86 7.2.3. Sequence Number . . . . . . . . . . . . . . . . . . . 11 87 7.2.4. Acknowledgment Number . . . . . . . . . . . . . . . . 12 88 7.2.5. Data Offset . . . . . . . . . . . . . . . . . . . . . 12 89 7.2.6. Reserved . . . . . . . . . . . . . . . . . . . . . . . 12 90 7.2.7. Flags . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.2.8. Window . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.2.9. Checksum . . . . . . . . . . . . . . . . . . . . . . . 12 93 7.2.10. Urgent Pointer . . . . . . . . . . . . . . . . . . . . 13 94 7.2.11. Options . . . . . . . . . . . . . . . . . . . . . . . 13 95 7.2.12. Padding . . . . . . . . . . . . . . . . . . . . . . . 13 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 100 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 102 Appendix A. Change log (to be removed before publication of 103 the document as an RFC) . . . . . . . . . . . . . . . 16 104 A.1. Changes from draft-gont-behave-nat-security-01 . . . . . . 16 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 107 1. Introduction 109 This document analyzes the security implications of Network Address 110 Translators (NATs). It neither deprecates nor encourages the use of 111 NATs, but rather aims to raise awareness about their security 112 implications, and possible implementation approaches to improve their 113 security. 115 Section 2 and Section 3 analyze the possible security implications of 116 basic NAT functionality. Section 5 analyzes the possible security 117 implications of DHCP-Configured NATs. Section 7 analyzes the 118 possible security implications araising from the non-modification of 119 protocol header fields by NATs. 121 Note: the security implications of a NAT device due to it being a 122 stateful device are not discussed in the current version of this 123 document (but may be added in future revisions). For what is worth, 124 many of these security implications are described in [RFC5382], 125 [RFC4787] and [I-D.ietf-behave-nat-icmp]. 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 2. Security Implications from IP fragmentation 133 2.1. Fragment processing for inbound IP packets 135 Routers in the network are able to forward fragmented IP packets just 136 as they do any other non-fragmented IP packets because packet 137 forwarding is based solely on looking up the destination IP address 138 in the routing table and finding the largest prefix match to identify 139 the next-hop to forward to. Routers do not need to retain any state 140 pertaining to fragmented packets traversing them. 142 A NAT device operates differently from a router in that the NAT 143 device must find the matching NAT Session for an IP packet and 144 perform NAT translation on the packet, prior to forwarding. NAT 145 Session lookup requires the full 5-tuple of the IP datagram. Only 146 the first fragment of the IP datagram contains the full-tuple. 147 Subsequent fragmented packets contain the fragment Id, but do not 148 contain transport protocol specific details such as source and 149 destination port numbers. The NAT device must be able to associate 150 the same session tuple for all fragments by virtue of the fragment ID 151 and use that information to locate the NAT Session the packets belong 152 to. Note however, the IP fragments cannot be assumed to arrive in 153 order. Some operating systems transmit the fragments of an IP 154 datagram out of their logical order as a matter of course. In 155 addition, network conditions can also cause dynamic packet reordering 156 in transit. 158 A NAT device not capable of processing all fragments of an inbound IP 159 datagram can cause the fragmented packets to be dropped causing some 160 applications to not function correctly. 162 NATs, capable of processing out-of-order packets store the out-of- 163 order packets prior to forwarding. This can open up the NAT device 164 for external attacks. As pointed out in [RFC4787], fragmentation has 165 been a tool used in many attacks, some involving passing fragmented 166 packets through NATs, and others involving DoS attacks based on the 167 state needed to reassemble the fragments. NAT implementers should be 168 aware of [RFC3128] and [RFC1858]. 170 NATs may protect themselves against such attacks by limiting the 171 length of time they retain an incomplete IP packet before discarding 172 it, or by limiting the amount of internal buffer space incomplete IP 173 packets may consume before the oldest fragments are discarded. The 174 appropriate values of these limits vary across NATs, and may be 175 determined by the network administrator. 177 [CPNI-IP] contains a detailed discussion of the security implications 178 arising from the reassembly of IP fragments and of a number of 179 approaches to mitigate them. 181 REQ-1: A NAT device capable of forwarding out-of-order IP fragments 182 MUST take measures to protect itself against well-known IP fragment 183 based attacks. 185 2.2. Fragment processing on the outbound 187 Say, two private hosts originated TCP/UDP packets (fragmented or not) 188 to the same destination host and both packets transit the same NAPT 189 device and use the same fragmentation identifier. Say, the NAPT 190 device assembled the IP packets (in the case they were fragmented) 191 and translated the same using the appropriate NAT Sessions. When 192 NAPT translates IP datagrams, it would assign all outbound IP 193 datagrams the same Public IP, but different TCP/UDP numbers. While 194 forwarding, an IP datagram may be fragmented on the way out. Only 195 the first fragment contains the TCP/UDP header that would be 196 necessary to associate the packet to a specific session. Subsequent 197 fragments do not contain TCP/UDP port information, but simply carry 198 the same fragmentation identifier specified in the first fragment. 200 When the target host receives the two unrelated datagrams, carrying 201 same fragmentation id, and from the same assigned host address, the 202 target host is unable to determine which of the two sessions the 203 datagrams belong to and might corrupt both sessions. This can be a 204 security breach any of the sessions associated. 206 In order to avoid problems of this kind, the NAPT device MUST further 207 translate fragment ID in the outgoing packets such that the tuples of 208 (SrcIP, DestIP, fragment Id, Protocol) are unique and distinguishable 209 across all outgoing packets from the NAT device. 211 When fragmenting packets on the outbound, a NAT device implementing 212 NAPT function MUST ensure that the tuples of (SrcIP, DestIP, fragment 213 Id, Protocol) are unique across all outgoing packets. 215 REQ-2: when forwarding IP fragments on the outbound, a NAT device 216 implementing NAPT function MUST ensure that the tuple of (SrcIP, 217 DestIP, Protocol, fragment ID) is unique across NAT Sessions. Doing 218 this will eliminate the possibility of cross-session contamination 219 due to fragment Identifier overlap when more than one NAT session 220 share the same DestIP and Protocol. 222 3. Port reservation 224 A NAT device implementing NAPT function shares the source ports for 225 its public IP address with nodes in the private realm. The NAPT 226 device may also have end host applications of its own. Consider the 227 following scenario when a NAPT device uses the same TCP/UDP port for 228 local use as well as for mapping to a private host. 230 Say, an application on the NAPT device runs on port 5060 (SIP 231 Server), but not enabled. Say, a host in the private domain of the 232 Nat device also uses 5060 and obtains port 5060 from the NAT device. 233 While this Port Binding is active, say, the application on NAPT 234 device is activated. The application on the NAT device is unlikely 235 to be aware of the NAT function enforced by the NAT device. Once the 236 same port is assigned for NAT use as well as for use by local 237 application on the NAT device, data packets directed to the NAT 238 device could end up with the end host within the private domain or 239 the application on the NAT device. This behavior can cause 240 unpredictable behavior and may even result in data snooping. 242 Manual intervention becomes necessary to ensure that only one 243 instance of an application is actively using a port at a given time. 244 It is not desirable to either allow possible simulataneous use (or) 245 require manual intervention to serialize the use. 247 REQ-3: When a NAT device supports local applications on the device, 248 it is RECOMMENDED that the NAT device reserves specific ports for 249 local use, different from NAT use, so there is no overlap of ports 250 between local use and NAT use. Doing this will ensure there is no 251 possibility of cross session contamination between NAT sessions and 252 local sessions. 254 4. Peer-to-peer Communication for the end hosts behind devices 256 [RFC5128] refers to applications using TCP/UDP hole punching 257 technique to establish peer-to-peer communication. Section 6.1 of 258 [RFC5128] describes a scenario in which it can be problematic for 259 applications that do not use appropriate authentication mechanisms 260 while setting up peer connections. An application could end up 261 connecting to the wrong host or have its connections hijacked 262 maliciously by other hosts. 264 REQ-4: Applications attempting to establish peer-to-peer 265 communication across NAT devices using TCP/UDP hole punching 266 technique SHOULD employ relevant authentication mechanism to connect 267 to their peers. 269 5. DHCP-Configured NATs 271 5.1. DHCP-Configured NATs in a Multi-Level NAT deployments 273 Many NATs, particularly consumer-level devices designed to be 274 deployed by nontechnical users, also act as DHCP [RFC2131] clients. 275 In its default configuration, a consumer NAT typically obtains its 276 public IP address, default router, and other IP configuration 277 information Via DHCP from an ISP or other "upstream" network. 279 On its internal network side, the NAT then automatically sets up its 280 own private "downstream" subnet in one of the private IP address 281 regions assigned to this purpose in [RFC1918]. The NAT typically 282 acts as a DHCP server for its private downstream network, managing 283 its pool of private IP addresses automatically and handing them out 284 to the hosts (and perhaps other NATs) on the private network on 285 demand. 287 This auto-configuration of private networks can be problematic, if 288 the NAT's upstream network is also in RFC 1918 private address space. 289 In the Multi Level NAT deployments, end-hosts could have their 290 security compromised due to mistaken serveri identities as described 291 in section 3 of [I-D.ford-behave-top]. 293 REQ-5: DHCP-Configured NATs SHOULD use different address spaces for 294 the private and the external realms. 296 5.2. DHCP-Configured NATs in a Remote Access VPN operation 298 In deployments where a corporate network deploys the same private 299 address space as used on sundry remote locations, end-hosts could 300 have their security compromised due to mistaken server identities, as 301 described in section 4 of [I-D.ford-behave-top]. 303 6. Secure Transport for the end hosts behind NAT Devices 305 NAT devices are ubiquitous in the Internet. NAT devices can be found 306 in homes, hotels, Airports, conferences, coffee shops and plethora of 307 internet cafes. 309 Most users needing to carry out financial transactions and other 310 personal, sensitive applications use SSL/TLS protocol [RFC2246] to do 311 this. NAT devices enroute MUST support the traversal of SSL/TLS 312 protocol. TCP port 443 is the default port used for SSL/TLS 313 protocol. 315 Secure VPNs is another important use of secure protocols to access 316 corporate networks. Telecommuters and users in remote locations use 317 secure VPN to access their corporate networks. The secure VPNs may 318 use a combination of NAT-T [RFC3947] and IPSec-over-UDP [RFC3948] to 319 secure the VPN traffic. Alternately, some VPN vendors use SSL/TLS 320 protocol [RFC2246] to secure the VPN traffic. NAT devices enroute 321 MUST support the traversal of NAT compliant security protocols such 322 as SSL/TLS, NAT-T and IPsec-over-UDP. 324 Enforcement of NAT-T for IKE negotiation can be problematic, as 325 described in Section 2.3 of [RFC3715], if the NAT device enroute has 326 an Application Level Gateway (ALG) that attempts to treat IKE packets 327 differently from other UDP packets. A NAT device MUST NOT include an 328 ALG that treats IKE or SSL/TLS packets differently than any other 329 TCP/UDP packet. 331 REQ-6: A NAT device MUST permit the traversal of NAT compliant 332 security protocols. Specifically, a NAT device MUST do the 333 following. 335 a. A NAT device MUST NOT block traffic directed to or coming from 336 UDP port numbers 500 and 4500. 338 b. A NAT device MUST NOT block traffic directed to or coming from 339 TCP/UDP port number 443. 341 c. A NAT device MUST NOT include an ALG that treats IKE packets or 342 SSL/TLS packets differently than any other TCP/UDP packet. 344 7. Security considerations arising from protocol header fields 346 From the external real, all packets originated by any host in the 347 internal realm (or by the NAT itself) are seen as originating from 348 the NAT box. As a result, the same requirements that are applied to 349 an internet host must be applied to the aggregate traffic at the NAT 350 box. For example, in the same way that an internet host is required 351 not to reuse a tuple (SrcIP, DstIP, Protocol, IP ID) at any given 352 time, a NAT should enforce that a tuple (SrcIP, DstIP, Protocol, IP 353 ID) of the aggregate traffic is not reused at any given time. 355 In order to enforce some of these requirements, a NAT will usually 356 need to rewrite some of the TCP and/or IP header fields of the 357 incoming and outgoing packets. 359 The following subsections analyze the interoperability and security 360 implications arising from the non-modification of protocol header 361 fields by Network Address Translators (NATs) 363 7.1. Internet Protocol version 4 (IPv4) header fields 365 7.1.1. Version 367 This field does not require any special handling by NATs. 369 7.1.2. IHL 371 This field does not require any special handling by NATs. 373 7.1.3. Type of Service 375 End-systems have traditionally selected different TOS values 376 depending on the nature of the application making use of the IP 377 services. As the TOS value selected for each packet usually depends 378 the specific IP implementation, this could be exploited to roughly 379 count the number of systems behind a NAT. In order to avoid the TOS 380 field from revealing this information, NATs could rewrite the TOS 381 field in outgoing packets according to the Protocol value in the IP 382 header, and the Destination Port value in the header of the transport 383 protocol running on top of IP. 385 7.1.4. Total Length 387 This field does not require any special handling by NATs. 389 7.1.5. Identification 391 NATs must ensure that a tuple (SrcIP, DstIP, Protocol, IP ID) is not 392 reused while there are still packets in the network with that tuple. 393 In order to enforce this requirement, NATs MUST rewrite the IP 394 Identification field of the outgoing IP packets. 396 A trivial approach to enforce this requirement would be to rewrite 397 the IP Identification from a global counter that is increment by one 398 each time a packet is transmitted. However, while this would fulfil 399 the interoperability requirements, this would lead to predictable 400 Identification values, which have been found to have a number of 401 security implications [CPNI-IP]. 403 In order to mitigate these security implications, NATs should rewrite 404 the IP Identification field such that it is not trivial for an 405 attacker to detect different "sequences" of the Identification field. 406 [CPNI-IP] discusses a number of approaches for selecting the 407 Identification value at end-systems, which could also be applied for 408 the selection of the Identification value at NATs. 410 REQ-6: NATs MUST ensure that a tuple (SrcIP, DstIP, Protocol, IP ID) 411 is not reused while there are still packets in the network with that 412 tuple. Additionally, they SHOULD generate the IP Identification 413 values such that they are not trivially predictable. 415 7.1.6. Flags 417 7.1.7. Fragment Offset 419 This field does not require any special handling by NATs. 421 7.1.8. Time to Live 423 To be added. 425 7.1.9. Protocol 427 This field does not require any special handling by NATs. 429 7.1.10. Header Checksum 431 This field does not require any special handling by NATs. 433 7.1.11. Source Address 435 Here we make no special considerations about this field. 437 7.1.12. Destination Address 439 Here we make no special considerations about this field 441 7.1.13. Options 443 Clearly, IP options could potentially be used for counting the number 444 of systems behind a NAT. However, as it is unusual for end-systems 445 to include IP options in the IP packets they send, in most cases this 446 IP options will not require any special handling by NATs. 448 7.1.14. Padding 450 This field does not require any special handling by NATs. 452 7.2. Transmission Control Protocol (TCP) header fields 454 7.2.1. Source Port 456 As part of its basic functionality, a NAT-PT will usually rewrite 457 (translate) the TCP Source Port of packets sent to the external 458 realm. As a result, the ephemeral port selection algorithm of a NAT 459 will "override" that of the end-systems behind the NAT. 461 In some cases, this may have the undesireable consequence that a 462 system implementing some algorithm for ephemeral port obfuscation may 463 end up establishing TCP connections with systems in the external 464 realm using a predictable (as seen from the external realm) ephemeral 465 port sequence. 467 NATs should implement an ephemeral port selection algorithm such that 468 the source port of outgoing packets is obfuscated, thus mitigating 469 blind (off-path) spoofing attacks. 471 It should be noted that use of an improper ephemeral port selection 472 algorithm may lead to collisions of connection-ids, with the 473 potential of failure in the establishment of new TCP connections. 474 [I-D.ietf-tsvwg-port-randomization] 476 7.2.2. Destination Port 478 Here we make no special considerations for this field. 480 7.2.3. Sequence Number 482 The choice of the Initial Sequence Number of a connection by an end- 483 system is not arbitrary, but aims to minimize the chances of a stale 484 segment from being accepted by a new incarnation of a previous 485 connection. [RFC0793] suggests the use of a global 32-bit ISN 486 generator, whose lower bit is incremented roughly every 4 487 microseconds. Based on the premise that the ISNs of consecutive TCP 488 connections are monotonically-increasing, BSD-derived implementations 489 use the ISN of an incomming connection request to perform heuristics 490 aiming at allowing a new incarnation of a previous connection to be 491 created, even if the pervious incarnation is still in the TIME-WAIT 492 state. However, an ISN such as that described in [RFC0793] makes it 493 trivial for an attacker to predict the ISN used for future 494 connections, thus making it easier for the attacker to perform 495 "blind" attacks against those connections. 497 NATs may rewrite the Sequence Number of outgoing segments such that 498 consecutive connections to a specific service at a specific system 499 use ISNs that are monotonically-increasing. Additionally, the ISN 500 generator should be such that it should be difficult for an off-path 501 attacker to predict the ISNs of future connections. [RFC1948] 502 describes an algorithm for the generation of ISN that complies with 503 these two "requirements". 505 7.2.4. Acknowledgment Number 507 If the NAT rewrites the Sequence Number of TCP segments forwarded 508 from the internal realm to the external realm, it must also rewrite 509 the Acknowledgement Number of TCP segments forwarded from the 510 external realm to the internal realm. 512 7.2.5. Data Offset 514 Here we make no special considerations for this field. 516 7.2.6. Reserved 518 Here we make no special considerations for this field. 520 7.2.7. Flags 522 Here we make no special considerations for this field. 524 7.2.8. Window 526 Here we make no special considerations for this field. 528 7.2.9. Checksum 530 Here we make no special considerations for this field. 532 7.2.10. Urgent Pointer 534 Here we make no special considerations for this field. 536 7.2.11. Options 538 7.2.11.1. TCP timestamps 540 The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP 541 to include a timestamp value in its segments, that can be used used 542 to perform two functions: Round-Trip Time Measurement (RTTM), and 543 Protect Against Wrapped Sequences (PAWS). 545 For the purpose of PAWS, the timestamps sent on a connection are 546 required to be monotonically increasing. While there is no 547 requirement that timestamps are monotonically increasing across TCP 548 connections, the generation of timestamps such that they are 549 monotonically increasing across connections between the same two 550 endpoints allows the use of timestamps for improving the handling of 551 SYN segments that are received while the corresponding four-tuple is 552 in the TIME-WAIT state. That is, the timestamp option could be used 553 to perform heuristics to determine whether to allow the creation of a 554 new incarnation of a connection that is in the TIME-WAIT state. 556 NATs could rewrite the TCP Timestamps option such that TCP 557 consecutive connections connections with a specific service at a 558 specific system use monotonically increasing timestamps (i.e., the 559 TCP timestamps are monotonically-increasing across those 560 connections). [I-D.gont-tcpm-tcp-timestamps] describes an algorithm 561 that complies with this requirement. 563 7.2.12. Padding 565 Here we make no special considerations for this field. 567 8. Security Considerations 569 This document analyzes the security implications of Network Address 570 Translators (NATs). It neither deprecates nor encourages the use of 571 NATs, but rather aims to raise awareness about their security 572 implications, and possible implementation approaches to improve their 573 security. 575 Note: the security implications of a NAT device due to it being a 576 stateful device are not discussed in the current version of this 577 document (but may be added in future revisions). For what is worth, 578 many of these security implications are described in [RFC5382], 580 [RFC4787] and [I-D.ietf-behave-nat-icmp]. 582 9. IANA Considerations 584 This document has no actions for IANA. 586 10. Acknowledgements 588 The authors of this document would like to thank (in alphabetical 589 order) Brian Carpenter, Remi Denis-Courmont, Reinaldo Penno, Dave 590 Thaler, and Dan Wing for providing valuable feedback on earlier 591 versions of this document. 593 11. References 595 11.1. Normative References 597 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 598 September 1981. 600 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 601 RFC 793, September 1981. 603 [RFC1122] Braden, R., "Requirements for Internet Hosts - 604 Communication Layers", STD 3, RFC 1122, October 1989. 606 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 607 for High Performance", RFC 1323, May 1992. 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, March 1997. 612 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 613 RFC 2246, January 1999. 615 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 616 (NAT) Compatibility Requirements", RFC 3715, March 2004. 618 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 619 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 620 January 2005. 622 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 623 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 624 RFC 3948, January 2005. 626 11.2. Informative References 628 [Bellovin2002] 629 Bellovin, S., "A Technique for Counting NATted Hosts", 630 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 632 [CPNI-IP] CPNI, "Security Assessment of the Internet Protocol", 633 2008 . 635 [CPNI-TCP] 636 CPNI, "Security Assessment of the Transmission Control 637 Protocol (TCP)", (to be published) . 639 [I-D.ford-behave-top] 640 Srisuresh, P. and B. Ford, "Unintended Consequence of two 641 NAT deployments with Overlapping Address Space", 642 draft-ford-behave-top-07 (work in progress), August 2009. 644 [I-D.gont-tcpm-tcp-timestamps] 645 Gont, F., "On the generation of TCP timestamps", 646 draft-gont-tcpm-tcp-timestamps-02 (work in progress), 647 September 2009. 649 [I-D.ietf-behave-nat-icmp] 650 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 651 Behavioral Requirements for ICMP protocol", 652 draft-ietf-behave-nat-icmp-12 (work in progress), 653 January 2009. 655 [I-D.ietf-tsvwg-port-randomization] 656 Larsen, M. and F. Gont, "Port Randomization", 657 draft-ietf-tsvwg-port-randomization-04 (work in progress), 658 July 2009. 660 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 661 Considerations for IP Fragment Filtering", RFC 1858, 662 October 1995. 664 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 665 E. Lear, "Address Allocation for Private Internets", 666 BCP 5, RFC 1918, February 1996. 668 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 669 RFC 1948, May 1996. 671 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 672 RFC 2131, March 1997. 674 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 675 Translator (NAT) Terminology and Considerations", 676 RFC 2663, August 1999. 678 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 679 Address Translator (Traditional NAT)", RFC 3022, 680 January 2001. 682 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 683 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 685 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 686 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 687 RFC 4787, January 2007. 689 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 690 Peer (P2P) Communication across Network Address 691 Translators (NATs)", RFC 5128, March 2008. 693 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 694 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 695 RFC 5382, October 2008. 697 Appendix A. Change log (to be removed before publication of the 698 document as an RFC) 700 A.1. Changes from draft-gont-behave-nat-security-01 702 o Addded Section 6. 704 Authors' Addresses 706 Fernando Gont 707 Universidad Tecnologica Nacional / Facultad Regional Haedo 708 Evaristo Carriego 2644 709 Haedo, Provincia de Buenos Aires 1706 710 Argentina 712 Phone: +54 11 4650 8472 713 Email: fernando@gont.com.ar 714 URI: http://www.gont.com.ar 715 Pyda Srisuresh 716 Kazeon Systems, Inc. 717 1161 San Antonio Rd. 718 Mountain View, CA 94043 719 U.S.A. 721 Phone: +1 408 836 4773 722 Email: srisuresh@yahoo.com