RE: NAT Traversal

["Chinna N.R. Pellacuru" <pcn@cisco.com>]

On Wed, 6 Mar 2002, Stephen Kent wrote:

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

Hi Steve,

If you follow the discussion more, I think it is not fair to blame only me
for quoting text from RFC 2401. I had to resort to quoting text from RFC
2401 because other people were trying to quote other text from RFC 2401 to
support their position. I agree, it was a waste of time, because you plan
to update it anyway.

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

I think I was a bit confused by the discussion about performance and
internal indexing of the SAD, which seems not very relevant to the
question of how a receiver can demux. I am in complete agreement to your
above statement.

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

IMHO, a NAT device is not an IPsec device, and the NAT device is not a
receiver of the SPI. The NAT device is only trying to translate ESP
traffic by *looking* at the SPIs in both directions.

Our scheme suggests that the Quick Mode responder choose to pick a SPI
according to a known alogrithm so that the NAT device can use that extra
information to translate the ESP traffic. The transmitter will still view
the SPI as opaque. The Quick Mode responder chooses to pick its SPI by
using a hash function on the Quick Mode initiator SPI to derive half of
its SPI. This hash function is known to the NAT device, and the NAT device
uses that information to Pair the incoming and outgoing SPIs.

We do not require all IPsec implementations to do it. We only require
implementations that want to implement our proposal to do so all the time.
All IPsec implementations can do it too. We will not restrict any IPsec
implementation from doing it. The proposal only advices the various IPsec
peers to pick their SPIs in a particular way so that the intermediate NAT
devices can pair the SPIs. This extra information is in no way used by the
IPsec peers themselves. This extra information is only used by the NAT
device.

     chinna