Subject: [BEHAVE] IPv6 NAT: implementer perspectives

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Nov 2008 09:36:41 -0500

Some initial thoughts about IPv6 NAT from an implementation
perspective follow.  I will likely add to this list over the
next while.

1) Recalculating the TCP/UDP pseudo-header checksum is easy,
    is not computationally expensive, and is widely deployed today
    in a wide range of IPv4 NAT devices, including very very
    low cost IPv4 NAT devices (e.g. consumer electronics home gateway
    boxes).

2) There are very few IPv6 optional headers defined.  Off the top
    of my head, I can only think of 3 non-null optional headers
    for IPv6:
	A) Routing Header
	B) CALIPSO IPv6 Sensitivity Label, a Hop-by-Hop Option
	C) ILNP Nonce, a Destination Option

3) Of the set listed in (2), none are commonly observed in the
    deployed IPv6 world.  So IPv6 header parsing probably is not
    a significant issue for IPv6 NAT boxes.
    (B) and (C) are currently only I-Ds, with no defined option numbers.
    (B) would only ever appear in special-purpose closed (i.e. never
    within the public Internet) environments.  (C) is part of a research
    concept and is even less likely to see measurable deployment.

4) Existing implementers on staff at various firms have experience
    implementing NATs in the way that most IPv4 NATs were built.
    Some of the properties of those NATs are undesirable, although
    this community has varying perspectives on which properties are
    desirable or undesirable.  However, there are existence proofs
    that the historic approach is computationally feasible even in
    very very low cost devices and that a wide range of implementers
    know how to code that type of NAT function.

5) Implementers are unlikely to object to a state-less NAT, but
    the "state-less translation" property might not be useful or  
sensible
    when the NAT function is co-located in a box that also seeks
    to be a firewall or a VPN gateway.  NATs are less commonly
    deployed by end users as stand-alone boxes, and much more commonly
    are deployed as part of a box that also serves as firewall and
    (IPsec or SSL) VPN gateway for the site.  This is true even for
    the "consumer electronics" home gateway boxes that are so common  
now.

Yours,

Ran Atkinson
[email-masked]

Disclaimer: Views are my own;
I am never authorised to speak for my employer.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Nov 2008 16:23:42 +0100

> 	C) ILNP Nonce, a Destination Option

I certainly hope prospective NAT66 implementers are a bit more careful  
than this: a common header is the fragmentation header, and there's  
also the destination options header.

>   So IPv6 header parsing probably is not

Well, I have yet to see one do it right.

The problem with maintaining per-session state and changing checksums  
is that now the NAT must be aware of all transports. We don't want this.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Nov 2008 10:47:52 -0500

Hi Ran,

This posting and your other postings about IPv6 NAT have been _very_  
useful.  Thank you for taking the time to write them.  I am replying  
to this one, because I have a comment on a couple of points...

>   know how to code that type of NAT function.

I was on the fence, but your post has convinced me that attempting a  
checksum neutral translation (while a neat trick, in some sense) is  
not all that useful.  There are actually two more useful things we  
could spend our time doing:

(1) Agreeing on a format for any future IPv6 extension headers so that  
they can be skipped without knowing what they are.  I think this work  
is already underway in 6man, and we should support it.

(2) Defining a NAT66 mechanism that provides the functions users need  
with as little negative impact on the Internet architecture as  
possible.  From this perspective, 1:1 translation, statelessness and  
leaving the ports alone are much more important than not modifying the  
TCP/UDP checksums.

>   to be a firewall or a VPN gateway.

This part I don't entirely agree with...  There is a significant  
difference between a stateful NAT (like IPv4 NAPT) and a stateless NAT  
co-located with a stateful firewall.  The second box can be configured  
by default to behave just like the first box, but if it is later  
necessary to reconfigure the firewall to support demand for a new  
application, the firewall can be reconfigured, while a stateful NAT  
cannot.

> NATs are less commonly

True, which I think will allow us to advocate for splitting the NAT  
and firewall functions, allowing for a more flexible device that (by  
default) serves as a drop-in replacement for today's IPv4 NA(P)T.  I  
hope.  What do you think?

Margaret

---

From: Rémi Després <[email-masked]>
Date: Wed, 26 Nov 2008 17:58:56 +0100

