Subject: [BEHAVE] Follow-up on the points raised at the draft-gont-behave-nat-security behave presentation

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Nov 2008 17:47:59 -0300

Folks,

During the BEHAVE WG meeting arguments were made against rewriting 
the TCP sequence numbers, TCP timestamps, etc.

If you don't rewrite the TCP sequence number or the TCP timestamps, 
you may basically break TCP, or call for problems (e.g., connection 
failures) that were not there before.

e.g., protection against old segments is provided by TCP's quiet-time 
concept and TCP's TIME-WAIT state. As in a NAT scenario a 
connection-id may be reused while some *other* system behind a NAT is 
maintaining the TIME-WAIT state (with no effect), it becomes more 
important that the sequence number space does not overlap (to protect 
against old segments (other than to allow the BSD SEQ# hack to 
work)), and that the TCP timestamps are monotonically increasing 
across connections (this will allow the timestamps heurisctics in 
Linux (and others) to work, and might even help protect against some 
stale segments...).

It was argued that rewriting the sequence numbers or TCP timestamps 
was not necessary if the NAT just avoided reusing the same ports. 
However, are NATs expected to record each connection-id for 2*MSL 
after it is used? Even then, the more systems behind a NAT, the more 
likely collisions of connection-id's will be, and the more necessary 
it becomes for the TCP ISN and timestamps heuristics to work.

I can't believe that BEHAVE was concerned about making the more 
cumbersome TCP simultaneous-open work (which some stacks have never 
supported), but people seem to ignore this more basic stuff.

P.S.: There are things in the document that can be easily argued 
against e.g., whether to rewrite the TTL (which some systems, like 
OpenBSD PF, already do) or not. However, there are others that are 
basically no brainers.

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Nov 2008 15:15:20 -0600

it's a good document.  the discussion needs to be had.  it's just hard
to do it in the context of a meeting with an agenda full of
presentations and with no time left for discussions.

the point is to have the discussion.  it's not necessary that everyone
share the same priorities or agree on the right answers.  this is stuff
that definitely needs wider awareness.

Keith

> Folks,
> 
> During the BEHAVE WG meeting arguments were made against rewriting the
> TCP sequence numbers, TCP timestamps, etc.
> 
> If you don't rewrite the TCP sequence number or the TCP timestamps, you
> may basically break TCP, or call for problems (e.g., connection
> concept and TCP's TIME-WAIT state. As in a NAT scenario a connection-id
> may be reused while some *other* system behind a NAT is maintaining the
> TIME-WAIT state (with no effect), it becomes more important that the
> sequence number space does not overlap (to protect against old segments
> (other than to allow the BSD SEQ# hack to work)), and that the TCP
> timestamps are monotonically increasing across connections (this will
> allow the timestamps heurisctics in Linux (and others) to work, and
> might even help protect against some stale segments...).
> 
> It was argued that rewriting the sequence numbers or TCP timestamps was
> not necessary if the NAT just avoided reusing the same ports. However,
> are NATs expected to record each connection-id for 2*MSL after it is
> used? Even then, the more systems behind a NAT, the more likely
> collisions of connection-id's will be, and the more necessary it becomes
> for the TCP ISN and timestamps heuristics to work.
> 
> P.S.: There are things in the document that can be easily argued against
> e.g., whether to rewrite the TTL (which some systems, like OpenBSD PF,
> already do) or not. However, there are others that are basically no
> brainers.
> 
> Kind regards,
> 
> -- 
> Fernando Gont

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 21 Nov 2008 23:24:25 +0200

> failures) that were not there before.

_If_and_only_if_ you do not implement proper TIME-WAIT on the NAT as well.

(...)
> after it is used?

Why not? they need to keep more state for active connections than for 
TIME-WAIT ones, anyway.

> Even then, the more systems behind a NAT, the more 

That only occurs over 546 TCP connections per minute per public IP address for 
a given remote host and port.

> supported), but people seem to ignore this more basic stuff.

Please don't misrepresent the opinions of others. The point was that you had a 
much simpler solution to port randomization (TIME-WAIT on the NAT). The point 
was not that there was no port randomization problem.

> OpenBSD PF, already do) or not.

That's not a job for a Network Address (and Port) Translator. That's a job for 
a transparent proxy or a network topology obfuscator.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Nov 2008 19:13:56 -0300

