Subject: [IPsec] two questions with the HA solution draft

From: zhangdacheng 00133208 <[email-masked]>
Date: Wed, 10 Nov 2010 09:19:00 +0800

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.
>

---

From: Frederic Detienne <[email-masked]>
Date: Fri, 12 Nov 2010 11:44:48 +0800

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:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 15 Nov 2010 10:06:48 +0200

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:
> 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
>
>
> > 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.
> >