Re: [IPsec] Failure detection proposals, stage 2

[Dacheng Zhang <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
> 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<[e-mail]>
> > To: IPsecme WG<[e-mail]>
> > Date: 08/04/2010 04:48 PM
> > Subject: [IPsec] Failure detection proposals Sent by: 
> > [e-mail]
> >
> >
> >
> > 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: [e-mail] 
> [mailto:[e-mail]] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> >
> >
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec