RE: NAT Traversal

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

On Wed, 6 Mar 2002, Stephen Kent wrote:

> first, despite your protestations, what we have described in the new
> ESP and AH drafts (with regard to SA demuxing) does not mandate
> changes to existing implementations and it is consistent with the
> current specs, from the perspective of an external IPsec peer.

That clears up a lot for me.

>
> The bottom line is that your proposal would affect how IPsec
> implementations choose SPIs, and thus is in conflict with the parts
> of 2401 that you choose not to quote, but which Paul pointed to
> earlier.

We plan to only effect IPsec implementations that choose to use our
proposal. They can choose our proposal if they want to get through NAT the
way we propose is a better way to get through NAT if someone has the
control or influence on the NAT devices.

More importantly, as I described in detail in my previous
> message, in most common contexts, the clarifications expressed in the
> new AH and ESP drafts do NOT have any appreciable impact on the
> effective SPI space. This is because:
> 	- AH is rarely used
> 	- an implementation that serves a single IPsec destination
> (i.e., and end system or a security gateway in a firewall, etc.) has
> no opportunity to use destination address for demuxing
>

I agree, I do not see anything I want to object to in your ESP draft.

Even though IPsec implementations that use destination address for
demuxing are rare by looking at raw numbers, I don't see how some
important kind of VPNs can be deployed wihtout having this flexibility of
choosing whatever tunnel endpoint the user wants to.


> That minimal or non-existent impact stands in stark contrast to a
> proposal to reduce the space by a factor of 65K.
>
> Steve
>

Point taken. We propose to folks who want to use our proposal to reduce
the SPI space by 16 bits, but not give up their flexibility of using
different tunnel endpoints to demux incoming ESP/AH traffic.

    chinna

chinna narasimha reddy pellacuru
s/w engineer