Re: NAT Traversal

["Chinna N.R. Pellacuru" <[e-mail]>]

On Sun, 3 Mar 2002, Tero Kivinen wrote:

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

Anything can be done in hardware. I am not sure what you are referring to
as "hardware". I think even basic ESP and AH are still only being
implemented in firmware mostly. I don't think people are doing
encapsulation in hardware yet.

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

That's good. Is that mentioned in the drafts? I thought that the draft
didn't give so much detail about keepalives. It just says "A peer SHOULD
send a NAT-keepalive packet if a need to send such packets is detected
according to [Kiv00] and if no other packet to the peer has...".

It also says that the keepalive timer should be 20 seconds, but I read
somewhere else that the practical recommended default timer is 9 seconds.

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

The checksum is a simple 16-bit ones-complement sum of the data. If the
checksum is so fool proof why is it not a MUST, and is only optional. I
think even back in those days when the hardware wasn't so reliable, the
designers made a conscious decision to use a dumb checksum which may not
catch all the errors in favour of an efficient and cheap software
implementation.

This can be done in "hardware" too for IPsec as part of the ESP
decapsulation.

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

OK. It's done in "hardware". It's generally done in firmware.

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

What do you propose? Instead use a very low lifetime so that it would work
everywhere? I think it would save a lot of chatter by choosing the right
lifetime, and using an appropriate lifetime rather than using a minimum
default of 9 seconds always, like some implementations do.

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

I am not proposing that you come up with another version of IKE just for
NAT traversal. I am saying that you can use a generic "NAT discovery"
protocol before even starting IKE.

If you use a generic protocol like the one above, you get those
tremendrous benefits like finding out the lifetime you have to use.
Keepalives are also consuming precious bandwidth. They shouldn't be just
considered from a CPU cost on laptops point of view.

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

OK. It's 16 bytes of overhead. I think that I saw a proposal that used
24 bytes at some point. 16 bytes is still a lot of overhead for each ESP
packet.

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

Who said 16 bytes of overhead is OK? People are already screaming about
the ESP overhead.

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

Yes, there are a ton of cases where someone has total control over all the
boxes, and in those cases the encapsulation overhead and keepalive
overhead can be saved both in terms of bandwidth and CPU costs on the
IPsec endpoints. Just because laptops have enough CPU capacity to do
whatever including stuff like sending keepalives very frequently, all the
nodes across the route has to forward them even the security gateway has
to some how deal with them to even simply discard them.

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

And there are these NAT boxes that were upgraded because some IPsec
implementations were broken, and your proposal will again not work through
these NAT boxes. It's ironic that broken IPsec will work through these
upgraded NAT boxes, but IPsec-NAT-traversal won't work.

------------------------------------------------------------------------
Some IPsec implementations were broken, and so people to workaround it
upgraded their NAT boxes with a hack. Now, there comes along this new
IPsec NAT traversal protocol which again doesn't work with these NAT
boxes, and so the NAT boxes need to be upgraded again to come up with
another hack to work with this new IPsec NAT Traversal protocol.  The
second upgrade to the NAT box is required because the IPsec NAT traversal
protocol is designed with the most important design goal as, NAT boxes
will NOT be upgraded! There seems to be a BIG disconnect between your
design goals and practical deployment.

If people are upgrading their NAT boxes with hacks to make broken IPsec
implementations work through them, then I am 100% sure that people will
upgrade them with a standard IPsec pass-through solution, that is much
more reliable adn doesn't have the enourmous costs of encapsulation and
keepalives.
-------------------------------------------------------------------------

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

OK. I just wanted to confirm, so that we are not setting unrealisitc
goals.

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

Exactly, "VALUE-ADD" is what people are willing to pay for double the
cost, and sometimes even more. My point is that the ISPs can add some
"VALUE" using our proposal, by translating IPsec properly, instead of the
customers trying to figure out a way by themselves to somehow sneak
through the ISP's NAT implementation.

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

Yes, most importantly "if" they can avoid it. Like anything else, NAT is
also trying to solve some important problems.

    chinna