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

Re: SPI in Delete Payload of IKE / IKEv2



Mr. Kaufman wrote:
  "I don't believe there is any advantage to being able to specify either SPI."
And I understand that for IKEv2.

So only remaining points which I'm concerned are,

   (1) Finally, does the expression in IKEv1, "the sending entity's SPI(s)",
        really mean the "Inbound SA" or not?
        If possible, I would like to get the comments from the editors, too.

        ==>>  I hope Mr. Maughan is checking this mail.   :-P
                  (Sorry that I send this mail to Mr. Maughan directly without
agreement.)

   (2) And does everyone agree with that?
         Some implementers may misunderstand the editor's meanings.

The (1) is about the editor's intention, and (2) is about a lot of real
products.

Maybe, I shouldn't discuss about the real products in this mailing list.
If I shoudn't, please kindly point it out.

Sincerely yours,
Atsuhiro Tsuji

> I believe the right thing to do at this point is to change the IKEv2 spec
> to match the IKEv1 behavior as deployed. The change was unintentional, and
> based on my misunderstanding of the arguably ambiguous text in IKEv1. In
> particular, to change:
>
> >the SPI [in the DELETE payload] is the SPI the sending
> >endpoint would place in outbound ESP or AH packets.
>
> to:
>
> >the SPI is the SPI the sending endpoint would expect
> >in inbound ESP or AH packets.
>
> does anyone object?
>
> "Yoav Nir" <ynir@checkpoint.com> wrote:
> > The Informational exchange with the delete payload has been used to
> correct
> > situations where you receive packets encrypted with an IPsec SA that you
> do
> > not recognize.  Suppose you get a packet with an SPI value you don't
> > recognize (for example, after you reboot) you can send a delete to the
> peer,
> > to make it stop sending.
>
> I would claim this is incorrect behavior in IKEv2. There is a NOTIFY error
> code "INVALID-SPI" specifically for this case. I would claim it was a
> protocol violation to close an SA that you don't know is open. The spec
> doesn't say what to do if it receives a request to close a nonexistent SPI.
> I can imagine anything from ignoring it to logging it to closing the
> IKE-SA. I don't believe the spec needs to say because it's not an
> interoperability issue.
>
> "Atsuhiro Tsuji" <tsuji.atsuhiro@jp.panasonic.com> wrote:
> > About the 1st point, let me summery the cases.
> >
> >   Case (a) :  Outbound IPsec SA for Delete Payload
> >
> >        That will mean:
> >             "I don't send anymore with this IPsec SA, so you don't have
> to
> >              maintain the corresponding Inbound IPsec SA."
> >        And all packets before the deletion of the peer Inbound IPsec SA
> >        can be received.
> >
> >   Case (b) :  Inbound IPsec SA for Delete Payload
> >
> >       That will mean:
> >            "I deleted this IPsec SA, so please don't send anymore with
> >             the corresponding Outbound IPsec SA."
> >       And some packets may drop since my deletion of Inbound SA
> >       to his deletion of Outbound SA.
>
> The current spec requires that the SAs in the two directions be opened and
> closed together, so I don't believe there is any advantage to being able to
> specify either SPI. If I send a notification to delete the pair, I promise
> not to send any additional packets on the outbound SA and once sent the
> sender is free to discard any subsequent packets arriving on the inbound
> SA. Because of packet reordering on the network, it is possible that
> packets will arrive on an SA after it is deleted. These packets should be
> discarded, though I don't believe any harm is done if an implementation
> accepts them late.
>
>           --Charlie
>
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or otherwise).