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

RE: Manual SA SPI range



It depends on your implementation. If you maintain an internal database of
SPI (which are currently used)then the system can always check user defined
SPI against the database before accepting it. But then you run in to other
problems and solving it depends on how much complexity you want - reserving
SPI is one simple effective way.

  Abbas B

-----Original Message-----
From: Mason, David [mailto:David_Mason@nai.com]
Sent: Friday, January 19, 2001 5:24 PM
To: 'Bagasrawala, Abbas'; 'Henry Spencer'; Brian Swander
Cc: ipsec@lists.tislabs.com
Subject: RE: Manual SA SPI range


I'm not sure why one would need to reserve SPIs for manual keys.  The manual
keys would be loaded on system startup and IKE would therefore never use
them.  Of course, there is the case where you might want to add a manual SA
after system startup, but the chance that whatever SPI chosen is already in
use would quite small (and the IKE negotiated SA that is using it, could be
made to rekey upon load of the manual key, thereby freeing up that SPI).
-dave

-----Original Message-----
From: Bagasrawala, Abbas [mailto:abagasrawala@lucent.com]
Sent: Friday, January 19, 2001 4:28 PM
To: 'Henry Spencer'; Brian Swander
Cc: ipsec@lists.tislabs.com
Subject: RE: Manual SA SPI range


Lucent (Springtide) has reserved the SPI range from 256-4096 (non-inclusive
for no reasons) SPI value for manual SA's. Our SPI rekeying algorithm will
never generate SPI within that range.

Abbas Bagasra


-----Original Message-----
From: Henry Spencer [mailto:henry@spsystems.net]
Sent: Monday, January 15, 2001 11:33 PM
To: Brian Swander
Cc: ipsec@lists.tislabs.com
Subject: Re: Manual SA SPI range


On Mon, 15 Jan 2001, Brian Swander wrote:
  > Does anyone know if there is a hard specification in any of the RFCs
  > that nails down ranges for manual SA SPIs?

There isn't.  SPIs below 256 are reserved for special purposes (only one
of them is currently assigned:  0 is reserved for system internal use and
may never appear in a packet), but there is no explicit assignment for
manual keying. 

The Linux FreeS/WAN project has decided to reserve all three-digit hex
numbers, i.e. 0x100 through 0xfff, for manual keying (one-digit and
two-digit hex numbers being the special-purposes area), and its automatic
keying will never generate those.  At the moment, I don't know of anybody
else who has copied this. 

                                                            Henry Spencer
                                                         henry@spsystems.net