Subject: [Ietf-behave] Fwd: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00

From: Lars Eggert <[email-masked]>
Date: Thu, 18 May 2006 00:50:53 -0700 (PDT)

Hi,

thanks for the review, Joe. I forwarded it to the behave list, where  
the discussion should take place.

Lars

Begin forwarded message:

From: Joe Touch <touch@xxxxxxx>
Date: May 17, 2006 11:26:16 PM GMT+02:00
To: tcpm@xxxxxxxx
Subject: Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00
I took a look as well. I agree with Tom's assessment: it doesn't  
stand as a readable document.

I also agree with Tom that:

1. this doc should start with the TCP roadmap as a reference, and  
should address items in there specifically (at least the basic  
ones, if not the recommended ones).

2. this doc should be more stand-alone regarding terminology

---

I'll be more specific than Tom as to TCP-technical errors:

- some of the scope declarations in section 1 are inappropriate.
        this document must declare the limit to which TCP headers can be
        interpreted in their entirety. declaring that anything not
        related to translation of TCP is out of scope begs the question
        of what's related to that translation - options? modification
        of the number of segments (e.g., splitting)? these are all
        definitely in-scope.
        I agree with the doc that above-TCP, below-TCP, and signalling
        beyond IP and TCP can be declared out of scope.
- REQ-2 is overstated; a NAT MUST support translation of any
        packet valid in a pending TCP session, where "pending TCP
        session" is initiated by an outbound TCP SYN
        that means a NAT MUST accept incoming TCP SYNs which match
        current pending sessions. this supports simultaneous open
        *if* after the session is initiated by an internal host
- REQ-3 is incorrect

        TCP defines sessions, sessions are defined by socket pairs,
        and sockets are defined by IP address/port pairs. Period.
        TCP port numbers do NOT identify hosts; they identify
        session demultiplexing points on hosts. To that end, the NAT
        is an early, remapping point for that demuxing, where everything
        behind a NAT (assuming it has only one external IP address)
        functions _exactly_ as if it were on a single host with that
        address.
        That also means that transmissions that differ in any of
        source IP, destination IP, source port, and destination port
        are unrelated from TCP's point of view. It is inappropriate
        for this document to suggest otherwise, or to suggest use
        of a NAT for that purpose. While other documents can refer to
        such 'NAT tricks', this document, from TCP's perspective, should
        recommend against such tricks, IMO.
- REQ-4 is incorrect

        First, the ways in which a NAT would respond to a
        TCP SYN not matching a pending session should be listed,
        e.g., ICMP dest unreachable (3 port unreach, 10 host admin
        unreach) or TCP RST.
        The document is written assuming the desire to support
        simultaneous opens, but ignores the desire to know more
        rapidly when a port is not available. In particular, when
        an ICMP dest unreach/3 port unreach is issued, that would
        be a hard error that would cause the external TCP to quickly
        abort. Not sending the error would impact those hosts and
        cause them to respond less quickly to connection failure.
        While I agree that simultaneous open MUST be supported for
        pending sessions, I disagree that external SYNs should always
        be silently discarded just to support simultaneous open. While
        simultaneous open is OK when it works, the whole notion of a
        NAT is counter to incoming, unsolicited connections.
        I would recommend that incoming SYNs that do not match pending
        sessions MAY be signalled by an ICMP or RST error. I would NOT
        recommend that silence be required.
- regarding ALGs
        FTP is not a relevant issue; FTP is already supported through
        NATs by passive mode; there is no requirement to translate the
        body of an FTP session to support NATs. There are other ALG
        issues, but they are - as noted in Sec 1 - above TCP, and not
        relevant to TCP.
- session refresh
        This section is too messy. TCP can be open and silent if
        neither side has pending data; this must be addressed.
        Discarding state might allow subsequent sessions from other
        hosts to inadvertently receive data from other hosts'
        connections; this is a hazard that MUST be discussed.
        NATs may typically send keepalive TCPs, but *this* document
        should recommend that such behavior be restricted to endpoints.
        This document should be VERY clear on when such state should
        be kept, for how long, and when it can be cleared. The NAT
        must keep state in TIME_WAIT just like any end host to avoid
        reuse of connections and crossed-data. This section is the
        most critical of this document, and currently is both
        too disorganized and incorrect to proceed.
- IPsec is missing
        since IPsec examines TCP headers, it would be useful to address
        IPsec/TCP combined issues here (e.g., transport mode issues)
I didn't bother with addressing the security considerations, given  
the errors above. I'm presuming that a thorough revision of that  
section would be needed, since the doc missed some very obvious  
issues IMO (above).

