Subject: Re: NAT Not Needed To Make Renumbering Easy

From: Christian Vogt <[email-masked]>
Date: Wed, 4 Nov 2009 07:51:06 -0500

On Oct 26, 2009, Andrew G. Malis wrote:

> Note that IPv6 NAT makes multihoming to different ISPs much easier as
> well.
>
> One thing that IPv6 NAT has in advantage to IPv4 NAT is that it can be
> stateless, isomorphic, and port transparent [...]

Right.  There is one limitation, though:  With stateless NAT'ing alone,
failover of active communication sessions between providers is not
possible.  This is because statelessness requires one-to-one address
mappings, hence a separate internal prefix for every provider-assigned
external prefix.  Many-to-one address mapping, such as by mapping a
single internal prefix onto multiple external prefixes, would require
stateful demultiplexing.

You can avoid above limitation with some support in the routing system.
[1] describes this.  It comes at a cost, however:  It requires selective
route announcements internally in lieu of a default route, as well as
redirects of incoming communication sessions.

- Christian

[1] http://christianvogt.mailup.net/pub/2008/vogt-2008-six-one-router-design.pdf

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Nov 2009 11:18:26 -0500

>>>>> "Christian" == Christian Vogt <[email-masked]> writes:

    Christian> Right.  There is one limitation, though: With stateless
    Christian> NAT'ing alone, failover of active communication
    Christian> sessions between providers is not possible.  

I agree with this statement.

    Christian> This is
    Christian> because statelessness requires one-to-one address
    Christian> mappings, hence a separate internal prefix for every
    Christian> provider-assigned external prefix.  Many-to-one address
    Christian> mapping, such as by mapping a single internal prefix
    Christian> onto multiple external prefixes, would require stateful
    Christian> demultiplexing.

I don't think this follows.  Statelessness only requires that when a
packet crosses from inside to outside, I be able to select the correct
external prefix without state.  There are a number of ways to do this,
including hashing the six-tuple (five tuple plus flow ID) to choose an
exit.  The return direction does not require state.

None of this allows you to fail over a connection.  However,
maintaining state does not help either.  If you have multiple external
prefixes most transports will not permit you to change the external
address on an ongoing connection.

We have a lot of tools if you want multihoming better than that.  Some
of them, like BGP multihoming, LISP and HIP, work quite nicely with
NAT66.  Others, like SHIM6, would need some work to work in a NAT66
environment.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 4 Nov 2009 22:27:28 -0500

On Nov 5, 2009, Sam Hartman wrote:

> There are a number of ways to do this, including hashing the six-tuple
> (five tuple plus flow ID) to choose an exit.

Yes, this is an alternative to what is described in the paper I referred
to.  It is an interesting idea actually.

> None of this allows you to fail over a connection.

Correct.  Another question is whether session failover is a requirement.
This may depend on the type of network we look at.  In some networks,
if failovers happen infrequently, a simple solution that causes some
sessions to break in the event of a failover may actually be acceptable.

All this requires extra intelligence in applications, of course: for NAT
traversal, and potentially for automated session re-establishment.  But
one may argue that applications require this functionality already  
today.

- Christian

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Nov 2009 09:55:02 -0500

>>>>> "Phillip" == Phillip Hallam-Baker <[email-masked]> writes:

    Phillip> I am not sure I want failover to be handled at the IP
    Phillip> transport level.  Failover is something I would see as
    Phillip> part of 'robust service connectivity' which would include
    Phillip> what to do if one or both endpoint hosts failed. 

I think I agree.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 06 Nov 2009 00:06:02 +0900

Christian Vogt wrote:

> Right.

Wrong.

As I already stated, proper translation of ftp PORT command,
for example, need stateful tracking of ftp command sequences.

Fragmentation reassembly needs another state, because transport
checksum may be located in second fragment.

And, IPv6 NAT can not be transparent to IPSEC.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Nov 2009 20:08:04 -0500

Lets start with a few design principles.

1) No application protocol has any business being tied to a particular
packet transport.

If your application transport is passing raw IP addresses about as a
means of forming connections it is broken. IP is the Inter-NETWORK
protocol. The original architecture made no assumption that IP would
run end to end, let alone that the IP address would be constant end to
end.

