NAT requirements for TCP (BEHAVE WG) - PowerPoint PPT Presentation

About This Presentation
Title:

NAT requirements for TCP (BEHAVE WG)

Description:

At the time of writing of this draft, draft-ford-behave-gen-00.txt was not ... lists the requirments first similar to behave-udp draft, followed by discussion ... – PowerPoint PPT presentation

Number of Views:143
Avg rating:3.0/5.0
Slides: 18
Provided by: CiscoSys8
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: NAT requirements for TCP (BEHAVE WG)


1
NAT requirements for TCP(BEHAVE WG)
  • draft-sivakumar-behave-nat-tcp-req-00.txt

S.Sivakumar, K.Biswas, B.Ford
2
Scope
  • Recommendations to NAT implementors as pertaining
    to TCP session processing.
  • At the time of writing of this draft,
    ltdraft-ford-behave-gen-00.txtgt was not available.
    Recommendations that are not specific to TCP or
    UDP will be moved to ltdraft-ford-behave-gen-00.txt
    gt, pending WG consensus.

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.

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?

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.

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.

7
Req 4 - Port Reservation
  • NATs TCP Port space is shared by 2 functions
  • (a) Routers local end-host functionality
  • (b) Routers NAT functionality
  • NAT MUST NOT use a single TCP port for both NATd
    sessions and local application sessions at the
    same time.
  • Recommendation NAT implementers SHOULD set
    aside port-blocks for end-host functionality vs.
    NAT functionality.

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.

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.

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.tx
    t.

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

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 ?

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.

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.

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)

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.

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.
Write a Comment
User Comments (0)
About PowerShow.com