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.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
