Subject: [IPsec] IKEv2 initial contact handling?

From: Kanaga Kannappan <[email-masked]>
Date: Tue, 9 Apr 2013 10:03:10 -0700 (PDT)

Hi All,

How to handle "Initial Contact Notification" during simultaneous IKEv2 SA negotiation?

For
 example: A pair of gateways are initiating IKEv2 negotiation almost at 
the same time resulting in 2 sets of IKEv2 SAs. In IKE_AUTH, both the 
boxes are sending "Initial Contact" notification and IKE_AUTH almost 
cross each other. On receiving the IC, if both try to delete the other 
IKE SAs on the box, we end up having different sets of IKE & child 
SAs on the both sides.

Thanks
Kanaga.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Apr 2013 15:00:14 -0400 (EDT)

On Tue, 9 Apr 2013, Kanaga Kannappan wrote:

> For example: A pair of gateways are initiating IKEv2 negotiation almost at the same time resulting in 2
> sets of IKEv2 SAs. In IKE_AUTH, both the boxes are sending "Initial Contact" notification and IKE_AUTH
> almost cross each other. On receiving the IC, if both try to delete the other IKE SAs on the box, we end
> up having different sets of IKE & child SAs on the both sides.

Initial contact is a bad feature all around. A responder should just
leave the old IPsec SA there to expire when its lifetime is reached.

Anything else causes issues. For example, with IKEv1 if you delete the
IPsec SA when you receive the payload, and then send back an IKE packet to
handle things like XAUTH authenticatin, there is a time when you have
no valid IPsec SA installed during a rekey, and thus tunnel downtime.
Especially if XAUTH requires a human punching in things from a token.

The only reason we (libreswan) implemented sending the payload (for IKEv1)
is that Cisco can refuse to replace an IPsec SA when it did not receive
Initial Contact, despite this new IKE having perfectly authenticated
without a problem. Libreswan fully ignores receiving an initial contact
payload. When it determines the peer ids match an existing IKE SA, it
will replace it, but again leave the IPsec SA to expire of old age, as
we cannot be sure when the other end switches from the old to the new
IPsec SA.

This all seems a remnant from configurations where the IDs are not
unique, commercially known as 'Group PSK' configurations, which were
always a bad idea as any member could pretend to be gateway and learn
all the remaining XAUTH credentials of all other users.

You should leave in the old IPsec SA despite the initial contact
payload. If your implementation allows you to keep track, you could
delete the old IPsec SA once you see traffic on the new IPsec SA.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Wed, 10 Apr 2013 05:11:49 +0000

On Apr 9, 2013, at 8:03 PM, Kanaga Kannappan <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

The simplest answer is not to handle it. It makes sense that peers will do a simultaneous negotiation for rekeying an IPsec SA. Most gateways do this proactively, but only in response to traffic. So if both are configured to expire SAs after 1 hour, but renegotiate after 55 minutes, then if there's a packet when the SA is 56 minutes old, it could trigger a simultaneous re-negotiation.

OTOH when initiating the first IKE SA, it's not likely to start from both sides at the same time. You could probably reproduce such a case in the lab. What you're supposed to do when presented with an Initial Contact, is delete all "other" IKE SAs.My code only erases established SAs (not things that are in the middle of the initial exchanges) so if they're simultaneous either both will be set up or only one based on the tie-breaker logic in RFC 5996.

But suppose your code is different. The worst case is that each side has deleted the IKE SA that it has initiated, and both gateways end up with one IKE SA each (different SAs). If your code has a recovery mechanism such as RFC 6290, that issue gets resolved quickly.

I don't think this edge case is something to worry about.

Yoav

---

From: Kanaga Kannappan <[email-masked]>
Date: Tue, 9 Apr 2013 22:16:05 -0700 (PDT)

Hi Paul,

Thanks for the response.

Yes, we can retain the IPsec SAs on responder to avoid blackholing.

But in IKEv2, IKE & IPsec SAs are tied together and, in this case we would have to create an exception, where IPsec SA would live without a parent IKE SA.

-kanaga.

________________________________
 From: Paul Wouters <[email-masked]>
To: Kanaga Kannappan <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Wednesday, April 10, 2013 12:30 AM
Subject: Re: [IPsec] IKEv2 initial contact handling?

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Apr 2013 16:11:47 +0300

Kanaga Kannappan writes:
> But in IKEv2, IKE & IPsec SAs are tied together and, in this case we
> would have to create an exception, where IPsec SA would live without
> a parent IKE SA. 

No.

First of all INITIAL_CONTACT is never sent rekeying so that is not a
problem. It is only sent when the end does not have any IKE or IPsec
SAs with the other end. Secondly, you are only supposed to delete IKE
SAs you have with the other end, i.e. not the ones you are middle of
negotiating with. Also as this notification is included in the
IKE_AUTH, it can only happen if the IKE_AUTH payloads really cross
each other on the wire.

As it might be possible that the first packets did cross on the wire,
but one of them got lost, and thats why it looks like the other peer
is sending INITIAL_CONTACT notification even after the first IKE SA
has already been created, you still need to take care of that
situation. I.e. the generic case you need to take care of is:

   Host A			    Host B
   ------			    ------