Minor nit: 6 authors? from a WG? pick a subset who are editors, please

Joe

_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm
--
Lars Eggert                                     NEC Network Laboratories

Attachment:
smime.p7s

---

From: Saikat Guha <[email-masked]>
Date: Thu, 18 May 2006 10:37:27 -0700 (PDT)

Thanks Joe. Responses (separate from those to Tom's mail) inline.

On Thu, 2006-05-18 at 09:50 +0200, Lars Eggert wrote:
> >     interpreted in their entirety. 
Ok.

> >     *if* after the session is initiated by an internal host

Depending on the filtering behavior of the NAT, a NAT can accept
incoming TCP SYNs for a 3-way handshake initiated from the outside.
(-00.txt didn't have that clarification). 

The constraint is that the very first session for a local address/port
must be initiated by the local endpoint. After that, (policy permitting)
sessions can be initiated (both 3-way and sim-open) by either internal
or external endpoints.

Can you suggest some text that would address your concerns?

> >     and sockets are defined by IP address/port pairs. Period.

Ok. The intention was to use the definition of session in RFC 2663 which
states: "a session is defined as the set of traffic that is managed as a
unit of translation." Unfortunately, 2663 contradicts itself for TCP by
later stating "sessions are uniquely identified by the [5-tuple]". This
latter claim doesn't distinguish between two TCP "connections" between
the same 5-tuple but not overlapping in time. Such two connections need
not be "managed as [one] unit of translation" (some NATs create a new
mapping for each one) and would therefore be considered two sessions.

RFC 2663 equates "connection" and session; is there another term that
distinguishes between two (temporally) separate TCP connections (between
the same 5-tuple), or should the document (re)define session?

> >     e.g., ICMP dest unreachable (3 port unreach, 10 host admin

OK.

> >     rapidly when a port is not available. 

While I don't disagree, it is not always possible to rapidly know whem a
port is not available -- routers that drop packets need not generate an
ICMP, the ICMP may be lost in the network and so on. Nor is it desirable
to force a TCP to shutdown if a port is (potentially temporarily)
unreachable -- it only forces the end to flood the network with SYNs so
it can win the Sim-Open race against a jabbering NAT.

Ideally, if there were an ICMP code that were to be considered a
soft-error during TCP initiation then the NAT could be required to send
that.

Fernando's draft in TCP-M proposes to make all ICMPs into hard-errors
during initiation.

Under the assumption that any unsolicited connection inbound into a NAT
is the result of a configuration error or attack, it may be desirable
for the NAT to stay silent while at the same time helping along
Sim-Open. Compounded is the ability of the NAT, as a router, of being
able to drop packets without being required to send an error.

Lacking a soft-error, this was roughly the discussion on the list that
lead to this requirement. Basically it helps more than it hurts.

> >     body of an FTP session to support NATs. 

Unfortunately, I believe that the most popular FTP client -- Microsoft
Internet Explorer -- doesn't support passive mode. For vendors to take
this document seriously, the FTP ALG should be allowed to be turned on
by default.

While the FTP ALG helps more than it hurts (atleast until the world
upgrades to a better FTP client), the case for other ALGs is not as
clear.

> >     neither side has pending data; this must be addressed.

The session timers affect idle sessions, and the established session
timer pertains to the state that you mention. I'll make it more clear.

> >     connections; this is a hazard that MUST be discussed.

I am not convinced of this. Once a session has been abandoned, another
session cannot be created through the same hole without a SYN going one
way or another. The new SYN sets up a different mapping (different
5-tuple) so delayed packets from the first sessions wouldn't match
(depending on endpoint filtering). Even if it does match and is routed
to the endpoint, is this case any different from a non-NAT'ed TCP stack
(say one that crashed, came back up and established a new session) from
receiving a stay packet from an old session?

> >     The NAT must keep state in TIME_WAIT just like any end host to avoid
> >     reuse of connections and crossed-data.

Agreed that to be consistent with other RFCs that a NAT should keep
connections in TIME_WAIT state for 4 minutes (although most all OS's use
30s). At the same time, TIME_WAIT is always encountered for TCP during
the normal operation (more typically at the client; where the NAT is)
and significantly cuts the connection throughput through a NAT with
bounded state. 

One compromise would be to leave the handling of TIME_WAIT unspecified
but point out the issues associated. I believe that is the current
consensus.

> >     IPsec/TCP combined issues here (e.g., transport mode issues)

Perhaps an IPSec draft may be a better place for that. As is there are
major hurdles getting IPsec flows (more than one, or even just one) to
work consistently through NATs.

cheers,
-- 
Saikat
Attachment:
signature.asc

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 May 2006 11:09:41 -0700 (PDT)

Comments below...

Saikat Guha wrote:

NATs can do anything they want, including not NAT. What we're talking 
about is that to be compliant with TCP:

All NATs MUST accept incoming SYNs to connections that are pending.

See above.

- REQ-3 is incorrect

        TCP defines sessions, sessions are defined by socket pairs,
        and sockets are defined by IP address/port pairs. Period.
Ok. The intention was to use the definition of session in RFC 2663 which
states: "a session is defined as the set of traffic that is managed as a
unit of translation."
You can define NAT sessions that way; this doc should be careful to 
distinguish between the term "NAT session" and "TCP session".

Unfortunately, 2663 contradicts itself for TCP by
later stating "sessions are uniquely identified by the [5-tuple]".
I presume you're referring to Sec 2.3; that's a 4-tuple. ;-)

This
latter claim doesn't distinguish between two TCP "connections" between
the same 5-tuple but not overlapping in time. Such two connections need
not be "managed as [one] unit of translation" (some NATs create a new
mapping for each one) and would therefore be considered two sessions.
RFC 2663 equates "connection" and session; is there another term that
distinguishes between two (temporally) separate TCP connections (between
the same 5-tuple), or should the document (re)define session?
A connection is a session in the connected state, IMO. There is no term 
to differentiate between non-overlapping TCP sessions; is there some 
reason to need this as a separate term?

- REQ-4 is incorrect

port is not available 
At a NAT it's trivial - the lack of a corresponding translation entry.

-- routers that drop packets need not generate an
ICMP, the ICMP may be lost in the network and so on. 
Routers drop packets due to load; a general rule is to never send a 
packet in response to congestion (to avoid collapse).

NATs drop packets due to policy; the latter is the kind of error that 
the source should potentially be informed of.

Nor is it desirable
to force a TCP to shutdown if a port is (potentially temporarily)
unreachable -- it only forces the end to flood the network with SYNs so
it can win the Sim-Open race against a jabbering NAT.
It doesn't _force_ anything. It informs. The other end should never 
flood SYNs in response to an ICMP error; that's an attack.

Ideally, if there were an ICMP code that were to be considered a
soft-error during TCP initiation then the NAT could be required to send
that.
Well, the error that's appropriate is a hard error as currently defined. 
It's a hard error because it tells the other end not to bother on this 
port again - the same error is expected. The alternative would be to NOT 
send the ICMP error.

I don't agree that redefining ICMP response is the right solution.

Fernando's draft in TCP-M proposes to make all ICMPs into hard-errors
during initiation.
That's a different issue, which is (IMO) motivated by trying to make 
ICMP compensate for the lack of a simple transition to IPv6 (which I 
don't support either). That's not really relevant to this discussion IMO.

Under the assumption that any unsolicited connection inbound into a NAT
is the result of a configuration error or attack, it may be desirable
for the NAT to stay silent while at the same time helping along
Sim-Open. Compounded is the ability of the NAT, as a router, of being
able to drop packets without being required to send an error.
We don't change protocols to compensate for configuration errors. Or do 
you accept all incoming packets with incorrect checksums too?

ICMP error messages already are supposed to be throttled, so an attack 
is not an issue.

Lacking a soft-error, this was roughly the discussion on the list that
lead to this requirement. Basically it helps more than it hurts.
I still see no reason to veer outside RFC1122 or RFC1812 on this - MAY 
send the error, MUST rate limit, etc.

- regarding ALGs
	FTP is not a relevant issue; FTP is already supported through
	NATs by passive mode; there is no requirement to translate the
	body of an FTP session to support NATs. 
Unfortunately, I believe that the most popular FTP client -- Microsoft
Internet Explorer -- doesn't support passive mode. For vendors to take
this document seriously, the FTP ALG should be allowed to be turned on
by default.
IE supports passive mode; it isn't on by default, but it's trivial to 
configure that way. A quick search of "internet explorer passive mode" 
will find it.

While the FTP ALG helps more than it hurts (atleast until the world
upgrades to a better FTP client), the case for other ALGs is not as
clear.
The world caught up in 2004 (according to what Microsoft's website says 
on the matter) ;-) http://support.microsoft.com/?kbid=309816

- session refresh
(depending on endpoint filtering).
Good point, but that means the doc needs another rule:

NATs MUST change the translation entry when a new SYN arrives if an 
existing translation entry matches it.

Even if it does match and is routed
to the endpoint, is this case any different from a non-NAT'ed TCP stack
(say one that crashed, came back up and established a new session) from
receiving a stay packet from an old session?
Not if the SYN is what fixes it. Got it.

Agreed.

- IPsec is missing
        since IPsec examines TCP headers, it would be useful to address
        IPsec/TCP combined issues here (e.g., transport mode issues)
Perhaps an IPSec draft may be a better place for that. As is there are
major hurdles getting IPsec flows (more than one, or even just one) to
work consistently through NATs.
This doc really needs to mention this IMO. It need not solve all issues, 
but it should be sufficient that if no IPsec draft were written, the doc 
would be sufficient in pointing out the issue.

Joe

---

From: Saikat Guha <[email-masked]>
Date: Sat, 20 May 2006 13:04:04 -0700 (PDT)

Ok.

> IMO. There is no term 

As with the UDP document, this document gives a name to (bad) behavior
that has been observed -- partly to classify NATs, partly to tell
vendors what not to do. When a mapping is active, some NATs have been
known to allocate a different mapping for a new TCP that matches the old
mapping ... resulting in non only non endpoint-independent behavior, but
an as-yet undefined type of destination dependent behavior. I am
guessing a better definition of session will make it more clear.

> I don't agree that redefining ICMP response is the right solution.

I agree that redefining ICMP is not the right solution, but mainly
because old stacks will not be aware of the new definition.

If one of the existing soft-error ICMPs could be used -- like one of the
Host Unreachables -- that could work with existing stacks. 

> don't support either). That's not really relevant to this discussion IMO.

If that draft does proceed, then it restricts the use of existing
soft-errors as well. 

> send the error, MUST rate limit, etc.

A NAT that MAY or MAY NOT cause the OS to abort a Sim-Open attempt
doesn't help an application developer traverse NATs. The goal of behave
is to define behavior that allows the app developer to reliably
establish connections through the NAT -- and Sim-Open is the single
biggest requirement for TCP apps traversing NATs. An application
developer should be able to depend on the guarantee that Sim-Open will
work with his OS stack (potentially old) and NAT (new/behave compliant).

Silently dropping the SYN provides this guarantee, as does requiring the
NAT to return a soft-error. A NAT that can possibly return a hard-error
does not provide this guarantee. 

Since silently dropping the SYN at the NAT-router does not violate any
RFCs (AFAIK), but helps application developers traverse NATs more easily
as compared to allowing NATs to OPTIONALly return hard-errors, the
long-standing WG consensus has been to silently drop SYNs. 

Are there any other options?

> configure that way. 

If it is not enabled by default, then it means a support call (from
grandma's) to the vendor's helpdesk. =/ Just one more reason for the
vendor to balk at the draft IMHO. 

But FTP aside, I think your question was whether ALGs are now in scope
since the draft was written. I believe so, as decided at IETF'65.

> would be sufficient in pointing out the issue.

Can you (or someone) suggest text for this.

cheers,
-- 
Saikat
Attachment:
signature.asc

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 May 2006 08:04:14 -0700 (PDT)

Saikat Guha wrote:
...
IMO. There is no term 
to differentiate between non-overlapping TCP sessions; is there some 
reason to need this as a separate term?
As with the UDP document, this document gives a name to (bad) behavior
that has been observed -- partly to classify NATs, partly to tell
vendors what not to do. When a mapping is active, some NATs have been
known to allocate a different mapping for a new TCP that matches the old
mapping ... resulting in non only non endpoint-independent behavior, but
an as-yet undefined type of destination dependent behavior.
You need to be more specific about why this behavior is bad. What is the 
appropriate period that makes it acceptable to reuse mapping 
information? Why is it not the TIME_WAIT, and why aren't all mapping 
entries put into that state when closed? That seems the only reasonable 
constraint to be TCP-safe.

I am
guessing a better definition of session will make it more clear.
See above. It's not the name that's the issue; it's sufficient to use 
names of existing TCP entities to describe the problem.

I don't agree that redefining ICMP response is the right solution.
I agree that redefining ICMP is not the right solution, but mainly
because old stacks will not be aware of the new definition.
This document is supposed to describe how TCP reacts to NATs and how to 
make NATs more TCP-compatible.

IMO, that takes all mods to _TCP_ off the table. This would be a mod to 
TCP; if that's what you're proposing, you need to write the document 
from the other perspective...

and, more importantly, propose it as work in TCPM (where changes to TCP 
are vetted). ;-)

If one of the existing soft-error ICMPs could be used -- like one of the
Host Unreachables -- that could work with existing stacks. 
That's an acceptable alternative, but note that there are some in TCPM 
who think that TCP's current reaction to soft and hard errors should be 
changed, so you may be referring to a specification issue that is in flux.

Yes, (unfortunately). That's what I'm referring to above.

I still see no reason to veer outside RFC1122 or RFC1812 on this - MAY 
send the error, MUST rate limit, etc.
A NAT that MAY or MAY NOT cause the OS to abort a Sim-Open attempt
doesn't help an application developer traverse NATs. The goal of behave
is to define behavior that allows the app developer to reliably
establish connections through the NAT -- and Sim-Open is the single
biggest requirement for TCP apps traversing NATs. An application
developer should be able to depend on the guarantee that Sim-Open will
work with his OS stack (potentially old) and NAT (new/behave compliant).
NATs prevent incoming connections; Sim-Open happens in one of two ways; 
one starts on the inside, in which case it's easy to specify what NATs 
need to do (accept incoming SYNs that match pending translations). When 
S-O starts on the outside, it's equivalent to a regular SYN arriving 
from the outside. That's a capability NATs do not support.

Silently dropping the SYN provides this guarantee, as does requiring the
NAT to return a soft-error. A NAT that can possibly return a hard-error
does not provide this guarantee. 
It's not appropriate to pick the error just on the response it 
generates; it must be reasonable to use. For a NAT, the following could 
be considered:

        0 net unreachable
        1 host unreachable
        2 protocol unreachable
        3 port unreachable
Of these, 0, 1, and 2 might cause a host to kill all other connections 
sharing the net, host, or protocol - that would be bad. So only #3 (type 
3, code 3) is appropriate.

Unfortunately that's a hard error.

Since silently dropping the SYN at the NAT-router does not violate any
RFCs (AFAIK), but helps application developers traverse NATs more easily
as compared to allowing NATs to OPTIONALly return hard-errors, the
long-standing WG consensus has been to silently drop SYNs. 
The NAT behaves like a combination of a router and a host; it needs to 
follow RFCs 1122/1123, 793, and 1812 on this. If we're talking about 
port unreachable, only 1122 says anything on this (that I could find).

1122 indicates that sending an ICMP port unreachable is a SHOULD. You're 
suggesting MUST NOT. That's a substantial change. Routers aren't 
supposed to drop TCP packets based on ICMP rules; when they do, they 
have SHOULDs as well.

Are there any other options?
Give up on allowing simultaneous open where the outside message arrives 
first. That would be more consistent with what NATs do anyway, IMO. Yes, 
it forces the connection to open from the inside first, but that's 
consistent.

IE supports passive mode; it isn't on by default, but it's trivial to 
configure that way. 
If it is not enabled by default, then it means a support call (from
grandma's) to the vendor's helpdesk. =/ Just one more reason for the
vendor to balk at the draft IMHO. 
Er, to balk at NATs, frankly. This is a problem that NATs create, and 
one that the public deployments haven't yet caught up to.

But FTP aside, I think your question was whether ALGs are now in scope
since the draft was written. I believe so, as decided at IETF'65.
My question was whether making requirements of FTP was in-scope for 
BEHAVE. This goes back to BEHAVE making requirements of TCP; in either 
case, it's out of scope for the WG (regardless of what the WG decides 
;-). IMO, the best *this doc* should do is indicate where things might 
break when NATs are used (e.g., that FTP has this capability but it 
isn't on).

- IPsec is missing
This doc really needs to mention this IMO. It need not solve all issues, 
but it should be sufficient that if no IPsec draft were written, the doc 
would be sufficient in pointing out the issue.
Can you (or someone) suggest text for this.
See the RFCs on NAT traversal by IPsec; it might be useful to contact 
their authors for suggestions.

Joe

---

From: Saikat Guha <[email-masked]>
Date: Mon, 22 May 2006 09:07:28 -0700 (PDT)

> from the outside. That's a capability NATs do not support.

When S-O starts from the outside, and the NAT is silent on the SYN (or
equivalently something that doesn't abort the attempt) then the NAT
supports S-O from the outside.

> first. 

The whole purpose of this draft is to ensure TCP can be established
between two NAT'ed hosts -- each behind its own NAT. In such scenarios,
S-O will *always* be initiated from the outside (for one of them). A NAT
MUST support S-O from the outside for TCP traversal to work.

> The NAT behaves like a combination of a router and a host; it needs 
> to follow RFCs 1122/1123, 793, and 1812 on this.

What happens when the requirements for the two (router and host) aren't
the same? The role of the NAT is open to interpretation, which in turn
determines which requirement should apply. For this specific instance,
it is beneficial to interpret the NAT as a router as opposed to as a
host. The justification is as follows:

#1: NAT as a host (for this specific case): 
  SHOULD send ICMP for non-routable SYN
Result: 
a) CANNOT establish TCP between two NAT'ed hosts.
b) Can quickly detect if port is closed

#2: NAT as router (for this specific case):
  Unspecified how to handle non-routable SYN
  (Proposed: silently drop)
Result:
a) Supports TCP establishment between two NAT'ed hosts
b) Can detect (with high probability) if port is closed after
   2-3 retransmissions

