Tero Kivinen <[email protected]> wrote:
    >> > it can be used in load-sharing scenario when there are

    >> That would run into replay protection problems, just like if you copy
    >> all kernel IPsec state between machines. And I believe load sharing
    >> when properly done should be invisible to client side and not need
    >> special support.

    > Actually I tihnk the idea is to get rid of the replay protection
    > issues. In normal case if you just copy all IKE and IPsec state
    > between the servers, then you need to make sure you also copy all
    > replay data. If you clone the IKE SA, move the cloned IKE SA to new
    > IP-address (and new load sharing server in the cluster), and then
    > create the IPsec Child SAs there, then each of the replay data is only
    > located in the server you are talking to, and there is no need to move
    > replay data between the cluster members.

Given the the original document is about making multiple interfaces work,
in the degenerate case of a phone with 3G and wifi,  it seems to me that the
case where there are multiple gateways (probably with different ISPs) is just 
the degenerate case on speed/PCP.

All that is to say that it seems we should adopt this document, if this
is really a use case we care about.

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

    > Private keys do not need to be transmitted, only the SKEYSEED and
    > material generated from there needs to be transmitted (i.e. the
    > computed shared state). Doing load-sharing without the client
    > knowledge, do require exactly same material to be transmitted, but in
    > addition to that all the replay protection related material needs to
    > be transmitted also. 
 
I left this here: I think that load balancers often *do* share private keys,
and I think this protocol could reduce this need.

-- 
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: pgp35ZicLxjz2.pgp
Description: PGP signature

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

Reply via email to