Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa

["Valery Smyslov" <[e-mail]>]

Hi Paul,

>> I think that the mechanism it describes is useful and could be used
>> as a building block for several solutions. For example,
>> it can be used in load-sharing scenario when there are
>> some gateways with different IP addresses, that share
>> the same credentials. If client established IKE SA with
>> any of them then the SA could be cloned and transfered
>> to other nodes of this cluster without reauthentication,
>> and the traffic from client then could be balanced
>> among those gateways.
>
> That would run into replay protection problems, just like if you copy
> all kernel IPsec state between machines.

Why? If I copy only IKE SA and then create IPsec SAs
on new gateway there will be no need to copy
kernel IPsec states and deal with replay protection.

> And I believe load sharing
> when properly done should be invisible to client side and not need
> special support.

I agree with you in general, but I don't think it is
always feasible in case of IPsec without some
cooperation with client (or you will really
need to share kernel IPsec state between
cluster nodes).

>>> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA 
>>> setup in cases where VPN gateways have multiple interfaces and want to 
>>> establish different SAs on the different interfaces without having to 
>>> repeat the IKE authentication. Instead, they could clone a single IKE SA 
>>> multiple times, and then move it to different interfaces using MOBIKE.
>>>
>>> If you agree with the need to standardize this usage, and believe that 
>>> draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place 
>>> for that standardization, and are willing to review and contribute text 
>>> to the document if it is adopted by the WG, please say so on the list.
>
> I am interested in the problem, but have bad feelings about throwing
> around IKE states from two peers to another peer, which this
> mechanism seems to leave open. For instance, I would much rather see
> some informational exchange method or create child sa method using the
> existing IKE SA for conveying this information and somehow creatie the
> additional new Child SA.

Isn't this similar to what resumption does?

> Throwing around private keys or computed shared secrets to multiple
> peers worry me.

It is often unavoidable in case of clusters.
And of course all due precautions need to be taken
in this case to minimize chances to leak information.

Valery.

> Paul