When it comes to best current practice, b) is actually perceived an
attack! IMHO b) is an exceptional case of which there are few legitimate
uses at the moment. a) is by-far what must be supported today. Case #1
precludes a) to optimize for b). Case #2 supports a) while de-optimizing
for b). Both #1 and #2 are equally consistent with the RFCs for the
corresponding interpretations of the NAT's role. Can you explain why #2
is not acceptable? IMHO, the intent of this document is to enable
connectivity in a NAT'ed world as opposed to maintaining the status-quo;
#2 is consistent with that goal while #1 is not.

Can the chairs take a stand?

cheers,
-- 
Saikat
Attachment:
signature.asc

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 May 2006 09:26:26 -0700 (PDT)

Saikat Guha wrote:
NATs do not support incoming connections in this way. They support 
having the source retry until it gets through.

Unfortunately, that would happen for ALL incoming SYNs, which is not 
necessarily the right answer. Since a NAT can't know whether an incoming 
SYN is for a S-O that hasn't started or is just an unsolicited request, 
it must treat the two the same.

Give up on allowing simultaneous open where the outside message arrives 
first. 
The whole purpose of this draft is to ensure TCP can be established
between two NAT'ed hosts -- each behind its own NAT. 
The purpose of the draft is to describe all interactions between NAT and 
TCP; if the purpose is to focus on ways to support S-O for two NAT'd 
hosts, the doc needs to be rewritten.

