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

Re: SPI orthogonality

> From: Ben Rogers <ben@Ascend.COM>
> Angelos D. Keromytis writes:
> > I believe this has not been answered (not "officially" anyway): are
> > the SPI-spaces for AH and ESP orthogonal or not ? Meaning: are the SAs
> > identified by tuples (SPI/Remote Address) or by (SPI/Remote
> > Address/Protocol), where Protocol = {AH, ESP} ?
>
> The last time I asked this question, it was as a result of
> inconsistencies between the IPsec and ISAKMP drafts.  The response was
> that the IPsec draft was in error (and would be modified).  SA's are
> indexed by SPI/Remote Address/Protocol triplets.
>
I agree.  We resolved this point several years ago, but the Kent drafts
are dense and unclear.  Needs paragraphs and formatting.

There are a few other semantic problems with the Kent draft.  The SPI
is not the same as a "SAID".  The SPI identifies the "parameters" for
the ESP "transform", not the Security Association itself.  (The Security
Association is identified by, for example, the Cookie pairs in Photuris
or Oakley).

I proposed the following change to the ESP SPI wording:

2.1.  Security Parameters Index (SPI)

   The SPI is a 32-bit (4 byte) unsigned value identifying the Security
   Association parameters for the ESP transform.  The value is relative
   to the IP Destination in the preceding IP Header of the datagram.

   The use of this value is orthogonal to usage of similar values by
   other related security protocols, such as the Authentication Header
   (AH).  That is, the same value MAY be used by multiple protocols to
   concurrently indicate different Security Association parameters.

   The value zero indicates that no Security Association has been estab-
   lished, and is primarily used for testing.

   Values in the range 1 through 255 are reserved to the Internet
   Assigned Numbers Authority (IANA) for future use.  A reserved SPI
   value will not normally be assigned by IANA unless the specification
   is openly available and documented in the RFC publication series.

   Values in the range 256 through 65535 are reserved for manual config-
   uration.

   Remaining values are utilized by automated Security Association man-
   agement.  These values are recommended to be generated by a crypto-
   graphically random method, to protect against replay attacks and
   traffic analysis.

   This field is mandatory and transparent.  That is, the field is
   always present, and the value is not concealed by encryption.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2