Re: [IPsec] Failure detection proposals, stage 2

["Palanivelan A (apvelan)" <[e-mail]>]

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