Margaret Wasserman  -  le (m/j/a) 11/26/08 4:47 PM
>>     C) ILNP Nonce, a Destination Option
One that should be in the list is the Fragmentation extension header.
Video games may use it extensively.
> could spend our time doing:
Glad we have an agreement on this.
(And thanks to Ran.).
> leaving the ports alone are much more important than not modifying the 
Full agreement on 1:1 and statelessness.
Still  not sure about including ports, or not, in the reversible scrambling:
- doing it achieves more host privacy (consecutive connections from a 
host are not recognizable as coming from the same host)
- on the other hand, it may create problems if some applications that, 
although they don't care about addresses being translated, would care 
that several connections do come from the same host.

Giving up my proposal that ports be included in the scrambling now seems 
acceptable to me, if this is  the consensus.

> application, the firewall can be reconfigured, while a stateful NAT 
After a discussion with Mark Townsley, I now believe that, rather than 
distinguishing between statefulness and statelessness,  we might prefer 
to distinguish between NAT66-1:n (the traditional one derived from 
NAT44) and NAT66-1:1 (the one being designed). It's more usage oriented, 
less internal-technique oriented.

Cheers,
RD
>>   the "consumer electronics" home gateway boxes that are so common now.
>

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Nov 2008 12:18:31 -0500

> Glad we have an agreement on this.

Well, Magnus' post followed by Iljtsch's post, and my own thinking in  
response to them, may have pushed me back over the fence again.

I think we should do checksum correction in the address if we can do  
it reliably without painful tradeoffs and not if we can't.  Regardless  
of whether we get that to work or not, though, I think we should write  
an IETF document on IPv6 NAT that promotes the implementation and  
deployment of a 1:1 stateless NAT and makes it clear how the simple  
security benefits of NAT could be obtained with a co-located stateful  
firewall (which should also be defined by the IETF).

>> (2) Defining a NAT66 mechanism that provides the functions users  
>> need with as little negative impact on the Internet architecture as  
>> possible.  From this perspective, 1:1 translation, statelessness  
>> and leaving the ports alone are much more important than not  
>> modifying the TCP/UDP checksums.
> - doing it achieves more host privacy (consecutive connections from  
> a host are not recognizable as coming from the same host)

Unless we do something else to hide this, consecutive connections from  
the same hosts will be identifiable by IP address.  Any 1:1 transform  
will result in the same value for the same input, so packets from a  
single host will all appear to come form the same IP address, while  
packets from other hosts will not.

> - on the other hand, it may create problems if some applications  
> that, although they don't care about addresses being translated,  
> would care that several connections do come from the same host.

Also this is where we actually start to mess with transport layers...

