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

Slides:



Advertisements
Similar presentations
CSC458 Programming Assignment II: NAT Nov 7, 2014.
Advertisements

Umut Girit  One of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer.
CISCO NETWORKING ACADEMY Chabot College ELEC Transport Layer (4)
Computer Security and Penetration Testing
TCP - Part I Relates to Lab 5. First module on TCP which covers packet format, data transfer, and connection management.
CCNA – Network Fundamentals
Transmission Control Protocol (TCP)
Guide to TCP/IP, Third Edition
Leone From global measurements to local management UC3M: inHome NAT detection RFC recommender ICMP UDP TCP Miguel Ángel Díaz, Francisco Valera.
UDP & TCP Where would we be without them!. UDP User Datagram Protocol.
1 TCP - Part I Relates to Lab 5. First module on TCP which covers packet format, data transfer, and connection management.
1 CS 4396 Computer Networks Lab Transmission Control Protocol (TCP) Part I.
1 Chapter 3 TCP and IP. Chapter 3 TCP and IP 2 Introduction Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) User Datagram Protocol.
Transport Layer – TCP (Part1) Dr. Sanjay P. Ahuja, Ph.D. Fidelity National Financial Distinguished Professor of CIS School of Computing, UNF.
Security implications of Network Address Translators (NATs) (draft-gont-behave-nat-security) Fernando Gont Pyda Srisuresh UTN/FRH EMC Corporation 76th.
1 Internet Networking Spring 2004 Tutorial 13 LSNAT - Load Sharing NAT (RFC 2391)
IP Basics. Physical Link Network IP ARP ICMP RoutingTables.
CSEE W4140 Networking Laboratory Lecture 6: TCP and UDP Jong Yul Kim
IP Basics. IP encapsulates TCP IP packets travel through many different routers (hops) before reaching it’s destination MTU variation at the physical.
1 CCNA 2 v3.1 Module Intermediate TCP/IP CCNA 2 Module 10.
FIREWALLS & NETWORK SECURITY with Intrusion Detection and VPNs, 2 nd ed. 6 Packet Filtering By Whitman, Mattord, & Austin© 2008 Course Technology.
WXES2106 Network Technology Semester /2005 Chapter 8 Intermediate TCP CCNA2: Module 10.
TCP/IP Basics A review for firewall configuration.
Transport Layer TCP and UDP IS250 Spring 2010
Chapter 4 OSI Transport Layer
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #12 LSNAT - Load Sharing NAT (RFC 2391)
IP/ICMP Translation Algorithm (IIT) Xing Li, Congxiao Bao, Fred Baker
Gursharan Singh Tatla Transport Layer 16-May
IOS Firewall IOS: Cisco’s Internetwork Operating System (the primary system running on Cisco’s routers) IOS Firewall: a stateful packet-filter firewall.
Guide to TCP/IP, Third Edition
Lab 5: NAT CS144 Review Session 7 November 13 th, 2009 Roger Liao.
Packet Filtering. 2 Objectives Describe packets and packet filtering Explain the approaches to packet filtering Recommend specific filtering rules.
1 IP: putting it all together Part 2 G53ACC Chris Greenhalgh.
Chapter 6: Packet Filtering
TCP Lecture 13 November 13, TCP Background Transmission Control Protocol (TCP) TCP provides much of the functionality that IP lacks: reliable service.
CS332, Ch. 26: TCP Victor Norman Calvin College 1.
TCP1 Transmission Control Protocol (TCP). TCP2 Outline Transmission Control Protocol.
Authentication Mechanism for Port Control Protocol (PCP) draft-wasserman-pcp-authentication-01.txt Margaret Wasserman Sam Hartman Painless Security Dacheng.
Chapter 12 Transmission Control Protocol (TCP)
 network appliances to filter network traffic  filter on header (largely based on layers 3-5) Internet Intranet.
© 2006 Cisco Systems, Inc. All rights reserved. Cisco IOS Threat Defense Features.
Computer Science and Engineering Computer System Security CSE 5339/7339 Session 25 November 16, 2004.
NAT/Firewall Behavioral Requirements draft-audet-nat-behave-00 François Audet - Cullen Jennings -
4343 X2 – The Transport Layer Tanenbaum Ch.6.
IP1 The Underlying Technologies. What is inside the Internet? Or What are the key underlying technologies that make it work so successfully? –Packet Switching.
© 2002, Cisco Systems, Inc. All rights reserved..
Data Communications and Networks Chapter 6 – IP, UDP and TCP ICT-BVF8.1- Data Communications and Network Trainer: Dr. Abbes Sebihi.
TCP/IP1 Address Resolution Protocol Internet uses IP address to recognize a computer. But IP address needs to be translated to physical address (NIC).
IP packet filtering Breno de Medeiros. Florida State University Fall 2005 Packet filtering Packet filtering is a network security mechanism that works.
11 CS716 Advanced Computer Networks By Dr. Amir Qayyum.
19 March 2003Page 1 BGP Vulnerabilities Draft March 19, 2003 Sandra Murphy
Draft-ietf-behave-nat-00 NAT/Firewall Behavioral Requirements draft-ietf-behave-nat-00 François Audet - Cullen Jennings -
Could SP-NAT Save the Internet?
Chapter 9: Transport Layer
Multiplexing.
Instructor Materials Chapter 9: Transport Layer
COMP2322 Lab 6 TCP Steven Lee Mar 29, 2017.
TCP/IP Internetworking
TCP.
© 2003, Cisco Systems, Inc. All rights reserved.
TCP/IP Internetworking
Introduction to Networking
NAT Behavioral Requirements for Unicast UDP
TCP - Part I Karim El Defrawy
TCP - Part I Relates to Lab 5. First module on TCP which covers packet format, data transfer, and connection management.
Figure 3-23: Transmission Control Protocol (TCP) (Study Figure)
TCP - Part I Relates to Lab 5. First module on TCP which covers packet format, data transfer, and connection management.
46 to 1500 bytes TYPE CODE CHECKSUM IDENTIFIER SEQUENCE NUMBER OPTIONAL DATA ICMP Echo message.
ITIS 6167/8167: Network and Information Security
Presentation transcript:

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

03/07/2005IETF 62, Minneapolis Scope Recommendations to NAT implementors as pertaining to TCP session processing. At the time of writing of this draft, was not available. Recommendations that are not specific to TCP or UDP will be moved to, pending WG consensus.

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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?

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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

03/07/2005IETF 62, Minneapolis 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 ?

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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)

03/07/2005IETF 62, Minneapolis 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.

03/07/2005IETF 62, Minneapolis 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.