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

Re: Notify SPI field specifications



  If you're sending it then it is the one from your "SPI space", the one
you came up with, your inbound SPI. These sorts of RFC2407/8/9 discrepancies
are just the sort of thing that will be cleaned up by combining all the
documents into one. If you're receiving it then it is the one from your
peer's "SPI space", the one he came up with, your outbound SPI.

  The thing about "the content of the SPI field MUST be ignored" is from
RFC2408 not RFC2407 and that was the mandated covert channel that we
all wanted to change but couldn't because the documents were in last call
for a year and then we were prohibited from changing them because they
were so confusing.

  Dan.

"I personally think it is very dangerous to organize
 referendums when you're not sure to win them"
   -- Louis Michel, President of the European Union

On Mon, 27 Aug 2001 17:14:15 CDT you wrote
> Since I cannot find the clear answer to Jari's question from ipsec mail
> list archives, and we got the same problem with several other vendors in
> Finland bakeoff, I'd like ask the same question again:
> 
> Which SPI, notification sender's inbound SPI or outbound SPI, should be
> put in
> RESPONDER-LIFETIME notify's SPI field ?
> 
> Thanks
> Jianhua
> 
> On Thu, Jan 27, 2000 at 03:42:02PM +0200, jari.arkko@ericsson.com wrote:
> > 
> > Hi. In the San Diego bakeoff I was studying the RFCs with somebody
> > and we noticed some strange descriptions for the Notify SPI field.
> > Here's what RFC 2408 says in section "3.14 Notification Payload":
> > 
> > >    o  SPI (variable length) - Security Parameter Index.  The receiving
> > >       entity's SPI. The use of the SPI field is described in section
> > 
> > And RFC 2407 says in section "4.6.3.1 RESPONDER-LIFETIME":
> > 
> > >     o  SPI - set to the two ISAKMP cookies or to the sender's inbound
> > >        IPSEC SP
> > 
> > I find the latter description quite clear. But the one in RFC 2408
> > is quite unclear and possibly even contradictory to it. In the RFC 2408
> > description, what is "receiving entity"? Is it the one receiving the
> > notification? If so, then which SPI does it have? The incoming? If so,
> > the RFC 2408 proposes the use of Notification-Receivers-Inbound-SPI
> > i.e. Notification-Senders-Outbound-SPI which is not the same as
> > Notification-Senders-Inbound-SPI in RFC 2407...
> > 
> > Even if I'm to ignore the SPI value for phase 1, the specifications
> > also disagree, I think, upon the value that should be put to the SPI
> > field for phase 1. Again from the same sections in these two RFCs:
> > 
> > RFC 2408:
> > >  The Protocol Identifier, in this case, is
> > >  ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
> > >  Header identifies the ISAKMP SA.
> > 
> > RFC 2407:
> > >     o  SPI - set to the two ISAKMP cookies or to the sender's inbound
> > >        IPSEC SPI
> > 
> > That is, RFC 2408 proposes zero and RFC 2407 the cookies.
> > 
> > Also, I found it quite funny for RFC 2407 to say in the description of
> > the SPI Size field that "If the SPI Size is non-zero, the content of
> > the SPI field MUST be ignored.". If the SPI Size is zero, I am expected
> > to check the SPI field! If I understood this right, the specification
> > should have said perhaps "The SPI Size and SPI fields MUST be ignored
> > for phase 1."
> > 
> > Jari Arkko
> > Ericsson
> > 
> >


References: