Hi Fred,
the main reason why we chose delta values over absolute values is
scalability: there may be a large number of IPsec SAs under any IKE SA.
It is not important to strictly synchronize the counters, what's
important is just to minimize packet loss. So the easiest way is to
increment *all* the SAs by a single delta value.
Regarding replay protection during the exchange: what you are mandating
here is to drop all incoming packets for 1 RTT, for all clients
connected to a cluster. This may be acceptable in some deployments, and
may be out of the question in others. So I suggest to clarify this
choice in the document, but to keep it as a local policy decision rather
than a MUST or SHOULD.
Thanks,
Yaron
On 11/12/2010 05:44 AM, Frederic Detienne wrote:
Hi Dacheng,
following our discussion, we kept evaluating the proposal we think it
is simpler to send the absolute values.
1) Delta computation
The whole computation would go as such:
Head-end sends (Rx.s, Tx.s) (s for "server") to the client.
Client computes Rx.delta = Tx.c - Rx.s (c for client)
Client computes Tx.delta = Rx.c - Tx.s
If Tx.delta> 0, the head-end needs to adjust its Tx.
If Rx,delta> 0, the head-end needs to adjust its Rx.
If the servers are already synchronized, there is a chance that
Rx.delta ==0 and Tx.delta == 0 (especially Tx).
The cases where Rx.delta< 0 and Tx.delta< 0 seem odd and probably
deserve some logging.
2) message format
Since the head-end sends absolute values, we think that the client
should also send absolute values for readability.
3) replay attack window
Also following our live discussion, we think that the draft should
recommend stopping all IPsec input handling as long as the IPsec sync
exchange is not complete. Otherwise, there is a small but very real
window of opportunity for replay.
We think this should be recommended as a "SHOULD" so to make it a
configuration option to the user or implementer.
Regards,
fred
On 10 Nov 2010, at 09:19, zhangdacheng 00133208 wrote:
> Hello everybody:
>
> During the discussion of the HA solution draft, we realized there
may be still some issues we have to carefully consider in the design
of the synchronization solution for IPsec replay counters.
>
> 1. whether a cluster member needs to send the delta increment of the
*outgoing* SAs or just unilaterally increments its counters.
> 2. How the user can calculate the the delta increment of its
*outgoing* SAs? To find out a proper delta increment value, the user
may have to know when the last synchronization between cluster
memebers was undertaken so so to reason how many packets it has sent
out using every SA. However, there is no such disucssion in the draft.
>
> So, what do you think of it?
>
> BR
>
> Dacheng
>
> On 11/09/2010 09:51 PM, Yoav Nir wrote:
>> I think so, but I also think that this deserves an issue.
>>
>> On Nov 9, 2010, at 6:42 PM, Yaron Sheffer wrote:
>>
>>> Hi Dacheng, Yoav,
>>>
>>> Now I'm confused myself. It seems to me that instead of sending the
>>> delta value of the outgoing replay counter, we should have sent the
>>> requested delta increment of the *incoming* SAs. The cluster doesn't
>>> need any signaling for its outgoing ESP traffic, it can just
>>> unilaterally increment its counters. What do you think?
>>>
>>> Thanks,
>>> Yaron
>>>
>>>
>>> On 11/09/2010 05:07 PM, zhangdacheng 00133208 wrote:
>>>> Hi, Yaron:
>>>>
>>>> I feel a little confused on a problem and hope to get your help. My
>> question is how a user know the deta of the outgoing counter value. I
>> can understand that a new active member know the time period between
>> the last synchorizaiton and the occurance of the failure so that it
>> can estimate how many packets the previous member has sent during the
>> period and how big a delta value shoudl be. However, a user does not
>> hav such knowledge. Howe can i
>>>> t find out how much the incoming counter of the cluster member
>> should increase?
>>>>
>>>> Cheers
>>>>
>>>> Dacheng
>>>
>>> Scanned by Check Point Total Security Gateway.
>>
>
>
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
