Re: NAT Traversal

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

On Wed, 6 Mar 2002, Tero Kivinen wrote:

> pcn@cisco.com ("Chinna N.R. Pellacuru") writes:
> > - 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.
>
> And, again I will once more repeat, only you are sending keeplives
> only if there is no other traffic going out, and only from the host
> that is behind NAT box (i.e the "server" end with fixed ip-address
> will not ever send them), and also the interval can be configured.

Consider a small router that is providing IPsec protection to a SOHO
network. If they are doing "continuous channel implementation", with no
"dangling SAs", then the box has the SAs up all the time, and even when
there is no data traffic, the router will be forced to keepalive the NAT
translations by sending IKE NAT keepalives. If the recommended NAT
keepalive timer is 20 seconds (I have seen practical deployment
recommendations as low as 9 seconds), that is a lot of bandwidth being
consumed by probably a lot of otherwise idle boxes that are trying to
keepalive NAT translations.

>
> > 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.
>
> If they can control the NAT boxes, then fine, they can modify the
> NAT-T translation lifetime up to 1 hour, and set the keepalive
> interval of the IPsec to 30 minutes. No need to complain about
> keepalives consuming bandwidth.

If they can control the NAT boxes, why should they take a hit of 16 bytes
of UDP encapsulation? My complaint is more about the encapsulation
overhead here.

>
> > - 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".
>
> Lets put it this way, if you ever want to get active mode FTP through
> the NAT that is forwarding IPsec packets, someone who has the clear
> text traffic must do the translation of the application data.
>

I vote for your option #2, because it is simpler, and that is why even we
support this scenario only.

    chinna