Subject: [IPsec] Issue #128: Can implementations not reply fully to Deletes?

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Dec 2009 10:55:35 -0800

Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction. There is one exception. If by chance both ends of a set of SAs independently decide to close them, each may send a delete payload and the two requests may cross in the network.

But, Section 4 (conformance requirements), says: Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply.

What should we do? Changing the conformance requirement is pretty serious, but not telling the other side that you understand the Delete is also serious.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Dec 2009 00:01:44 +0200

Section 1.4.1 also says:

"A node MAY refuse to accept incoming data on half-closed
   connections but MUST NOT unilaterally close them and reuse the SPIs."

So if your peer is only responding with empty INFORMATIONAL responses to your deletes, you're going to accumulate more and more stale inbound SAs.   One of these statements has to go.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Hoffman [[email-masked]]
Sent: Tuesday, December 15, 2009 20:55
To: IPsecme WG
Subject: [IPsec] Issue #128: Can implementations not reply fully to Deletes?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 16 Dec 2009 00:15:02 +0200

This seems to prove that no such "minimal implementations" exist, because they would leak memory like crazy. So we could simply say that INFORMATIONAL messages containing DELETE payloads are an exception to the "you may return an empty INFORMATIONAL" rule.

Thanks,
    Yaron

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Yoav Nir [[email-masked]]
Sent: Wednesday, December 16, 2009 12:01 AM
To: Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes?

Section 1.4.1 also says:

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Dec 2009 10:11:28 +0200

I would actually rather remove the "MUST NOT unilaterally close them" and replace it with "may unilaterally close them".

But wait, there's something weird here.

>From the PoV of any implementation, the SA pair is one inbound SA and one outbound SA. When you send a DELETE, you send it for the INBOUND SA. So I was wrong - it's outbound SAs that you accumulate. If the peer does not close the other end, you are left with a half-closed SA - just an outbound SA.  Surely closing that is easy - you just don't use it any more, so you might as well delete it from your database - no leak on your end, and the minimal implementation should take care of itself.

So what's this text about "MAY refuse to accept incoming data"?  There is no incoming data unless your peer misunderstood your DELETE payload. An INVALID_SPI notification might set them straight.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Dec 2009 12:41:45 +0200

Paul Hoffman writes:
> Section 1.4.1 says: Normally, the reply in the INFORMATIONAL
> exchange will contain delete payloads for the paired SAs going in
> the other direction. There is one exception. If by chance both ends
> of a set of SAs independently decide to close them, each may send a
> delete payload and the two requests may cross in the network. 
> 
> But, Section 4 (conformance requirements), says: Every
> implementation MUST be capable of responding to an INFORMATIONAL
> exchange, but a minimal implementation MAY respond to any
> INFORMATIONAL message with an empty INFORMATIONAL reply. 

Support for deleting Child SAs is not required from minimal
implementations. If you have implementation which does only support
exactly one Child SA there is no point of deleting Child SAs
separately, as there can be only one, and as it does not support
CREATE_CHILD_SA exchanges, there is no way of creating new one.

The conformance requirement will say that minimal implementation
needs to send reply back to INFORMATIONAL exchange, but it can be
empty, and that will leave the Child SA in half-closed state (which is
allowed). Later when the SA is staying there for longer the other end
will most likely notice the situation and clear it by restarting the
IKE SAs (as explained in the 1.4.1).

> What should we do? Changing the conformance requirement is pretty
> serious, but not telling the other side that you understand the
> Delete is also serious. 

So I do not think we need to do anything as minimal implementation is
not required to understand delete notifications. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Dec 2009 12:54:39 +0200

Yoav Nir writes:
> So if your peer is only responding with empty INFORMATIONAL
> responses to your deletes, you're going to accumulate more and more
> stale inbound SAs.

In which case you follow the text in 1.4.1 which says:

   If connection state becomes sufficiently messed up, a node MAY close
   the IKE SA; doing so will implicitly close all SAs negotiated under
   it.  It can then rebuild the SAs it needs on a clean base under a new
   IKE SA.  The response to a request that deletes the IKE SA is an
   empty Informational response.

and that will fix the situation with minimal implementation. Also with
minimal implementation you cannot really get more and more stale
inbound SAs, as if implementation is so small it does not support
Delete notifications, it most likely doesnot support more than one
Child SA, i.e. it does not support CREATE_CHILD_SA (it will always
reply with NO_ADDITIONAL_SAS to that), thus at most you get one extra
SA. And as other end didn't understand the delete, it is not stale, as
it will be working half-closed SAs, it is outbound SA for you and if
you encrypt data and send it to the minimal implementation it will
still decrypt, and process that packet. It will might even send reply
back to your already closed inbound SA, but you will drop that as you
have already deleted that half. 

