Subject: SPI in Delete Payload of IKE / IKEv2

From: "Atsuhiro Tsuji" <[email-masked]>
Date: Thu, 6 Mar 2003 21:50:50 +0900

Hi, all,

I'd like to discuss about SPI value in the Delete Payload
of IKE / IKEv2.

It is the first time to send a question to the mailing list,
so if my behavior/expression is not appropriate,
please kindly point it out to me.

As you know, there is a field which contains SPIs in Delete Payload
of IKE / IKEv2. But I cannot find the direction of the SA.
So, I'm confused I have to delete the INBOUND SA or OUTBOUND SA,
especially for IPsec-SA.

Is there any rule for this?
I wonder we had better add a new field which indicates the direction.

If you've already discussed this issue, please tell me the pointer
for them.

I'm looking forward to your joining this discussion.

Thank you in advance.

-----
 Atsuhiro Tsuji [[email-masked]]

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 6 Mar 2003 15:55:42 +0200

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Atsuhiro Tsuji
Sent: Thursday, March 06, 2003 2:51 PM
To: [email-masked]
Subject: SPI in Delete Payload of IKE / IKEv2

Hi, all,

Thank you in advance.

-----

---

From: "Atsuhiro Tsuji" <[email-masked]>
Date: Fri, 7 Mar 2003 09:46:06 +0900

Hi, Mr. Nir,

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.

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?

Thank you and I hope you help me again.

Atsuhiro Tsuji

----- Original Message -----
From: "Yoav Nir" <[email-masked]>
To: "'Atsuhiro Tsuji'" <[email-masked]>;
<[email-masked]>
Sent: Thursday, March 06, 2003 10:55 PM
Subject: RE: SPI in Delete Payload of IKE / IKEv2

---

From: "Atsuhiro Tsuji" <[email-masked]>
Date: Fri, 7 Mar 2003 09:46:06 +0900

Hi, Mr. Nir,

On the other hand,

Atsuhiro Tsuji

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 9 Mar 2003 10:59:29 +0200

It is described in RFC 2408 section 3.15

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Atsuhiro Tsuji
Sent: Friday, March 07, 2003 2:46 AM
To: [email-masked]
Cc: 'Atsuhiro Tsuji'
Subject: Re: SPI in Delete Payload of IKE / IKEv2

Hi, Mr. Nir,

By the way, I wonder you don't mind that you tell me where the spec. is
written.

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?

Atsuhiro Tsuji

---

From: "Atsuhiro Tsuji" <[email-masked]>
Date: Mon, 10 Mar 2003 10:23:25 +0900

Dear, Mr. Nir,

Thank you for your reply.
While I was almost convinced of your explanation,
the draft of IKEv2 is making me confused...
# Sorry, It was the first time I read draft-ietf-ipsec-ikev2-05.txt.

Actually, RFC2408 section 3.15 describes as:
  "Deletion which is concerned with a Protocol SA,
   such as ESP or AH, will contain the Protocol-Id of that
   protocol (e.g.  ESP, AH) and the SPI is the sending entity's SPI(s)."
Do you mean "the sending entity's SPI(s)." expresses INBOUND SA'(s) SPI?

And during I'm reviewing the draft-ietf-ipsec-ikev2-05.txt section 3.11,
I found it describes as:
  "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.
It may describe the different specification from you...

What do you think?
Am I misunderstanding the draft of IKEv2?

Sincerely yours,
Atsuhiro Tsuji

----- Original Message -----
From: "Yoav Nir" <[email-masked]>
To: "'Atsuhiro Tsuji'" <[email-masked]>;
<[email-masked]>
Sent: Sunday, March 09, 2003 5:59 PM
Subject: RE: SPI in Delete Payload of IKE / IKEv2

---

From: [email-masked]
Date: Sun, 9 Mar 2003 21:24:29 -0500

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

> By the way, I wonder you don't mind that you tell me where the spec.

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.

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

---

From: "Atsuhiro Tsuji" <[email-masked]>
Date: Mon, 10 Mar 2003 14:00:49 +0900

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: <[email-masked]>
    Date: Mon, 10 Mar 2003 10:23:25 +0900
    From: "Atsuhiro Tsuji" <[email-masked]>
    To: "Yoav Nir" <[email-masked]>, [email-masked]
    Cc: "'Atsuhiro Tsuji'" <[email-masked]>
    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: <[email-masked]>
To: "Atsuhiro Tsuji" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "'Atsuhiro
Tsuji'" <[email-masked]>
Sent: Monday, March 10, 2003 11:24 AM
Subject: Re: SPI in Delete Payload of IKE / IKEv2

---

From: [email-masked]
Date: Mon, 10 Mar 2003 22:12:26 -0500

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" <[email-masked]> 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.

>       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

---

From: "Atsuhiro Tsuji" <[email-masked]>
Date: Tue, 11 Mar 2003 14:34:55 +0900

Sorry, Mr. Maughan's mail address seems to have been changed.

Please remove his old mail address when you send the reply to my last mail.

Thank you.

----- the Last Mail -----
From: "Atsuhiro Tsuji" <[email-masked]>
To: <[email-masked]>; "Atsuhiro Tsuji"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 11, 2003 2:22 PM
Message-id: <[email-masked]>
Subject: Re: SPI in Delete Payload of IKE / IKEv2

---

From: "Atsuhiro Tsuji" <[email-masked]>
Date: Tue, 11 Mar 2003 14:22:10 +0900

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Mar 2003 10:30:21 +0100

In your previous mail you wrote:

   ...

=> which INVALID-SPI: there are two defined in the current document (:-)?

Regards

[email-masked]

---

From: [email-masked]
Date: Tue, 11 Mar 2003 20:43:05 -0500

> => which INVALID-SPI: there are two defined in the current document (:-)?

How embarrassing. There are currently two different errors with the same
name. I picked up the error codes from ISAKMP, where code 4 was
INVALID-COOKIE and code 11 was INVALID-SPI. But when I switched terminology
to refer to the IKE connection identifiers are SPIs instead of cookies, I
renamed error code 4 and created the duplicate.

Fixed.

      --Charlie