Subject: [BEHAVE] RE: DISCUSS and COMMENT: draft-ietf-behave-tcp

From: Saikat Guha <[email-masked]>
Date: Sun, 22 Apr 2007 10:28:19 -0400

During the IESG last call of draft-ietf-behave-tcp, a couple of concerns
were raised some of which were discussed on list. One recent concern
adds a new requirement (REQ-9), which the authors wanted to bring to the
list (Change #1 below).

A new version of the draft is now available (to be posted shortly):
I-D: http://saikat.guha.cc/pub/draft-ietf-behave-tcp-07.txt
Diff: http://saikat.guha.cc/pub/draft-ietf-behave-tcp-07-from-06.diff.html

Key changes:

1. PMTU support requirement: The new version now explicitly recommends
PMTU support using RFC 2119 terminology. Previous version was silent on
this issue and implicitly depended on the corresponding UDP
recommendation.

        REQ-9: If a NAT translates TCP, it SHOULD translate ICMP
        Destination
               Unreachable "Fragmentation Needed and Don't Fragment was
               Set" (Type 3, Code 4) messages.

This text is consistent with both the UDP doc and recent WG discussion
on the list. Additional text surrounding this requirement discourages
filtering any destination unreachables for efficiency purposes.
        
2. Scope clarification: Clarify connections to the NAT itself (e.g. an 
HTTP-management interface) are out-of-scope of this document. How to deal
with such connections (be they TCP or UDP) is complex, which an 
implementation-guideline document could address.

3. SACK support: Callout to implementers that packets with SACK
notifications should be properly handled.

cheers,
-- 
Saikat
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Apr 2007 20:39:02 -0400

>>>>> "Saikat" == Saikat Guha <[email-masked]> writes:
    Saikat> 2. Scope clarification: Clarify connections to the NAT
    Saikat> itself (e.g. an HTTP-management interface) are
    Saikat> out-of-scope of this document. How to deal with such
    Saikat> connections (be they TCP or UDP) is complex, which an
    Saikat> implementation-guideline document could address.

For the record, I think my comment triggered this.  Personally, I
think the WG has made the document worse rather than better by moving
in this direction.

It's not bad enough that I'm going to enter a discuss, but please do
not make the change on my account.

I think that if you were going to create a document that had positive
impact you would address this issue or at least discuss the
challenges.

Note however that my comment is non-blocking.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 24 Apr 2007 18:19:15 -0700

Sam Hartman wrote:

> For the record, I think my comment triggered this. 

Yes.

> Personally, I

The authors and I exchanged several messages about your original
comment and still don't understand what change you are suggesting.

Would you have time to explain your comment in a phone call with
us?  If it's not important, I guess that sentence can just be 
backed out, but I know you created that comment because you
wanted the document improved.

> Note however that my comment is non-blocking.

Understood.

-d

---

From: Saikat Guha <[email-masked]>
Date: Tue, 24 Apr 2007 21:59:25 -0400

> impact you would address this issue or at least discuss the

I am not completely sure I understand your concerns. Can you clarify the
issue or illustrate a case where some NAT behavior in this regard breaks
applications?

cheers,

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Apr 2007 05:08:38 -0400

>>  I think that if you were going to create a document that had
    >> positive impact you would address this issue or at least
    >> discuss the challenges.

    Saikat> I am not completely sure I understand your concerns. Can
    Saikat> you clarify the issue or illustrate a case where some NAT
    Saikat> behavior in this regard breaks applications?

One of the purposes of behave is to make it easy for NAT vendors to
get it right.  So, you need to provide enough implementation guidance
that you actually get that result.

I'm implementing a NAT on top of a commodity OS--say stripped down arm
Linux or something like that.  But the point is I have a normal TCP
stack as well as my NAT.

I receive a TCP packet.  If it is a locally destined syn to a port I
have nothing running on, I should respond with a reset.  If it is a
packet to a port that is a not-yet-allocated NAT mapping, your
document claims I should respond a few seconds later with an ICMP
message.  Absent looking into the future, I need to do something
clever.  For some platforms I can assume any port that doesn't have
anything locally bound is a potential NAT mapping and use that
behavior.  For other platforms that would be highly undesirable.  For
example I don't think you can convince Windows connection sharing or
OS X 's NAT functionality to treat things this way.  I'm curious how
you propose that Linux implement this; it's definitely going to be
tricky to get the configuration right.

By ignoring these issues, you increase the probability that people
will produce boxes that don't do what you expect and don't do what
your users expect.  If people who try and follow your rules run into
market acceptance problems because they ignored some tricky case and
produced a broken product, then they will ignore your rules in the
future.

---

From: Saikat Guha <[email-masked]>
Date: Wed, 25 Apr 2007 16:48:31 -0400

On Wed, 2007-04-25 at 05:08 -0400, Sam Hartman wrote: 
> behavior.  For other platforms that would be highly undesirable.  

Ah ok, I think I understand your concern now. For such devices, the
following implementation would be compliant.
- the NAT part only allocates mappings in a fixed port range. Say
   ports 45000--55000. Or perhaps has an allocation black-list 
   (port 80, 22, etc.)
- the host part uses ports outside that range (or in the black-list)
- when a SYN arrives in the allocation range, the NAT follows BEHAVE
- when a SYN arrives outside the allocation range, the NAT follows 1122

Would the following text address your concern?

Below the justification for REQ-4 (unsolicited SYN, delayed ICMP req):

"For NATs that combine NAT functionality with end-host functionality
(e.g. an end-host that also serves as a NAT for other hosts behind it),
this requirement applies only to SYNs intended for the NAT'ed hosts and
not to SYNs intended for the NAT itself. One way to determine whether
the inbound SYN is intended for a NAT'ed host or for the NAT itself is
for such an implementation to allocate NAT mappings from one port range,
and allocate ports for local endpoints from a different non-overlapping
port range. More dynamic implementations can be imagined."

cheers,

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Apr 2007 21:15:52 -0400

That text is fine, although note it interacts badly with your other
desire that when possible ports not be remapped.

---

From: Saikat Guha <[email-masked]>
Date: Thu, 26 Apr 2007 17:45:54 -0400

> desire that when possible ports not be remapped.

Not sure I understood the last part (about remapping).

In the naive implementation suggested in the previous mail, the NAT
functionality is completely isolated from endhost functionality by
partitioning the port space.

Inside the NAT port space, it can be BEHAVE compliant. e.g. when the
same NAT'ed host uses the same local port for multiple connections, the
same mapped port must be used (with the added constraint now that the
port lies in the port space partition used by the NAT).

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Apr 2007 11:07:45 -0400

Saikat> On Wed, 2007-04-25 at 21:15 -0400, Sam Hartman wrote:
    >> That text is fine, although note it interacts badly with your
    >> other desire that when possible ports not be remapped.

    Saikat> Not sure I understood the last part (about remapping).

Your document indicates that it is desirable for the inner port to be
the same as the outer port--or at least I think I remember that from
behave-nat-udp.  Obviously there are a lot of situations where you
don't get that.  This creates another.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 27 Apr 2007 18:38:38 +0100

>                Set" (Type 3, Code 4) messages.

The paragraph following REQ-9 says:

    Furthermore, TCP's connection establishment and maintenance
    mechanisms also behave much more efficiently when ICMP Destination
    Unreachable messages arrive in response to outgoing TCP segments.

Those messages are type-3 messages other than code-4, which is the  
only one REQ-9 talks about.

Should this be rephrased as:

    REQ-9:  If a NAT translates TCP, it SHOULD translate ICMP  
Destination
       Unreachable (Type 3) messages.

And then explaining in the justification that code 4 is especially  
important for preventing black holes, but the other codes are also  
recommended to translate, because TCP's connection establishment and  
maintenance mechanisms also behave much more efficiently when ICMP  
Destination Unreachable messages arrive in response to outgoing TCP  
segments?

Lars

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Apr 2007 11:56:53 -0700

> behave-nat-udp. 

Behave-nat-udp (now RFC4787) talked about preservation of port numbers,
but didn't make a recommendation for or against port preservation.  The
WG consensus is that port preservation is bad (because it allows and
encourages applications to be sloppy and not signal ports, thus causing
failure when two applications behind the same NAT expect to be allocated
the same public port), yet there are applications that only work in the
presence of a NAT that does attempt its best to preserve ports.  

One requirement related to this which is in RFC4787 is:

  "REQ-3:  A NAT MUST NOT have a "Port assignment" behavior of "Port
      overloading".

      a) If the host's source port was in the range 0-1023, it is
         RECOMMENDED the NAT's source port be in the same range.  If the
         host's source port was in the range 1024-65535, it is
         RECOMMENDED that the NAT's source port be in that range."

> Obviously there are a lot of situations where you

Agreed.  But because RFC4787 didn't encourage re-using ports this
shouldn't be too significant a complication.

-d