RE: NAT Traversal

[Stephen Kent <kent@bbn.com>]

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