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

RE: NAT Traversal



On Sun, 3 Mar 2002, Jayant Shukla wrote:
> > -----Original Message-----
> > On Behalf Of Chinna N.R. Pellacuru
> >
> > For our solution we do not require to even discover NAT. The SPIs can
> be
> > generated as a pair in all cases because this is such a simple
> operation.
> > If there are any NATs enroute, they will use this property to
> de-multiplex
> > the IPsec traffic and do IPsec pass-through.
> >
>
> So, you are suggesting modifications to IKE, right?
>
> This is interesting! According to your earlier e-mail, IKE modification
> for "NAT discovery" is not acceptable, but now IKE modification for "NAT
> traversal" is acceptable?
>

SPI is an IPsec parameter as opposed to IKE. In almost all implementations
the SPI space is managed by the IPsec implementation (if we divide IPsec
into IPsec implementation and IKE).

When a responder receives a bunch of Phase2 proposals in Quick mode, it'll
pick one proposal, and for that proposal it generates the SPI(s) which are
a hash of the initiator's SPI(s). In general, IKE will have to request
SPIs from the IPsec implementation because SPI is an IPsec parameter.

We only propose to change the semantics of the SPI, IE., now incoming and
outgoing SPIs of an IPsec protocol (ESP or AH) can be paired. One of them
will be the hash of the other. Actually only half of one of them is a hash
of the other. The other half is still left free, to allow some flexibility
for implementations who want to do fancy things with SPI generation.

No other change is required in IPsec or IKE. NAT implementation will use
this extra intelligence to translate ESP traffic. NAT can place the IPsec
SPIs in its translation table and pair the SPIs which belong to an IPsec
flow and demultiplex the incoming traffic. NAT also does NOT change
anything in either IKE or IPsec. NAT does a passive IPsec pass-through.

Please let me know if you need more details.

    chinna