Pekka Riikonen writes: > - 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.
That was my main request during the last IETF. I think this protocol needs to be split to contain separate parts one for IKE SA and one for IPsec SAs. In many environments it is quite possible to keep the IKE SA state in sync between the cluster members, especially if the liveness checks are used correctly, i.e. only when needed, not every n seconds. I.e if IKE SA messages are only sent when Child SAs are created, rekeyed, or deleted, or when IKE SA is rekeyed, then syncing data between cluster members is anyways something you want to do as you want to move that new child SA state to other cluster member anyway and syncing the message ids in that case is very small part of the syncing you do. If you have 100,000 clients, and each have IPsec rekey interval of one hour, that means you do 27 IPsec rekeys per second. The rekeys usually dominate the IKE SA exchanges unless you use per flow Child SAs (I do not think people will be using such things on this kind of setup). If you add some liveness checks for completely silent connections, you end up around 50-100 message IDs you need to sync from one cluster member to another. Assuming you send IKE SPIs (16 bytes), window information (32 bits for window, 32 bits for left and right pointer, and 32 bits for next outgoing id) you send less than 100 bytes per IKE SA, thus meaning you need to send one 1000 byte sync information packet every 100 ms (i.e. ten times per second). That should not be overwhelming the cluster sync channel even when you are using state of the art 115200 bit/s serial connection.... If you have stupid implementation which will send liveness check packet for every single IKE SA (regardless whether there has been traffic or not in the IPsec SAs associated to them) every 10 seconds then you will be updating all 100,000 IKE SAs every 10 seconds. This means 10,000 updated IKE SAs per second, thus meaning 1 MB/s just for those sync messages. This will overwhelm your serial connection, but using trusted old 10 Mbit/s ethernet will be enough... (as you can see I am mostly assuming you do not need the IKE SA message id syncing at all, as syncing the peers for IKE SA message is completely feasible). Syncing the ESP sequence numbers for per packet is not feasible, thus there it might be useful to have some protocol support, especially if it is very important to protect against reply attacks. For outgoing packets you can simply jump over enough packets, but for incoming packets you cannot, and this means you might be taking in packets which you have already processed before the crash, and allow those go through. If protection against that is something you need in your environment, then having protocol for syncing up the ESP sequence numbers helps. Other option is simply to rekey the IPsec SA immediately and delete old IPsec SA, and that will reset the sequence numbers to "good" values. To protect against replayed old packets, you need to throw away all incoming ESP packets, altought you can still send packets out using "large enough" sequence numbers. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
