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

RE: NAT Traversal



Given that we have sufficiently diluted the discussion, and pulled it in
all possible tangents, let me try to summarize the main disadvantages of
UDP encapsulation. This is the thought process that prompted us to look
for another soluton:

- overhead of 16 bytes per ESP packet (according to latest drafts). The
real time voice protocols are already effected by the ESP overhead per
voice frame. If we keep on adding to this overhead then fewer and fewer
protocols will use IPsec. It's always a tradeoff between the benefits Vs
cost, and these people will develop their own protocols for securing their
traffic. We are increasing the price people have to pay for security,
which is already too high according to many people.

- Because of the above enormous overhead, it becomes absolutely necessary
for the encapsulation schemes to "discover NAT". All the current schemes
propose modifying IKE to do this. IKE is already considered to be too
complex, and we thought that the IETF will not approve anymore changes to
IKE anyway. But, looks like most people are OK with modifying IKE just for
this one thing. Even if the WG is OK with it, we are still paying a price
of increasing the complexity of IKE.

- UDP encapsulation schemes require the use of keepalives to keep the
translation alive. That would not be easy to do, particularly if you are
assuming that no one knows what kind of NAT boxes are out there. It's like
trying to sneak through NAT, and when we get burnt, give up. It is more
prudent for a customer with business critical data that needs to get
across, to make absolutely sure about what kind of NAT devices exist
enroute, and plan his network accordingly end-to-end. We felt that the UDP
encapsulation schemes are heavyly over engineered for the "road-warrior"
scenario, at the expence of everyone else. There are some very simplistic
assumptions that a "road-warror" can never have any control over what NAT
devices are out there. While it is true, not everyone is a "road-warrior".
There is a vast majority of IPsec users who have a home and an office, and
can know and influence what kind of NAT devices are butchering their IPsec
traffic.

- We had reports of some UDP encapsulation deployments having trouble, and
the solution being using TCP, but using a skinny TCP protocol without
retransmits and other stuff on each side. We felt that using TCP isn't
going to be an option because of all the violations that it would need.

- As people have pointed out, even our solution has a lot of restrictions
on which scenarios are supported. But, those restrictions also apply to
the UDP encapsulation schemes. There are some schemes that claim to
support more scenarios, but when we looked at them, they were paying a
price that we were not willing to pay in terms of implementing a "built-in
NAT". That's a whole NAT implementation within IPsec. That is exporting
the NAT functionality to another device that is actually an IPsec device.
It is not easy to manage multiple NAT devices, and it would be almost
impossible to manage multiple NAT devices, and multiple NAT
implementations within each IPsec implementation.

I hope people can appreciate what prompted us to look for an alternative
solution to the UDP encapsulation schemes.

    chinna


On Mon, 4 Mar 2002, Srinivasa Addepalli wrote:

>
> Hi Chinna,
>    As I see it, we are trying to debate on three solutions:
>
>    1. Supporting ESP ALG in NAT boxes with SPI changes.
>    2. NAT traversal as defined in current drafts.
>    3. Some independent solution. ( You indicated that independent NAT
>       discovery
>       and NAT traversal alerady being taken care off by midcom
>       working group. So, we can postpone this discussion).
>
>    Solution 2:
>      By standardizing different UDP port for encapsulating ESP/AH traffic,
>      it works through all existing NATs (supporting ESP ALG or not).
>      One disadvantage is that it requires changes to IKE/IPSEC
>      implementations.
>
>      By having different UDP port, the overhead also comes down by
>      8 bytes. But, one more keepalive timer is required to make
>      the NAT session alive.
>
>    Solution 1:
>      Have limitations such as only ESP traffic, no AH traffic.
>      What about Transport Mode? Does this solution support?
>      SPI modifications which require changes in existing hardware
>      and software implementations. (It was assumed that SPI selection
>      is local matter).
>      What happens if hash value of different SPIs come out to be same?
>      How does it work, if quick mode responder sends the packets first?
>
>
>   Keeping both the solutions in mind, it appears that solution 2 is
>   better.
>
>
> Regards
> Srini
>
> On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote:
>
> > On Mon, 4 Mar 2002, Paul Koning wrote:
> > > >>>>> "Chinna" == Chinna N R Pellacuru <pcn@cisco.com> writes:
> > >
> > >  Chinna> And considering the fact that an IPsec SA is identified by
> > >  Chinna> the tuple: Destination, Protocol and SPI, the probability of
> > >  Chinna> a collision is even lower, and for all practical purposes
> > >  Chinna> zero.
> > >
> > > But we're talking about NAT.  NAT hides addresses behind it and makes
> > > everything look like a single address.
> > >
> > > So in the context of NAT (at the other end) you have lots of SAs from
> > > the same address, and of course the protocol is constant (50).
> > >
> >
> > I think that there seems to be a big problem with people who want to only
> > casually look at this problem of NAT and IPsec. I think that these casual
> > observers tend to assume that any and every possible scenario of NATs and
> > IPsec will work with some solution. You'll have to first take the time to
> > understand what is feasible, and what is not. Once you have come up with a
> > set of scenarios in which it is feasible to solve this problem, then you
> > have to pick a technique that will only work in those scenarios.
> >
> > Now, given that, please let me know what scenario are you particularly
> > interested in, and I can try and see if our solution will work. Without
> > the details, I don't know what you are talking about. Lets not try and
> > talk about NAT and IPsec in general, because I think both of these
> > protocols are very complex individually, and once you combine them, they
> > tend to become intractable.
> >
> >     chinna
> >
>
> --
> Srinivasa Rao Addepalli
> Intoto Inc.
> 3160, De La Cruz Blvd #100
> Santa Clara, CA
> USA
> Ph: 408-844-0480 x317
>

chinna narasimha reddy pellacuru
s/w engineer