[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NAT Traversal



On Fri, 1 Mar 2002, Tero Kivinen wrote:

> Chinna N.R. Pellacuru writes:
> > On Thu, 28 Feb 2002, Tero Kivinen wrote:
> > > 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.
>
> True, but if it is done after the decryption etc it must be done using
> the CPU (i.e the ethernet card etc cannot do it, the crypto hardware
> could do it, but I don't think they support this kind of operations
> (yet)). CPU is limited resource and might be too slow for this kind of
> operations.

Consider adding 24 bytes of encapsulation on each packet, and
decapsulating it and sending keepalives on the IKE SA for IKE and each
IPsec SA if each of them are using different source ports. Compared to all
this, recomputing the checksum is probably .01% of the cost.
Encapsulation, decapsulation and sending keepalives isn't done in hardware
too.

>
> > 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.
>
> I don't know any such protocols (note, it must work without modifying
> the NAT, and preferrably it will also tell what is the exact
> translation so we can do the checksum fixing quickly). Can you give me
> some pointers?
>

http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt

Abstract

   Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol
   that allows applications to discover the presence and types of
   Network Address Translators (NATs) and firewalls between them and the
   public Internet. It also provides the ability for applications to
   determine the public IP addresses allocated to them by the nat. STUN
   works with nearly all existing NATs, and does not require any special
   behavior from them. As a result, it allows a wide variety of
   applications to work through existing NAT infrastructure. The STUN
   protocol is very simple, being almost identical to echo.

Is that close enough? It's almost looks like they wrote the draft just for
us!

http://www.ietf.org/internet-drafts/draft-shore-friendly-midcom-00.txt

Seems to be asking more long term questions and seeking a longer term
solution to the problem of middleboxes interfearing with
network applications and protocols.


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

>
> > 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?
>
> Yes we still use them to identify IKE SA,

------------------------------------------------------------------------
No, you are NOT using cookies to identify the IKE SA. You are using them
as a "NON-IKE marker".
-----------------------------------------------------------------------

 but all the existing NAT
> boxes need to be updated to support new format. I am sure NAT vendors
> will be more than happy to sell new versions of the boxes which
> support next version of IKE, but I don't think customers are going to
> update their boxes any time soon. This means that we again have broken
> NAT traversal for those who relied on the NAT box doing this magic.

Firstly, the son-of-ike isn't finilized yet, and generally the time line
for updating IKE seems to be more like once every 5-10 years. We don't
update IKE every year.

>
> > "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.
>
> I agree that there is broken IPsec implementations there. I still
> would have fixed those broken implementations instead of making the
> patch for NAT boxes.
>

Wonder why those people went and updated their NAT boxes instead of fixing
their broken IPsec boxes. Is it easier to update a NAT box then to update
a broken IPsec box?


> > 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!
>
> There are much fewer IPsec boxes in the world than there are NAT
> boxes. Also IPsec boxes / software is normally adminstrated by you,
> you can control them. On the other hand NAT boxes normally are not
> adminstrated by you, you cannot update hotel's NAT box at will.
>

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.

> > 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.
>
> Running tcp over tcp has some quite bad characteristics (I know, we
> tried that in our first vpn systems, i.e running normal IP traffic
> over encrypted tcp/ip stream). I think most of the NAT boxes out there
> do support UDP.

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.

>
> > 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.
>
> Money? They will propably add new NAT box and sell you IPsec enabled
> version of their IP-connectivity :-) They are the ISP you know, they
> can do anything they want...
>

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?

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

----------------------------------------------------------------------
If an ISP can say, you can run what ever IPsec implementation you want,
and our NAT boxes can handle and translate the traffic, that is what a
serious customer will choose. Not an ISP who says, you have to UDP
encapsulate your ESP traffic (24 bytes of overhead) because we don't know
what our NAT boxes will do to the IPsec traffic.

I think we are coming from totally different angles, and hence the totally
different approaches.
----------------------------------------------------------------------

    chinna

> > If basic stuff is broken, then we are hosed anyway. Why bother to even
> > encapsulate ESP in another protocol?
>
> That was about the same comment I gave when I heard that NAT boxes
> does not support fragmentation...
> --
> 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