Subject: Re: [tcpm] [tsvwg] I-D Action: draft-ietf-tsvwg-behave-requirements-update-01.txt

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 18 Feb 2015 22:38:43 +0000

Hi,

On 2015-2-18, at 04:35, [email-masked] wrote:
> 
>        Title           : Network Address Translation (NAT) Behavioral Requirements Updates
> 
> Abstract:
>   This document clarifies and updates several requirements of RFC4787,
>   RFC5382 and RFC5508 based on operational and development experience.
>   The focus of this document is NAPT44.
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tsvwg-behave-requirements-update-01

I gave this a quick read; here are some comments. Also CC'ing TCPM, as this is of interest there.

Lars

Throughout:
  Please check your use of RFC2119 terms - some are user lowercase where
  I'd capitalize them, and vice versa.

Section 2., paragraph 1:
>    [RFC5382] specifies TCP timers associated with various connection
>    states but does not specify the TCP state machine a NAPT44 should use
>    as a basis to apply such timers.  The TCP state machine depicted in
>    Figure 1, adapted from [RFC6146], provides guidance on how TCP
>    session tracking could be implemented - it is non-normative.

  So Figure 1 is not normative, but Section 2 is? (Because otherwise the
  RFC2119 language used in it doesn't make much sense.)

Section 2.1., paragraph 2:
>    This document clarifies that a NAT device SHOULD provide different
>    knobs for configuring the open and closing idle timeouts.  This
>    document further acknowledges that most TCP flows are very short
>    (less than 10 seconds) [FLOWRATE][TCPWILD] and therefore a partially
>    open timeout of 4 minutes might be excessive if security is a
>    concern.  Therefore, it MAY be configured to be less than 4 minutes
>    in such cases.  There also may be cases that a timeout of 4 minutes
>    might be excessive.  The case and the solution are written below.

  There seems to be some repetition in this paragraph. I also don't see
  the "case and the solution" anywhere following this. Finally, the
  average length of a TCP flow is completely unrelated to how long this
  timeout should be. The MSL, however, is related to this, and it's
  where the 4 minutes originated from. If you want to allow shortening
  this, you should explain why waiting for a fraction of an MSL is OK.

Section 2.2., paragraph 0:
> 2.2.  TIME_WAIT State

  The language is pretty rough in some places in Section 2.2, to the
  point where it makes it difficult to understand what exactly is
  proposed.

Section 2.2.1., paragraph 3:
>    Also, PAWS works to discard old duplicate packets at NAT.  A packet
>    can be discarded as an old duplicate if it is received with a
>    timestamp or sequence number value less than a value recently
>    received on the connection.

  Why should the NAT not simply translate and forward these packets?
  This adds a bunch of complexity at the NAT that doesn't really seem to
  gain anything.

Section 2.2.1.1., paragraph 3:
>    B: NAT rewrite timestamp and sequence number values of incoming
>       packets to be monotonically increasing.

  If the NAT mucks around with the timestamp options, how is this going
  ot affect TCP's RTT calculation? Which fields of the Timestamp option
  are being rewritten here?

Section 2.2.1.2., paragraph 0:
> 2.2.1.2.  Split an assignable number of port space to each client

  This section needs more text. I can't understand what the proposal is.

Section 2.3., paragraph 0:
>    To solve the port shortage problem on the client side, the behavior
>    of remote host should be compliant to [RFC6191] or the mechanism
>    written in Section 4.2.2.13 of [RFC1122], since NAT may reuse the
>    same 5 tuple for a new connection.  We have investigated behaviors of
>    OSes (e.g., Linux, FreeBSD, Windows, MacOS), and found that they
>    implemented the server side behavior of the above two.

  Which versions of these operating systems have you tested?

Section 2.3., paragraph 1:
>    [RFC5382] leaves the handling of TCP RST packets unspecified.  This
>    document does not try standardize such behavior but clarifies based
>    on operational experience that a NAT that receives a TCP RST for an
>    active mapping and performs session tracking MAY immediately delete
>    the sessions and remove any state associated with it.  If the NAT
>    device that performs TCP session tracking receives a TCP RST for the
>    first session that created a mapping, it MAY remove the session and
>    the mapping immediately.

  If the NAT kills the binding after forwarding an RST, and that RST is
  lost between the NAT and the recipient, any retransmission of the RST
  by the other end will not be forwarded. This may cause connection
  stalls.

Section 3., paragraph 4:
>    [RFC4787] and [RFC5382] requires "endpoint-independent mapping" at
>    NAT, and port overlapping NAT cannot meet the requirement.  This
>    mechanism can degrade the transparency of NAT in that its mapping
>    mechanism is endpoint-dependent and makes NAT traversal harder.
>    However, if a NAT adopts endpoint-independent mapping together with
>    endpoint-dependent filtering, then the actual behavior of the NAT
>    will be the same as port overlapping NAT.

  There was a reason why EIM was chosen in those past RFCs. Has the
  rationale here changed?

Section 5., paragraph 1:
>    [RFC4787]:REQ-8 and [RFC5382]:REQ-3 End-point independent filtering
>    could potentially result in security attacks from the public realm.

  NATs do not perform a security function. That is why we have
  firewalls. We had long discussions in the past on this difference.