We have seen the result of designing IPSEC to be intentionally NAT
unfriendly. I was there in the IPSEC WG meeting when folk were
laughing about the problems they would cause for NAT. As a result
IPSEC was a botched protocol and has required ad hoc, proprietary and
in many cases patented tweaks to make it fit for its intended purpose.
Remote access over SSL or SSH works a lot better in practice than
IPSEC does.

I do not see any architectural value in insisting that applications
assume that the IP address is constant from one end of a communication
to the other. It is not a necessary assumption, it is not a helpful
assumption, it is not one that any application protocol can rely on if
it is to work on 99% of the Internet deployed today.

2) IPv6 should be as little different to deployed IPv4 as possible.

IPv4 has NAT, get over it. NAT will be essential to enable the
transition from 4 to 6, get over it. NAT is part of the IP stack and
people will insist that the functionality remains in IPv6, get over
it.

3) You can't force contractual obligations through technology standards.

IPv6 is a hard enough transition without people trying to use it as an
opportunity to refight battles they lost with IPv4. The only rationale
that I have heard for the resistance to NAT that makes the least sense
to me is Keith Moore's point that he would like to force ISPs to
provide functionality necessary for server/peer support.

Whether or not you think that is a good idea, you cannot push with a
piece of string. If Comcast does not want to support certain
functions, they will do that.

Remember that the first rule of the Internet is: You are SO NOT in
charge here (for all values of YOU). The US govt is not in charge,
ICANN is not in charge, Comcast is not in charge, the UN is not in
charge and that even goes for the IETF.

The Internet got the way it was because it did not make unnecessary rules.

Thirty odd years ago, IP address consistency might have mattered. But
the consistency of the Internet is not determined by IP address
consistency any more, it is determined by intersubjective agreement of
DNS address authority.

Asking why would people want to do X is not the way the Internet got here.

NAT66 may not be essential as a security control, but it is mighty
useful as a security audit tool. And auditing the security of a
network is at least as hard as securing one. So I would want someone
who thinks I should not NAT66 to give me a really good reason why not
and an equally effective audit control.

And no, 'I do not have a good feeling in my gut about this' is not an
argument, not even when the person making it is incredibly eminent.

If I sound somewhat testy on this subject, it is because I think that
the anti-NAT camp have been the biggest barrier to deployment of IPv6
by cutting off the only viable technical transition strategy.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Nov 2009 23:39:05 -0500

I am not sure I want failover to be handled at the IP transport level.

Failover is something I would see as part of 'robust service
connectivity' which would include what to do if one or both endpoint
hosts failed. If I have a strategy for dealing with that I should get
TCP reconnection for free.

Part of the problem here, is I believe a misinterpretation of the OSI
layer model, namely the idea that it is useful rather than a
hinderance. Thinking in terms of layers introduces unhelpful political
issues (lower layer folk think they are more important as they are the
foundation for what is built on top, upper layer think the lower
layers are beneath them). I now think of the 'layers' more as objects
in an encapsulation/object oriented fashion.

Where exactly does SSL fit in the layer model? It is actually an
application layer protocol that presents what appears to be a
transport protocol. And that is what I think any robustness package
should look like. In fact I am pretty sure we have that already in the
WS-* stack.

I would make the same argument for multicast. Anything that I would
want to use Internet multicast for is much better done by working at
the application layer. Network multicast is another matter, there the
deployment and security and resource allocation issues are tractable.

Working at the application layer using unicast as my main protocol, I
can imagine an architecture in which ISPs have the option of setting
up application layer burst points that allow large volumes of data to
be split off to multiple end recipients. As I am working at the
application layer I can set up my communications so that I have a
shared data channel and separate control/security channels for each
endpoint (this could be a reasonably straightforward derrivative SSL
even). I can also support caching at the nodes so that if 30% of the
audience for the baseball streaming video are actually wanting to
watch the game tape delayed, I can direct the data to be pulled from
the cache at the burst point rather than send the data over the wire
again.

Such an architecture could present an upper layer that looks pretty
much like HTTP as far as the application is concerned, just like SSL
is pretty much like TCP/IP.

