[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