1 / 17

NAT requirements for TCP (BEHAVE WG)

NAT requirements for TCP (BEHAVE WG). draft-sivakumar-behave-nat-tcp-req-00.txt. S.Sivakumar , K.Biswas , B.Ford. Scope. Recommendations to NAT implementors as pertaining to TCP session processing.

Albert_Lan
Download Presentation

NAT requirements for TCP (BEHAVE WG)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. NAT requirements for TCP(BEHAVE WG) draft-sivakumar-behave-nat-tcp-req-00.txt S.Sivakumar, K.Biswas, B.Ford IETF 62, Minneapolis

  2. Scope • Recommendations to NAT implementors as pertaining to TCP session processing. • At the time of writing of this draft, <draft-ford-behave-gen-00.txt> was not available. Recommendations that are not specific to TCP or UDP will be moved to <draft-ford-behave-gen-00.txt>, pending WG consensus. IETF 62, Minneapolis

  3. Req # 1 – TCP State Machine(SM) • TCP NAT Sessions MUST be stateful. NAT MUST use light-weight TCP State Machine for managing timers, seq/ack adjustments etc. • TCP NAT Sessions can be light-weight and must carry three states at a minimum – STARTUP, ACTIVE, CLOSING. • A TCP NAT Session enters STARTUP state upon seeing the first SYN for a TCP session. • A TCP NAT Session enters ACTIVE state upon completing 3-way handshake. • A TCP NAT Session enters CLOSING state upon seeing FIN or RST for the session. IETF 62, Minneapolis

  4. Req # 2 - Address/Port Binding • NAT MUST maintain Address Binding and/or TCP Port Binding. Multiple TCP NAT Sessions could reuse the same TCP Port Binding. • The filtering behavior of NAT for TCP sessions is as dictated by the NAT type (traditional, Bi-directional, Twice NAT types). • Port parity, Port-contiguity - Some suggestions have been made to specifically mention about port-parity, port-contiguity not being applicable to TCP traffic. Needs discussion? IETF 62, Minneapolis

  5. Req # 3 – TCP SM Timeouts • NAT MUST maintain timeouts for different states of state machine in a TCP NAT Session.The timeouts MUST be configurable. • NAT MUST maintain SYN Timer to protect against SYN flood-attacks in STARTUP state. Suggested timeout: 30 to 60 secs. • NAT MUST maintain Session Timer to track idle-time on active TCP sessions. Suggested timeout: 60 mins if no KeepAlive implemented and 120 minutes if KeepAlive implemented. • NAT MUST maintain Close Timer, to allow for proper session termination, and to allow re-opening a recently closed or reset TCP session if desired. NAT can delete the TCP NAT session Upon expiry of Close timer, or enter STARTUP state and initiate SYN timer upon receipt of SYN. Suggested timeout: 2xMSL (Maximum Segment Lifetime) to 60 seconds. IETF 62, Minneapolis

  6. Req # 3 – TCP Keep-alive • Upon Session Timer expiry, NAT SHOULD enter a "probe" state and send TCP keep-alive packets to internal endpoint. • Upon receiving ACK or data traffic, NAT should reset Session Timer and remain in ACTIVE state. • Upon receiving RST, NAT should forward the RST to External Server, enter CLOSING state and start Close Timer. • Upon not receiving any response after a few retries, NAT should send RST to both parties, enter CLOSING state and start Close Timer. IETF 62, Minneapolis

  7. Req # 4 - Port Reservation • NAT’s TCP Port space is shared by 2 functions: (a) Router’s local end-host functionality (b) Router’s NAT functionality • NAT MUST NOT use a single TCP port for both NAT’d sessions and local application sessions at the same time. • Recommendation: NAT implementers SHOULD set aside port-blocks for end-host functionality vs. NAT functionality. IETF 62, Minneapolis

  8. Req # 5 - IP Frags,TCP Segments • IP Fragments: Suggest moving this to draft-ford-behave-gen-00.txt • TCP Segment processing - Recommended only when ALGs are enabled on the same NAT device. Not mandatory requirement. • NAT SHOULD support TCP Segments received out of order. TCP Segment processing SHOULD be as described in the draft. • NAT SHOULD enforce sequencing on the out-of-order TCP segments such that NAT reassembles the TCP segments prior to handing off to an ALG. • NAT SHOULD send TCP ACK to the endpoint (when a segment is out of order) for obtaining subsequent segments from the endpoint. IETF 62, Minneapolis

  9. Req # 6 - Seq/Ack # adjustment • Recommendation for NAT only when ALGs are enabled on the same device. Not mandatory requirement. • If NAT has ALG enabled, the ALG might cause application-payload to increase/decrease in size. The ALG will need to change seq/ack number in the TCP header & save this information along with the delta of change in the TCP NAT Session, so as to adjust subsequent TCP packets of the session. • If NAT has ALG enabled, the TCP NAT Sessions SHOULD be extended to include [seq-delta, ack-delta] info in the TCP NAT Session. IETF 62, Minneapolis

  10. Req # 7 - ICMP Err-Msg handling • NAT SHOULD fix the embedded payload in the ICMP Error messages. This is not specific to TCP. Suggest moving this to draft-ford-behave-gen-00.txt. IETF 62, Minneapolis

  11. New Reqs (Not included yet) • NAT must generate & process PMTU msgs for TCP packets • TCP packets often have DF(Donot Fragment) bit set & will require devices enroute to not fragment TCP segments. If MTUs donot match, NAT MUST send a destination unreachable ICMP message with suggested MTU to the sender & drop the TCP packet. • NAT must also honor the ICMP destination unreachable messages it receives from intermediate nodes in either realm and forward to appr. end-node IETF 62, Minneapolis

  12. Wrap-up Comments/Suggestions ? (We plan to summarize the requirements at the end, and move the text common to both TCP & UDP to draft-ford-behave-gen-00.txt, based on WG inputs ) Accept as WG item ? IETF 62, Minneapolis

  13. Differences between 2 TCP submissions Both drafts (Sivakumar-draft & Modadugu-draft) are similar in content. So, common Reqs are not listed. Below are the main differences: • TCP State Machine requirement sivakumar-draft states that NAT MUST maintain a light-weight TCP state-machine. modadugu-draft doesnot mandate this. IETF 62, Minneapolis

  14. Differences between 2 TCP submissions • Port reservation requirement sivakumar-draft recommends that NAT SHOULD set aside ports for local TCP applications running on the box and avoid port-number conflicts. modadugu-draft does not provide a recommendation. • TCP Timers requirement sivakumar-draft recommends that NAT MUST maintain SYN, Session & Close timers modadugu-draft discusses timers, but does not list them as a requirement. IETF 62, Minneapolis

  15. Differences between 2 TCP submissions • TCP KeepAlive requirement sivakumar-draft recommends this as a SHOULD, without making this a mandatory requirement modadugu-draft does not offer a recommendation (author believes this is not needed). • TCP Segments handling requirement sivakumar-draft recommends this as a SHOULD only when ALG enabled on the NAT. modadugu-draft does not offer a recommendation (Author believes this is not needed) IETF 62, Minneapolis

  16. Differences between 2 TCP submissions • Allow Incoming SYN requirement sivakumar-draft does not offer an explicit recommendation on this. modadugu-draft recommends that NAT MUST allow incoming SYN while a Nat Session is alive (ex: in CLOSING state) • Paired Source-IP address pooling behavior requirement sivakumar-draft does not offer a recommendation on this. (draft-ford-behave-gen-00.txt covers this) modadugu-draft recommends that a NAT SHOULD support IP address pooling behavior of “Paired”, if NAT supports IP address pooling. IETF 62, Minneapolis

  17. Differences between 2 TCP submissions • Finally, some stylistic differences: Sivakumar-draft lists the requirements as you go along. Summary requirements intended to be listed at the end. Modadugu-draft lists the requirments first similar to behave-udp draft, followed by discussion on the requirements. IETF 62, Minneapolis

More Related