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

RE: NAT Traversal



Excerpt of message (sent 5 March 2002) by Chinna N.R. Pellacuru:
> 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}.

There is absolutely nothing in any RFC that requires an IPsec
implementation to allow the existence of two inbound SAs for
<DA1,Prot1,SPI1> and <DA2,Prot2,SPI2> where DA1 != DA2 || Prot1 != Prot2
such that SPI1 == SPI2.  Yes, that's allowed, no, it's not required.

Furthermore, there's this point: how many distinct values of DA and
Prot are there in a given IPsec implementation in the first place?

For an edge device with one WAN-side interface, there may very well be
just one possible DA for inbound IPsec traffic -- that WAN interface
address.  If only ESP is used by the customer, there is just one
protocol (50).

So it doesn't matter whether the SPI values are distinct among all SAs
in the box, or unique only within a single DA and protocol -- because
there may easily be just one DA and one protocol.  

> First of all, the performance argument is pretty moot.

Only if you don't care about the price/performance of your product.
 
> 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?

Nothing I said relies in any way, shape, or form on any I-D
whatsoever.  I'm only talking about what's in the RFCs.

Of course RFC 2401 is relevant to IPsec.  Why else would I quote from
RFC 2401 to support an argument about IPsec?

Right now, the RFCs say that choice of SPIs is a local matter.  For
example, RFC 2409, page 18, says:

    Different SPIs for each SA (one chosen by
   the initiator, the other by the responder)...

The text from RFC 2401 I quoted earlier makes the same point.

So there is specific text that says the choice of SPI values is a
local matter done at each end.  There is no text that imposes specific
requirements on the algorithm used for doing this, with one
exception: values 0-255 are reserved.

Yes, it would be possible to create an RFC that requires a particular
algorithm for SPI assignment.  Such an RFC would impose new
restrictions, thereby requiring redesign of some IPsec
implementations.  That redesign will come at a performance penalty
if it requires the SA lookup to become more complex.

If such a proposed new restriction was well enough justified, it would
presumably be adopted.

So the real question is: is the specific new restriction which you are
proposing -- requring half of the SPI bits to be computed as a
function of some other input -- justified by something sufficiently
valuable to convince people that they should support this notion?

That's for the WG to decide.  I've stated my answer, which is "no".
The reason is that I don't see a good argument for limiting the max SA
count to 64k.  Or more precisely, 64k for some currently conforming
implementations, and 64k times the number of protocols (1 or 2) times
the number of local SA endpoint addresses (which is 1 for a
significant class of products/configurations) in the most general
case.

       paul