In such scenarios,
S-O will *always* be initiated from the outside (for one of them). A NAT
MUST support S-O from the outside for TCP traversal to work.
NATs don't know what S-O is _unless_ it's after a translation is already 
established. Otherwise, they're just incoming SYNs.

A NAT SHOULD send an ICMP for an incoming SYN that doesn't match its 
tables; it MAY (as a result) ignore that SYN.

You might suggest that it SHOULD ignore the first incoming SYN for a 
non-existent entry, but respond to other SYNs - however, that provides 
an opportunity for an external DOS attack (to flood the 'incoming SYN' 
table).

You might suggest that you just rate limit the ICMPs you SHOULD be 
sending as a result of the SYNs, but that means that some connections 
will work while others will just fail.

The NAT behaves like a combination of a router and a host; it needs 
to follow RFCs 1122/1123, 793, and 1812 on this.
What happens when the requirements for the two (router and host) aren't
the same? The role of the NAT is open to interpretation, which in turn
determines which requirement should apply.
Agreed. However, there are only two options:

- it's a host:
        where it SHOULD send an ICMP dest unreachable / port unreachable
- it's a router:
        where it MUST generate a dest unreachable / net unreachable
        or dest unreachable / host unreachable
(I've already noted why the latter would be worse).

> For this specific instance,
SHOULD seems bad, but allowing MAY causes DOS attack opportunities (as 
above).

Er, see RFC1812, 4.3.3.1

Unroutable IP packets MUST generate ICMP error messages. There's no 
provision for silent drop. There is ONLY a provision for ICMP rate limit 
(which I already noted won't help much).

Result:
is not acceptable?
Just did ;-)

Joe

IMHO, the intent of this document is to enable
connectivity in a NAT'ed world as opposed to maintaining the status-quo;
#2 is consistent with that goal while #1 is not.
Can the chairs take a stand?

cheers,

---

From: Saikat Guha <[email-masked]>
Date: Mon, 22 May 2006 10:51:27 -0700 (PDT)

> (which I already noted won't help much).

I suppose if it does come down to finding loopholes, 4.3.3.1 specifies
exactly when the ICMP must be sent: "cannot forward a packet because it
has no routes at all (including no default route) to the *destination
specified in the packet*, then the router MUST generate ..."; which one
could claim doesn't hold in this case because the "destination specified
in the packet" is that of the router itself to which a route does exist.
Alternatively the RFC allows for arbitrary implementation-specific
rate-limiting, which could be exploited to create a 0-rate icmp channel
for inbound SYN. Following the RFC to the word would still allow for
silently dropping inbound SYNs without violating any requirements. 

But I completely agree with you that the spirit of the RFC is to
indicate when an error happens, as is the case here. The right solution
IMHO would be to define a new ICMP unrechable type that accurately
captures the error (since no other ICMP unreachable captures it), and
tell stacks how to handle such errors. Potentially let the application
opening the socket indicate to the stack whether or not it expects
Sim-Open to be the normal case and whether or not to abort quickly. Is
that an option?

If not, then perhaps enabling TCP connectivity rather than hindering it
while staying compliant with at least the word (regrettably not
necessarily the spirit) of the specific RFC is acceptable.

Given the two, long debated, options 
1. to sent an ICMP error that prevents NAT'ed TCP
 or
2. to remain silent for inbound SYN packets

Does anyone else have any comments to make?

How about the following text:

  REQ-X: If the NAT cannot determine whether the application is
    attempting a Simultaneous-Open when processing an inbound SYN
    that cannot be routed, the NAT MUST NOT cause the attempt to be
    aborted prematurely by the end-host.
    a) If the NAT can indicate the error to the end-host without
       causing it to prematurely abort the attempt, it SHOULD do so.
    b) Otherwise the NAT MUST silently discard the inbound SYN packet.