Even if we know about UDP and TCP and change their checksums (which  
I'd like to avoid, but may not succeed...), we won't know about other  
transport layers.  Those layers will have to live with the possibility  
that IP addresses may change underneath them, but they certainly  
shouldn't have to put ports somewhere that we can modify them.

  If folks want to prevent correlation of multiple connections with a  
single host, the best way to do that would be to demand host  
implementations that include IPv6 privacy addresses and random port  
selection.  We could build a box that does it, but I don't think we  
should build that into all IPv6 NATs, when it doesn't seem (from what  
we've heard so far) that most deployments will demand this.

>> difference between a stateful NAT (like IPv4 NAPT) and a stateless  
>> NAT co-located with a stateful firewall.  The second box can be  
>> configured by default to behave just like the first box, but if it  
>> is later necessary to reconfigure the firewall to support demand  
>> for a new application, the firewall can be reconfigured, while a  
>> stateful NAT cannot.
> After a discussion with Mark Townsley, I now believe that, rather  
> than distinguishing between statefulness and statelessness,  we  
> might prefer to distinguish between NAT66-1:n (the traditional one  
> derived from NAT44) and NAT66-1:1 (the one being designed). It's  
> more usage oriented, less internal-technique oriented.

Actually, there is a difference between being 1:1 and being stateful  
or stateless.  In the current NAT66 document (as opposed to what we've  
discussed since) the 1:1 algorithmic mapping is 1:1 and stateless,  
while the topology hiding mapping is 1:1, but it requires state to  
restore the subnet bits.  So we need both sets of terminology.  Unless  
you have a 1:1 way to map ports, I think that any mapping that maps  
ports will be stateful, even if it utilizes a 1:1 address mapping  
mechanism.

In an attempt to unravel or terminology in this case and around the  
topology hiding/node correlation discussion, I've started a taxonomy  
and terminology document that I'll post soon.  Hopefully we can all  
agree on the terms, which should let us have a better discussion of  
the trade-offs of different approaches.

Margaret

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Nov 2008 12:25:21 -0500

> we've heard so far) that most deployments will demand this.

I fully agree with the above.

In practice, I think most IPv6 host implementations at least
have implemented support for "IPv6 Privacy Addresses".

I do not clearly understand what the default setting might be
for that feature (i.e. enabled or not) in various implementations.

> the trade-offs of different approaches.

That seems likely to help focus discussion.

I'd urge that the document distinguish "topology hiding" from
"able to count the hosts behind the NAT", as the former does not
imply the latter AND the latter seems challenging to truly achieve
(e.g. see URL from an earlier note today).

Cheers,

Ran

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Nov 2008 12:36:07 -0500

> (e.g. see URL from an earlier note today).

Yes, that is absolutely a distinction that we need to make.

Also, we need to distinguish between "topology hiding" and "preventing  
the correlation of multiple connections with a single node" (which  
I've called "connection correlation" in my draft).

And between "reachability" and "the ability to uniquely identify a  
node"  With the use of firewalls and ULAs, it is possible to have an  
IPv6 address that uniquely identifies a node, but that can't be used  
to reach that node from some locations.  In IPv4, we have net 10  
address that don't uniquely identify a node, but may be useful to  
reach one (although not necessarily the right one) from some  
locations.  This could be a big difference for some management tools  
and applications.

Margaret

---

From: Rémi Després <[email-masked]>
Date: Wed, 26 Nov 2008 19:17:07 +0100

Margaret Wasserman  -  le (m/j/a) 11/26/08 6:18 PM:
> of whether we get that to work or not, though, 
:-(
To me, the freedom of defining new address formats for the future (i.e. 
upward compatibility and anticipation) should not be sacrificed for such 
a low order reason that finding transport ports of well known protocols 
would be found difficult.
> I think we should write an IETF document on IPv6 NAT that promotes the 
> implementation and deployment of a 1:1 stateless NAT and makes it 
> clear how the simple security benefits of NAT could be obtained with a 
> co-located stateful firewall (which should also be defined by the IETF).
FULL AGREEMENT
>>> leaving the ports alone are much more important than not modifying 
>>> the TCP/UDP checksums.
Not in my understanding: if the IID and the port are scrambled together, 
two consecutive connections of a host, having different ephemeral ports, 
will appear externally as having different IIDs.
> shouldn't have to put ports somewhere that we can modify them.
The rule would be of course to scramble ports only for protocols that 
are known to have ports, and in well known position (UDP, TCP, SCTP, 
DCCP that all have ports at the same place). For other protocols, the 
scrambling simply falls back to  address-only scrambling, which is fine.
> we've heard so far) that most deployments will demand this.
As a matter of fact, I may have been the first one, in February, to 
propose privacy addresses for this  
(http://www.ietf.org/mail-archive/web/ietf/current/msg50369.html).

It remains that between two changes of a privacy address all connections 
of a host are known to be from the same hos (and that changing for each 
connection as I first proposed is unrealistic).
>>> is later necessary to reconfigure the firewall to support demand for 
>>> a new application, the firewall can be reconfigured, while a 
>>> stateful NAT cannot.
>> than distinguishing between statefulness and statelessness,  we might 
>> prefer to distinguish between NAT66-1:n (the traditional one derived 
>> from NAT44) and NAT66-1:1 (the one being designed). It's more usage 
>> oriented, less internal-technique oriented.
>
Unless I am mistaken, what is proposed in 
http://www3.ietf.org/proceedings/08nov/slides/behave-15.pdf  IS INDEED a 
stateless 1:1 mapping of address + port.

Its scrambling goes as follows:
- Extract the n bits you are willing to change, from the different 
fields where you find them.
- Multiply them modulo 2^n by a secret odd multiplier.
- Place the result back where bits were extracted.
To unscramble, do the same but with the inverse of the multiplier.

RD