Subject: [Ipsec] IKEv2: invalid SPI in DELETE payload

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 15 Dec 2005 17:20:31 +0100

Hi
What is the preferred behaviour when a DELETE payload containig an
unknown IPSEC SPI is received in IKEv2?

Should be to send an empty DELETE payload response?

Thanks.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Dec 2005 12:13:34 +0200

> unknown IPSEC SPI is received in IKEv2?

This should not really happen in normal case, as IKEv2 keeps both ends
in sync, but it can happen in case the other end creates IPsec child
SA, and your response to that gets delayed, and before the other end
receives that packet, you decide to delete the newly created IPsec SA
(from your point of view it is ready, but for the other end it is
still half-created, and he does not know what SPI you are going to
use). 

> Should be to send an empty DELETE payload response?

Hmmm... I think you need to send error notify as a response. If you
simply ignore the notify then in the case I describe above both ends
end up in different state (i.e. other end thinks it has SA and other
end does not have that SA).

What error notify to use is another question then. Most logical would
be INVALID_SPI,but that is supposed to be used only when you receive
ESP or AH packets with invalid SPI. The problem with other notifies
like INVALID_SYNTAX is that the other end might consider that as fatal
error, and delete the IKE SA because of it.

I think we need a clarification text saying we can use INVALID_SPI in
that case too. 
-- 
[email-masked]

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 20 Dec 2005 10:09:15 +0100

> I think we need a clarification text saying we can use INVALID_SPI in

IMHO, if an INVALID_SPI is sent, it should has the SPI field filled,
because it is needed to know what SPI has been rejected. But draft
appears to doesn't allow this.

The draft says:

        <<   o  Protocol ID (1 octet) - If this notification concerns
              an existing SA, this field indicates the type of that SA.
              For IKE_SA notifications, this field MUST be one (1). For
              notifications concerning IPsec SAs this field MUST contain
              either (2) to indicate AH or (3) to indicate ESP. For
              notifications which do not relate to an existing SA, this
              field MUST be sent as zero and MUST be ignored on receipt.
              All other values for this field are reserved to IANA for
        future assignment.
        
           o  SPI Size (1 octet) - Length in octets of the SPI as
        defined by
              the IPsec protocol ID or zero if no SPI is applicable.
        For a
              notification concerning the IKE_SA, the SPI Size MUST be
        zero.
        
Since INVALID_SPI is sent becasue SPI is unknown, it doesn't concern any
existing SA and PROTOCOL_ID MUST be 0. If PROTOCOL_ID=0, then SPI_SIZE
MUST be 0 and SPI=NULL.

I'm still thinking that if the PAYLOAD_DEL in the response doesn't
contain the paired SPI implies peer doesn't delete that. IMHO no error
notify is needed here.

If Host A has some CHILD_SAs with the following SPIs:
                A1-A2
                B1-B2
                C1-C2
                D1-D2
but Host B has only the following ones:
                A2-A1
                B2-B1
                C2-C1

Then, if Host A wants delete all its CHILD_SAs
                
                Host A				Host B
                ------				-------
                DELETE A1,B1,C1,D1 ---------------->
                   <------------------- DELETE A2,B2,C2

but Host B only deletes A, B and C.

Host A should now, delete D1-D2 unilaterally.

Regards

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Dec 2005 14:44:42 +0200

> appears to doesn't allow this.

The draft says that the SPI is sent inside the notification data
field.

> contain the paired SPI implies peer doesn't delete that. IMHO no error

That does not work as the returned delete payload can be empty in case
of simultaneous deletes:

Initiator				Responder
=========				=========
SPI 1234<-				SPI ->456

Sends delete SPI 1234  -->	    <-- Sends delete SPI 456

Receives delete 456			Receives delete 1234
from other end, notices			from other end, notices
that there is already			that there is already
delete 1234 sent out			delete 456 sent out so 
so sends empty return			sends empty return ACK 
ACK back		-->	<--	back.

Receives empty ACK			Receives empty ACK

after that SPI par 1234 <-> 456 is deleted.

If the respoder has not yet seen the DELETE SPI 1234 then he does not
know whether initiator replied to his DELETE SPI 456 with empty ACK
because of invalid SPI error, or because initiator has already
initiated delete. In case if delete was already issued, then he will
delete the other part of SPI (1234) when receiving it, but he should
delete SPI 456 already now. If the SPI was unknown he needs to keep
456 and try again later (i.e. it might be that initiator has not yet
created the SPI 456 in his end). 

> but Host B has only the following ones:

How did we end up in this state? In IKEv2 we should not ever end up in
this state, and if either end detects this it should restart the IKE
SA from the beginning to fix up the situation, i.e. create new IKE
SA, create required IPsec SAs, and delete old IKE SA (and all IPsec
SAs). 
-- 
[email-masked]

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 20 Dec 2005 13:55:30 +0100

> The draft says that the SPI is sent inside the notification data

But this is only true when notification concern to an existing SA (in
this case concern to an inexisting SA and it is not applicable), it
isn't?

---

