idnits 2.17.1 draft-sivakumar-behave-nat-tcp-req-02.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.5 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 605. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([BEH-UDP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 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 20, 2005) is 6764 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: 'ASND' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'ICMP' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'NAT-CHK' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'NAT-CMPL' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'UNSAF' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'V4-REQ' is defined on line 542, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2663 ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 923 (ref. 'ASND') (Obsoleted by RFC 943) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 BEHAVE P. Srisuresh 2 Internet-Draft Consultant 3 Expires: April 23, 2006 S. Sivakumar 4 K. Biswas 5 Cisco Systems 6 B. Ford 7 M.I.T 8 October 20, 2005 10 NAT Behavioral Requirements for TCP 11 draft-sivakumar-behave-nat-tcp-req-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 23 Internet-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 April 23, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 NAT devices are available from a number of vendors and are in use by 45 several residential and enterprise users. Yet, there is much 46 variation in how the NAT devices work. Application developers, 47 network administrators and users of NAT devices seek some level of 48 uniformity and predictability in how various of the NAT devices 49 operate. The objective of this document is to specify the 50 operational and behavioral requirements on the NAT devices while 51 processing TCP packets. A NAT device that conforms to the 52 requirements listed in the document will bring predictability in how 53 NATs operate with regard to TCP packet processing. A NAT device is 54 said to be IETF behave compliant when it complies with the 55 requirements outlined in this document and other companion BEHAVE 56 documents like [BEH-UDP], which outlines the requirements for 57 processing UDP and some generic requirements. 59 Table of Contents 61 1. Introduction & Scope . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. TCP requirements . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1 Address Mapping and/or TCP Port Mapping . . . . . . . . . 3 65 3.2 Timeouts for TCP NAT Sessions . . . . . . . . . . . . . . 4 66 3.3 Handling Inbound SYN packets for an exisitng NAT TCP 67 Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.4 Handling Inbound SYN packets for non-existent TCP 69 connections . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.5 Denial of Service (DoS) attacks . . . . . . . . . . . . . 6 71 3.6 NAT initiated TCP keep-alives . . . . . . . . . . . . . . 7 72 3.7 NAT initiated RST packets . . . . . . . . . . . . . . . . 7 73 4. Hints to implementers . . . . . . . . . . . . . . . . . . . . 8 74 4.1 Light weight TCP state machine is a common practice . . . 8 75 4.2 TCP segment processing in NATs supporting ALGs . . . . . . 9 76 4.3 Adjusting Sequence Acknowledgement Numbers . . . . . . . . 10 77 5. TCP behavioral requirements summary . . . . . . . . . . . . . 10 78 6. Security considerations . . . . . . . . . . . . . . . . . . . 11 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 82 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 84 Intellectual Property and Copyright Statements . . . . . . . . 14 86 1. Introduction & Scope 88 NAT implementations vary amongst vendors in how they handle TCP 89 packets. This document defines the operational and behavioral 90 requirements that the NAT devices should comply with while processing 91 TCP packets. In addition, a section is devoted to describing hints 92 to implementers in deciphering some of the requirements. 94 The requirements outlined here are applicable across all NAT types 95 identified in [RFC2663], most importantly the Traditional NAT, as 96 described in [RFC3022]. This document does not mandate a specific 97 implementation choice. Behavioral requirements for UDP are covered 98 in [BEH-UDP]. 100 Application Layer Gateways (ALGs) are out of scope for this document. 101 However, hints on how a NAT could be extended to support ALGs are 102 discussed under the hints section. Permissible ALGs are listed in 103 [BEH-UDP] . 105 2. Terminology 107 Definitions for the NAT terms used throughout the document may be 108 found in [RFC2663]. TCP terms used in the document are as per the 109 definitions given in [TCP]. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. TCP requirements 117 This section lists the behavioral requirements of a NAT device when 118 processing TCP packets. Associated with each requirement, the 119 rationale behind the requirement is discussed in detail. 121 3.1 Address Mapping and/or TCP Port Mapping 123 NAT provides transparent routing between address realms by assigning 124 realm-specific endpoint locator(s), as packets pertaining to a 125 session cross realm boundaries. Several applications use the same 126 endpoint to establish multiple simultaneous sessions. Many 127 peer-to-peer applications use the public endpoint registration of 128 peering hosts to initiate sessions into. 130 In order to support peer-to-peer applications and applications that 131 entertain multiple simultaneous sessions using the same TCP endpoint, 132 NAT MUST retain the association it assigned to an endpoint at the 133 start of the first session and reuse the same endpoint association 134 when multiple sessions using the same endpoint are routed through the 135 NAT device. Such a mapping between endpoints can occur when a NAT 136 device maintains Address Mappings and/or TCP Port Mappings. 138 REQ-1: A NAT device MUST maintain Address and/or TCP Port Mappings 140 3.2 Timeouts for TCP NAT Sessions 142 As may be noted from [TCP], an end-to-end TCP session in its lifetime 143 goes through three phases, namely Connecting, Established, and 144 Closing. Each end-to-end TCP session is managed through a separate 145 NAT Session within NAT. The NAT Session must be capable of 146 identifying the current phase of the end-to-end TCP session it 147 represents and use an idle timeout period that is appropriate for the 148 current phase. 150 Connecting Phase: An end-to-end TCP session is said to enter the 151 Connecting Phase when either of the endpoints sends the first SYN for 152 the TCP session and exit the phase upon completion of 3-way SYN 153 handshake. The idle timeout used by the NAT Session during this 154 phase is called the SYN timeout. SYN timeout needs to be relatively 155 short, so NAT can protect itself (and, potentially, the hosts behind 156 it) from SYN flood attacks. A NAT session is freed when the SYN 157 timeout expires 159 Established Phase: An end-to-end TCP session is said to enter the 160 Established Phase upon completion of 3-way handshake and exit the 161 phase upon seeing the first FIN or RST for the session. The idle 162 timeout used by the NAT during this phase of the end-to-end TCP 163 session is called the Session timeout. Session timeout needs to be 164 relatively long, so the NAT Session can retain state of the 165 end-to-end TCP Session within itself even after long periods of 166 inactivity in the session. Long periods of inactivity is not 167 uncommon with applications such as telnet and ftp. When Session 168 timer expires, the corresponding NAT Session may be freed (or) the 169 NAT Session may assume the TCP connection to have transitioned into 170 the Closing phase. 172 Closing Phase: An end-to-end TCP session is said to enter the Closing 173 Phase when either of the endpoitns sends the first FIN or RST for the 174 session. Alternately, the NAT Session may deem the TCP session to 175 have entered this phase when the TCP Session timer expires. The idle 176 timeout used by the NAT Session during this phase is called the Close 177 timeout. Close timeout is relatively short to ensure that the ACKs 178 for the final FINs on a gracefully-closed TCP session had a chance to 179 propagate in both directions, and to allow time for either endpoint 180 to re-open a recently closed or reset TCP session if desired. A NAT 181 device MAY opt to have different Close timeouts depending upon 182 whether the Closing phase is triggered by FIN or not. Once the Close 183 timer expires, the NAT Session will be freed. 185 The following requirements apply to the NAT's timeouts: 187 REQ-2: A NAT device MUST be capable of identifying the current phase 188 of an end-to-end TCP session and use different idle timeout periods 189 for each phase of the TCP Session. The timeouts used for each phase 190 SHOULD be admin configurable. The recommended value for SYN timeout 191 is 30 seconds. The recommended value for TCP session timeout is 30 192 minutes. Lastly, the recommended value for close timeout is 2 x MSL 193 (Maximum Segment Lifetime) or 4 minutes. 195 3.3 Handling Inbound SYN packets for an exisitng NAT TCP Session 197 A NAT device might allow sessions to be initiated in just one 198 direction and not the other. However, once a NAT session is created 199 for a permitted TCP session, and the TCP session is in Connecting 200 phase, the NAT device MUST let the SYN packets through in either 201 direction. This is because TCP protocol fundamentally permits 202 simultaneous TCP Open from either end. A number of TCP based 203 Peer-to-peer applications utilize the simultaneous TCP open technique 204 to establish peer-to-peer connections. 206 If the TCP session is in established or Closing phases and a new SYN 207 packet arrives, the NAT device should assume that the TCP session has 208 re-entered the Connecting phase and initiate SYN timer. In summary, 209 a NAT device MUST let the SYN packets through once a NAT Session is 210 established for the TCP connection. 212 The following requirement applies to SYN packets arriving during 213 Connecting, Established or Closing phases of a TCP connection. 215 REQ-3: A NAT device MUST let the SYN packets through when the SYN 216 Packets are received on a TCP connection which is in one of 217 Connecting, Established or Closing phases. 219 3.4 Handling Inbound SYN packets for non-existent TCP connections 221 Inbound SYN packets MUST be permitted on all NAT devices so long as 222 an outbound SYN packet has been initiated first on the same 223 connection tuple via the NAT device (and the NAT device has a NAT 224 Session created for it). Inbound SYN packets are permitted, even 225 without an outbound SYN on bi-directional NAT and load share NAT 226 devices. In addition, NAT devices configured with a static 227 inbound/birectional address or port mapping that matches the 228 connection tuple of the inbound SYN packets MUST also permit the SYN 229 packets. 231 In all other cases, the NAT devices MUST simply drop the inbound SYN 232 packets. The NAT device should not send RST packet or an ICMP error 233 packet back to the sender. However, there is an exception to this 234 behavior. A NAT device sharing the TCP ports of the external IP 235 address between NAT function and its own endhost applications may 236 choose to respond with a RST when an inbound SYN is directed to one 237 of the endhost TCP ports. However, when the inbound SYN is directed 238 to one of the NAT function TCP ports, the response should be as 239 described earlier for a NAT device. 241 The following requirement applies to incoming SYN packets. 243 REQ-4: A NAT device MUST let the incoming SYN packets through so long 244 as an outbound SYN packet has been initiated first on the same 245 connection tuple via the NAT device. NATs MUST permit inbound SYN 246 even without an outbound SYN on bi-directional NAT & load share NAT 247 devices. NATs MUST NOT generate RST or ICMP error packet back to the 248 sender upon inbound SYN processing. 250 3.5 Denial of Service (DoS) attacks 252 Since NAT devices are Internet hosts, they can be the target of a 253 number of different DoS attacks, such as SYN floods and RST attacks. 254 NAT devices SHOULD employ the same sort of protection techniques as 255 Internet-based servers do. 257 Let us examine two types of Dos attacks that are well known with 258 regard to TCP connections. A SYN flood attack is a DoS attack in 259 which one or more external entities initiate a number of simultaneous 260 TCP connections using a SYN packet, but donot complete the 3-way 261 handshake. Naturally, a NAT device is prone to this type of attack 262 when the NAT device is in the traversal path of the SYN attacks. One 263 technique to defend against this type of attack is to ensure that the 264 NAT device employs a short SYN timeout and reduce the timeout even 265 further when it determines it is under SYN flood attack. 267 RST attack is another well known DoS attack. An attacker could 268 simply forge a number of RST packets for a variety of Established TCP 269 connections and cause the NAT sessions to be reset and freed. One 270 technique to defend against this type of attack is to validate the 271 RST packet and not let the packet through unless the sequence number 272 used in the RST packet is within the expected TCP window size of the 273 TCP Session. 275 REQ-5: A NAT device SHOULD employ necessary techniques to defend 276 against well known DoS attacks the endhosts are subject to. 278 3.6 NAT initiated TCP keep-alives 280 When session timer expires for a NAT session, that indicates that the 281 associated TCP session has been idle with no activity for the period 282 matching the TCP Session timeout. Sensing no activity, NAT could 283 free up the NAT Session and remove the state associated with the TCP 284 connection within the NAT device. However, doing so would violate 285 the end-to-end reliability of the IP network. Ideally speaking, IP 286 network is not supposed to retain any hard state. Unfortunately, a 287 NAT device retains session state within itself (via the NAT Sessions) 288 and this information should not be dropped without confirming that 289 one or both halfs of the TCP session are alive. 291 A NAT device may validate the liveness of a TCP client by sending 292 keep-alive packets to the TCP client using the technique described in 293 section 4.2.3.6 of [HOST]. If the NAT device receives an ACK or 294 other traffic from the internal endpoint, it resets the session timer 295 and assumes the connection to be in ôEstablished" phase. If the NAT 296 device receives a RST from the TCP client, the NAT device transitions 297 the TCP connection into the "closing" phase and initiates Close 298 timeout for the session. If the NAT device receives no response from 299 the internal endpoint after sending several keep-alive packets, the 300 NAT assumes that the internal endpoint is dead and again assumes that 301 the TCP connection has entered the "closing" phase. 303 Below is the keep-alive requirement on NAT devices 305 REQ-6: When session timer expires for an established TCP connection, 306 the NAT device MAY initiate sending TCP keep-alives to the clients 307 prior to freeing up the Session state within NAT. 309 3.7 NAT initiated RST packets 311 When session timer expires for a NAT session, it is an indication 312 that the associated TCP connection has been idle with no activity for 313 the duration matching the TCP Session timeout. Sensing no activity, 314 NAT could free up the NAT Session and remove the state associated 315 with the TCP connection. When this happens, the two TCP endpoints in 316 the network, which might potentially be alive, may be unable to 317 resume activity on the connection because the NAT device enroute no 318 longer has the state information pertaining to the end-to-end TCP 319 connection. This can be problematic for application servers that 320 impose limits on the number of connections a user might be allowed to 321 setup in a given period of time. After a few zombie sessions, the 322 server might deny access to its clients, when the connection count on 323 the server exceeds the set limit. The Server has no way to know that 324 some of the client sessions it retains are zombies and shouldnt be 325 counted as real. In such a situation, the NAT device sending a RST 326 packet to both parties will alert the two parties of the connection 327 going away. And, the application servers are not fooled with zombie 328 sessions. Note, a NAT device may choose to send RST packets after it 329 probed the TCP client with TCP Keep-alive packets. 331 Below is the requirement on sending TCP RST packet 333 REQ-7: When Session timer expires on an Established TCP connection, 334 the NAT device SHOULD send a RST packet to both halfs of a TCP 335 connection and enter Closing state on the connection prior to freeing 336 up the NAT Session. 338 4. Hints to implementers 340 4.1 Light weight TCP state machine is a common practice 342 Unlike UDP, TCP sessions are fundamentally unicast in nature and 343 multiple NAT Sessions cannot be aggregated. NAT devices maintain a 344 separate NAT Session to track each end-to-end TCP connection that 345 traverses the NAT device. A NAT device needs to be able to track the 346 current phase of a TCP session at any given time so an idle timer for 347 a duration appropriate for the phase is initiated. Further, a NAT 348 device defending against even the most trivial type of DoS attack 349 will require the knowledge of TCP sequence number and window Size to 350 defend itself against such attacks. As such, many vendors use a 351 light-weight state machine within the NAT Session to track the 352 current state of a TCP connection. Items tracked within the state 353 machine would include the last acknowledged sequence number from 354 either half of the TCP session, TCP window size, and the TCP 355 connection phase. 357 The State machine within a NAT Session enters the Connecting state 358 when NAT sees the first SYN packet for that session. The state 359 machine transitions from the Connecting to Established state once the 360 3-way handshake is completed. The state machine transitions from the 361 Established state to the Closing state when the NAT observes a 362 FIN/FIN ACK sequence, representing graceful shutdown reached 363 cooperatively by both endpoints, or when the NAT observes a RST from 364 either endpoint, representing a non-graceful connection reset forced 365 by one endpoint. The NAT device deletes the NAT session after the 366 Close timer expires while the TCP connection is in the Closing state. 368 In addition to the basic state information, NAT devices also record 369 information about TCP sequence numbers and acknowledgment numbers on 370 the traversing TCP packets, so as to defend against DOS attacks 371 (REQ-5). If the NAT contains built-in ALGs that can change the 372 payload length of TCP packets, effectively inserting or removing 373 bytes from the TCP stream in one or both directions, then the NAT 374 MUST adjust the sequence numbers in all subsequent packets exchanged 375 in either direction to reflect these inserted or removed bytes. 377 4.2 TCP segment processing in NATs supporting ALGs 379 The following discussion on TCP segment processing is relevant only 380 when a NAT device includes support for one or more embedded ALGs. 381 Many NAT devices have the ALG for FTP enabled by default. A NAT 382 device may receive payload relevant to an ALG in multiple TCP 383 segments. Consider the following diagram where the MSS is set to 536 384 bytes in each endpoint of the TCP connection. 386 +-------------------+ +-------------------+ 387 | Application-Layer | | Application-Layer | 388 +-------------------+ +-------------------+ 389 | TCP [MSS = 536] | | TCP [MSS = 536] | 390 +-------------------+ +-------------------+ 391 | IP | | IP | 392 +-------------------+ +-------------------+ 393 | Lower-Layer | | Lower-Layer | 394 | | | | 395 +-------------------+ +-------------------+ 396 End-host -1 End-host -2 397 | +--------+ | 398 +-------------------| NAT |----------------+ 399 +--------+ 401 Say the application layer on end-host-1 is sending a payload of size 402 600 bytes. The payload will be sent to the recipient in 2 TCP 403 segments as follows, because the MSS is set to 536 bytes. 405 TCP Segment 1: 406 +---------+------------------------------------------+----------+ 407 |IP header| TCP header[Payload-Len=536,PUSH flag = 0]|Appl-data1| 408 +---------+------------------------------------------+----------+ 410 TCP Segment 2: 411 +---------+-----------------------------------------+----------+ 412 |IP header| TCP header[Payload-Len=64,PUSH flag = 1]|Appl-data2| 413 +---------+-----------------------------------------+----------+ 415 A NAT device enroute may receive the TCP segments either in order or 416 out of order. In either case, the NAT device needs to assemble the 417 individual segments into a contiguous payload and make the complete 418 payload available for the ALG to process prior to forwarding the 419 segments transparently to another realm. 421 In order to do this, a NAT device is required to enforce some type of 422 queuing mechanism such that when all relevant segments of a payload 423 are received, it is able to reassemble the TCP segments and make the 424 contiguous payload available for ALG processing. 426 For in-order segments, the NAT device needs to send a TCP ACK for the 427 initial segments it received, but didnt forward to the recipient 428 enpoint. This is done so the NAT device can prompt the sending 429 endpoint to continue to send the remaining TCP segments. 431 4.3 Adjusting Sequence Acknowledgement Numbers 433 The following discussion on adjusting Sequence and Acknowledgement 434 numbers is relevant only when a NAT device includes support for one 435 or more embedded ALGs. 437 When the embedded ALG on a NAT device modifies the TCP payload, the 438 corresponding payload may increase or decrease in size. As a result, 439 the NAT device is expected to remember the delta change and adjust 440 sequence/acknowledgement numbers in all subsequent TCP packets within 441 the session. Implementors of NAT devices often keep the delta 442 changes in payload due to ALG processing within the NAT Session as an 443 extension of the state information the NAT device keeps. 445 5. TCP behavioral requirements summary 447 Below is a summary of all the TCP behavioral requirements. 449 REQ-1: A NAT device MUST maintain Address and/or TCP Port Mappings. 451 REQ-2: A NAT device MUST be capable of identifying the current phase 452 of an end-to-end TCP session and use different idle timeout periods 453 for each phase of the TCP Session. 455 The timeouts used for each phase SHOULD be admin configurable. The 456 recommended value for SYN timeout is 30 seconds. The recommended 457 value for TCP session timeout is 30 minutes. Lastly, the recommended 458 value for close timeout is 2 x MSL (Maximum Segment Lifetime) or 4 459 minutes. 461 REQ-3: A NAT device MUST let the SYN packets through when the SYN 462 Packets are received on a TCP connection which is in one of 463 Connecting or Closing phase. 465 REQ-4: A NAT device MUST let the incoming SYN packets through so long 466 as an outbound SYN packet has been initiated first on the same 467 connection tuple via the NAT device. NATs MUST permit inbound SYN 468 even without an outbound SYN on bi-directional NAT & load share NAT 469 devices. NATs MUST NOT generate RST or ICMP error packet back to the 470 sender upon inbound SYN processing. 472 REQ-5: A NAT device SHOULD employ necessary techniques to defend 473 against well known DoS attacks the endhosts are subject to. 475 REQ-6: When session timer expires for an Established TCP connection, 476 the NAT device MAY initiate sending TCP keep-alives to the clients 477 prior to freeing up the Session state within NAT. 479 REQ-7: When session timer expires for an Established TCP connection, 480 the NAT device SHOULD send a RST packet to both halfs of a TCP 481 connection and enter Closing state on the connection prior to freeing 482 Up the NAT Session. 484 6. Security considerations 486 The security considerations described in [RFC2663] for all 487 variations of NATs are applicable here. The recommendations and 488 requirements in this document do not effect the security properties 489 of the NAT devices adversely. 491 7. Acknowledgements 493 The authors would like to thank Nagendra Modadugu, Saikat Guha and 494 other BEHAVE workgroup members for their valuable feedback and 495 comments. 497 8. References 499 8.1 Normative References 501 [HOST] Braden, R., "Requirements for Internet-Hosts - 502 Communication Layers", RFC 1122, October 1998. 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", RFC 2119, BCP 14, March 1997. 507 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 508 Translator (NAT) Terminology and Considerations", 509 RFC 2663, August 1999. 511 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 512 Address Translator (Traditional NAT)", RFC 3022, January 513 2001. 515 [TCP] Postel, J., "Transmission Control Protocol (TCP) 516 Specification", RFC 793, STD 7, September 1981. 518 8.2 Informative References 520 [ASND] Reynolds, J. and J. Postel, "Assigned numbers", RFC 923, 521 October 1984. 523 [BEH-UDP] Audet, F. and C. Jennings, "NAT Behavioral Requirements 524 for Unicast UDP, draft-ietf-behave-nat-00.txt 525 (work-in-progress)", January 2005. 527 [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792, 528 September 1981. 530 [NAT-CHK] Ford, B. and D. Andersen, "Nat Check Web Site: 531 http://midcom-p2p.sourceforge.net", June 2004. 533 [NAT-CMPL] 534 Holdrege, M. and P. Srisuresh, "Protocol Complications 535 with the IP Network Address Translator", RFC 3027, 536 January 2001. 538 [UNSAF] Daigle, L. and IAB, "IAB Considerations for Unilateral 539 Self-Address Fixing (UNSAF) Across Network Address 540 Translation", RFC 3424, November 2002. 542 [V4-REQ] Baker, F., "Requirements for IP Version 4 Routers", 543 RFC 1812, June 1995. 545 Authors' Addresses 547 Pyda Srisuresh 548 Consultant 549 20072 Pacifica Dr. 550 Cupertino, CA 95014 551 USA 553 Phone: (408)836-4773 554 Email: srisuresh@yahoo.com 555 Senthil Sivakumar 556 Cisco Systems, Inc. 557 170 West Tasman Dr. 558 San Jose, CA 95134 559 USA 561 Phone: 562 Email: ssenthil@cisco.com 564 Kaushik Biswas 565 Cisco Systems, Inc. 566 170 West Tasman Dr. 567 San Jose, CA 95134 568 USA 570 Phone: +1 408 525 5134 571 Email: kbiswas@cisco.com 573 Bryan Ford 574 M.I.T. 575 Laboratory for Computer Science 576 77 Massachusetts Ave. 577 Cambridge, MA 02139 578 USA 580 Phone: 1-617-253-5261 581 Email: baford@mit.edu 583 Intellectual Property Statement 585 The IETF takes no position regarding the validity or scope of any 586 Intellectual Property Rights or other rights that might be claimed to 587 pertain to the implementation or use of the technology described in 588 this document or the extent to which any license under such rights 589 might or might not be available; nor does it represent that it has 590 made any independent effort to identify any such rights. Information 591 on the procedures with respect to rights in RFC documents can be 592 found in BCP 78 and BCP 79. 594 Copies of IPR disclosures made to the IETF Secretariat and any 595 assurances of licenses to be made available, or the result of an 596 attempt made to obtain a general license or permission for the use of 597 such proprietary rights by implementers or users of this 598 specification can be obtained from the IETF on-line IPR repository at 599 http://www.ietf.org/ipr. 601 The IETF invites any interested party to bring to its attention any 602 copyrights, patents or patent applications, or other proprietary 603 rights that may cover technology that may be required to implement 604 this standard. Please address the information to the IETF at 605 ietf-ipr@ietf.org. 607 Disclaimer of Validity 609 This document and the information contained herein are provided on an 610 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 611 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 612 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 613 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 614 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 615 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 617 Copyright Statement 619 Copyright (C) The Internet Society (2005). This document is subject 620 to the rights, licenses and restrictions contained in BCP 78, and 621 except as set forth therein, the authors retain all their rights. 623 Acknowledgment 625 Funding for the RFC Editor function is currently provided by the 626 Internet Society.