RE: NAT Traversal

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

Hi Steve,

Is it possible that along with the sequence number, we also increase the
SPI space so that we can use some of the SPI space for NAT translation.
We could keep the original restrictions on how to pick an SA, or we need
to come up with elaborate schemes to effectively increase the SPI space,
like you are attempting to increase the sequence number.

How does the transition happen? If the new ESP ID is placing additional
restrictions that did not exist originally I think it is fair to ask the
new ID to accomidate NAT traversal by increasing the SPI space. It's like
shutting off all the doors for us.

You bring up another good point about multicast. Frankly, I haven't
thought about it. I'll have to look at this and get back to you and the
list.

    thanks,
    chinna


On Mon, 4 Mar 2002, Stephen Kent wrote:

> Chinna,
>
> Reasonable questions. Let me try to provide some history and explain
> the motivations for the clarifications:
>
> 	<SNIP>
>
> >
> >  > Just a few notes re this discussion:
> >>
> >>	- the revised ESP/AH documents emphasize that an IPsec
> >>  implementation need not use the protocol type for SPI
> >>  differentiation. so, if one starts assuming this is true, it will be
> >>  yet another conflict with the IPsec specs
> >
> >Curious what are the reasons for removing this restriction, and what are
> >the cons of still reqiring that this restriction apply.
>
> There was never a real need to use the protocol type and, in fact,
> one IPsec device generally cannot tell if its peer is or is not using
> the protocol type for SPI demuxing. We got feedback over the last 2
> years from vendors asking us to revise the description to better
> reflect what they tended to do, and which in no way detracted from
> interoperability.
>
> As for the destination address, this was a result of poor wording,
> i.e., we never needed this for demuxing, except for multicast, but we
> did a very poor job of saying that.  Again, we have gotten feedback
> from vendors who didn't understand why this "requirement" was
> imposed, and so we explained under what circumstances one really
> needs to use the dest addr for SPI demuxing.
>
> >
> >>
> >>	- similarly, an IPsec implementation does not need to use the
> >>  dest IP address as part of the SPI lookup, unless that address is for
> >>  a multicast group.
> >>
> >
> >Here also, curious why that it is not required anymore to have dest IP
> >address as part of SPI lookup.
>
> It never was needed, as noted above, except for multicast. It is
> needed for multicast only because in that case the receiver does NOT
> select the SPI, i.e., the multicast controller does.  If you propose
> to impose restrictions on SPI generation, you should take into
> account the multicast case as well.  The MSEC WG is getting close to
> promulgating standards that will support the simple case,  single
> sender, multiple receivers, so we should be careful to not do
> anything that will interfere with that work.
>
> >
> >>	- do I understand correctly that you are suggesting a change
> >>  to the specs to reduce the effective SPI space by a factor of 65K?
> >>  is everyone comfortable with this?
> >>
> >>  Steve
> >>
> >
> >I am suggesting that the original concept of IPsec SA being identified by
> >a tuple: destination IP, protocol, SPI be required, and within the SPI add
> >new semantics for picking a SPI on the phase2 responder.
>
> The new ESP ID, published before the December IETF, clarified the SPI
> demuxing description. We have received feedback on the ID, and nobody
> has voiced any objections to this revised SPI demuxing description.
> There appear to be no "cons" to the new wording. The "pros" are that
> IPsec implementations need not spend cycles matching additional
> fields in inbound IPsec headers that are not needed to demux SAs,
> which potentially improves performance.  As people develop high speed
> IPsec implementations (note the extended sequence number option is
> motivated by the need to support multi-gigabit IPsec speeds), using
> fewer inputs to SA selection for inbound traffic reduces costs (e.g.,
> narrower CAMs).
>
> Steve
>

chinna narasimha reddy pellacuru
s/w engineer