But the main advantage of working that way, beyond simplicity is that
instead of sitting on our thumbs waiting for multicast to become
ubiquitous, we instead propose an architecture that creates direct
incentives for parties to play nice. The broadband ISPs would have to
pay for the cache hardware, their incentive to do so might be to
reduce their connection costs and/or payments from content providers
using the distribution mechanism. The content providers would have to
write a bit of code to support the system but would also see their
bandwidth costs drop.

The most interesting part though, would be how the ISPs would select
the content to cache. If there is a free market in broadband
provision, then the interests of the ISPs will be to choose the
content that minimizes their bandwidth costs. Otherwise they can
attempt to charge, but content providers know that the alternative
will cost the ISP money and reduce service to the customer, so their
bargaining leverage is perhaps limited.

A precondition for the scheme to work would be that the content would
have to be signed and there would have to be accountability so the
party injecting it into the system is a known entity.

That is the sort of thing you can do at the application layer but does
not make a whole lot of sense if you are dealling with the type of
things you are allowed to be dealing with at the transport layer.

Thats layers again... To the extent that the OSI model has utility, it
is that there are objects that you can only interact with at
particular layers in the stack. If it is copper wire then it better be
layer 1, if it is IP addresses then layer X, if it is organizations
then application layer.

On Wed, Nov 4, 2009 at 10:27 PM, Christian Vogt
<[email-masked]> wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 06 Nov 2009 07:24:40 +0900

> run end to end, let alone that the IP address would be constant end to

Your statement is well understood to be wrong and does not affect
the fact that ICMP, which is an integral part of the Internet from
the beginning, carrys raw IP addresses.

For a more recent example, RSVP establishes virtual connection
using raw IP addresses.

The reality is that the original architecture made no assumption
that IP would not run end to end.

Note that "Inter-NETWORK" of IP means "Inter-datalink". May I
laugh at you, please? 

> I was there in the IPSEC WG meeting when folk were

I'm fine to laugh at IPv6, which declares IPSEC MUST BE an
integral part of IPv6.

							Masataka Ohta

---

From: Christian Vogt <[email-masked]>
Date: Sat, 7 Nov 2009 04:30:45 -0500

On Nov 5, 2009, Masataka Ohta wrote:

> As I already stated, proper translation of ftp PORT command, for
> example, need stateful tracking of ftp command sequences.

That's right; address referrals don't work through address translation
in the absence of ALGs or host support for NAT traversal.  What was
meant is that the translation of the IP header is stateless, isomorphic,
and port transparent.

> may be located in second fragment.

No.  IPv6 NAT includes checksum offset compensation and hence does not
change the checksum.

> And, IPv6 NAT can not be transparent to IPSEC.

Nobody claimed that IPv6 NAT was transparent to IPsec.  But as you
mention it:  Of course, IPv6 NAT can be transparent to IPsec.  It
depends on whether the IP addresses in the (outermost) IP header are
covered by the protection.

- Christian

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 07 Nov 2009 19:39:07 +0900

Christian Vogt wrote:

> What was

Note that transport checksum must also be translated. See below.

> No.  IPv6 NAT includes checksum offset compensation

I'm not talking about the amount of value to be offset but the
location of transport checksum.

The location of transport checksum can be known only by traversing
all the extension headers from the beginning of a (unfragmented)
packet.

So, the second and latter fragments of the packet may or may not
contain transport checksum to be offset, which means IPv6 NAT must
first reassemble fragmentation.

> and hence does not change the checksum.

I'm not sure what you mean hear, after you mention "compensation".

> covered by the protection.

IPv6 specification requires IPSEC, which means outer most IPv6 must
also support IPSEC.

Feel free to laugh at stupid specification.

						Masataka Ohta

---

From: Christian Vogt <[email-masked]>
Date: Sat, 7 Nov 2009 21:30:13 -0500

> first reassemble fragmentation.

Why would an IPv6 NAT need to find the checksum if the checksum does
not need to be changed anyway?

> IPv6 specification requires IPSEC, which means outer most IPv6 must

Sure, no one is arguing with this.  My point was that, while IPv6 NAT
does interfere with some modes of IPsec, there are other IPsec modes
that are not affected by IPv6 NAT.  Makes sense?

- Christian

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 09 Nov 2009 18:12:07 +0900

> not need to be changed anyway?

