Sure we are, but I didn't want to start the discussion, because QCD is my proposal.
Hopefully we've learned something from the history of XAuth vs Hybrid, and we won't end up with two non-interoperable, proprietary ways of doing this, neither of which makes it to RFC. I think that failure led to the rise of L2TP client and maybe even the SSL VPN client. On Jul 7, 2010, at 8:02 PM, Paul Hoffman wrote: > [[ 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/html/draft-ditienne-ikev2-recovery>), 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 > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
