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

RE: NAT Traversal




Hi,
  I am not sure whether you can restrict the responder to choose
  its own SPI. Lot of implementations take advantage of SPI
  for faster lookups. This is possible if the IPSEC implementation
  is given chance to choose its own SPI without any limitation.
  There are some implementations which use all bits of SPI value
  for different functionalities within the device.

Regards
Srini

  

On Mon, 4 Mar 2002, Chinna N.R. Pellacuru wrote:

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

-- 
Srinivasa Rao Addepalli
Intoto Inc.
3160, De La Cruz Blvd #100
Santa Clara, CA
USA
Ph: 408-844-0480 x317