Subject: Re: [BEHAVE] New I-D: "Security Implications of Network Address Translators (NATs)" (draft-gont-behave-nat-security-01.txt)

From: Fernando Gont <[email-masked]>
Date: Fri, 07 Nov 2008 23:56:57 -0300

Hello, Dave

Thanks so much for your feedback!

Comments in-line....

> > > NATs may protect themselves against such attacks by limiting the
> > > length of time they retain an incomplete IP packet before discarding
> > > it, or by limiting the amount of internal buffer space incomplete IP
> > > packets may consume before the oldest  fragments are discarded.
> >
> > Simply discarding the oldest fragment just opens another attack vector.
> > If your incoming rate of new fragment ids is high enough (which an
> > attacker could do), you'll never be able to complete any packet if
> > you toss the oldest one first, since you'd be discarding stuff just
> > before you get the last piece you need.

Agreed. I will fix this according to what's described in: 
http://www.cpni.gov.uk/Docs/InternetProtocol.pdf (I did provide a 
pointer, though).

> > Section 5.1.8
> >
> > > In order to avoid having the IP Time to Live field reveal this
> > > information, NATs could rewrite the TTL field of translated packets,
> > > such that this field is set homogeneously  among all packets
> > forwarded
> > > toward the external network.
> >
> > Be careful not to break traceroute.

