On Fri, 3 Dec 2010, Tero Kivinen wrote:
: Depends how we define failover counter. If we define so it is
: monotonously increasing counter which can skip forward there are ways
: to do it without syncing the information. As most of the sync
: protocols already have either timestamps or some kind of message ids
: using those as failover counter would work. I.e. in the simplest case
: just use last failover time as failover counter.
:
: There is no reason for failover counter to increment by one for every
: failover, its value just needs to be bigger than the previous failover
: counter so we can detect whether this is old failover message or
: whether it is something we haven't seen before.
:
That's a good point, but there's still the receiving end that has to
consistently be able to determine whether given failover counter is replay
or not. Let say, both ends are clusters, this means that the receiving
end has to somehow sync the information between its nodes. Otherwise its
nodes might not know which value is old and which isn't (for example due
to failover or load balancing). Unless, of course, this is somekind of
timestamp (an actual clock or something like that) that can be
consistently verified also at the receiving end without syncing.
On the other hand, I do say that this is better than what it is now in the
draft; even if the receiving end has to sync it and fails to do so
properly the protocol still works, it just opens a possibilty for a replay
attack.
: > 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.
:
: So the node 2 should first agree that it really is the one who is
: going to take care of the failing node 1 traffic, thus it needs to
: communiate with node 3 and agree on that (to prevent both node 2 and
: node 3 acting as failover hosts). During this communication it can
: also sync the failover counter.
:
Here it usually would be determined by the IKE SAs that were "owned" by
node 1 that are now owned by node 2. It's quite possible, by the way,
that both node 2 and node 3 can now "own" some of node 1's IKE SAs, and
have to perform the HA protocol for those independently. This would be a
cluster were all nodes are "online" and one of them fails. The case
described in the draft is a hot stanbdy cluster case where only one node
is online and others are standby until the online node fails. This would
imply that the standby node that becomes online after failover gets all of
the SAs of the failed node.
All this is implementation specific. Though, in my opinion the protocol
should be able to work in all scenarios, including in one were multiple
nodes independently perform HA protocol for their IKE SAs (a case not
described in the draft currently. This would change the original scope of
the draft from hot standby cluster case to include online cluster case
were load balancing change (failover, online/offline transition or other
artificial load balancing change) re-balances SAs among multiple online
nodes).
: I think the current text should be clear that failover counter can be
: incremented by any number, and message is accepted if failover counter
: is larger than any previous failover counter node has seen.
:
: This kind of text would allow using for example timestamp instead of
: failover counters, on those clusters where they do have good enough
: synced clocks.
:
I agree, but it needs to be carefully defined so that the receiver can
actually verify its validity in case it's a cluster.
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