From: [email-masked]
Date: Tue, 20 Dec 2005 16:15:56 +0200

> this case concern to an inexisting SA and it is not applicable), it

If the notification concerns an existing SA, the SPI is sent 
in the "SPI" field of the Notify payload. In this case, it's sent 
in the "Notification Data" field of the Notify payload:

     INVALID_SPI                              11

         MAY be sent in an IKE INFORMATIONAL Exchange when a node
         receives an ESP or AH packet with an invalid SPI. The
         Notification Data contains the SPI of the invalid packet.
         [...]

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Dec 2005 16:18:27 +0200

> this case concern to an inexisting SA and it is not applicable), it

In case of the existing SA then the SPI is in the SPI field of the
notify payload. In case of unknown SPI it is in notification data
(i.e. in different field). 
-- 
[email-masked]

---

From: [email-masked]
Date: Tue, 20 Dec 2005 16:59:55 +0200

Tero Kivinen wrote:
> > What is the preferred behaviour when a DELETE payload containig
> > an unknown IPSEC SPI is received in IKEv2?
> 
> This should not really happen in normal case, as IKEv2 keeps both
> ends in sync, but it can happen in case the other end creates
> IPsec child SA, and your response to that gets delayed, and before
> the other end receives that packet, you decide to delete the newly
> created IPsec SA (from your point of view it is ready, but for the
> other end it is still half-created, and he does not know what SPI
> you are going to use).

One solution to this would be to prohibit the responder from
deleting SAs that are not fully created yet. But perhaps this is not
very nice either, since then we need some way to know for sure when
the SA is really ready.

> Hmmm... I think you need to send error notify as a response. If
> you simply ignore the notify then in the case I describe above
> both ends end up in different state (i.e. other end thinks it has
> SA and other end does not have that SA).

I agree, we won't want to end up in different states.

> What error notify to use is another question then. Most logical
> would be INVALID_SPI,but that is supposed to be used only when you
> receive ESP or AH packets with invalid SPI. The problem with other
> notifies like INVALID_SYNTAX is that the other end might consider
> that as fatal error, and delete the IKE SA because of it.
> 
> I think we need a clarification text saying we can use INVALID_SPI
> in that case too.

Hmm... what would be the expected behavior of a host receiving this
notification?  Presumably, it had a reason for requesting deletion
in the first place, and it might have already removed most of the
local state associated with the inbound half of the SA pair. Now it
gets a notification saying "the state isn't synchronized". Should
it just try sending the same Delete payload again (in a new 
Informational request) or what?

Best regards,
Pasi

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 20 Dec 2005 16:09:18 +0100

> (i.e. in different field).

It's true. I read too quickly this section :)

Thanks for your response
Regards

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Dec 2005 11:09:06 +0200

> very nice either, since then we need some way to know for sure when

The problem is that if responder's policy changes then he might want
to delete SA even when there has not been any traffic over that SA
(which would indicate that the other end managed to create the SA).

The case is like this:

Initiator				Responder
=========				=========
Starts create child
HDR(MessageID=22, Initiator),
    SK{SA(SPI=1234), Ni,
        TSi, TSr}	-->
					Replies to the create
					child, and installs SA
			X	<--	HDR(MessageID=22, Reply),
					    SK{SA(SPI=456), Nr,
					        TSi, TSr}
			Packet
			is lost
			or delayed

					Responder gets policy
					change which makes created SA
					against policy, so responder
					starts to delete SA
				<--	HDR(MessageID=44),
					    SK{D(SPI=456)}
Delete reaches initiator,
but initiator does not know
anything about SPI 456
as he has not yet seen the reply
to the create child exchange
from responder.
He should send error notify back
HDR(MessageID=44, Initiator, Reply),
    SK{N(INVALID_SPI(data=456))}
			-->
					Responder knows that delete
					didn't get through, so he
					keeps SPI 456 still but does
					not use it (he stopped using
					it when he originally created
					delete notifiation).

Initiator restransmits
create child as he has not
received reply to it
HDR(MessageID=22, Initiator),
    SK{SA(SPI=1234), Ni,
        TSi, TSr}	-->
					Responder retranmits his
					packet.
				<--	HDR(MessageID=22, Reply),
					    SK{SA(SPI=456), Nr,
					        TSi, TSr}
Initiator installs SA.

					Responder can later retry
					deleting the SPI 456.
				<--	HDR(MessageID=45),
					    SK{D(SPI=456)}
Now initiator knows the SPI
thus it deletes the SA and
replies to packet
HDR(MessageID=45, Initiator, Reply),
    SK{D(SPI=1234)}	-->

After that SA has been deleted in both ends and peers are again in
sync. 

> Informational request) or what?

It should keep the SA in half closed state (i.e. he will not use it,
but will still accept incoming data to the SA). Later he should retry
delete (say after few minutes) and if the problem persists it should
then start corrective actions (i.e. restart IKE SA, but it might want
to set up new IKE SA and replacement IPsec SAs before it deletes the
old IKE SA).
-- 
[email-masked]