Yes, shame on me again: I was meaning to comment on traceroute. 
However, it seems I was rushing too much to get the document out, and 
missed it. :-(  (but will fix this in the next revision of the document)

> > > Clearly , IP options could potentially be used for counting the
> > number
> > > of systems behind a NAT.
> >
> > Don't assume it's clear to the reader.  How?

Different systems could include different options. (Okay, for the 
most part this would leak that there are different types of systems 
behind a NAT, rather than the actual number of boxes)

> > Section 5.2.1
> >
> > > NATs should  implement an ephemeral port selection algorithm such
> > that
> > > the source port of outgoing packets is obfuscated , thus mitigating
> > > blind (off-path) spoofing attacks.
> >
> > This conflicts with the "port preserving" behavior of many NATs that is
> > intended to allow more apps to work than if the port is obfuscated.

Why should it? See Section 3.2 of: 
http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-02.txt

Thanks!

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: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 10 Nov 2008 10:29:02 +0200

On Saturday 08 November 2008 04:56:57 ext Fernando Gont, you wrote:
> > > > NATs should  implement an ephemeral port selection algorithm
> > > > such that the source port of outgoing packets is obfuscated ,
> > > > thus mitigating blind (off-path) spoofing attacks.
> > >

I fail to see a contradiction. If the host uses random internal ports, then 
its port-preserving NAT will also exhibit random external ports. As Dave 
notes, port-preserving is common practice as some applications tend to assume 
certain port numbers are used.

There is a problem with port preservation when it _never_ changes the port 
number, even in case of conflict. There are some such horribly broken NATs. 
But, I don't see a reason to ban port preservation.

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 10 Nov 2008 10:53:30 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rémi Denis-Courmont
> Sent: Monday, November 10, 2008 12:29 AM
> To: [email-masked]
> Cc: Dave Thaler
> Subject: Re: [BEHAVE] New I-D: "Security Implications of 
> Network AddressTranslators (NATs)" 
> (draft-gont-behave-nat-security-01.txt)
> 
> http://www.gont.com.ar/drafts/port-randomization/draft-ietf-ts
> vwg-port-rand
> >omization-02.txt
> 
> notes, port-preserving is common practice as some 
> applications tend to assume certain port numbers are used.

A NAT cannot determine if a host is randomizing its port numbers or is using
predictable port numbering.

> But, I don't see a reason to ban port preservation.

For whatever it's worth, the TCP NAT specification (RFC5382) says:
 
   NAT behavior for preserving the source TCP port range for connections
   is left unspecified

and t UDP NAT specification (RFC4787) is longer-winded, but concludes with:

   Applications must, therefore, be able
   to deal with both port preservation and no port preservation.

-d

---

From: Dave Thaler <[email-masked]>
Date: Mon, 10 Nov 2008 16:00:35 -0800

[...]
> predictable port numbering.
[...]

Exactly.  The "conflict" is that the text says that a NAT should
change the source port, whereas port preservation says to
avoid changing it unless you have no choice.  You cannot both
preserve the port and obfuscate the source port of outgoing packets.
Hence there's an inherent tradeoff here between security and
making more apps work.

-Dave

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 10 Nov 2008 18:56:08 -0800 (PST)

Dave,

Do you know of specific applications that fail when port preservation is not enforced by a NAT. 

Also, what are the port ranges where port preservation is particularly sensitive to applications?

regards,
suresh

--- On Mon, 11/10/08, Dave Thaler <[email-masked]> wrote:

> From: Dave Thaler <[email-masked]>
> Subject: Re: [BEHAVE] New I-D: "Security Implications of Network AddressTranslators (NATs)" (draft-gont-behave-nat-security-01.txt)
> To: "Dan Wing" <[email-masked]>, "'Rémi Denis-Courmont'" <[email-masked]>, "[email-masked]" <[email-masked]>
> Date: Monday, November 10, 2008, 4:00 PM
> [...]
> > > > > > This conflicts with the "port
> preserving" behavior of
> > > many NATs that is
> > > > > > intended to allow more apps to
> work than if the port is
> > > obfuscated.
> > > >
> > > I fail to see a contradiction. If the host uses
> random
> > > internal ports, then
> > > its port-preserving NAT will also exhibit random
> external
> > > ports. As Dave
> > A NAT cannot determine if a host is randomizing its
> port numbers or is
> > using

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 Nov 2008 19:58:18 -0800

We have a few requirements related to this in RFC 4787 (REQ-3 and REQ-4).

We ended up making no recommendations on port preservation because lots many
people opposed us recommending against it.

So the discussion in RFC 4787 and the REQs are mostly on the range to use
and what to do if you use port preservation, but you have a collision.

On Nov10 2008 18:56 , "Pyda Srisuresh" <[email-masked]> wrote:

>> Subject: Re: [BEHAVE] New I-D: "Security Implications of Network
>> AddressTranslators (NATs)" (draft-gont-behave-nat-security-01.txt)
>> To: "Dan Wing" <[email-masked]>, "'Rémi Denis-Courmont'"
>> <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 11 Nov 2008 09:20:54 +0200

On Monday 10 November 2008 20:53:30 ext Dan Wing, you wrote:
> A NAT cannot determine if a host is randomizing its port numbers or is
> using predictable port numbering.

Mostly true. But it's not the NAT's job, is it?

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Nov 2008 08:59:57 -0800

> > A NAT cannot determine if a host is randomizing its port 
> > numbers or is using predictable port numbering.
> 

Some do consider it their job; some don't.  That's why we never 
achieved consensus to say much about port preservation in the 
UDP or TCP specifications.

Port preservation is moot with IPv4 address sharing between
subscribers, though (as we are considering with all of BEHAVE's
new work) -- it becomes nearly impossible to get the same 
port on the public side because it (a) isn't within your
authorized port range [port range proposals] or (b) is already 
allocated to another subscriber [Service Provider-operated
NAT proposals].

-d

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Nov 2008 22:48:02 -0300

>Hence there's an inherent tradeoff here between security and

Sorry, Dave: I just got confused with port reservation vs preservation.

So, how something along the lines of:

"NATs SHOULD obfuscate the ephemeral ports, unless they are 
implementing port preservation"?

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Nov 2008 22:50:13 -0300

>    to deal with both port preservation and no port preservation.

So, at least for UDP traffic, there's seem to be room for something 
along the lines of "NATs SHOULD obfuscate the ephemeral ports they 
use for outgoing connections". Am I missing something?

Thanks!

Kind regards,

---

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Nov 2008 18:06:20 -0800

> From: Fernando Gont [mailto:[email-masked]]
> Sent: Tuesday, November 11, 2008 5:48 PM
> To: Dave Thaler; Dan Wing; 'Rémi Denis-Courmont'; [email-masked]

Sure, though I can't tell whether that will have any real effect.

>From http://tools.ietf.org/html/draft-jennings-behave-test-results-04
roughly half of the NAT vendors do port preservation.

-Dave

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Nov 2008 23:44:30 -0300

>Sure, though I can't tell whether that will have any real effect.

I guess that we just need to get hit a few times by attacks that 
depend on guessing the source port, and that's it. That's how the 
industry seem to work. (only half-joking)

>roughly half of the NAT vendors do port preservation.

Well, what's "worse" is when a NAT rewrites the source port, but does 
it with the non-obfuscated incremental port selection algorithm. A 
few months back, when the Kaminsky's DNS vulnerabilities were 
disclosed there was this problem: Some systems were doing port 
randomization. However, they were behind NATs, and these NATs were 
re-writing the source-port using the traditional BSD algorithm.

Thanks!

Kind regards,

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Nov 2008 18:52:17 -0800

> use for outgoing connections". Am I missing something?

To increase security, a NAT might want to do that.  However, it
can break applications which (for whatever reason) only communicate
32 bits of address information rather than 48 bits (32+16).  I
don't know what applications those might be, though.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Nov 2008 19:02:52 -0800

> roughly half of the NAT vendors do port preservation.

Port preservation becomes less likely when an IPv4 address is shared
with many busy subscribers -- such as with CGN, Dual-Stack Lite.  The
port-range proposals (A+P, SAM, boucadair-port-range, and 
bajko-v6ops-port-restricted-ipaddr-assign) will only be port 
preserving if the host happens to use an ephemeral port that is
within the subscriber's port range.

I expect application writers will notice this pretty quickly,
if they haven't already in an effort to work with the 50% of
non-port-preserving NATs.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 11 Nov 2008 20:26:22 -0800

Right, that's exactly why we took it out.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 11 Nov 2008 20:32:03 -0800

> don't know what applications those might be, though.

A typical case would be an application where the NATed IP address is
discovered from where the signalling came from, but the port is assumed to
be fixed (in particular for the media).

I've seen this with pre-SIP call servers.

I believe that when this was discussed, they were games that used more than
one port that worked in a similar way.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 12 Nov 2008 09:25:20 +0200

> don't know what applications those might be, though.

In my understanding, that's the operating model of IGD (v1), not just port 
preserving NATs.