Hi Pekka,
Regarding the race condition, I think instead of starting the message
Id's altogether with 1, we can have the devices sync up to the higher
value among the responses.
Cluster A Cluster B
request SYNC -->
<-- request SYNC
response (4,4) -->
<-- response (5,5)
Cluster A should update its values to 5,5 whereas Cluster B should not
update its values since its values are higher than the values at Cluster
A.
Which means Cluster B has correctly synced its message values to some
extent when compared with Cluster A.
In the next revision we shall explain this in the draft.
Regards,
kalyani
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Pekka Riikonen
Sent: Thursday, September 16, 2010 2:19 PM
To: Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] Moving forward with the HA solution draft
On Mon, 13 Sep 2010, Yaron Sheffer wrote:
: I propose that version -01 of the draft should resolve the following 3
issues
: (and if possible, no others):
:
: * Separate negotiation of synchronization of the IKE SA counters
vs.
: the IPsec SA counters. IPsec counter sync should work even when
: used with a "normal" IKE exchange (non-zero Message ID).
: * A scalable solution for the IPsec counter sync: send a delta
: value that applies to all (incoming) child SAs, instead of
sending
: one value per child SA.
: * The replay issue that Tero identified at the meeting.
:
I started implementing the draft yesterday and here are some of the
issues
that came up (in addition to the issues listed above):
- Error handling. The draft explains what to do if the nonce in the
response is wrong but it doesn't mention what to do if the entire
SYNC_SA_COUNTER_INFO payload is malformed (in request or response).
- The SYNC_SA_COUNTER_INFO payload defined in the draft is sent inside
Notify Payload, but the draft doesn't mention what to fill into the
Notify
Payload header. Are the fields zero or should it define the Protocol
ID,
for example? There's some redundancy between the Notify Payload and the
SYNC_SA_COUNTER_INFO payload (in the header).
- The draft could also give additional reason for sending
SYNC_SA_COUNTER_INFO request. For example, in a cluster setup with two
or
more online nodes that actively handle IKE and IPSEC SAs any load
balancing change that changes the ownwership of the IKE SA in the
cluster
could trigger the use of this protoocol. This protocol applies to also
non-failover cases when ownerships change (protocol may or may not be
needed depending on the cluster implementation).
- Race condition when both ends are clusters and failover happen at the
same time in both ends. In this case both ends may end up sending the
SYNC_SA_COUNTER_INFO request. Since both ends now cannot know the
window
reliably some solution for this should be defined in the protocol. One
way to do this to say that implementations MUST set their window to the
values of one and respond with that:
Cluster A Cluster B
request SYNC -->
<-- request SYNC
response (1,1) -->
<-- response (1,1)
If you receive SYNC_SA_COUNTER_INFO request while you're waiting for
response to your own request it means that the remote peer has had
failover too, and it cannot reliably return to you any valid values.
Neither can you, so only thing you can do is to return window with
values
one. (Actually implementation should check whether it has had failover
(or the IKE SA has changed ownership) when it receives the request, even
if it hasn't yet sent its own request, and in that case respond with the
value one and set its own window. Implementation must also be careful
not to cancel its own pending request.)
- Validation of SYNC_SA_COUNTER_INFO request. The draft could more
clearly define what is the proper way of validating that a packet with
message id 0 is actually a valid SYNC_SA_COUNTER_INFO request:
- Message id MUST be 0
- Exchange type MUST be INFORMATIONAL
- Packet MUST be encrypted
- IKE SA MUST be authenticated
- Packet MUST have Notify Payload
- The Notify type MUST be SYNC_SA_COUNTER_INFO
>From this it's clear that most implementations will have to do the
validation in multiple steps. One before decryption, one after
decryption
and perhaps one after decoding the Notify Payload.
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
