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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
