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

Re: Notify SPI field specifications

  RFC2408 is the generic language/transport. It does not define how to 
use things that are specific to a particular service like IPsec and, in
fact, says, "The DOI will also determine which SPIs (i.e.  initiator's
or responder's) are sent during communication." If the DOI field of the
notify message is 1 then RFC2407 dictates how to construct the message.

  Let me state again that it is just these sorts of things that will be
solved by having a single document to describe key management. The generic
language/transport (RFC2408) with a generic key exchange (RFC2409) on top
with a specific service (RFC2407) on top of that does not work. Things
that are required for the service have to be defined in the language or
key exchange. The commit bit is another example. The entire layering is
artificial and the source of this sort of confusion. That is being rectified.

  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 18:43:44 PDT you wrote
> 
> Is it the consensus?  In RFC2408 it says "The receiving entity's SPI" which
> implies the receiver's inbound SPI.  From my experience in bake-off, many
> vendors have implemented notify payload based on "receiver's inbound SPI".
> 
> --------------------------------------------
> Michael Shieh
> --------------------------------------------
> 
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Monday, August 27, 2001 5:51 PM
> To: jhfeng@austin.ibm.com
> Cc: ipsec@lists.tislabs.com; jari.arkko@ericsson.com
> Subject: 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
> > > 
> > >
Follow-Ups: References: