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

RE: NAT Traversal

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