Re: NAT Traversal

[Tero Kivinen <[e-mail]>]

Chinna N.R. Pellacuru writes:
> Consider adding 24 bytes of encapsulation on each packet, and
> decapsulating it

All this can (and will) be done using hardware without problems,
adding fixed amount of the header is quite easy to implement on the
hardware.... 

> and sending keepalives on the IKE SA for IKE and each
> IPsec SA if each of them are using different source ports.

The keepalives are only needed if you are actually the one who is
behind NAT box. If we are talking about road warrior - SGW case, then
the road warrior will send keepalives, the SGW will not send them.
Also we are mostly interested in the performance in the SGW end the
road warriors laptop do have enough cpu to do the few SA flow
processing it is doing. The SGW might be doing thousands of tunnels
and every small operation we need to do there counts. 

> Compared to all this, recomputing the checksum is probably .01% of
> the cost.

If that is so small why do you think people are adding checksum
calculation on the ethernet cards then?

> Encapsulation, decapsulation and sending keepalives isn't done in hardware
> too.

Encapsulation and decapsulation can be done in the hardware, the
keepalives are not usually sent by the end that is more performance
limited, thus they are not interesting here. 

> http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt
...
> Is that close enough? It's almost looks like they wrote the draft just for
> us!

I have to check it out. BTW they also complains that upgrading NAT(s)
is not an option, so I agree with them at least with that :-)

The STUN protocol seems quite complicated, it for example does binary
search with different timeouts to find out the lifetime discovery etc.
It also does not implement any tunneling mechanism, and it does not
provide protocol to give the information to the other end (to undo the
modifications done by NAT box, both ends needs to know what
transformations are happening). 

> > If would have done it by putting the complete IKE header and special
> > IKE payload number which contains the whole packet inside, but some
> > other people considered 28 bytes of IKE header too much.
> 
> 24 Vs 28.

8 vs 28 or 16 vs 36 bytes. Current UDP encapsulation has UDP header
(8 bytes) + non-ike marker (8 bytes). If we add full ike header it
would be UDP header (8 bytes) + ike header (28 bytes). All of those
packets then have still IP header (20 bytes). 

> How much is too much? 24 is OK but 28 is too much? 24 bytes of
> encapsulation on every data packet is huge! And, this is on top of what
> ESP adds.

I think you have something wrong with the calculations. Normal ESP
packet is

IP(20) + ESP(xxx)

trasnport mode nat encapsulated IP packet is:

IP(20) + UDP(8) + NonIKE(8) + ESP(xxx)

So the difference is 16 bytes. Where does the 24 come? If we would add
full IKE header then the difference would be 36 bytes. Some people
think that is too much. 

> This seems to be the main theme in your design principles. IPsec boxes are
> administered by the user, but NAT boxes are administered by the hotels and
> conferences. You seem to be heavily over engineered towards the
> "road-warrior" scenario. "road-warrior" is just one scenario in which
> IPsec is used, there are many other scenarios where someone has more
> control over where the data is going, and how it is being routed.

I agree, I am considering the case where I am moving around with my
laptop, and I want to connect all kinds of hosts around the world
using ipsec. This includes office network in Finland, my home machine,
and hopefully later more and more using opportunistic encryption or
similar. In that kind of cases I normally don't have option do
anything for the NAT, but I have option for updating at least some of
the ipsec systems I am talking with (actually I wrote most of those
IKE implementations, and they do work already, and have been working
from the beginning).

If I can control the NAT box then the problem space is different, but
in that case I also usually do have control over the IPsec still (or
can you give me example where I have control over the NAT box, but I
don't have control over the IPsec box ("having control" meaning that I
can update / change the box)).

So I almost always have control over the IPsec box and for some of
those case I can also have control over the NAT box.

> So, your goal is to work with "most" NAT boxes, and NOT "all" NAT boxes.
> Just confirming that, I think there were some claims made that you need
> to work with "all" NAT boxes.

We tried to work with "most" NAT boxes, because some of the NAT boxes
do not for example support UDP at all. We do not try to work with
those. Also I am pretty much sure there are yet another type of NAT
boxes I have never ever heard about that will not work, because they
do something different.

Knowing how much broken stuff there is out there, I think there is no
way anybody can make anything that will work with "all" boxes. 

> Hey, if they want to follow the money, you should advice them to start
> talking about "VALUE-ADD". You should advice them to not focus only on
> cyber cowboys who don't care whether their traffic is being routed over
> long-haul DWDM or barbed wire. They should also focus on businesses that
> want to run misson critical data over their networks. If you talk to such
> businesses they have very detailed requirements. Their requirements are
> down to the level of what door stop you use in your office, if you want to
> provide service/equipement to them. That is where the $$$$$$$ is, in
> "VALUE-ADD". How much does a "business" DSL cost, and how much does a
> "consumer" DSL cost?

Business DSL (without NAT at all) costs about double to the "consumer"
DSL (most of them are with NAT).

> A road-warrior who doesn't care what kind of NAT box the ISP is running
> isn't going to pay big $. It's the business customers and corporations who
> specify every detail of how they want their traffic to be routed, that pay
> the big $$$$$$$.

And they do not want to have anything that looks like NAT anywhere
near if they can avoid it. 
-- 
[e-mail]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/