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

RE: NAT Traversal



	<SNIP>

>We based our design on what the RFC 2401 says:
>
>"         o SPI: the 32-bit value used to distinguish among different
>            SAs terminating at the same destination and using the same
>            IPsec protocol.
>            [REQUIRED for all implementations]
>"

Chiana,

I'll continue to explain the reasoning behind the clarifications that 
have already appeared in the revised ESP ID and in the about to be 
published AH ID, despite your increasingly belligerent messages. 
Ignoring my responses to your comments and pointing to isolated 
pieces of text from RFCs to support your position is not constructive.

>So, RFC 2401 is wrong? The suggestion is that we reduce the SAID space by
>4 bytes of IP address, and a bit for protocol (because we currently have
>only two IPsec protocols, AH and ESP). Effectively reducing the SAID space
>by 33 bits.

I wrote RFC 2401, so, of course it's not wrong :-).

RFC 2401 is one of 3 RFCs dealing with processing AH and ESP traffic. 
There is overlap among the RFCs and we try to maintain consistency 
among them. The text cited above does not REQUIRE a receiver to use 
all three data items to demux inbound IPsec traffic; it ALLOWS a 
receiver to use all of these data items. The demuxing mechanism 
details are at the discretion of the receiver, just as is the 
checking of sequence numbers. Elswehere the RFC alludes to that, 
noting that any structure associated with the SPI up to the receiver, 
while the transmitter must view the SPI as opaque. Does your proposal 
require that a receiver coordinate with a NAT device in constructing 
an SPI? If so, that arguably violates the SPI model embodied in 2401.

>This is being suggested only for performance-based reasons. I don't think
>the performance benefits are significant enough for us to change RFC 2401.
>TCAMs can handle large selectors. Selector size is not the most important
>problem that TCAMs are dealing with now. I think the resoning that TCAMs
>cannot handle large selector sizes is dated. We are only talking about
>adding 4 bytes of destination IP address, and a byte for protocol into the
>selector for the TCAM. That is just 5 bytes. The TCAMs are alredy having
>to deal with the increase in IP address from 4 bytes to 16 bytes, and
>there can be multiple of these IP addresses in the selector (for IPsec
>atleast 2). I think it is just a myth that the biggest problem with TCAMs
>is the selector size.

I don't recall arguing that the TCAM lookup on a larger amount of 
data was a gating factor in performance; just that it was a factor 
(e.g., a cost factor due to larger CAM size or a performnace hit in 
software). Nonetheless, we are not changing the requirements; we are 
clarifying what the requirements have always been, in reality, and 
better describing how many folks have implemented the demuxing 
process. What we are describing is within the bounds of what receiver 
have always been allowed to do, consistent with all the RFCs.

>Even in software, I don't think that there is any significant performance
>benefit. I think it's more of a burden (regardless of hardware or
>software) to make absolutely sure that the SPI we use is unique on the
>box, if we are going to require it to be unique. The SPIs are sent with
>each proposal, and we only endup using one of the proposals. We need to
>keep track of what SPIs were allocated to these proposals that are being
>negotiated. We can NOT just look at the SADB and pick a SPI that is not in
>the SADB. And, there needs to be some garbage collection to be done to
>scavange all the SPIs we burn up when we propose a bunch of proposals. The
>SPI space can get pretty fragmented once rekeys happen, and it just
>becomes a nightmare to have to pick a SPI that we are absolutely sure that
>it is unique.

We always require the SPI to be unique, relative to some context, 
period.  We're just arguing over the scope of that context. (there is 
the kernel of an old joke there, but I digress ...) The context you 
envision makes use of the destination address and protocol type at 
each receiver for additional demuxing. For a unicast traffic flow 
directed to an IPsec receiver, the destination address is generally 
constant, and thus there is no change in the effective SAID space if 
one uses this value for demuxing.  For a multicast receiver, the 
destination address is always needed, because the receiver does not 
select the SPI in this case.

We have only two protocols here, AH and ESP, and we are moving to a 
situation in which only ESP may be of interest.  So, at most, the 
effective SAID space might be doubled if one demuxed on protocol 
type, but in general, and in what is like to be the common case in 
the future, there is NO increase, since only ESP is being used.

This brief analysis suggests that your protests are a red herring. 
In the  common cases noted above, the effective SAID space is 
unchanged, irrespective of whether the destination address or 
protocol fields are used by a receiver, in addition to the SPI.

However, if one reduces by half the number of bits in the SPI that 
are available to the receiver, as I think you propose, that DOES have 
a very significant impact on the difficulty of ensuing uniqueness, 
since you are reducing the SAID space by a factor of about 65K!

One final comment: when we wrote 2401 we identified several options 
for IPsec deployment, but not the POP model, where IPsec is deployed 
at a POP serving many subscribers.  If one chooses to implement IPsec 
in this environment and if one associates multiple, distinct IP 
addresses with the implementations (representing each of the 
subscribers), then in that case the destination address would need to 
be used for SPI demuxing, and we will note that fact in the revised 
text.  I don't recall you mentioning this case in any of your 
correspondence, so I hope this case has not been the motivation for 
this prolonged discussion.

>It is much more easier to not have to change RFC 2401 and reduce the
>existing SAID space.

"much more easier?"

Steve