>_If_and_only_if_ you do not implement proper TIME-WAIT on the NAT as well.

That is not true.

Nowadays, if you have a previous incarnation of a 
connection in the TIME-WAIT state, a new 
incarnation may be created thanks to the SEQ# and 
timestamps heuristics. If your NAT does not 
rewrite the SEQ and timestamps, these connections 
may fail. The larger the number of systems behind 
the NAT, the more likely this will be the case.

>Why not? they need to keep more state for active connections than for

You wouldn't need to do this if you we're 
rewriting the SEQ and timestamps. What you 
propose makes the NAT more of a Single porint of Failure than necessary.

>a given remote host and port.

Yes, and assuming that more numbers are sort of 
selected sequentially (which unless you're doing 
alg #3 or alg #4 of 
draft-ietf-tsvwg-port-randomization , is probably NOT what you should be doing)

>much simpler solution to port randomization (TIME-WAIT on the NAT).

What does TIME-WAIT in the NAT have to do with 
port randomization? If anything, TIME-WAIT at the 
NAT is an expensive mechanism for avoiding collisions.

>a transparent proxy or a network topology obfuscator.

Point taken for the TTL stuff. But not for the other stuff above.

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Nov 2008 23:20:36 -0800

> failures) that were not there before.

The same is true for rewriting IP ID values; for the same reason, esp.
if fragmentation can occur, NOT rewriting these values breaks IP.

I have noted before that a NAT *must* act like a host to the rest of the
network; that includes making sure that all packets it emits with its
source address follow *all* of the host requirements (and it acts like a
router to hosts behind the NAT, and *must* follow gateway requirements
for inbound packets).

Joe

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 26 Nov 2008 07:55:18 -0500

What disturbs me about this conversation is that there seems to be an
assumption that it's impossible to design and deploy a NAT that is not
so overloaded that it cannot provide basic reliable service.  In this
case, it seems to be a question of whether a NAT can afford to honor
TIME_WAIT for its connections.  In other threads, there are arguments
against endpoint-independent mapping using similar justification.

I have two questions:
- is it true that all of the proposed rewriting is necessary only if a
NAT is not able to honor TIME_WAIT at the end of a connection?  The
only suggestion I've seen so far that this is not true related to
multiple endpoints behind the NAT, but assuming the NAT is a NAPT
doing endpoint-independent mapping, I can't figure out how that is
relevant.

- do we really have consensus that it's impossible to build a NAT that
doesn't need to operate in this overloaded manner?  If so, then this
draft raises important points about TCP that essentially mean we need
to do 5382bis, because we didn't address how you really NAT TCP in
that document.

Bruce

On Wed, Nov 26, 2008 at 2:20 AM, Joe Touch <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Fernando Gont wrote:
>> Folks,
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkks+MQACgkQE5f5cImnZruGPACg5XCDD4wPOkJ9iFlPdMPDI8z0
> w7kAoJM4wr1RMfWw7xMDro4OVKHAaiRK
> =n5EB
> -----END PGP SIGNATURE-----

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 26 Nov 2008 15:05:55 +0200

> against endpoint-independent mapping using similar justification.

Conversely, I wonder why a NAT should be allowed to violate TIME_WAIT anyway. 
TIME_WAIT is there for a reason.

> to do 5382bis, because we didn't address how you really NAT TCP in

I am pretty sure we do not.

As a user device vendor, I would rather NAT mess with TCP as little as 
possible. If I were a NAT vendor, I would rather have to mess with TCP as 
little as possible.

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Nov 2008 07:41:48 -0800

Rémi Denis-Courmont wrote:
...
> possible. If I were a NAT vendor, I would rather have to mess with TCP as 

As little as *necessary*.

Joe

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 26 Nov 2008 13:05:29 -0500

> As little as *necessary*.

What is *necessary* and why?

Bruce

> iEYEARECAAYFAkktbjwACgkQE5f5cImnZruoDwCg/oxu7C0kRItO6lKFg8+RV8Co
> go4AnA890LLEzj1Uqn8lDeW7RNxBwHNC
> =79qK

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Nov 2008 13:35:36 -0500

Bruce Lowekamp wrote:
> so overloaded that it cannot provide basic reliable service.  

