idnits 2.17.1 draft-sivakumar-behave-nat-tcp-req-00.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 617. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 28, 2005) is 6990 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'KEYWRD' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'UNSAF' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'ASND' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'H323' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'ICE' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'ICMP' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'NAT-1' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'NAT-2' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'NAT-3' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'P2P-1' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'P2P-2' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RTP' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'SIP' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'STUN-1' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'STUN-2' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'V4-REQ' is defined on line 562, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3424 (ref. 'UNSAF') -- Obsolete informational reference (is this intentional?): RFC 923 (ref. 'ASND') (Obsoleted by RFC 943) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-02 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. 'STUN-1') (Obsoleted by RFC 5389) == Outdated reference: A later version (-02) exists of draft-jennings-midcom-stun-results-01 Summary: 6 errors (**), 0 flaws (~~), 21 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE S. Sivakumar 3 Internet-Draft K. Biswas 4 Expires: August 1, 2005 Cisco Systems 5 B. Ford 6 M.I.T 7 January 28, 2005 9 NAT Behavioral Requirements for TCP 10 draft-sivakumar-behave-nat-tcp-req-00 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 1, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 Inconsistent behavior by NATs makes it difficult for the application 46 developers and network administrators to predict the operation of 47 NATs. This document describes the behavior required by NATs when 48 handling TCP traffic. It also specifies the address and port binding 49 behavioral requirement, timeout aspects and adjusting the sequence 50 numbers and the acknowledgement numbers when changing the payload 51 length. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. TCP requirements . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1 State Machine . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2 NAT address and port binding . . . . . . . . . . . . . . . 4 60 3.3 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.4 Port reservation. . . . . . . . . . . . . . . . . . . . . 5 62 3.5 Processing IP fragments and TCP segments . . . . . . . . . 6 63 3.5.1 IP Fragments handling . . . . . . . . . . . . . . . . 6 64 3.5.2 TCP Segments handling . . . . . . . . . . . . . . . . 7 65 3.6 Adjusting Sequence Acknowledgement Numbers . . . . . . . . 8 66 3.7 Handling of ICMP Error messages . . . . . . . . . . . . . 10 67 4. Security considerations . . . . . . . . . . . . . . . . . . . 11 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 11 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 73 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 75 Intellectual Property and Copyright Statements . . . . . . . . 14 77 1. Introduction 79 A lot of issues caused by inconsistent NAT behavior are documented in 80 [UDP-REQ]. Different NAT implementations behave differently when 81 handling the TCP traffic streams. This document defines the required 82 behavior of NATs when handling TCP traffic. 84 NATs maintain various pieces of session information to translate the 85 TCP streams correctly. NATs would have to run a state machine for 86 TCP to keep track of the state changes. The state machines are 87 predominantly used for controlling the different timers that are 88 maintained by NAT. NATs should also keep track of the payload 89 changes by upper layer ALGs in order to adjust the sequence numbers 90 and acknowledgement numbers properly. 92 2. Scope 94 This document will focus specifically on issues that relates to TCP. 95 This document will refer to [UDP-REQ] for all the common NAT 96 behavioral issues and requirements. Application Layer Gateways 97 (ALGs) are out of scope for this document. This document will not 98 propose any solution but will define only the requirements of NAT 99 when handling TCP. 101 3. TCP requirements 103 The behavioral requirements of NAT when processing TCP packets are 104 described in this section. 106 3.1 State Machine 108 NATs maintain a database of active TCP sessions flowing across the 109 NAT. Each session in the NAT's database has an associated state 110 machine that dynamically tracks the state of the TCP session from the 111 perspective of the NAT. The NAT creates a database entry for a new 112 session, and starts the TCP state machine for that session, when it 113 forwards the first SYN packet for that session across the NAT. The 114 NAT's TCP state machine transitions from the "active" to the "closed" 115 state when the NAT observes a FIN/FIN ACK sequence, representing 116 graceful shutdown reached cooperatively by both endpoints, or when 117 the NAT observes a RST from either endpoint, representing a 118 non-graceful connection reset forced by one endpoint. Finally, the 119 NAT deletes its database entry for the session some time after the 120 state machine enters the "closed" state, depending on the timeouts 121 described below. 123 In addition to this basic state information, many NATs also record 124 information about the TCP sequence numbers and the acknowledgment 125 numbers they observe in the TCP packets flowing across the NAT. If 126 the NAT contains built-in ALGs that can change the payload length of 127 TCP packets, effectively inserting or removing bytes from the TCP 128 stream in one or both directions, then the NAT MUST adjust the 129 sequence numbers in all subsequent packets exchanged in either 130 direction to reflect these inserted or removed bytes. 132 NATs also use the state machine information associated with a TCP 133 session in order to filter packets arriving from the external realm 134 toward the internal realm. Unless specifically configured to do 135 otherwise, any SYN packets originating from the external realm will 136 be filtered out by the NAT if the NAT's database contains no entry 137 for that session. This behavior reflects the standard firewall 138 policy of rejecting all "unsolicited incoming connection attempts" by 139 default. NATs that implement a state machine for keeping track of 140 the TCP streams are referred to as State Aware NAT (abbreviated SM = 141 YES). 143 A NAT SHOULD be SM=YES. 145 3.2 NAT address and port binding 147 The address and port binding requirements remain the same as the 148 requirements described in [UDP-REQ]. 150 3.3 Timeouts 152 NATs maintain different types of timeouts for the TCP sessions. 153 These timeouts apply to the different states of the TCP state 154 machine. 156 * The NAT's SYN timer has a relatively short timeout, and helps to 157 protect the NAT (and, potentially, the hosts behind the NAT) from SYN 158 flood attacks. The SYN timeout starts when the NAT observes the 159 first SYN on a new session, and is cancelled when the NAT receives an 160 ACK for that SYN from the opposite endpoint, indicating that 161 legitimate two-way communication is taking place. 163 * The NAT's session timer is a relatively long timeout, and ensures 164 that the NAT is eventually able to delete database entries for 165 formerly-active TCP sessions on which both endpoints have silently 166 ceased communication without either closing or resetting the 167 connection. The NAT's session timer starts when the TCP session 168 enters the active, "fully-open" state (typically at the same time its 169 SYN timer is cancelled), and the session timer MUST be reset whenever 170 the NAT observes an outbound packet from the internal realm to the 171 external realm. Inbound packets SHOULD NOT cause the NAT to reset 172 its session timer. 174 When the NAT's session timer expires, it SHOULD NOT immediately 175 delete its database entry for the session, since TCP sessions are 176 legitimately allowed to go idle for arbitrary lengths of time with no 177 exchanged traffic. Instead, the NAT SHOULD enter a special "probe" 178 state, in which it sends TCP keep-alive packets to the internal 179 endpoint, using the technique described in section 4.2.3.6 of [HOST], 180 in order to detect whether the internal endpoint still considers the 181 connection to be open. If the NAT receives an ACK or other traffic 182 from the internal endpoint, it resets the session timer and re-enters 183 the "active" state. If the NAT receives a RST from the internal 184 endpoint, it enters the "closed" state and starts the close timer as 185 described below. If the NAT receives no response from the internal 186 endpoint after sending several keep-alive packets, the NAT assumes 187 that the internal endpoint is dead and again enters the "closed" 188 state. 190 * The NAT's close timer is a relatively short timeout that ensures 191 that the ACKs for the final FINs on a gracefully-closed TCP session 192 have a chance to propagate in both directions, and also to allow time 193 for either endpoint to re-open a recently closed or reset TCP session 194 if desired. The NAT starts the close timer after it observes a FIN 195 packet in each direction, or after it observes an RST from either 196 endpoint. If a new SYN packet arrives from either endpoint before 197 the close timer expires, the NAT re-enters the active, "half-open" 198 state & re-starts the SYN timer as described above. Otherwise, once 199 the close timer expires the NAT is free to delete its database entry 200 and release all resources allocated to the session. 202 The following requirements apply to the NAT's timeouts: 204 A NAT MUST have a SYN timer so that the box is not prone to SYN 205 attacks. The SYN timeout value MUST be configurable, and SHOULD 206 default to at least 30 seconds and no more than 60 seconds. 208 A NAT MUST have a session timeout. The NAT's session timeout MUST be 209 configurable. The session timeout MUST by default be at least 60 210 minutes if the NAT uses TCP keep-alives to probe the session after 211 the session timeout expires, and the session timeout MUST by default 212 be atleast 120 minutes if the NAT just silently deletes the database 213 entry for the session after the session timeout expires. 215 A NAT MUST have a close timeout. NAT MAY have separate timeouts for 216 session close due to FIN versus RST. NAT's close timeouts MUST be at 217 least 2xMSL, or 60 seconds. 219 3.4 Port reservation. 221 The TCP port space associated with a NAT's own IP addresses, 222 particularly its IP addresses on the external network side, are 223 commonly shared between two separate functions: 225 1. TCP endpoints for address and port translated sessions 227 2. TCP endpoints for applications residing on the NAT device 229 The first function results in port reservation for address-translated 230 client sessions. The second function results in port reservation due 231 to applications running on the NAT device itself. Examples of such 232 applications include: a web-based externally accessible management 233 interface, or a port forwarding application that has a predefined 234 binding. Many NATs are actually general-purpose network hosts that 235 also run ordinary TCP-based applications as well. Even dedicated NAT 236 middleboxes often provide remote management functionality, requiring 237 communication between external hosts and applications on the NAT 238 itself. The resulting sharing of the NAT's TCP port space between 239 address-translation sessions and local applications creates a 240 potential for resource contention. 242 NATs MUST NOT use a single TCP port for both address-translated 243 sessions and local application sessions at the same time. NATs MAY 244 dynamically re-assign a TCP port from one function to the other on 245 demand, but only after any previous TCP sessions involving that port 246 have become inactive. 248 3.5 Processing IP fragments and TCP segments 250 This section describes how a NAT is recommended to behave with 251 regards to handling IP fragments and TCP segments. There are 2 252 scenarios which can cause fragmentation/segmentation: 254 1. The MTU of the link can be as such as to cause the IP packets to 255 be fragmented 257 2. The TCP stack at the either end-point can have the TCP MSS set to 258 value lower than the application payload size which will cause the 259 packets to be TCP segmented. 261 3.5.1 IP Fragments handling 263 A NAT may receive a fragmented TCP packet. The following section is 264 provided from [UDP-REQ] for completeness. 266 The IP packet containing the TCP header could arrive first or last 267 depending of various conditions. NAT that is capable only of 268 receiving TCP fragments in order (that is, with the TCP header in the 269 first packet) and forwarding each of the fragments to the internal 270 host is described as Received Fragments Ordered (abbreviated RF=O). 272 NAT that is capable of receiving TCP fragments in or out of order and 273 forwarding the individual packets (or a reassembled packet) to the 274 internal host is referred to as Receive Fragments Out of Order 275 (abbreviated RF=OO). 277 A NAT that is neither of these is referred to as Receive Fragments 278 None (abbreviated RF=N). 280 NAT MUST support RF=O or RF=OO. NAT MAY support RF=OO. 282 3.5.2 TCP Segments handling 284 A NAT may receive a TCP segmented packet. The following diagram 285 explains this: 287 +-------------------+ +-------------------+ 288 | Application-Layer | | Application-Layer | 289 +-------------------+ +-------------------+ 290 | TCP [MSS = 536] | | TCP [MSS = 536] | 291 +-------------------+ +-------------------+ 292 | IP | | IP | 293 +-------------------+ +-------------------+ 294 | Lower-Layer | | Lower-Layer | 295 | (MTU = 1500 | | (MTU = 1500 | 296 +-------------------+ +-------------------+ 297 End-host -1 End-host -2 298 | +--------+ | 299 +-------------------| NAT |----------------+ 300 +--------+ 302 Say the application layer is sending data with size = 600. Since the 303 MTU is 1500 this should not be an issue with respect to IP 304 fragmentations, but this packet will still be TCP segmented. The 305 following 2 TCP segments might appear on the wire: 307 TCP Segment 1: 308 +------------------------------+------------------------+----------+ 309 |IP[Frag-offset=0,More-flags =0|TCP hdr[Payload-Len=536]|Appl-data1| 310 +------------------------------+------------------------+----------+ 312 TCP Segment 2: 313 +------------------------------+------------------------+----------+ 314 |IP[Frag-offset=0,More-flags =0|TCP hdr[Payload-Len=64] |Appl-data2| 315 +------------------------------+------------------------+----------+ 316 There are 2 scenarios : 318 1. The TCP segments are received by NAT, in-order 320 2. The TCP segments are received by NAT, out-of-order 322 For out-of-order segments, if the NAT has the intelligence to process 323 the application-payload, it should be able to figure out the 324 out-of-order TCP segments and enforce some queueing mechanism such 325 that when the prior segment is received it SHOULD reassemble the TCP 326 segments and proceed with the application-payload processing. In 327 addition it SHOULD send a TCP ACK for getting subsequent TCP segments 328 from the endpoint. 330 For in-order segments, the application has to provide the length of 331 data. In such cases the NAT has to enforce the same queuening 332 mechanism as mentioned above and reassemble the TCP segments and 333 proceed for its processing. This applies only for application which 334 has the support for providing the length in the application-data. 336 NATs that behave as described in this section are refered to as 337 "Support Segmentation Yes" (abbreviated SS=Y). NATs that do not 338 support any of the above are called "Support Segmentation none" 339 (abbreviated SS=N). 341 If a NAT is doing application-payload processing it SHOULD support 342 SS=Y. 344 3.6 Adjusting Sequence Acknowledgement Numbers 346 A NAT might modify the TCP data carrying the application-payload 347 resulting in the TCP data to increase or decrease in size. As a 348 result of this the NAT is expected change/remember the sequence/ 349 acknowledgement number in the TCP header and save this information 350 along with the delta of change, in the NAT entry associated with this 351 particular packet flow so that subsequent TCP packets of this flow 352 are adjusted accordingly. 354 If a NAT receives a particular type of TCP payload for which it is 355 capable/enabled to do a deep packet inspection it is expected to 356 create a NAT entry with the full flow information irrespective of the 357 type of NAT configuration, and save the [seq, ack, delta] associated 358 with the TCP flow. It may chose to store any other additional 359 information. 361 For eg: 363 +-------+ 364 +-------| Host B| 365 | +-------+ 366 +-------+ +------+ | 367 |Host A |---------| NAT |--------------------+ 368 +-------+ +------+ | 369 | +-------+ 370 +-------| Host C| 371 +-------+ 373 Say the NAT is configured to do NAT and not PAT, meaning it is 374 configured to do 1:1 translation say (A->A'). In such cases most 375 NATs will create a simple NAT entry in the database to optimize on 376 the memory or otherwise, and not create one with the full flow 377 information. 379 So when A is sending a TCP flow to B & to C and the NAT does not have 380 the intelligence to do a deep packet inspection for this TCP payload, 381 then the NAT can chose to create just the following entry in the NAT 382 database. 384 +---+------+------+------+------+---------+----------+ 385 |Prt|L-Addr|L-Port|G-Addr|G-Port|Dest Addr| Dest Port| 386 +---+------+------+------+------+---------+----------+ 387 |- |A |- |A |- |- | - | 388 +---+------+------+------+------+---------+----------+ 390 Where L-Addr/Port are the internal address/port of the Host, G-Addr/ 391 port are the NAT Translated address/port. 393 But if A sends TCP traffic for which the NAT can do deep packet 394 inspection and thereby possibly change the TCP payload-data-length, 395 then the NAT SHOULD create entries with full flow information with 396 the information about the [seq, ack,delta]. 398 +---+------+------+------+------+---------+----------+-------+ 399 |Prt|L-Addr|L-Port|G-Addr|G-Port|Dest Addr| Dest Port| | 400 +---+------+------+------+------+---------+----------+-------+ 401 |TCP|A |p |A |p' |B | q |[seq, | 402 | | | | | | | | ack, | 403 | | | | | | | | delta]| 404 +---+------+------+------+------+---------+----------+-------+ 406 Say for example the NAT is not doing so and the TCP sessions from 407 A->B and A->C are not differentiable then the subsequent TCP flows' 408 sequence/acknowledgement number-fixups will be incorrect. 410 NATs that operate as described in this section are described as 411 "Supports Seq/Ack Delta Adjustment" (abbreviated SDA=S). NATs that 412 do not operate in this mode are described as "Supports Seq/Ack Delta 413 Adjustment none" (abbreviated SDA=N). NATs MAY chose to be SDA=N for 414 TCP flows for which it does not do deep packet inspection but SHOULD 415 do SDA=S for the ones it does. 417 A NAT SHOULD support SDA=S. 419 3.7 Handling of ICMP Error messages 421 In addition to what has been described in [UDP-REQ] with respect to 422 handling ICMP Error-messages, a NAT is expected to do a fixup of the 423 embedded TCP payload in the ICMP Error message. As a result the ICMP 424 Error message will correctly communicate the proper address/port 425 information to the TCP stack on endpoint which can associate it with 426 its internal data-structures and act accordingly. 428 For eg: 430 +-------+ +---------+ +--------+ 431 |Host A | ---------|NAT |----------| Host B | 432 +-------+ +---------+ +--------+ 434 Say A sends a TCP packet via NAT to Host B (A,p) -> (B,p). NAT 435 changes the source address/port of the TCP header to say (A',p'). 436 For some reason the B sends back an ICMP Error message back towards 437 A'. This ICMP Error message will contain part of the TCP header. 438 The NAT is expected to not only modify the ICMP header but look into 439 the TCP payload in the ICMP Error message and modify the TCP header 440 accordingly so that when the ICMP Error is processed by the stack on 441 A, it is able to correctly co-relate with its internal 442 data-structures and act accordingly. 444 NATs that operate as described in this section are described as 445 "Supports ICMP Fixup Yes" (abbreviated SIF=Y). 447 NATs that do not are described as "Supports ICMP Fixup No" 448 (abbreviated SIF=N). 450 A NAT SHOULD support SIF=Y. 452 4. Security considerations 454 NATs are often deployed to achieve security goals. Most of the 455 recommendations and requirements in this document do not affect the 456 security properties of these devices, but a few of them do have 457 security implications and are discussed in this section. 459 When a fragmented packet is received from the external side and the 460 packets are out of order so that the initial fragment does not arrive 461 first, many systems simply discard the out of order packets. 463 Moreover, since some networks deliver small packets ahead of large 464 ones, there can be many out of order fragments. NATs that are 465 capable of delivering these out of order packets are possible but 466 they need to store the out of order fragments, which can open up a 467 DoS opportunity. Fragmentation has been a tool used in many attacks, 468 some involving passing fragmented packets through NATs and others 469 involving DoS attacks based on the state needed to reassemble the 470 fragments. NAT implementers SHOULD be aware of [TINY] and [FRAG] 472 5. IANA Considerations 474 There are no IANA considerations. 476 6. IAB Considerations 478 There are no IAB considerations. 480 7. Acknowledgements 482 The authors would like to thank Cullen Jennings & Nagendra Modadugu 483 for their review comments. 485 8. References 487 8.1 Normative References 489 [KEYWRD] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", RFC 2119, BCP 14, March 1997. 492 [UNSAF] Daigle, L. and IAB, "IAB Considerations for Unilateral 493 Self-Address Fixing (UNSAF) Across Network Address 494 Translation", RFC 3424, November 2002. 496 8.2 Informative References 498 [ASND] Reynolds, J. and J. Postel, "Assigned numbers", RFC 923, 499 October 1984. 501 [FRAG] Ziemba, G. and D. Reed, "Security Considerations for IP 502 Fragment Filtering", RFC 1858, October 1995. 504 [H323] "Packet-based Multimedia Communications Systems, ITU-T 505 Recommendation H.323", July 2003. 507 [HOST] Braden, R., "Requirements for Internet-Hosts - 508 Communication Layers", RFC 1122, October 1998. 510 [ICE] Rosenberg, J., "Interactive Connectivity Establishment 511 (ICE): A Methodology for Network Address Translator (NAT) 512 Traversal for the Session Initiation Protocol (SIP) 513 draft-ietf-mmusic-ice-02 (work in progress)", RFC , July 514 2004. 516 [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792, 517 September 1981. 519 [NAT-1] Srisuresh, P. and K. Egevang, "Traditional IP Network 520 Address Translator (Traditional NAT)", RFC 3022, January 521 2001. 523 [NAT-2] Srisuresh, P. and M. Holdrege, "IP Network Address 524 Translator (NAT) Terminology and Considerations", 525 RFC 2663, August 1999. 527 [NAT-3] Holdrege, M. and P. Srisuresh, "Protocol Complications 528 with the IP Network Address Translator", RFC 3027, 529 January 2001. 531 [P2P-1] Ford, B., Srisuresh, P. and D. Kegel, "Peer-to-Peer(P2P) 532 communication across Network Address Translators(NATs) 533 draft-ford-midcom-p2p-03 (work in progress)", June 2004. 535 [P2P-2] Ford, B. and D. Andersen, "Nat Check Web Site: 536 http://midcom-p2p.sourceforge.net", June 2004. 538 [RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. 539 Jacobson, "RTP: A Transport Protocol for Real-Time 540 Applications", RFC 3550, July 2003. 542 [SIP] Rosenberg, J., Schulzrinne,, H., Camarillo, G., Johnston, 543 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 544 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 546 [STUN-1] Rosenbert, J., Weinberger, J., Huitema, C. and R. Mahy, 547 "STUN - Simple Traversal of User Datagram Protocol (UDP) 548 Through Network Address Translators (NATs)", RFC 3489, 549 March 2003. 551 [STUN-2] Jennings, C., "NAT Classification Results using STUN, 552 draft-jennings-midcom-stun-results-01 (work in progress)", 553 July 2004. 555 [TINY] Miller, I., "Protection Against a Variant of the Tiny 556 Fragment Attack", RFC 3128, June 2001. 558 [UDP-REQ] Audet, F. and C. Jennings, "NAT Behavioral Requirements 559 for Unicast UDP, draft-ietf-behave-nat-00.txt 560 (work-in-progress)", January 2005. 562 [V4-REQ] Baker, F., "Requirements for IP Version 4 Routers", 563 RFC 1812, June 1995. 565 Authors' Addresses 567 Senthil Sivakumar 568 Cisco Systems, Inc. 569 170 West Tasman Dr. 570 San Jose, CA 95134 571 USA 573 Phone: 574 Email: ssenthil@cisco.com 576 Kaushik Biswas 577 Cisco Systems, Inc. 578 170 West Tasman Dr. 579 San Jose, CA 95134 580 USA 582 Phone: +1 408 525 5134 583 Email: kbiswas@cisco.com 585 Bryan Ford 586 M.I.T. 587 Laboratory for Computer Science 588 77 Massachusetts Ave. 589 Cambridge, MA 02139 590 USA 592 Phone: 1-617-253-5261 593 Email: baford@mit.edu 595 Intellectual Property Statement 597 The IETF takes no position regarding the validity or scope of any 598 Intellectual Property Rights or other rights that might be claimed to 599 pertain to the implementation or use of the technology described in 600 this document or the extent to which any license under such rights 601 might or might not be available; nor does it represent that it has 602 made any independent effort to identify any such rights. Information 603 on the procedures with respect to rights in RFC documents can be 604 found in BCP 78 and BCP 79. 606 Copies of IPR disclosures made to the IETF Secretariat and any 607 assurances of licenses to be made available, or the result of an 608 attempt made to obtain a general license or permission for the use of 609 such proprietary rights by implementers or users of this 610 specification can be obtained from the IETF on-line IPR repository at 611 http://www.ietf.org/ipr. 613 The IETF invites any interested party to bring to its attention any 614 copyrights, patents or patent applications, or other proprietary 615 rights that may cover technology that may be required to implement 616 this standard. Please address the information to the IETF at 617 ietf-ipr@ietf.org. 619 Disclaimer of Validity 621 This document and the information contained herein are provided on an 622 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 623 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 624 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 625 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 626 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 627 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 629 Copyright Statement 631 Copyright (C) The Internet Society (2005). This document is subject 632 to the rights, licenses and restrictions contained in BCP 78, and 633 except as set forth therein, the authors retain all their rights. 635 Acknowledgment 637 Funding for the RFC Editor function is currently provided by the 638 Internet Society.