1) IKE_SA_INIT request -->	    <-- IKE_SA_INIT request
2) IKE_SA_INIT reply -->	    <-- IKE_SA_INIT reply
3) IKE_AUTH request -->		    (the IKE_AUTH of host B got lost)
4)				    Host B receives IKE_AUTH request,
 				    sends reply
5)				    <-- IKE_AUTH reply
6) Host A gets IKE_AUTH reply, finishes IKE SA
7)				    <-- IKE_AUTH request retransmission
8)  Host A gets IKE_AUTH request with INITIAL_CONCACT notification
9)  Host A replies to it
10) IKE_AUTH reply -->
11)				    Host B gets IKE_AUTH reply and
				    finishes 2nd IKE SA

Now the problem would be in the step 8, where the Host A has already
finished the IKE SA, and gets INITIAL_CONTACT notification from the
other end.

There are few ways to solve this, either it can check that as the IKE
SA it has was not ready at the point when this IKE SA negotiation
started, and detect that this is exchange collision. With this
exchange collision, it might simply continue normally and not to
delete the IKE SA it already has as this is exchange collision. After
this it has two IKE SAs and that is not a problem.

Other options the Host A could do is when it detects exchange
collision is to remove one of the IKE SAs, but in that case it needs
to send IKE SA delete to inform the other end that it has deleted it,
as this is not the case of leftover IKE SAs, but it is the case of
exchange collision. 

Other option is to simply not to delete "recently" created IKE SAs,
and simply assume all of those are collisions. What it could do for
those "recently" created IKE SA is to assume that they might be dead,
and it could start dead peer detection for them, or it can simply wait
for the normal dead peer detection to kick up when there is no traffic
from the other end.

The definition of recently could be something like last 30 seconds.

Note, that it should not be considered a problem to have multiple IKE
SAs between two peers. The INITIAL_CONTACT notification is not
supposed to be preventing that, it is supposed to clear out old unused
IKE SAs the other end might have. If both ends are configured to
automatically initiate connections immediately when the there is on
IKE SA (which can cause this setup), then it is best to configure SAs
so that they do not send INITIAL_CONTACT notifications. If the IKE SA
is kept alive all the time, then normal dead peer detection and other
methods will take care of the old SAs.

INITIAL_CONTACT was much more important in the IKEv1 world where there
was no reliable deletes, or other ways of knowing whether the other
end was alive or not. In IKEv2 there is less need for it, so leaving
it out does not cause that much problems. 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Apr 2013 09:48:31 -0400 (EDT)

On Thu, 11 Apr 2013, Tero Kivinen wrote:

> SAs with the other end.

But this can happen in various scenarios where your IKE's lifetime
passed but not the IPsec SA lifetime. Then you might have one or more
IPsec SA' open to the other end but without the corresponding IKE SA
you might not realise these SA's are to the same peer.

> IKE SAs the other end might have.

You mean unused IPsec SA's right? Because clearing out old IKE SA's is
easy - if the IDs match and you establish the IKE SA, loop through all
existing IKE SA's and if the credentials/IDs match (and this is not some
group PSK kind of setup) then delete the old IKE SA. Openswan/libreswan
never used initial contact to determine that.

> it out does not cause that much problems.

I really only see the need for initial contact to interop with Cisco,
who can refuse to replace an existing IKE SA without the latest incoming
IKE request carrying the INITIAL_CONTACT payload - at least for IKEv1.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Apr 2013 17:11:47 +0300

> you might not realise these SA's are to the same peer.

Not with IKEv2.

If the IKE SA lifetime is gone, then you REKEY the IKE SA. This cannot
cause INITIAL_CONTACT notifications. Also when IKE SA is expired, or
deleted all the IPsec SAs are also deleted automatically, so there is
also no problem for INITIAL_CONTACT. 

> You mean unused IPsec SA's right?

Both IKE and IPsec SAs. 

> Because clearing out old IKE SA's is easy - if the IDs match and you
> establish the IKE SA, loop through all existing IKE SA's and if the
> credentials/IDs match (and this is not some group PSK kind of setup)
> then delete the old IKE SA. Openswan/libreswan never used initial
> contact to determine that.

There is nothing in the RFC5996 that says you should do or need to do
that. Nothing there prevents peer to create multiple IKE SAs with same
ID payloads with the peer. In some cases it is even needed. For
example in some high availibitity environments the peer is using same
ID payload, but different IP addresses, and each node in cluster might
create separate IKE SA to the other peer and all of them have
identical ID.

You implementation will prevent that from working. 

> IKE request carrying the INITIAL_CONTACT payload - at least for IKEv1.

We are not talking IKEv1 here. IKEv1 has lots of problems with
reliability and state syncronization, so the issues with it are
completely different.

The subject was about INITIAL_CONTACT in IKEv2. 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Apr 2013 10:48:53 -0400 (EDT)

> also no problem for INITIAL_CONTACT.

Understood. I'll re-read the RFCs before implementing this for IKEv2.

> You implementation will prevent that from working.

We have an option to choose this behaviour, uniqueids=yes|no (default yes)

Paul

---

From: sandeep kampati <[email-masked]>
Date: Fri, 12 Apr 2013 15:20:06 +0530

In IKEv2 it MUST not send INITIAL_CONTACT notifications at time of
reauthentication

-Sandeep.kampati