Hi Nico, I thought about rekeying problem when the software lifetime expires. If two security gateway to initiate rekeying, what is the additional benefit brought to IKE?
We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Nico Williams Sent: Tuesday, April 05, 2011 4:23 PM To: Frank Bailey Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC 5996: IKEv2 - rekey question about 'equivalent' SA's On Tue, Apr 5, 2011 at 4:07 PM, Frank Bailey <frank.bai...@securecommconsulting.com> wrote: > I have a question about what is meant by 'equivalent' SA's wrt > to rekeying. If someone has already addressed this, my apologies > and please point to the thread I missed. - thx. > > In section 2.8 it talks about when rekeying a Child SA or an IKE SA, that > the peers should establish an 'equivalent' SA. The question I have, > is what is meant by equivalent? Does that mean there can only be > one proposal in the SA when rekeying? And, does that proposal have > to match the currently used algorithms for that SA (i.e. the new SA, > must match the SA (as far as transforms) to be rekeyed)? > > In section 2.18, 4th paragraph, it mentions that the 'old and new IKE SA > may have selected a different PRF. .' Which leads me to think that > we can re-negotiate the transforms during a rekey. My take is that "equivalent SA" means "the same type of SA (IKE or not) with the same traffic selectors and with transforms that are allowed by the policy (SPD)". Think of it this way: suppose you have an extant packet flow (e.g., an open TCP connection) with no traffic, SAs expire, later new outbound traffic triggers the creation of new SAs for that flow's traffic selectors -- if the new SAs meet local policy, then nothing stops their being installed in the SAD and taking effect to protect the packet flow. That is re-keying. If policy allows a range of transforms, then otherwise equivalent SAs remain equivalent even if their transforms differ as long as the transforms are all allowed by policy. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
