Re: [IPsec] Failure detection proposals
Scott C Moonen <smoonen@us.ibm.com> Thu, 05 August 2010 13:31 UTC
Return-Path: <smoonen@us.ibm.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713CB3A6B27; Thu, 5 Aug 2010 06:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.635
X-Spam-Level:
X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vks7j2vP5kmG; Thu, 5 Aug 2010 06:31:56 -0700 (PDT)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 83FFD3A6B2D; Thu, 5 Aug 2010 06:31:24 -0700 (PDT)
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o75DR1Rb024393; Thu, 5 Aug 2010 07:27:01 -0600
Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o75DVSMu068594; Thu, 5 Aug 2010 07:31:32 -0600
Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o75DVOIX000393; Thu, 5 Aug 2010 07:31:24 -0600
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o75DVOp6000375; Thu, 5 Aug 2010 07:31:24 -0600
In-Reply-To: <4C59D035.50108@gmail.com>
References: <p06240822c85a639e75c8@[10.20.30.158]> <4C59D035.50108@gmail.com>
X-KeepSent: 88DFF0A4:2592C261-85257776:0049DC49; type=4; name=$KeepSent
To: Yaron Sheffer <yaronf.ietf@gmail.com>
X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010
Message-ID: <OF88DFF0A4.2592C261-ON85257776.0049DC49-85257776.004A03BF@us.ibm.com>
From: Scott C Moonen <smoonen@us.ibm.com>
Date: Thu, 05 Aug 2010 09:28:26 -0400
X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 08/05/2010 07:31:23
MIME-Version: 1.0
Content-type: multipart/related; Boundary="0__=0ABBFDE5DFDA5AD98f9e8a93df938690918c0ABBFDE5DFDA5AD9"
Cc: IPsecme WG <ipsec@ietf.org>, ipsec-bounces@ietf.org
Subject: Re: [IPsec] Failure detection proposals
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2010 13:31:59 -0000
I think this is an important problem to solve and I'm willing to participate in discussion of the alternatives, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yaron Sheffer <yaronf.ietf@gmail.com> To: IPsecme WG <ipsec@ietf.org> Date: 08/04/2010 04:48 PM Subject: [IPsec] Failure detection proposals Sent by: ipsec-bounces@ietf.org 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-bounces@ietf.org [mailto:ipsec-bounces@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.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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
- [IPsec] NUDGE: Starting discussion of failure det… Paul Hoffman
- Re: [IPsec] NUDGE: Starting discussion of failure… Yoav Nir
- Re: [IPsec] NUDGE: Starting discussion of failure… Yaron Sheffer
- Re: [IPsec] NUDGE: Starting discussion of failure… Paul Hoffman
- [IPsec] Failure detection proposals Yaron Sheffer
- Re: [IPsec] Failure detection proposals Scott C Moonen
- Re: [IPsec] Failure detection proposals Yoav Nir
- Re: [IPsec] Failure detection proposals V Jyothi-B22245
- Re: [IPsec] Failure detection proposals Palanivelan A (apvelan)
- Re: [IPsec] Failure detection proposals Dacheng Zhang
- Re: [IPsec] Failure detection proposals David Wierbowski
- [IPsec] Failure detection proposals, stage 2 Yaron Sheffer
- Re: [IPsec] Failure detection proposals, stage 2 Scott C Moonen
- Re: [IPsec] Failure detection proposals, stage 2 Yoav Nir
- Re: [IPsec] Failure detection proposals, stage 2 Scott C Moonen
- Re: [IPsec] Failure detection proposals, stage 2 David Wierbowski
- Re: [IPsec] Failure detection proposals, stage 2 Palanivelan A (apvelan)
- Re: [IPsec] Failure detection proposals, stage 2 Dacheng Zhang
- Re: [IPsec] Failure detection proposals, stage 2 Paul Hoffman