Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-00.txt

[Raj Singh <[e-mail]>]

Hi Pekka,

Thanks for your comments. Please find my reply inline.

Best Regards,
Raj



On Mon, Sep 6, 2010 at 11:13 AM, Pekka Riikonen <[e-mail]> wrote:

>
> From the draft:
>
>   There were some concerns about the current window sync process.  The
>   concern was to make IKEv2 window sync optional but we beleive IKEv2
>   window sync will be mandatory.
>
> The IKEv2 message id sync is definitely mandatory, but the IPSEC SA seqno
> sync IMHO isn't.  Although, none of this would be an issue if IKEv2 would
> allow initiator to move the window forward freely (that would be real
> "fix").
>
> The IPsec SA replay counter sync is required for these reasons:
1.  In cluster environment, IPsec SA reply counter will get get updated from
active to standby in
     periodic manner. Suppose, we sync IPsec reply counter for every 1,000
IPsec packets and
     last sync happened at 30,000. So, the next sync will happen 31,000.
     Now, say failover happened at 30, 500. So, standby member becomes
active, and it start
    using IPsec replay counter from 30, 000. It will be considered as Replay
Attack and SA has to be destroyed.
    This applies to both outbound and inbound replay counters.

   So, IPsec replay counter sync is required as it mitigate the these
attacks.

2. Another option is doing IPsec Rekey after failover. Now consider a
scenario where gateways has thousands of SA.
    and after failover, we are doing IPsec rekey for them. The gateway will
be so much loaded. If we follow IPsec replay counter
    sync mechanism, we can sync many IPsec SA with single sync message.

So, if replay attack and load on server is OK, this option is not required.

I'm not sure if any of the following should be mentioned in the draft:
>
> - Multiple failovers.  In a cluster with three or more nodes, it's
> possible that failovers happen in rapid succession.  The protocol and the
> implementation must be able to handle new failover even if they are still
> processing the old failover (for example doing the IPSEC SA seqno sync,
> which, if we leave it in, can take time).  I see no reason why the
> protocol wouldn't allow for this, but implementations must make sure they
> can handle it.
>
> Very interesting point! Opened a ticket for it.
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/196

- Simultaneous failover at both ends.  If failover happens at the same
> time in both ends, implementations must be able to handle situation where
> they receive SYNC_SA_COUNTER_INFO request before they receive response to
> their own request (they may receive the response only after
> retransmission).
>
> I don't think we have any solution for this and any solution is possible
(?). This basically means that both sides has lost the SA.
So we have to establish SA from scratch. This draft assumes, that both side
has the SA and their message windows has mis-matched.

> - Should there be way to negotiate support for IKE SA window sync but not
> for IPSEC SA sync?  Currently by sending SYNC_SA_COUNTER_INFO_SUPPORTED
> you agree to support both, which can mean you may receive the IPSEC SA
> syncs.
>
> This is very much possible and we can have flag for IPsec SA sync in
SYNC_SA_COUNTER_INFO_SUPPORTED notify payload.
If that flag can be TRUE if we support IPsec SA sync, else we support only
IKEv2 SA sync.
More discussion on this will be interesting.

> There's also still bunch of typos in the draft.
>
>        Pekka
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>