I think we just realize that if NATs are going to be employed on a large
scale, that the potential for service disruption is MUCH greater if
those NATs have to maintain per-connection state, or even per-binding
state.  And the disruption caused by a SINGLE NAT running out of table
space would affect a MUCH wider user population than any single NAT does
now.

If we can't figure out a way to make such NATs both reliable and
cost-effective, it might be that large-scale NAT is not a viable path
for v4/v6 transition.

Keith

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 26 Nov 2008 14:21:25 -0500

> cost-effective, it might be that large-scale NAT is not a viable path

I have yet to see any sort of quantitative analysis of the load
expected on one of these large scale NATs.  Mostly what I've seen are
assertions that they will always be resource starved, and so all of
the requirements for NATs specified previously (4787, 5382, etc) can
be disregarded.

There needs to be a solid analysis of requirements here: what the load
will be, what resources are actually going to be the bottleneck, and
what the frequency of overload will be.  If it's necessary to
recommend degenerate behavior in overload scenarios, that's probably
not a bad idea, but starting from the beginning saying this box won't
meet current recommendations is a recipe for failure.

A lot of people spent a lot of time coming up with 4787, 5382, etc to
allow applications to work well behind NATs.  If we're going to throw
away all that work, we might as well go home now because the final
product will be as unusable as the first generation of NATs.

If there is already a draft with a solid requirements analysis, please
point me to it.  I haven't seen it.

Bruce

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Nov 2008 14:18:24 -0800

>> What is *necessary* and why?

Well, anything that breaks Internet requirements - as noted by earlier
posts - is necessary. Breaking TCP because a NAT vendor is lazy is not a
viable option.

Joe

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 26 Nov 2008 18:41:04 -0500

> posts - is necessary. Breaking TCP because a NAT vendor is lazy is not a

I'm still trying to find a clear statement of why it is necessary to
change *anything* (other than port).  The motivations I've seen so far
assume that the NAT is already having to violate the TCP state
machine, and I think it may be violating the endpoint-independent
requirement of 5382, but I'm not sure.  That's breaking both TCP and
many applications using it, so I'm hoping someone can try to explain
exactly why they believe such changes are necessary.

Bruce

---

From: james woodyatt <[email-masked]>
Date: Wed, 26 Nov 2008 16:01:08 -0800

> exactly why they believe such changes are necessary.

There are two other places that IPv4/NAT functions may find it  
necessary to modify TCP headers.

A) To clamp the MSS as a workaround for path MTU discovery blackholes  
in PPPoE access concentrators.

B) To insert/remove segment octets in application packets as part of  
an ALG, e.g. FTP and RTSP.

This is before we even get to the places where a stateful firewall may  
find itself rewriting TCP headers for the purpose of normalizing  
flows, operating system fingerprint hiding, et cetera.  These things  
have nothing to do with NAT and everything to do with firewall  
behaviors.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Nov 2008 16:18:51 -0800

Bruce Lowekamp wrote:
> change *anything* (other than port). 

It may be simple to view NATs as "just" changing source IP addresses and
ports, but as far as the device is contacting is concerned they are
*generating* IP and TCP packets.

As a result, they're subject to exactly the same requirements as any
other source of such packets. IMO, draft-gont-behave-nat-security
doesn't state this sufficiently (though I don't consider these security
issues; they're protocol correctness issues).

In particular, at least:

- - IP packets MUST (not just SHOULD) have unique srcIP/dstIP/ID/proto
tuples over 2 MSL (I have an I-D to relax this a bit, but if the packet
is fragmentable or has already been fragmented by the time the NAT
translates it, the requirement still holds)

- - TCP connections MUST NOT repeat for 2*MSL after a close

- - TCP timestamps MUST be monotonically increasing

> The motivations I've seen so far

Although we may not have seen the impact of NATs that don't properly
enforce host requirements, that doesn't ensure such impacts won't be
seen in the future.

Joe

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 26 Nov 2008 21:50:11 -0500

On Wed, Nov 26, 2008 at 7:18 PM, Joe Touch <[email-masked]> wrote:
> doesn't state this sufficiently

