Tero, > 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. > > 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. 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.) I am not suggesting we require the responder to re-create the SAs. But I don't think we should disallow it, Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen <kivi...@iki.fi> To: Scott C Moonen/Raleigh/i...@ibmus Cc: ipsec@ietf.org Date: 09/08/2010 08:19 AM Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00 Scott C Moonen writes: > > I think it would simplify the implementations and the protocol by just > > limiting that only responders can be token makers without loosing any > > of the functionality. > > I don't think we should limit this. First, rekeys can easily reverse the > sense of who is initiator. I was thinking about the original initiator, not the exchange initiator. > 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 talkin gabout traffic patters, 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. The initiator has all this information in its configuration as it already created the SAs in the first place earlier, so for it, it is enough to just start new IKE SA with INITIAL_CONTACT notification when it boots up. -- kivi...@iki.fi
<<inline: graycol.gif>>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
