Re: SPI in Delete Payload of IKE / IKEv2

["Atsuhiro Tsuji" <tsuji.atsuhiro@jp.panasonic.com>]

Dear, Mr. Kaufman,

Thank you for your pointing it out and giving comments.

Actually, I sent another mail and asked the difference between v1 and v2.

    Message-id: <001001c2e6a3$a5f8f810$cb06b684@isl.mei.co.jp>
    Date: Mon, 10 Mar 2003 10:23:25 +0900
    From: "Atsuhiro Tsuji" <tsuji.atsuhiro@jp.panasonic.com>
    To: "Yoav Nir" <ynir@CheckPoint.com>, ipsec@lists.tislabs.com
    Cc: "'Atsuhiro Tsuji'" <tsuji.atsuhiro@jp.panasonic.com>
    References: <000601c2e61a$326fef90$292e1dc2@YnirNew>
    Subject: Re: SPI in Delete Payload of IKE / IKEv2

And the points to be discussed are:

  1. If we don't change the payload format, which direction's IPsec SA
      should we sent for Delete Payload?
  2. Shouldn't we add the field which indicates the direction?

I understand the INFORMATIONAL Exchange of IKEv2 : Closing SA.
So the 2nd point may not be needed, but I dared to list it up.

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.

Which is the specification, and which is better?
And how is everyone implementing for IKEv1?



By the way,
I found a IPsec BOX which sends Delete Payload for both Inbound
and Outbound IPsec SAs.
One of the persons who are selling it said,
 "Our BOX manages SPI so that they are unique for both direction.
   So we can know which direction they are."
But if the opposite IKE isn't theirs, .....oops.

Sincerely yours,
Atsuhiro Tsuji

----- Original Message -----
From: <Charlie_Kaufman@notesdev.ibm.com>
To: "Atsuhiro Tsuji" <tsuji.atsuhiro@jp.panasonic.com>
Cc: <ipsec@lists.tislabs.com>; <owner-ipsec@lists.tislabs.com>; "'Atsuhiro
Tsuji'" <tsuji.atsuhiro@jp.panasonic.com>
Sent: Monday, March 10, 2003 11:24 AM
Subject: Re: SPI in Delete Payload of IKE / IKEv2


> Note: this exchange has uncovered an unintended difference between IKEv1
> and IKEv2. Question for the list: should I change IKEv2 to match (assuming
> it's true that IKEv1 works as described).
>
> "Yoav Nir" <ynir@checkpoint.com> wrote:
> > Hi,
> >
> > You send a Delete-SA to stop the peer from using that SA.  The IPsec SA
> is
> > outbound for the peer, but inbound for you.
> >
> > If A and B negotiate an IPsec SA, A sends ESP packets with SPI 17, and B
> > sends packets with SPI 49.  If A wants this traffic to stop, he sends B a
> > Delete payload with the SPI field 49.
> >
> > To stop transmissions on SPI 17, A needs not send out anything.  It is
> > enough that he stops using it.  It might have been nice to also be able
> to
> > tell peer B that no more traffic will come with SPI 17, so that peer B
> has
> > an easier time dropping fake packets, but this is not in the spec.
> >
> > Hope this helps.
> >
> > Yoav Nir
>
>
> "Atsuhiro Tsuji" <tsuji.atsuhiro@jp.panasonic.com> wrote:
> > Thank you for your telling me the spec. of Delete Payload.
> > I understand that is reasonable under the current spec.
> >
> > By the way, I wonder you don't mind that you tell me where the spec.
> > is written.
>
> For IKEv2 (draft-ietf-ipsec-ikev2-05.txt), the processing is described in
> Section 3.11: Delete Payload. It says:
>
> "Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but no
> SPIs. Deletion of a CHILD-SA, such as ESP or AH, will contain the
> Protocol-Id of that protocol (1 for ESP, 2 for AH) and the SPI is the SPI
> the sending endpoint would place in outbound ESP or AH packets."
>
> So in IKEv2, you identify the SA to delete by the SPI chosen by the other
> end. Apparently in IKEv1, it was identified by the SPI chosen by you.
>
> > On the other hand,
> > I think it is useful we can tell the deletion of the outbound SA to the
> peer,
> > and I wonder why don't we specify it...
> > Because "Simple is Best."?
> > Have anyone discussed this?
>
> For IKEv2, this is discussed in section 1.4 The INFORMATIONAL Exchange. The
> ESP SAs in the two directions MUST be closed together. When you get a
> request to close one side, you MUST close the other (unless it's already
> closed in an unlikely race condition where both ends decide to close the
> SAs simultaneously).
>
> I don't know how this was handled in IKEv1.
>
>           --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).