Re: NAT Traversal

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

On Thu, 28 Feb 2002, Tero Kivinen wrote:

> pcn@cisco.com ("Chinna N.R. Pellacuru") writes:
> > Depending on local policy, one of the following MUST be done:
> > a) If the protocol header after the ESP header is a TCP/UDP
> >    header, zero the checksum field in the TCP/UDP header.
> > b) If the protocol header after the ESP header is a TCP/UDP
> >    header, recompute the checksum field in the TCP/UDP header.
> > c) If the protocol header after the ESP header is a TCP/UDP
> >    header and the peer's real source IP address has been received
> >    according to [Kiv00], incrementally recompute the TCP/UDP checksum:
> >    - subtract the IP source address in the received packet
> >      from the checksum
> >    - add the real IP source address received via IKE to the checksum
> >
> > - What "local policy" is being reffered to here?
>
> Implementations own local policy. If the implementation knows for sure
> that it's TCP/UDP stack does not care about checksums, it can simply
> zero them. If the IPsec + NAT-T is working under operating system
> TCP/UDP stack, and cannot affect the checksumming code of the stack,
> it needs to recalculate the checksum (either by incremental update or
> with full packet).

"local policy" is only applicable to end system IPsec implementations. If
we are dealing with a security gateway IPsec implementation, then it won't
be easy to make any assumptions on what the hundreds of applications
expect which are running on thousands of hosts behind it. These machines
could be running different Operating Systems too.

>
> > - If it is OK here to just "recompute the checksum field" why not do it
> > for all ESP decapsulation.
>
> Performance reasons. Also it is simply extra stuff if you know that
> the operating system stack is going to ignore it anyways.
>

Calculating the checksum is a very cheap operation.

> > - IKE is a key management protocol. "NAT discovery" doesn't belong in a
>
> I agree. Some people in the WG think that we should also allow NATs to
> live, thus we must cope with them. If you do not agree with the IPsec
> WG, then you should complain to WG in general.
>
> The IPsec WG charter has item:
>
> ----------------------------------------------------------------------
> The IPSEC working group will restrict itself to the following
> short-term work items to improve the existing key management protocol
> (IKE) and IPSEC encapsulation protocols:
>
> 1. Changes to IKE to support NAT/Firewall traversal
> ...
> ----------------------------------------------------------------------
>

My only question is why should "NAT discovery" be included in a key
management protocol. Why can't it be done as a separate protocol, in and
of itself, so that as more generic protocols for "NAT discovery" evolve,
we can easily use those. "NAT discovery" is a generic problem that many
people are trying to solve. Why do we have to clutter the IKE protocol
with another vendor-id? Why should we try and come up with yet another way
of discovering NAT when there is already a lot of work done in the NAT
related working groups.


> > - Cookies are used to identify IKE SAs. Just because you have a bizzare
>
> Yes. Cookies identify IKE, and there is NOTHING anybody else can
> assume that the cookies are. For example the one of the son of the ike
> drafts changes the order of the cookies to fix one problem in IKE (i.e
> the cookie order will always be receiver, sender, not initiator,
> responder). Also the sender cookie can change. This means that all the
> NATs doing IKE cookie magic will be broken again...

But, the UDP encapsulation scheme tries to use the cookie as a "NON-IKE
marker". If cookies only identify the IKE SA, and there is NOTHING anybody
else can assume, why is the UDP encapsulation scheme trying to use the
cookie as a differentiator of whether the IKE packet is a IKE packet or a
packet which has ESP encapsulated in UDP? You can use something else.
Possibly a flag in the IKE header?

Even if you change the order of the cookies in son-of-ike, the cookies are
still being used for identifying an IKE SA. And, how often do we revise a
protocol like IKE?

"IKE cookie magic" is actually being done by NAT boxes not because the NAT
boxes are broken, but because of some broken IPsec implementations! The
"IKE cookie magic" is being done by NAT boxes because some IKE
implementations cannot deal with a src port other than 500 on the IKE
packets! The NAT boxes are trying to workaround broken IPsec boxes. I
don't think it is fair to turn around and blame those NAT boxes in this
situation.

So, for some reason, people felt that upgrading the NAT box by working
around a broken IPsec implementation is much easier than fixing and
upgrading the IPsec implementation. And, your "most important" design goal
is to not touch the NAT box, but only upgrade all IPsec boxes!