> One of these statements has to go.

Not really. Note, that I would expect all normal versions of the IPsec
to support both CREATE_CHILD_SA and delete notifications, but we are
talking now about the minimal requirements.

I.e. if you have your battery powered garage door opener, who knows
IKEv2 just enough to do IKE_SA_INIT (with exactly one set of crypto
algorithms), IKE_AUTH (with preshared key and with one set of crypto
algorithms and fixed traffic selectors). It only supports this exactly
one Child SA, which it uses to send message saying "Open or Close the
garage door" and after 30 seconds if no more buttons is pressed it
will shutdown.

As it does not support CREATE_CHILD_SA or INFORMATIONAL in any other
way than sending NO_ADDITIONAL_SAS or empty reply back, it does not
know how to process delete payloads at all. It even does not know how
to delete the IKE SA, but that does not matter as it automatically
goes away when it automatically turns itself off.

It expects that your home area network server which acted as responder
to its IPsec connection is smart enough to start DPD later and when
garage door opener does not reply it will also delete the IKE SA from
the server side.

This kind of minimal implementations are not meant to be used in
normal operations. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Dec 2009 13:04:14 +0200

Yoav Nir writes:
> I would actually rather remove the "MUST NOT unilaterally close
> them" and replace it with "may unilaterally close them".

You MAY close the IKE SA and that will take care of the SAs. You MUST
NOT unilaterally close them.

>From the PoV of any implementation, the SA pair is one inbound SA and
>one outbound SA. When you send a DELETE, you send it for the INBOUND
>SA. So I was wrong - it's outbound SAs that you accumulate. If the
>peer does not close the other end, you are left with a half-closed SA
>- just an outbound SA.  Surely closing that is easy - you just don't
>use it any more, so you might as well delete it from your database -
>no leak on your end, and the minimal implementation should take care
>of itself.

In your example case that is true, but note that this paragraph is not
restricted to inbound SAs.

The paragraph starts with "Half-close ESP or AH connections are
anomalous ..." which talks about Half-closed SAs in general.

This means you can also have half-closed outbound SAs, i.e. the one
where other end send delete notification, but for which you decided
not to send delete reply back. 

> So what's this text about "MAY refuse to accept incoming data"?

I.e. if you have received delete notification for your outbound SA,
but you decided not send out delete notification back for your inbound
SA (lets say there was some failure which meant you could not do it).
Then that means you can refuse incoming packets on that SA as it is
already in half-closed state. When your failure situation is resolved
(lets say your crypto hardware board got stuck, and you needed to wait
for your watchdog timer to reset it after 10 seconds), then you will
notice you have half-closed SAs, and you start clearing the situation
by either sending your end of the delete notification or by noticing
that things are really messed up, and deleting the whole IKE SA and
starting over.

> There is no incoming data unless your peer misunderstood your DELETE
> payload. An INVALID_SPI notification might set them straight.

Depends which party you are. For half-closed SAs the one end has
half-closed SA where they have only inbound SA and other party has
only the outbound SA.

I do not think there is any need to change any of those locations.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Thu, 17 Dec 2009 19:36:07 -0500

I'm not sure I'm going to buy that garage door opener if I have to wait for
dead peer detection before I can open or close it again :>).

Dave Wierbowski

  From:       Tero Kivinen <[email-masked]>                                                                 
                                                                                                            
  To:         Yoav Nir <[email-masked]>                                                                
                                                                                                            
  Cc:         IPsecme WG <[email-masked]>, Paul Hoffman <[email-masked]>                             
                                                                                                            
  Date:       12/16/2009 05:55 AM                                                                           

  Sent by:    [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Dec 2009 13:30:56 +0200

> dead peer detection before I can open or close it again :>).

You don't, if the device is already sleeping, and you press the
button again it wakes up, creates NEW IKE SA and the IPsec SA and
sends the packet forward.

The single Child SA is only for the opener itself, the server it is
connected is assumed to be bigger device which also is able to support
multiple Child SAs simultaneously and which can do complex things like
DPD etc (note that the minimal implementation can already reply to DPD
as that is just empty INFORMATIONAL exchange).

The garage door opener can also always put up the INITIAL_CONTACT
notification so if the server has not yet deleted the IKE SA by when
it connectes again it will delete it based on that notification.
-- 
[email-masked]