RE: NAT Traversal

[Stephen Kent <kent@bbn.com>]

At 6:05 PM -0800 3/5/02, Chinna N.R. Pellacuru wrote:
>On Tue, 5 Mar 2002, Paul Koning wrote:
>>  Judging by the tone of your note, I am probably wasting my time, but I
>>  will make one more attempt to explain this to you.
>
>Same here. I'll also try and make one last attempt to try and convince you
>that RFC2401 pretty strongly recomments that the IPsec SA be picked on
>{dest IP, IPsec protocol, SPI}.
>
>First of all, the performance argument is pretty moot.

You have expressed an opinion that, for some types of designs, it's 
not a critical path factor. That's not the same as declaring it 
irrelevant in the overall, discussion.

>
>Please clarify your position more:
>
>And, are you saying that RFC 2401 is irrelevant to IPsec, because we are
>fully and more clearly specifying in an update to the ESP RFC, how all
>IPsec implementations should *implement* their internal SPI selection
>logic, (which has only local significance). How about an RFC just to
>specify how all IPsec implementations MUST *implement* their SPI
>selection. That way there will be no need to update RFC 2401 just because
>by "mistake" the *implementation* of SPI selection by all IPsec
>implementations was not specified properly.
>
>- Are there any IDs already trying to supercede RFC 2401?

I announced plans to revise ESP, AH, and 2401, in that order, in the 
later half of 2001. I noted the flavor of changes being made.  So, 
when we are finished, all three of these document will again be 
consistent.

>- Are there any IDs trying to just specify how all IPsec implemenations
>MUST *implemnt* their internal SPI selection.

Not to the best of my knowledge, unless you count the proposal you 
have put forth.

>- How can an ESP RFC supercede some behaviour in the Architecture RFC?

see the above reminder of what was announced many months ago.

>- Are there any IDs that are trying to "fix" this in AH too?

yes, you will see an updated AH published today or tomorrow, 
consistent with the timeline I advertised previously.

>- People are already complaining about the number of redirections that are
>needed becuase there are already too many RFCs that people have to read,
>to get a basic understanding of IPsec. By having a new kind of dependency
>where something is specified in one RFC (the Architecture RFC), and
>"fixed" in another RFC (a new ESP RFC) which is actually superceding
>another RFC (original ESP RFC), will just make people crazy.

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.

second, we chose not to wait until all the documents were revised to 
publish any of them. specifically, the iSCSI folks were anxiously 
awaiting the definition of the extended sequence number option, so we 
published the ESP update first, to address their needs.

	<deleted isolated quotes from various RFCs>

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. 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

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

Steve