Scott C Moonen writes: > > I was thinking about the original initiator, not the exchange > > initiator. > > Ok, but this then imposes an awkward new requirement to remember the > "original original initiator," as it were. Today the initiator of the > rekey becomes the original initiator of the rekeyed IKE SA.
True, we need some other term for it. Something like the original IKE_SA_INIT initiator or the party initiating the initial connection (i.e. triggering). Or simply say that the QCD_TOKENs in INFORMATIONAL exchanges and rekeys can only be sent by the peer who originally sent them in the IKE_AUTH, and in IKE_AUTH limit the QCD_TOKEN to the responder. > > > Second, it is a stretch to assume that the underlying traffic > > > pattern is always such that at all times the initiator's side is the > > > one doing sending/retransmitting and can thus resurrect the SA. > > > > I am not talking about traffic patterns, I am talking about the ability > > to recreate the SA. The reason the SGW in normal case cannot simply > > recreate the IKE SA after the reboot is because it does not know who > > the other end was, i.e. it does not know their IP-addresses, > > identities, the traffic selectors etc used for that. > > But the responder side does have this information -- if the initiator > reboots, the responder still has the original SAs. Once it receives the N > (INVALID_IKE_SPI)+N(QCD_TOKEN) it can treat it essentially as a case where > it needs to reauthenticate the IKE SA rather than starting from some > hypothetical clean slate. Yes. But on the other hand the initiator also has this information in this case, as it originally initiated the connection by triggering the IKE SA to be created. So when next packet which will cause similar trigger comes, then the party who originally initiated the connection will trigger again, and recreate the IKE SA, and in that case it will also send INITIAL_CONTACT notification which will clean up the state from the SGW. In road warrior cases if the party who originally initated the connection (i.e. road warrior client) is rebooted, it already lost all other state too which means that the state that SGW has (TCP connections, IP number allocations etc) are not useful, and will be cleaned out anyways. The other way is not possible in common case. I.e. if the party who was responder to the initial connection is rebooted, it does not have enough information to recreate the IKE/Child SAs. It must somehow indicate this to the party who originally initiated the connection, so it can restart the IKE SA creation from the beginning. For this QCD_TOKENs are useful. > In the normal case the responder should be able > to negotiate new SAs. (I realize this may be problematic for some EAP and > some NAT traversal cases.) In road warrior case it not normally possible for the responder (road warrior server, sgw) to negotiate new SAs as it does not have configuration needed to create them. For example its policy is usually that from any IP, anybody who can identify itself with id that is in my database can connect and allocate IP-address from me and use that for tunneling all traffic from that IP-address to the internal network. Now if SGW is rebooted it does not know who was connected to it before the crash, thus it cannot recreate the state. Even if it gets some IP packets from the internal network directed to some road warrior client, it does not have information to tell how to recreate the connection. > I am not suggesting we require the responder to re-create the SAs. But I > don't think we should disallow it, If it has enough information, sure it can recreate the state, but in that case it does not even need QCD at all. I.e. if both parties have all the information they need to recreate the state (for example site to site VPN) then there is no need for QCD. Quite often the setup is so that the tunnels are brough up immediately when the peer is up again, thus immediately when the peer recovers from the crash it will recreate the IKE / Child SAs and by sending INITIAL_CONTACT notification it cleans up the state from the other end. Even if the peers are configured to create SAs only based on the packets, most likely if there was any traffic going through the tunnel then that traffic is two way, which means that the crashed party will get triggering packet very soon. Even if that is not true when the crashed peer gets unknown ESP packets from the source it knows based on its configuration (i.e. it is configured remote peer of IPsec tunnel), it can use that to trigger IKE SA exchange and use that IKE SA to send delete for that Child SA (our implementation already does this kind of operations). In general I do not think there is that much use for QCD in site to site VPNs, or the trying to detect crashed road warrior clients. I do think there is use case for them in detecting and recovering from the crashing road warrior servers. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