This supports our assumption that the NAT boxes are the ones which are
upgraded all the time, even if it so happens that there are some broken
IPsec boxes, and NAT has to come up with a workaround for it.

>
> > - Port 500 is for IKE, not for UDP encapsulated ESP traffic. The rest of
> > the world assumed that, and now that you are coming in later and breaking
> > that assumption, you should deal it somehow, and not expect the rest of
> > the world to just vanish. How convenient!
>
> Because of the broken NAT boxes we propably need to do special hack to
> switch ports on the fly inside phase 1 just to get those broken NAT
> boxes working.
>

Those NAT boxes are not broken. They are just trying to help out with
broken IKE implementations.

> > What design principles is your solution based on?
>
> Has to work with existing hardware. When this proposal was first made
> none of the NAT boxes did this kind of broken magic on the IKE
> packets, thus it worked fine with NAT boxes out there. Then we
> suddenly noticed that our fine proposal that worked everywhere has
> been broken by people doing some kind of magic that do work sometimes
> somewhere if the phase of the moon is right.
>

Does "existing hardware" include all existing hardware? UDP doesn't seem
to be working with all existing hardware. TCP seems to be the better
choice in some situations. If your goal is to work with all existing
hardware, then you should consider flexibility in which protocol to use
for encapsulation.

> > Why is not changing a NAT device the "most important" design
> > principle?
>
> I think second largist (or so) ISP in Finland would be too happy if I
> go there and say that I want to change their NAT boxes, so that I can
> run IPsec through it.

Probably that is the reason they are only the second largest, and not the
largest. What would it take to upgrade a handful of NAT boxes wihtout a
blip, and that too for such an important protocol like IPsec. To stay
competitive ISPs have to upgrade and honor the requirements of its users.
If there is no solution, then it's fine, but when there is a solution, if
one ISP doesn't upgrade, users will find one that is more sensible. I
don't see why upgrading a NAT box is being portrayed as if it is something
like upgrading all the switches in a Frame Relay cloud at once. If you
look at how NAT works, NAT is probably the simplest of all the upgrades an
ISP has to deal with.

>
> > NAT changes every day to accomidate new protocols.
>
> NAT might change, installed base does not change that often. What I
> would really like to see to get those broken NAT boxes to support
> basic IP properly before they start breaking other protocols. If the
> NAT vendors cannot even get the fragmentation/reassembly working I
> don't think we can assume they can get anything done properly.

If basic stuff is broken, then we are hosed anyway. Why bother to even
encapsulate ESP in another protocol?

>
> > Ever wonder why customers are buying those "IPsec pass-through" boxes like
> > crazy?
>
> Propably because they don't know anything about it and they do not
> know how it works? They think it might work, and next time when they
> start using it they will notice that it only works in some limited
> cases?
>

Firstly, UDP encapsulation will also only work in some limited cases.
There are claims of supporting some more *corner* cases by having a
"built-in NAT"  implementation, which is actually a whole NAT
implementation within IPsec.  I don't think anyone will actually implement
a whole NAT implementation within the IPsec implementation just to cover
some corner cases.

I know that Cisco has only recently implemented the basic "IPsec
pass-through" becuase of customers asking for it. This is deployed in the
field, and is working in production networks. These customers are not
consumers (not that consumers are not real customers), but real
enterprises who run business critical data over IPsec and use NAT. So,
saying that the "IPsec pass-through" doesn't work, is just trying to
mis-lead everyone here.

> > Because they work and it is simple and elegant and because of it's
> > simplicity they are cheap.
>
> Considering how much IPsec is now used if we count out all the VPN
> stuff, I don't think you can say that they work because people buy
> them... I think most of the customers who buy them haven't run single
> IPsec session through the boxes.
> --

No, there are real enterprises running their business critical data over
"IPsec pass-through" solution. The pressure on Cisco was so high that we
had to come up with something in a very short time that will improve the
scalability and predictablity of the "IPsec pass-through" solution, by
doing the SPI matching. This solution is not something that we just made
up. We already have it working.

> kivinen@ssh.fi
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
>

chinna narasimha reddy pellacuru
s/w engineer