First, the requirement allows the NAT to abort an inbound SYN for
application it knows are not attempting a S-O: http, ftp etc. for
instance. For other protocols, the above requirement gives priority to
informing the end-host of the error. It is forward compatible with new
ICMP errors defined for this purpose that are soft-errors during
connection establishment. Until then, it prefers to err on the side of
caution by allowing a connection (while stalling erroneous ones) rather
than aborting all attempts.

-- 
Saikat
Attachment:
signature.asc

---

From: Saikat Guha <[email-masked]>
Date: Mon, 22 May 2006 10:54:50 -0700 (PDT)

>     b) Otherwise the NAT MUST silently discard the inbound SYN packet.

Same thing, with "cause" to be aborted replaced with "force"

REQ-X: If the NAT cannot determine whether the application is
    attempting a Simultaneous-Open when processing an inbound SYN
    that cannot be routed, the NAT MUST NOT force the attempt to be
    aborted prematurely by the end-host.
    a) If the NAT can indicate the error to the end-host without
       forcing it to prematurely abort the attempt, it SHOULD do so.
    b) Otherwise the NAT MUST silently discard the inbound SYN packet.

-- 
Saikat
Attachment:
signature.asc

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 May 2006 11:11:52 -0700 (PDT)

Saikat Guha wrote:

Er, then you're arguing that 1122 applies. You can't eat your cake and 
have it too ;-)

Alternatively the RFC allows for arbitrary implementation-specific
rate-limiting, which could be exploited to create a 0-rate icmp channel
for inbound SYN. Following the RFC to the word would still allow for
silently dropping inbound SYNs without violating any requirements. 
Rate-limiting to 0 is stretching things a bit, but you just argued that 
1812 doesn't apply, so that's not an issue.

But I completely agree with you that the spirit of the RFC is to
indicate when an error happens, as is the case here. The right solution
IMHO would be to define a new ICMP unrechable type that accurately
captures the error (since no other ICMP unreachable captures it), and
tell stacks how to handle such errors. 
YES!!! But that's new work, and ends up making NATs expose themselves, 
which (last I recalled) was abhorrent from their perspective.

Potentially let the application
opening the socket indicate to the stack whether or not it expects
Sim-Open to be the normal case and whether or not to abort quickly. Is
that an option?
Not that I'm aware.

If not, then perhaps enabling TCP connectivity rather than hindering it
while staying compliant with at least the word (regrettably not
necessarily the spirit) of the specific RFC is acceptable.
The issue with S-O is important only for the case where both hosts are 
behind NATs. My general impression is that opening a connection to a 
host behind a NAT is - in spirit - something NATs prohibit (excepting 
mapped ports).

