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

From: Fernando Gont <[email-masked]>
Date: Tue, 04 Nov 2008 12:32:36 -0300

Hello, folks,

We (Pyda Srisuresh and me) have posted a new I-D entitled "Security 
Implications of Network Address Translators (NATs)".

The document will show up in the repositories soon. In the mean time, 
you can download it from: 
http://www.gont.com.ar/drafts/nat-security/draft-gont-behave-nat-security-01.txt 
, and you can download it in other fancy formats (e.g. PDF & HTML) 
from: http://www.gont.com.ar/drafts/nat-security/index.html

The abstract of the document is:

---- cut here ----
    This document analyzes the security implications of Network Address
    Translators (NATs).  It neither deprecates nor encourages the use of
    NATs, but rather aims to raise awareness about their security
    implications, and possible implementation approaches to improve their
    security.
---- cut here ---

Any comments will be more than welcome....

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: Dave Thaler <[email-masked]>
Date: Fri, 7 Nov 2008 14:38:58 -0800

Section 2.1:

> 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.

Section 5.1.3

> As
> the TOS value selected for each packet usually depends the specific
> IP implementation, this could be exploited to roughly count the
> number of systems  behind a NAT.

You should elaborate more on what the threat model is, and also
elaborate on how the TOS value could be used to count the number
of systems.

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.

Section 5.1.13

> 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?

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.

I also have a bunch of editorial nits I'll send just to the authors.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Fernando Gont
> Sent: Tuesday, November 04, 2008 7:33 AM
> To: Behave Mailing List
> Subject: [BEHAVE] New I-D: "Security Implications of Network Address
> Translators (NATs)" (draft-gont-behave-nat-security-01.txt)
>
> Hello, folks,
>