RE: NAT Traversal

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

A correction below:

On Thu, 7 Mar 2002, Chinna N.R. Pellacuru wrote:

> 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
^^^^^^^^^^
transmitter      (not the receiver)

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

chinna narasimha reddy pellacuru
s/w engineer