>(though I don't consider these security

agree here (more later)

> - - TCP timestamps MUST be monotonically increasing

OK, so those are basic TCP requirements, no one is questioning them
(at least I'm not).  The question I have is how a NAT could be
violating any of those if all it is doing is rewriting port (and the
couple of things that James mentioned), honoring the TCP state machine
(particularly TIME_WAIT), and following 5382 (primarily
endpoint-independent mapping)?

My belief is that there is no need to deal with the sequence number,
timestamps, or ID unless the NAT is either allowing some sort of port
reuse or reusing source ports without honoring TIME_WAIT (I think the
NAT can still allow the same internal host to reuse the same tuple
before TIME_WAIT expires).

If that's true, then the issues with sequence number, id, and
timestamp may need to be addressed in a port reuse draft if behave
goes in that direction, but I really don't think that they need to be
addressed for NATs in general.

If there is a need to rewrite any of these when the NAT is not reusing
ports or something similar, then I am very curious what it is.

> enforce host requirements, that doesn't ensure such impacts won't be

Are you saying here that NATs should ensure that the hosts behind the
NATs are following the host requirements properly?  I'm assuming that
if the NAT doesn't make any changes that would affect host
requirements, there is no reason to expect the NAT to audit the
correctness of traffic going through it.

Bruce

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Nov 2008 00:41:10 -0300

>TIME_WAIT is there for a reason.

Could you please elaborate on what you mean by "violate TIME-WAIT"?

>possible. If I were a NAT vendor, I would rather have to mess with TCP as

A NAT is messing with TCP already. from the 
external realm, all outgoing connections look as 
if they came from the same system. Therefore, as 
Joe said, you should be doing RFC 1122.

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Nov 2008 22:37:05 -0800

...
> before TIME_WAIT expires).

To the public Internet side of a NAT, the NAT *is* the source of all
traffic that it emits. All its traffic MUST follow 1122 (i.e., MUST
follow MUSTs, SHOULD follow SHOULDs, etc.).

> ports or something similar, then I am very curious what it is.

It doesn't matter if the NAT reuses the port; it matters that the port
is reused. The NAT is responsible for all packets that are emitted on
its public side, because they have the NAT's IP address as a source.

> NATs are following the host requirements properly? 

It doesn't matter *why* a NAT violates 1122; it only matters if it does.
> I'm assuming that

You can blame it on the host behind the NAT, but the NAT takes
responsibility when it puts its IP address in the source field.

Joe

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 27 Nov 2008 07:39:31 -0500

Your proposal that NATs are required to do deep packet inspection and
fully understand the implications of all packets they emit, including
TCP retrans, etc, is interesting.  I suspect the contributors to this
group who worry about NATs not being able to keep port use state due
to resource starvation haven't considered such a requirement.

Bruce

On Thu, Nov 27, 2008 at 1:37 AM, Joe Touch <[email-masked]> wrote:
> iEYEARECAAYFAkkuQBEACgkQE5f5cImnZrumfgCg+GrM19nb52tpW0ghiIEoi2sF
> wLkAn0lXLCh3jrNYdazp/BTLH0gFR7YS
> =TqXv

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Nov 2008 09:10:37 -0800

Hi, Bruce,

Bruce Lowekamp wrote:
> TCP retrans, etc, is interesting.

NATs are as responsible as any other host is for packets it emits with
its IP address as source; it's useful to keep in mind that Fernando and
I are not adding any new Internet requirements, just recognizing that
existing ones apply.

> I suspect the contributors to this

Understood. Also, it's useful to note that not all conventional hosts on
the Internet follow every corner case of 1122 either; there are numerous
places where optimizations are either noted (in 1122) or have emerged in
the code base of the majority. A good example of the former are ways to
avoid TIME_WAIT hazards after a reboot - if the reboot takes more than 2
minutes, no state need be kept across restarts. A good example of the
latter is the IP ID, which is clearly being reused in ways that violate
required uniqueness.

When those requirements are bent (or broken), it's useful to consider
whether conventional hosts share that perspective, and what the impact
is on the host behind the NAT, the server/host on the other end of the
connection, and other connections going through that NAT.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Nov 2008 15:18:20 -0300

>doesn't state this sufficiently

This is a very good point, and I will try to address it in the next 
revision of our draft.

>issues; they're protocol correctness issues).

You're right that that these are protocol correctness issues. That's 
the bottom-line, and the reason for which NATs should re-write these 
protocol header fields.

That said, when considering alternatives for re-writing the protocol 
fields, we tried to pick those that are more "security-wise" (e.g., 
port obfuscation vs. global incremental port sequence, RFC 1948 vs 
global incremental ISNs, etc.)

Kind regards,