Subject: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04

From: Tero Kivinen <[email-masked]>
Date: Sun, 25 Jul 2010 17:30:58 +0300

I have read the the draft now, altought my paper version was -03 (last
version from the ietf repository), but noticed before starting to read
it that there was this newer version in the hidden web-page (where you
can even download it if you find the fine print version saying
"original format" download link).

I have one big issue with the document which is very hard to fix, and
then two smaller attacks which may (and needs) to be fixed.

The big issue is that the draft does not provide solution to case
where the IKEv2 SA messages missed actually did something. It seems to
completely assume that all IKEv2 SA messages are DPD messages meaning
it does not matter if we processed them or not, and because of that
only syncs the message IDs and not what was done using those messages.

In sensible implementation DPD messages are NOT majority of the
messages. DPD messages is only sent when the traffic was changed to
one way or if there is some other reason to belive the other end is
not up and working anymore. If there is normal IPsec traffic flowing
through the any of the IPsec SAs tied to the IKE SA there is no reason
to send DPD ever. This means that in normal case rekeys, deletes and
create child requests are more frequent than DPD messages.

Because of not solving the problem this protocol can cause the IKEv2
peers to be out of sync from each other. I.e. other end might think he
has new IPsec SA he has successfully created with the other end, but
then other end looses that when the failorver happens, or peer might
have deleted some IPsec SAs only to find that they were not deleted,
or it might have rekeyed some IPsec SA but other end does not know
that etc.

The current draft does not explain anything how those cases should be
handled.

We had long discussion and text editing to get the IKEv2bis document
take care of the simultaneous exchange cases properly and if we want
to do the IKEv2 SA sync here we must add similar processing rules for
each of those case here too. This will make the protocol and the
processing rules much more complex. We also should make sure there is
some way to detect those cases, hopefully before the IPsec SA is used
for real traffic.

The IKEv2 protocol tries very hard to be reliable and make sure that
SA state cannot get out of sync between the two peers and adding
protocol extension which makes them out of sync very easily is not
really an option.

----------------------------------------------------------------------

The first smaller point is that the protocol as currently written
allows very easy way to replay SYNC_SA_COUNTER_INFO requests as there
is no protection for them (they have message ID 0 and the nonce only
protects the response not the request).

As the recipient of the SYNC_SA_COUNTER_INFO message actually does
some processing and updates its state (i.e. it marks missing messages
so they do not going to get reply anymore) this means this allows a
way to actively delete IKEv2 SAs requests.

I.e. when failover has once happened and the attacker has seen the
SYNC_SA_COUNTER_INFO message with message id 0 on the wire it will
store that for later attack use. Now whenever the attacker wants the
peer to forget one message he first deleted it on the wire, then waits
for next exchange to come and when it is processed he resends the
SYNC_SA_COUNTER_INFO which causes the other peer to ignore the fact
that it hasn't seen that message yet.

>From section 8:

   o  The peer should not wait for pending request also.  For example if
      window size is 5 and peer window is 3-7 and if peer has received
      requests 4,5,6,7 but not 3 then it should send the
      EXPECTED_RECV_REQ_MESSAGE_ID as 8 and should not wait for 3
      anymore.

----------------------------------------------------------------------

Second smaller point is that for IPsec SAs there is bit similar attack
but in this case the attacker will use the SYNC_SA_COUNTER_INFO
messages to reset the IPsec SA replay counters to the values they had
when failover happend. He can do this at will and then he can replay
anything that was sent after that. This should be quite easy to fix by
adding text saying that when "The peer will update its Inbound SA
Counters for each IPsec SA" it will do that only if the SA counters in
the message were smaller than what he had himself. This of course
means that the failover host needs to increment the counter by large
enough number or that the protocol is modified so that the peer will
tell his bigger numbers back.

----------------------------------------------------------------------

The document has huge number of typos, and misplaced punctuation
characters, repeated text etc, and I don't want to confuse those 3
bigger points by including them in this message.

For solving the big issue and the first smaller issue, I would think
the easiest way would be to remove the IKE SA message ID syncing
completely. The cluster can quite easily be made so that the IKE SA
message counters are updated every time when IKE SA message is sent,
as in most cases the IEK SA message update is needed to be sent to the
other cluster member anyways, as it affects the IPsec SAs (i.e.
created, deleted or rekeyed them). I.e. it does not require protocol
modifications, just smart and good implementations.

The IPsec SA replay counter problem is something that cannot be very
easily be kept completely in sync with cluster members as there is so
much more IPsec traffic than there is IKE SA traffic. Because of this
it might be better to modify the protocol to only solve that problem.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Sun, 25 Jul 2010 17:55:32 +0300