I see no reason not to just admit that. I appreciate that this 
interferes with the peer case, but that's a problem NATs are somewhat 
intended to create.

(a), and the spirit of the MUST NOT above it are against RFC1122 IMO.

First, the requirement allows the NAT to abort an inbound SYN for
application it knows are not attempting a S-O: http, ftp etc. for
instance. 
IMO, a doc that describes NAT's interaction with TCP _MUST NOT_ 
proscribe behavior that is either port or application specific.

That is an issue for NAT's interaction with apps. I don't see anywhere 
in 791-793, 1122, or 1812 that indicates transport - or ICMP signalling 
behavior - that is application-specific (short of 'port not available', 
of course).

For other protocols, the above requirement gives priority to
informing the end-host of the error. It is forward compatible with new
ICMP errors defined for this purpose that are soft-errors during
connection establishment. Until then, it prefers to err on the side of
caution by allowing a connection (while stalling erroneous ones) rather
than aborting all attempts.
I don't see a way around this per se, at least not so far.

Joe

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 11:56:32 -0700 (PDT)

I would have no idea how to implement this. I done know how I would  
know if could determine an SO was happening. I have not idea how I  
could indicate an error without forcing a premature abort.

I'm not objecting to what you are trying to accomplish here but the  
language propose here will not be useful for the people that build  
residential NATs.

