Hi, I think both solutions are very interesting. But after carefully consideration, I prefer to support QCD.
Firstly, compared to SIR, the QCD solution is simpler. It can use fewer packets to achieve the objective, because a peer can verify the token directly after receiving an INVALID_SPI packet. Secondly, in SIR, a peer has to wait for a certain period to ensure that it did not get a CHECK_SPI (NACK) packet from an attacker. This solution seems relatively ineffective and low efficient. (According to the draft, the period should be a least a few m-seconds. However, I don’t think it is long enough. It is just my humble opinion. --Dacheng > > Hi, > > I had a look at both the documents and here are my thoughts. > > I support QCD to be taken forward of the two. > > Both these documents have good thoughts in addressing the > issue, but also have gaps in terms of security. Both these > designs are prone to security attacks and going by the > proposed solutions, the QCD seems the better of the two. > > Some effort into Liveness detection mechanism , the method of > generating secured QCD token and managing the token in an > optimized manner are some of the items that can be worked on > from the QCD draft. I think, Fixing these items would lead > to a more secured and acceptable solution and I will be more > than happy to work with the team on these items. > > Thanks and Regards, > A.Palanivelan > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Yaron Sheffer > Sent: Tuesday, August 10, 2010 3:50 PM > To: IPsecme WG > Subject: [IPsec] Failure detection proposals, stage 2 > > OK, Paul and I are finally convinced that we have sufficient > WG interest > > in solving this problem. Now, I'd like to ask the people who > have responded (as well as others) to read the two drafts, > and to tell us why > > they prefer the one over the other. > > Quoting myself: "If you speak up, we will expect you to > contribute to the selection of the preferred document". > > Please respond with comments to the drafts and/or a > comparison within the next week, i.e. by August 17. > > Thanks, > Yaron > > > From: Yaron Sheffer<[email protected]> > > To: IPsecme WG<[email protected]> > > Date: 08/04/2010 04:48 PM > > Subject: [IPsec] Failure detection proposals Sent by: > > [email protected] > > > > > > > > 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: [email protected] > [mailto:[email protected]] 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.txt>), > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
