On Tue, 23 Nov 2010, Tero Kivinen wrote:
: > EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a
: > response to message 3 anymore.
:
: This opens new attacks, because now receiving sync message with
: message ID zero has also other effects than just syncing the max
: message ID for future use, it also causes existing exchanges to be
: destroyed.
:
: I.e. if host A and B have done sync earlier, meaning attacker has a
: copy of IKE SA Message ID sync message having message ID of zero, then
: attacker can wait for host B to start few exchanges and then reply the
: old sync message. If host A now immediately while processing the
: request destroys old existing exchanges then this allows attackers to
: delete exchanges at will.
:
: Nonce in the Message ID sync message will not help in this case, but
: the failover counter will help, as in that case the host A will reject
: the replay because of the reused failover counter.
:
: > Are the Security Considerations in the draft valid anymore at all? And
: > are the nonce and failover count needed? Yaron wanted to eliminate these,
: > and I'm all for it.
:
: I think we still need both. The failover counter protects against the
: attack I explained in this email (i.e. attacker replaying request),
: and nonce protects against the attacks where attacker tries to replay
: response message.
:
I'd like to return to this failover counter. It's the single issue in the
protocol which I don't like. The reasons are, first, that it makes an
assumption how clustering and sync has been implemented, that is this
value has to be synced in the cluster and the protocol cannot work without
it, and second, that the protocol itself becomes vulnerable to the very
issues it tries to combat, namely the fact that sync messages can be
dropped.
Consider for example three node cluster where node 1 fails. Node 2
increments the failover counter but fails to sync it to node 3 (the packet
is dropped or node 2 fails immediately itself). Node 3 now hasn't the
updated failover counter and will create a request that is effectively a
replay.
The draft has the following text:
In case multiple successive failover events and sync request getting
lost, the failover count value at peer will not be updated and new
standby member will become active with incremented failover count
value. So, peer can receive valid failover count value which is not
just incremented by 1 in case of multiple failover. Accepting
incremented failover count within a range is allowed and increases
interoperability.
Which is vague, and I don't even completely understand what it tries to
tell here. In case of multiple failovers the failover counter might *not*
be incremented at all because the sync may have been dropped.
I think the protocol should not have a feature that depends on the sync
itself working. That's the very issue it tries to fix in HA, the fact
that IKE SA message IDs in failover may be in desync. The failover
counter may be in desync as well. And if implementations are expected to
be lax about the value (due to the issues listed above) then it doesn't
really provide replay protection either.
I think we should try to find alternative methods to combat the replay of
requests. Here's some thoughts:
o Some kind of expiration timestamp to requests. Not sure how easy or
practical it would be to implement but would not require any sync
expectations.
o Request could always propose message_id + delta, so that if it is
replayed it's already too old and can be detected. This is something
that Yaron suggested as well, I believe. It does have some issues,
some of them already discussed earlier.
Some other way?
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
