Re: SPI in Delete Payload of IKE / IKEv2

[Charlie_Kaufman@notesdev.ibm.com]

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).