Hmmm, you should be assuming that all the transport checksums will
be 1's complement 16 bit sum, even though modern transport protocols
are using different checksum.

Anyway, checksum of ICMP error generated against ICMP echo must
still be changed, and the error packet may (though does not usually
have to) be fragmented.

BTW, I have noticed that possibly-lengthy extension header is not
protected by IP nor transport checksum, which should be a flaw of
IPv6.

Also, SCTP ignores to protect source and destinaiton addresses
in IP header, maybe for NAT transparency, though IPv6 expect
transport protocls to do so.

> that are not affected by IPv6 NAT.  Makes sense?

The problem is that IPSEC requirement of IPv6 is not specified
as "some modes of IPsec" should be supported.

Instead, IPv6 requires support for AH and ESP extension headers.

I think we can laugh at the reason why IPv6 insists on IPSEC
documented in rfc2463.

   5.1 Authentication and Encryption of ICMP messages

   ICMP protocol packet exchanges can be authenticated using the IP
   Authentication Header [IPv6-AUTH].  A node SHOULD include an
   Authentication Header when sending ICMP messages if a security
   association for use with the IP Authentication Header exists for the
   destination address.  The security associations may have been created
   through manual configuration or through the operation of some key
   management protocol.

   Received Authentication Headers in ICMP packets MUST be verified for
   correctness and packets with incorrect authentication MUST be ignored
   and discarded.

where, thanks to IPSEC, DoS by ICMP can be prevented only with a
*SMALL* amount of computation and message exchanges of some key
management protocol. :-)

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Nov 2009 11:22:08 -0500

We are so not in charge.

Support for IPSEC is a requirement to describe an implementation as
IPv6. That is all, it does not mean anyone has to use it, or that they
will use it.

There are two typical modes of deployment for IPSEC, the first is as a
lousy remote access protocol where the lack of NAT support makes it
far more effort than other solutions. SSL and SSH remote access just
works, IPSEC VPN may or may not work depending on the phase of the
moon. The third party clients are terrible, the built in support in
the O/S is unusable because it does not have the tweaks necessary to
get through the firewall. So we do not really have a standard for
IPSEC remote access.

The other mode for IPSEC is not really an Internet application, it is
creating a virtual network by joining together a bunch of routers at
local sites. Here the NAT issue is moot because the objective is to
create a single network with a consistent IP address space. The fact
that this is usually NAT space is not really relevant unless you are
attempting to create an industry wide network. Have fun with that.

What IPSEC has never got close to achieving is providing an Internet
security solution in which packets are secure at the transport layer
by default. The obvious reason for this is that IPSEC is not connected
to a pervasively deployed PKI for authenticating the end points. There
is no commercial infrastructure to support this today, and I doubt
that there will be one for some time. NAT is relevant to this scenario
only insofar as it will be aa fait acompli long before any PKI is
established that might support pervasive IPSEC.

And lest folk think I am picking on them here, the reason I raise
problems is because I want to see them fixed, not just to carp. I want
to deploy DNSSEC because I think that it is the most appropriate PKI
to support packet level security.

I use NAT for a very simple reason: I do not want my machines to be on
the Internet by default. I only want my printers to be accessed by
machines in my network. I only want the security system, the home
automation system, the daleks, the lab, the coffee maker to be
accessible from the network. I do not want Mr Coffee talking to
strange computers, he has little common sense.

Now I would like my network to have a greater geographic extent than
just my house. But there is still a very clear distinction between
machines that I own, that I am responsible for, that I want to connect
to my network core and all the rest of the stuff on the Internet.

Some computers, the desktops and laptops, I do want to have greater
access, but there are only eight of them in total, that is a small
fraction of my network.

The ability to give these devices and IP address THAT WILL NOT ROUTE
is very valuable to me as a security control. It is not a perfect
control, but I have many, many layers to my defense in depth and I
want all of them.

We are not in charge of the Internet, but I am in charge of my
network, and my policy is to use NAT.

In a commercial environment, policy is everything. You do not get
security from security technology, you get it from the security
practices that the technology supports.

Changing a security policy in a commercial environment is a very
expensive affair. People are going to demand NAT66 (and cisco is going
to support it) because it is cheaper to deploy NAT66 than change the
policy.

But even then, we are getting way ahead of ourselves. In the real
world every network is going to have IPv4 devices on it for decades. I
have a 36" plotter upstairs that is ten years old. I am not paying $3K
to upgrade it just for the sake of IPv6.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Nov 2009 09:41:54 +1100

In message <[email-masked]>, Phill
> strange computers, he has little common sense.

Well give your printers a ULA addressand don't advertise the prefix.
You don't need NAT to provide this seperation.
 
> to upgrade it just for the sake of IPv6.

And your boxes will talk to it over IPv4  even if you don't have a
external IPv4 connection.
 
Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 10 Nov 2009 03:11:56 +0000

> get through the firewall. So we do not really have a standard for

There's at least one product making actual money in this space,  
Hamachi ( http://www.hamachi.cc/ ).  Basically third-party-mediated  
IPSec-lite that goes over NAT.  If you must use NAT, at least be aware  
of what can come back to your network due to NAT behaviour and  
internally initiated connections.  I don't think NAT is providing the  
right kind of security here.  But I must be careful not to start  
another flame war.

But anyway, IPv6/Teredo does the same thing, and better; Microsoft is  
working on going that extra mile with IP over HTTPS, too, so soon  
we'll have peer-to-peer VPNs that really do "Just work".  In every  
case it is better than Hamachi's use of unassigned address space, and  
in no case better than fixing the trouble at the root, and shredding  
NAT.

But, if NAT's your thing ...

Cheers,
Sabahattin

---

From: Christian Vogt <[email-masked]>
Date: Mon, 9 Nov 2009 23:28:07 -0500

> still be changed, and the error packet may (though does not usually

Sure, applications that use address referrals don't work well through
NAT; we mentioned this earlier.  ICMP is one of these "applications".

- Christian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 11 Nov 2009 09:51:22 +0900

> NAT; we mentioned this earlier.  ICMP is one of these "applications".

You miss the point.

People expect NAT support ICMP. But, NAT for ICMPv6 does not need
state, unless it is ICMP error against ICMP echo, contains large
routing header, is fragmented and the first fragment does not
contain checksum.

It is an example of how IPv6 was bloated to have many useless
features ignoring corner cases of interactions of the features.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Nov 2009 22:13:47 -0500

Forgive me if I do not see botching the IPSEC spec so that it fails
through NAT as an argument against NAT.

Why don't we repair the damage instead? If we are serious about the
IPv6 transition then we should be insisting that IPSEC work
transparently over NAT46 and NAT64.

Its easy enough to solve the NAT issue in IPSEC.

Just extend the key agreement so that the endpoints inform each other
of the IP address that they believe to be in use and store that with
the key data required to check the MAC. Then consider fixing up the IP
address to be part of the verification function.

Problem solved - unless some patent troll has claimed this rather obvious fix.

The IETF can choose not to add it to the standard, and thus choose to
ensure that IPSEC connectivity remains fragile. But that is a really
lousy way to respect your customers.

Authenticating the IP address is totally unnecessary from a security
point of view, the data can only be checked at the security
association endpoint. So if the packet has got there the address can't
have been too far wrong. Further the binding of the key to the
security association is going to be keyed of the IP source and
destination addresses so it is rather hard to see how an attacker can
gain from manipulating the IP addresses.

Probably simpler to just declare some dummy algorithm identifiers for
HMAC-SHA256 ignoring the IP addresses.

And you can probably use the exact same hack to make the connection
NAT46/64 agnostic, though to be honest I have not thought the issue
through.

OK back to polishing the moulds for my robot.

On Mon, Nov 9, 2009 at 10:11 PM, Sabahattin Gucukoglu
<[email-masked]> wrote:
> There's at least one product making actual money in this space, Hamachi (
> http://www.hamachi.cc/ ).  Basically third-party-mediated IPSec-lite that
> goes over NAT.  If you must use NAT, at least be aware of what can come back
> to your network due to NAT behaviour and internally initiated connections.
>  I don't think NAT is providing the right kind of security here.  But I must
> be careful not to start another flame war.
>
> working on going that extra mile with IP over HTTPS, too, so soon we'll have
> peer-to-peer VPNs that really do "Just work".  In every case it is better
> than Hamachi's use of unassigned address space, and in no case better than
> fixing the trouble at the root, and shredding NAT.
>