Thanks for the extensive review, Tero.

I haven't had time to read it through yet, but I would like to respond to one point in this  (below)

> only syncs the message IDs and not what was done using those messages.

I agree that the draft in its current form glosses over the fact that the missing IKE exchanges did something, like setting up a child SA, or tearing one down. I don't believe there is any way you can set up a cluster so that this never ever happens. You can make it rare, but not completely eliminate it.

When this does happen, we have two things we might prescribe. We can detect this and delete the IKE SA along with all associated child SAs, or we can try to recover. draft-kagarigi-ipsecme-ikev2-windowsync takes the latter way.

To get recovery actually working we need some more "stuff".  We need to accept this case of mis-matched states between peers, and work towards making them better matched, by allowing an implementation to inform its peer that the SA that is using is unknown - an obvious thing is to send an INVALID_SPI notify in an INFORMATIONAL exchange, or maybe add a DELETE_ALL_CHILDREN notification. The draft will need text that discusses how this actually converges in a matched IKE SA.

It should be noted (in the draft!) that this changes some assumptions about IKEv2 state. 

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Jul 2010 15:33:01 +0300

Yoav Nir writes:
> I agree that the draft in its current form glosses over the fact
> that the missing IKE exchanges did something, like setting up a
> child SA, or tearing one down. I don't believe there is any way you
> can set up a cluster so that this never ever happens. You can make
> it rare, but not completely eliminate it.

It does require bit more implementation effor to make them so that
they never happen (but that causes bit more traffic on the sync
channel as the active node needs to know whether standby received its
sync message before it can send IKEv2 message back).

On the other hand there is no reason to completely eliminate that,
making it rare is enough (i.e. assume that majority of the sync
channel traffic is going through and there is no need to get ack from
other end before continuing IKEv2 exchange).

> When this does happen, we have two things we might prescribe. We can
> detect this and delete the IKE SA along with all associated child
> SAs, or we can try to recover.
> draft-kagarigi-ipsecme-ikev2-windowsync takes the latter way.

draft-kagarigi-ipsecme-ikev2-windowsync does not try to recover, it
just skips over the problem. It could provide a way to detect this,
i.e. it peers could quickly check the message ids and check whether
they missed some IKEv2 messages and if so they could do something (for
example delete that IKEv2 SA directly just to clean up state quickly). 

> To get recovery actually working we need some more "stuff".

I think we need quite a lot of more stuff, if we really want to
recover fully for those lost messages. 

> We need to accept this case of mis-matched states between peers, and

I would rather not accept the mis-matched state. I would rather clean
up those messed up IKE SAs and recreate them to get the state matching
than trying to make protocol trying to recover from messed up state.

> work towards making them better matched, by allowing an
> implementation to inform its peer that the SA that is using is
> unknown - an obvious thing is to send an INVALID_SPI notify in an
> INFORMATIONAL exchange,

That is one option, but I think the draft needs to add text explaining
how to handle cases where:

1) Peer did IPsec SA delete, which active member answered, but
   which got undone when standby member took over.
2) Peer did IPsec SA Create Child SA, which active member answerd, but
   which got undone when standby member took over.
3) Peer did IPsec SA rekey, which active member answered, but which
   got undone when standby member took over.
4) Peer did IKEv2 SA rekey, which active member answered, but which
   got undone when standby member took over.

Then exactly same cases where the active member started those
negotiations and peer responded, but then change got undone when
standby member took over (there are cases where there is difference
depending who started operation, for example in the rekey case the
initiator is supposed to delete the old SA, so if the crashed active
member started that the standby member will not continue that
operation even when peer expects that to happen). 

> or maybe add a DELETE_ALL_CHILDREN
> notification.

That would be about the same than deleting the IKEv2 SA, except
deleting IKEv2 SA also takes care of other configuration data like
configuration payload information (virtual addresses etc). I would
suggest it would be better to just delete the whole IKEv2 SA than to
create another protocol extension to delete all IPsec SAs. 

> The draft will need text that discusses how this actually converges
> in a matched IKE SA.
> 

Yes.

I would except that going through all those cases and explaining what
will happen to them and how they are supposed to work takes several
pages (in IKEv2bis we have about 3.5 pages of similar text
(simultaneous rekeys and exchange collisions sections)).

As that is also going to require implementations I would really hope
if this IKEv2 SA window sync part is ever defined it will made
optional so it can be left out.
-- 
[email-masked]