idnits 2.17.1 draft-gont-behave-nat-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.2b on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 644. -- The document has an RFC 3978 Section 5.2(b) Derivative Works 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 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 (November 4, 2008) is 5623 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 499, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'CPNI-TCP' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'RFC3022' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC5128' is defined on line 577, 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) == Outdated reference: A later version (-07) exists of draft-ford-behave-top-04 == Outdated reference: A later version (-04) exists of draft-gont-tcpm-tcp-timestamps-00 == Outdated reference: A later version (-12) exists of draft-ietf-behave-nat-icmp-10 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-port-randomization-02 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 10 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: May 8, 2009 Kazeon Systems, Inc. 6 November 4, 2008 8 Security implications of Network Address Translators (NATs) 9 draft-gont-behave-nat-security-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 This document may not be modified, and derivative works of it may not 18 be created. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 8, 2009. 38 Abstract 40 This document analyzes the security implications of Network Address 41 Translators (NATs). It neither deprecates nor encourages the use of 42 NATs, but rather aims to raise awareness about their security 43 implications, and possible implementation approaches to improve their 44 security. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Security Implications from IP fragmentation . . . . . . . . . 3 50 2.1. Fragment processing for inbound IP packets . . . . . . . . 3 51 2.2. Fragment processing on the outbound . . . . . . . . . . . 4 52 3. Port reservation . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. DHCP-Configured NATs . . . . . . . . . . . . . . . . . . . . . 5 54 4.1. DHCP-Configured NATs in a Multi-Level NAT deployments . . 6 55 4.2. DHCP-Configured NATs in a Remote Access VPN operation . . 6 56 5. Security considerations arising from protocol header fields . 6 57 5.1. Internet Protocol version 4 (IPv4) header fields . . . . . 6 58 5.1.1. Version . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.1.2. IHL . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1.3. Type of Service . . . . . . . . . . . . . . . . . . . 7 61 5.1.4. Total Length . . . . . . . . . . . . . . . . . . . . . 7 62 5.1.5. Identification . . . . . . . . . . . . . . . . . . . . 7 63 5.1.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1.7. Fragment Offset . . . . . . . . . . . . . . . . . . . 7 65 5.1.8. Time to Live . . . . . . . . . . . . . . . . . . . . . 7 66 5.1.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1.10. Header Checksum . . . . . . . . . . . . . . . . . . . 8 68 5.1.11. Source Address . . . . . . . . . . . . . . . . . . . . 8 69 5.1.12. Destination Address . . . . . . . . . . . . . . . . . 8 70 5.1.13. Options . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.1.14. Padding . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.2. Transmission Control Protocol (TCP) header fields . . . . 8 73 5.2.1. Source Port . . . . . . . . . . . . . . . . . . . . . 8 74 5.2.2. Destination Port . . . . . . . . . . . . . . . . . . . 9 75 5.2.3. Sequence Number . . . . . . . . . . . . . . . . . . . 9 76 5.2.4. Acknowledgment Number . . . . . . . . . . . . . . . . 9 77 5.2.5. Data Offset . . . . . . . . . . . . . . . . . . . . . 10 78 5.2.6. Reserved . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.2.7. Flags . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.2.8. Window . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.2.9. Checksum . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.2.10. Urgent Pointer . . . . . . . . . . . . . . . . . . . . 10 83 5.2.11. Options . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.2.12. Padding . . . . . . . . . . . . . . . . . . . . . . . 11 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 92 Intellectual Property and Copyright Statements . . . . . . . . . . 14 94 1. Introduction 96 This document analyzes the security implications of Network Address 97 Translators (NATs). It neither deprecates nor encourages the use of 98 NATs, but rather aims to raise awareness about their security 99 implications, and possible implementation approaches to improve their 100 security. 102 Section 2 and Section 3 analyze the possible security implications of 103 basic NAT functionality. Section 4 analyzes the possible security 104 implications of DHCP-Configured NATs. Section 5 analyzes the 105 possible security implications araising from the non-modification of 106 protocol header fields by NATs. 108 Note: the security implications of a NAT device due to it being a 109 stateful device are not discussed in the current version of this 110 document (but may be added in future revisions). For what is worth, 111 many of these security implications are described in [RFC5382], 112 [RFC4787] and [I-D.ietf-behave-nat-icmp]. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Security Implications from IP fragmentation 120 2.1. Fragment processing for inbound IP packets 122 Routers in the network are able to forward fragmented IP packets just 123 as they do any other non-fragmented IP packets because packet 124 forwarding is based solely on looking up the destination IP address 125 in the routing table and finding the largest prefix match to identify 126 the next-hop to forward to. Routers do not need to retain any state 127 pertaining to fragmented packets traversing them. 129 A NAT device operates differently from a router in that the NAT 130 device must find the matching NAT Session for an IP packet and 131 perform NAT translation on the packet, prior to forwarding. NAT 132 Session lookup requires the full 5-tuple of the IP datagram. Only 133 the first fragment of the IP datagram contains the full-tuple. 134 Subsequent fragmented packets contain the fragment Id, but do not 135 contain transport protocol specific details such as source and 136 destination port numbers. The NAT device must be able to associate 137 the same session tuple for all fragments by virtue of the fragment ID 138 and use that information to locate the NAT Session the packets belong 139 to. Note however, the IP fragments cannot be assumed to arrive in 140 order. Some operating systems transmit the fragments of an IP 141 datagram out of their logical order as a matter of course. In 142 addition, network conditions can also cause dynamic packet reordering 143 in transit. 145 A NAT device not capable of processing all fragments of an inbound IP 146 datagram can cause the fragmented packets to be dropped causing some 147 applications to not function correctly. 149 NATs, capable of processing out-of-order packets store the out-of- 150 order packets prior to forwarding. This can open up the NAT device 151 for external attacks. As pointed out in [RFC4787], fragmentation has 152 been a tool used in many attacks, some involving passing fragmented 153 packets through NATs, and others involving DoS attacks based on the 154 state needed to reassemble the fragments. NAT implementers should be 155 aware of [RFC3128] and [RFC1858]. 157 NATs may protect themselves against such attacks by limiting the 158 length of time they retain an incomplete IP packet before discarding 159 it, or by limiting the amount of internal buffer space incomplete IP 160 packets may consume before the oldest fragments are discarded. The 161 appropriate values of these limits vary across NATs, and may be 162 determined by the network administrator. 164 [CPNI-IP] contains a detailed discussion of the security implications 165 arising from the reassembly of IP fragments and of a number of 166 approaches to mitigate them. 168 2.2. Fragment processing on the outbound 170 Say, two private hosts originated TCP/UDP packets (fragmented or not) 171 to the same destination host and both packets transit the same NAPT 172 device and use the same fragmentation identifier. Say, the NAPT 173 device assembled the IP packets (in the case they were fragmented) 174 and translated the same using the appropriate NAT Sessions. When 175 NAPT translates IP datagrams, it would assign all outbound IP 176 datagrams the same Public IP, but different TCP/UDP numbers. While 177 forwarding, an IP datagram may be fragmented on the way out. Only 178 the first fragment contains the TCP/UDP header that would be 179 necessary to associate the packet to a specific session. Subsequent 180 fragments do not contain TCP/UDP port information, but simply carry 181 the same fragmentation identifier specified in the first fragment. 183 When the target host receives the two unrelated datagrams, carrying 184 same fragmentation id, and from the same assigned host address, the 185 target host is unable to determine which of the two sessions the 186 datagrams belong to and might corrupt both sessions. This can be a 187 security breach any of the sessions associated. 189 In order to avoid problems of this kind, the NAPT device SHOULD 190 further translate fragment ID in the outgoing packets such that the 191 tuples of (SrcIP, DestIP, fragment Id, Protocol) are unique and 192 distinguishable across all outgoing packets from the NAT device. 194 When fragmenting packets on the outbound, a NAT device implementing 195 NAPT function SHOULD ensure that the tuples of (SrcIP, DestIP, 196 fragment Id, Protocol) are unique across all outgoing packets. 198 3. Port reservation 200 A NAPT device often shares the source ports for its public IP address 201 with nodes in the private realm. Reserving port blocks explicitly 202 for local use vs. NAT use is valuable for several reasons. Consider 203 the following scenario. 205 Say, an application on the NAPT runs on port 5060 (SIP Server), but 206 not enabled. A host in the private domain uses 5060 at this time and 207 say, gets the port 5060 from the NAT device. While this Port Binding 208 is active, say, the application running on NAT is activated. Several 209 things can go wrong now depending on the implementation: 211 1. The application is totally unaware of NAT's existence, (maybe 212 because NAT never does a bind on the ports it is using). So it 213 starts using 5060 and the subsequent packets directed to this 214 server could end up in the end host within the private domain or 215 the packets meant for the application on the end host could end 216 up in the NAT box's TCP/UDP stack. Both are bad and can cause 217 unpredictable behavior. 219 2. The application on the NAT box is aware that someone is using 220 5060 so the Bind fails and the app fails to come up. The 221 administrator would have to clear the NAT session and restart the 222 application. 224 3. The application on the NAT box is intelligent enough to tell NAT 225 to clean up any sessions that it plans to use and NAT cleans up 226 its session(s). The application on the end host is effected as a 227 result. 229 Clearly, there can be unpredictable behavior when ports are not 230 reserved explicitly for local use vs NAT use. 232 4. DHCP-Configured NATs 233 4.1. DHCP-Configured NATs in a Multi-Level NAT deployments 235 Many NATs, particularly consumer-level devices designed to be 236 deployed by nontechnical users, also act as DHCP [RFC2131] clients. 237 In its default configuration, a consumer NAT typically obtains its 238 public IP address, default router, and other IP configuration 239 information Via DHCP from an ISP or other "upstream" network. 241 On its internal network side, the NAT then automatically sets up its 242 own private "downstream" subnet in one of the private IP address 243 regions assigned to this purpose in [RFC1918]. The NAT typically 244 acts as a DHCP server for its private downstream network, managing 245 its pool of private IP addresses automatically and handing them out 246 to the hosts (and perhaps other NATs) on the private network on 247 demand. 249 This auto-configuration of private networks can be problematic, if 250 the NAT's upstream network is also in RFC 1918 private address space. 251 In the Multi Level NAT deployments, end-hosts could have their 252 security compromised due to mistaken serveri identities as described 253 in section 3 of [I-D.ford-behave-top]. 255 4.2. DHCP-Configured NATs in a Remote Access VPN operation 257 In deployments where a corporate network deploys the same private 258 address space as used on sundry remote locations, end-hosts could 259 have their security compromised due to mistaken server identities, as 260 described in section 4 of [I-D.ford-behave-top]. 262 5. Security considerations arising from protocol header fields 264 The following subsections analyze the security implications arising 265 from arising from the non-modification of protocol header fields by 266 Network Address Translators (NATs) 268 5.1. Internet Protocol version 4 (IPv4) header fields 270 5.1.1. Version 272 This field does not require any special handling by NATs. 274 5.1.2. IHL 276 This field does not require any special handling by NATs. 278 5.1.3. Type of Service 280 End-systems have traditionally selected different TOS values epending 281 on the nature of the application making use of the IP services. As 282 the TOS value selected for each packet usually depends the specific 283 IP implementation, this could be exploited to roughly count the 284 number of systems behind a NAT. In order to avoid the TOS field from 285 revealing this information, NATs could rewrite the TOS field in 286 outgoing packets according to the Protocol value in the IP header, 287 and the Destination Port value in the header of the transport 288 protocol running on top of IP. 290 5.1.4. Total Length 292 This field does not require any special handling by NATs. 294 5.1.5. Identification 296 The IP Identification field is used for the reassembly of IP 297 fragments. Most IP implementations have typically selected the IP 298 Identification field from a global counter that is incremented by one 299 each time a packet is transmitted [CPNI-IP]. As discussed in 300 [Bellovin2002], the Identification field can be exploited to count 301 the number of systems behind a NAT, thus unnecesarily revealing 302 information about the "internal" network. In order to avoid this 303 issue, NATs could rewrite the IP Identification field such that it is 304 not trivial for an attacker to detect different "sequences" of the 305 Identification field. [CPNI-IP] discussed a number of approaches for 306 selecting the Identification value at end-systems, which could also 307 be applied for the selection of the Identification value at NATs. 309 It should be noted that if a NAT does not rewrite the Identification 310 field, a given Identification value could end up being reused too 311 quickly, with the potential of interoperability problems. 313 5.1.6. Flags 315 5.1.7. Fragment Offset 317 This field does not require any special handling by NATs. 319 5.1.8. Time to Live 321 As discussed in [CPNI-IP], the IP Time to Live field can be exploited 322 to: 324 o Fingerprinting the operating system being used by the source host. 326 o Fingerprinting the physical device from which the packets 327 originate. 329 o Locating the source host in the network topology. 331 In order to avoid having the IP Time to Live field reveal this 332 information, NATs could rewrite the TTL field of translated packets, 333 such that this field is set homogeneously among all packets forwarded 334 toward the external network. 336 5.1.9. Protocol 338 This field does not require any special handling by NATs. 340 5.1.10. Header Checksum 342 This field does not require any special handling by NATs. 344 5.1.11. Source Address 346 Here we make no special considerations about this field. 348 5.1.12. Destination Address 350 Here we make no special considerations about this field 352 5.1.13. Options 354 Clearly, IP options could potentially be used for counting the number 355 of systems behind a NAT. However, as it is unusual for end-systems 356 to include IP options in the IP packets they send, in most cases this 357 IP options will not require any special handling by NATs. 359 5.1.14. Padding 361 This field does not require any special handling by NATs. 363 5.2. Transmission Control Protocol (TCP) header fields 365 5.2.1. Source Port 367 As part of its basic functionality, a NAT-PT will usually rewrite 368 (translate) the TCP Source Port of packets sent to the external 369 realm. As a result, the ephemeral port selection algorithm of a NAT 370 will "override" that of the end-systems behind the NAT. 372 In some cases, this may have the undesireable consequence that a 373 system implementing some algorithm for ephemeral port obfuscation may 374 end up establishing TCP connections with systems in the external 375 realm using a predictable (as seen from the external realm) ephemeral 376 port sequence. 378 NATs should implement an ephemeral port selection algorithm such that 379 the source port of outgoing packets is obfuscated, thus mitigating 380 blind (off-path) spoofing attacks. 382 It should be noted that use of an improper ephemeral port selection 383 algorithm may lead to collisions of connection-ids, with the 384 potential of failure in the establishment of new TCP connections. 385 [I-D.ietf-tsvwg-port-randomization] 387 5.2.2. Destination Port 389 Here we make no special considerations for this field. 391 5.2.3. Sequence Number 393 The choice of the Initial Sequence Number of a connection by an end- 394 system is not arbitrary, but aims to minimize the chances of a stale 395 segment from being accepted by a new incarnation of a previous 396 connection. [RFC0793] suggests the use of a global 32-bit ISN 397 generator, whose lower bit is incremented roughly every 4 398 microseconds. Based on the premise that the ISNs of consecutive TCP 399 connections are monotonically-increasing, BSD-derived implementations 400 use the ISN of an incomming connection request to perform heuristics 401 aiming at allowing a new incarnation of a previous connection to be 402 created, even if the pervious incarnation is still in the TIME-WAIT 403 state. However, an ISN such as that described in [RFC0793] makes it 404 trivial for an attacker to predict the ISN used for future 405 connections, thus making it easier for the attacker to perform 406 "blind" attacks against those connections. 408 NATs should rewrite the Sequence Number of outgoing segments such 409 that consecutive connections to a specific service at a specific 410 system use ISNs that are monotonically-increasing. Additionally, the 411 ISN generator should be such that it should be difficult for an off- 412 path attacker to predict the ISNs of future connections. [RFC1948] 413 describes an algorithm for the generation of ISN that complies with 414 these two "requirements". 416 5.2.4. Acknowledgment Number 418 Here we make no special considerations for this field. 420 5.2.5. Data Offset 422 Here we make no special considerations for this field. 424 5.2.6. Reserved 426 Here we make no special considerations for this field. 428 5.2.7. Flags 430 Here we make no special considerations for this field. 432 5.2.8. Window 434 Here we make no special considerations for this field. 436 5.2.9. Checksum 438 Here we make no special considerations for this field. 440 5.2.10. Urgent Pointer 442 Here we make no special considerations for this field. 444 5.2.11. Options 446 5.2.11.1. TCP timestamps 448 The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP 449 to include a timestamp value in its segments, that can be used used 450 to perform two functions: Round-Trip Time Measurement (RTTM), and 451 Protect Against Wrapped Sequences (PAWS). 453 For the purpose of PAWS, the timestamps sent on a connection are 454 required to be monotonically increasing. While there is no 455 requirement that timestamps are monotonically increasing across TCP 456 connections, the generation of timestamps such that they are 457 monotonically increasing across connections between the same two 458 endpoints allows the use of timestamps for improving the handling of 459 SYN segments that are received while the corresponding four-tuple is 460 in the TIME-WAIT state. That is, the timestamp option could be used 461 to perform heuristics to determine whether to allow the creation of a 462 new incarnation of a connection that is in the TIME-WAIT state. 464 NATs could rewrite the TCP Timestamps option such that TCP 465 consecutive connections connections with a specific service at a 466 specific system use monotonically increasing timestamps (i.e., the 467 TCP timestamps are monotonically-increasing across those 468 connections). [I-D.gont-tcpm-tcp-timestamps] describes an algorithm 469 that complies with this requirement. 471 5.2.12. Padding 473 Here we make no special considerations for this field. 475 6. Security Considerations 477 This document analyzes the security implications of Network Address 478 Translators (NATs). It neither deprecates nor encourages the use of 479 NATs, but rather aims to raise awareness about their security 480 implications, and possible implementation approaches to improve their 481 security. 483 Note: the security implications of a NAT device due to it being a 484 stateful device are not discussed in the current version of this 485 document (but may be added in future revisions). For what is worth, 486 many of these security implications are described in [RFC5382], 487 [RFC4787] and [I-D.ietf-behave-nat-icmp]. 489 7. IANA Considerations 491 This document has no actions for IANA. 493 8. Acknowledgements 495 9. References 497 9.1. Normative References 499 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 500 September 1981. 502 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 503 RFC 793, September 1981. 505 [RFC1122] Braden, R., "Requirements for Internet Hosts - 506 Communication Layers", STD 3, RFC 1122, October 1989. 508 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 509 for High Performance", RFC 1323, May 1992. 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 9.2. Informative References 516 [Bellovin2002] 517 Bellovin, S., "A Technique for Counting NATted Hosts", 518 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 520 [CPNI-IP] CPNI, "Security Assessment of the Internet Protocol", 521 2008 . 523 [CPNI-TCP] 524 CPNI, "Security Assessment of the Transmission Control 525 Protocol (TCP)", (to be published) . 527 [I-D.ford-behave-top] 528 Srisuresh, P. and B. Ford, "Complications from Network 529 Address Translator Deployment Topologies", 530 draft-ford-behave-top-04 (work in progress), October 2008. 532 [I-D.gont-tcpm-tcp-timestamps] 533 Gont, F., "On the generation of TCP timestamps", 534 draft-gont-tcpm-tcp-timestamps-00 (work in progress), 535 October 2008. 537 [I-D.ietf-behave-nat-icmp] 538 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 539 Behavioral Requirements for ICMP protocol", 540 draft-ietf-behave-nat-icmp-10 (work in progress), 541 October 2008. 543 [I-D.ietf-tsvwg-port-randomization] 544 Larsen, M. and F. Gont, "Port Randomization", 545 draft-ietf-tsvwg-port-randomization-02 (work in progress), 546 August 2008. 548 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 549 Considerations for IP Fragment Filtering", RFC 1858, 550 October 1995. 552 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 553 E. Lear, "Address Allocation for Private Internets", 554 BCP 5, RFC 1918, February 1996. 556 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 557 RFC 1948, May 1996. 559 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 560 RFC 2131, March 1997. 562 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 563 Translator (NAT) Terminology and Considerations", 564 RFC 2663, August 1999. 566 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 567 Address Translator (Traditional NAT)", RFC 3022, 568 January 2001. 570 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 571 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 573 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 574 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 575 RFC 4787, January 2007. 577 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 578 Peer (P2P) Communication across Network Address 579 Translators (NATs)", RFC 5128, March 2008. 581 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 582 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 583 RFC 5382, October 2008. 585 Authors' Addresses 587 Fernando Gont 588 Universidad Tecnologica Nacional / Facultad Regional Haedo 589 Evaristo Carriego 2644 590 Haedo, Provincia de Buenos Aires 1706 591 Argentina 593 Phone: +54 11 4650 8472 594 Email: fernando@gont.com.ar 595 URI: http://www.gont.com.ar 597 Pyda Srisuresh 598 Kazeon Systems, Inc. 599 1161 San Antonio Rd. 600 Mountain View, CA 94043 601 U.S.A. 603 Phone: +1 408 836 4773 604 Email: srisuresh@yahoo.com 606 Full Copyright Statement 608 Copyright (C) The IETF Trust (2008). 610 This document is subject to the rights, licenses and restrictions 611 contained in BCP 78, and except as set forth therein, the authors 612 retain all their rights. 614 This document and the information contained herein are provided on an 615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 617 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 618 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 619 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 622 Intellectual Property 624 The IETF takes no position regarding the validity or scope of any 625 Intellectual Property Rights or other rights that might be claimed to 626 pertain to the implementation or use of the technology described in 627 this document or the extent to which any license under such rights 628 might or might not be available; nor does it represent that it has 629 made any independent effort to identify any such rights. Information 630 on the procedures with respect to rights in RFC documents can be 631 found in BCP 78 and BCP 79. 633 Copies of IPR disclosures made to the IETF Secretariat and any 634 assurances of licenses to be made available, or the result of an 635 attempt made to obtain a general license or permission for the use of 636 such proprietary rights by implementers or users of this 637 specification can be obtained from the IETF on-line IPR repository at 638 http://www.ietf.org/ipr. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights that may cover technology that may be required to implement 643 this standard. Please address the information to the IETF at 644 ietf-ipr@ietf.org.