As other experts said, this is an interesting issue and worth us spending efforts on it. I would like to join this work.
> > In the Maastricht meeting there was just a tiny bit of > interest in the failure detection idea (reminder: the goal is > to ensure that one peer discovers that the other IKE peer has > restarted, within a short time duration, milliseconds instead > of minutes). But we didn't see enough interest to justify > having this as a WG item. So, one last time: if you think > this is a worthwhile idea, regardless of the proposals on the > table, please say so publicly. If you speak up, we will > expect you to contribute to the selection of the preferred document. > > If this is of no interest, fine. But if it is an important > problem to solve and we don't take it on, we could end up > with competing non-WG proposals. Which would be far from ideal. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of Paul Hoffman > Sent: Wednesday, July 07, 2010 8:03 PM > To: IPsecme WG > Subject: [IPsec] NUDGE: Starting discussion of failure > detection proposals > > [[ This topic generated a fair amount of discussion in the > past; are folks still interested? ]] > > Greetings again. The WG has one item on our charter that we > have barely discussed, namely failure detection. The charter > item says that the work item is: > > >- A standards-track IKEv2 extension that allows an IKE peer > to quickly and securely detect that its opposite peer, while > currently reachable, has lost its IKEv2/IPsec state. Changes > to how the peers recover from this situation are beyond the > scope of this work item, as is improving the detection of an > unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and > draft-detienne-ikev2-recovery-03 can be used as starting points. > > I gave a brief presentation on failure detection at the last > IETF meeting in Anaheim. The slides are at > <http://www.ietf.org/proceedings/77/slides/ipsecme-4.pdf>, > and the following is directly derived from them. > > The basic problem being covered by the new extension is: > - Alice and Bob have SAs up and ESP traffic is flowing, but > then Bob crashes > - Alice keeps sending ESP to Bob > - When Bob finally comes back up, he replies to Alice's ESP > with INVALID_SPI notifications > - Alice starts sending IKE liveness checks until she is > "sure" that the INVALID_SPI responses are not a DoS attack; > this could be "several minutes" > - Then Alice rekeys > > Some other problem cases include: > - Bob has two gateways in some failover architecture. One > gateway goes down, the other gateway detects this and wants > to tell Alice to rekey > - Bob has a bunch of gateways in some load-balancing or > cluster architecture. One gateway is taken down on purpose, > and the system wants to tell Alice to rekey > - Protocol robustness: Bob's gateway loses the SA without going down > > Our primary goal is that, as soon as Bob starts sending > INVALID_SPI responses to Alice's ESP traffic, Bob and Alice > should be able to quickly determine that this is not an > attack and therefore they probably want to rekey right away. > Note that if Bob and Alice are also using session resumption, > they can use that instead of rekeying; however, in the > discussion here, we always use "rekey" to mean "rekey or, if > appropriate, resume". The proposed extension does not include > the actual rekeying, just the context for them to do it now. > > The WG has seen two proposed solutions, QCD and SIR. The > following are brief summaries of the two proposals. > > In QCD (<http://tools.ietf.org/html/draft-nir-ike-qcd>), Bob > gives Alice a secret token in the AUTH exchange, and then > puts the token in his INVALID_SPI response as a way to say > "this SPI is gone". Bob must remember his tokens across > reboots, or derive tokens from a master token that he > memorizes across reboots, and Alice must remember the token > (or a hash of it) for each SA. > > In SIR > (<http://tools.ietf.org/id/draft-detienne-ikev2-recovery-03.tx > t>), Alice sends a new Check_SPI query with a stateless > cookie, essentially asking "do you really not know about this > SPI?"; Bob responds by saying "I'm sure I don't know that > SPI". Nothing is stored on either side, so a > man-in-the-middle can attack this to cause an unnecessary > rekey just as they can normal IKE. > > The first task for the WG is to decide which of these two > quite different approaches to take. After we have done that, > we can then hone the chosen proposal. During earlier > discussion of the proposals, the following criteria were > mentioned as ones that the WG should consider when thinking > about the approaches: > > - Support for different scenarios (load balancers, active clusters, > failover) > - Security from man-in-the-middle DoS attacks > - Resources used > - Intellectual property rights > > So: please start discussing the two proposals with respect to > these criteria or other criteria that are important to you. > In a few weeks (hopefully well before the Maastricht > meeting), I make a call for consensus and see where it leads us. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > 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