---

From: Saikat Guha <[email-masked]>
Date: Mon, 22 May 2006 12:20:07 -0700 (PDT)

> host behind a NAT is - in spirit - something NATs prohibit (excepting 

The typical policy of a NAT is to allow a connection if the internal
endpoint wants it.

A convenient way of doing that is to let the internal end to send the
first packet that creates the mapping. That is what UDP-traversal (STUN)
uses. If an internal host doesn't want to talk, then you cannot do STUN,
you cannot traverse a NAT. If an internal host wants to talk, then you
can do STUN and get UDP between hosts both behind their NAT. This
adheres to the NAT policy of allowing internal hosts to determine
whether to talk or not.

The policy for TCP is still the same but you cannot do the STUN trick in
its simplicity. Even when both ends behind the NAT _want_ to talk, and
the NAT policy allows a connection as long as the internal host wants to
talk, a strict 3-way handshake will always fail. A Sim-Open is necessary
here. 

This requirement does not define NAT behavior that would contradict the
predominant policy. You cannot Sim-Open unless the internal side agrees.

-- 
Saikat
Attachment:
signature.asc

---

From: Saikat Guha <[email-masked]>
Date: Mon, 22 May 2006 12:30:10 -0700 (PDT)

On Mon, 2006-05-22 at 11:56 -0700, Cullen Jennings wrote:
> I would have no idea how to implement this.

At the very least b) applies and you silently drop packets. That is the
fallback case.

>  I done know how I would  
> know if could determine an SO was happening. 

If the NAT is doing some app-level processing (like labling port-80 as
http etc.) then it know that an http-server would not do an SO. The
doecument does not require the NAT to do any such sort of
application-specific behavior (to answer Joe's concern), but simply
provides a safe harbor for NATs that want to adhere to 1122 by returning
a ICMP asap.

> I have not idea how I  

Current TCP stacks, should (and most do) as per spec, consider some ICMP
unreachables as a soft-error. A NAT can send that.

Ofcourse, if the TCPM soft-errors draft was to override that behavior,
then NATs would not be allowed to send that; alternatively, if a new
soft-error ICMP was defined in the future, that could be used.

But the lowest common denominator for vendors taking extra precautions
would be to silently drop.

> language propose here will not be useful for the people that build  

Can you propose some text that vendors would be more likely to
understand?

-- 
Saikat
Attachment:
signature.asc

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 May 2006 12:44:44 -0700 (PDT)

Saikat Guha wrote:

Unreachable codes 0,1, and 5 are soft:

        0 net unreachable
        1 host unreachable
        5 source route failed
Codes 0,1,4,5 all are sent ONLY from gateways, not hosts. If this is a 
host, then these can't come from there.

All ICMPs sent from hosts are spec'd as hard errors at this time.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 May 2006 12:54:55 -0700 (PDT)

Saikat Guha wrote:
There are only two ways I know that this is indicated:

	- manual configuration (port map overrides)

	- seeing an outgoing SYN

A convenient way of doing that is to let the internal end to send the
first packet that creates the mapping.
Sure - that's the outgoing SYN.

That is what UDP-traversal (STUN)

This requirement does not define NAT behavior that would contradict the
predominant policy. You cannot Sim-Open unless the internal side agrees.
A true simultaneous open would work - IF both ends' SYNs hit their NAT 
before the incoming SYN arrives.

The problem occurs because you can't control when the SYNs arrive at the 
NATs, and you need to to make this work. That's the reason you want to 
be silent on an arriving SYN, but IMO that's inappropriate.

At best, you might delay sending the ICMP back, e.g., by 1 second or 
something like that. So long as it's fast enough to hit the retry timer 
of most TCPs (e.g., 6 seconds with exponential backoff), but slow enough 
that it allows loose sync between the endpoints, it would work.

Would that suffice (again, this is an opportunity for an attack, though 
- you're keeping state during that period)?

Joe