Re: [btns] Q: How to deal with connection latch breaks?
Michael Richardson <mcr@sandelman.ottawa.on.ca> Wed, 12 August 2009 20:40 UTC
Return-Path: <mcr@marajade.sandelman.ca>
X-Original-To: btns@core3.amsl.com
Delivered-To: btns@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5173A6EBE for <btns@core3.amsl.com>; Wed, 12 Aug 2009 13:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.937
X-Spam-Level:
X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6]
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 ofd-OoCL48Kp for <btns@core3.amsl.com>; Wed, 12 Aug 2009 13:40:40 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 43AE13A6EB3 for <btns@ietf.org>; Wed, 12 Aug 2009 13:40:39 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 188B834949 for <btns@ietf.org>; Wed, 12 Aug 2009 20:40:01 +0000 (UTC)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 162743EC5 for <btns@ietf.org>; Wed, 12 Aug 2009 16:39:58 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: "btns@ietf.org" <btns@ietf.org>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C22ACD505@NALASEXMB04.na.qualcomm.com>
References: <5D4C4002AC7C3340987C37B1E4B66A54029A9076@SACMVEXC2-PRD.hq.netapp.com> <20090806215107.GB10982@Sun.COM> <20090807061512.GG1035@Sun.COM> <9561.1249662976@marajade.sandelman.ca> <20090812180608.GF10982@Sun.COM> <BF345F63074F8040B58C00A186FCA57F1C22ACD505@NALASEXMB04.na.qualcomm.com>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Aug 2009 16:39:58 -0400
Message-ID: <10677.1250109598@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
Subject: Re: [btns] Q: How to deal with connection latch breaks?
X-BeenThere: btns@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <btns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/btns>
List-Post: <mailto:btns@ietf.org>
List-Help: <mailto:btns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2009 20:40:41 -0000
>>>>> "Julien" == Julien Laganier <Laganier> writes: Julien> Not sure I caught all the details of the discussion, but Julien> just to make sure I understand correctly: If a peer Julien> restarts, DPD will eventually detect it, and then the peers Julien> can proceed with re-establishing IKE and CHILD SAs. In the Julien> BTNS case where the BTNS IKE SA gets re-established after Julien> DPD, each of the BTNS peers can verify that they're talking Julien> to the same peer right? yes. The channel-binding information that would be maintained by at least one of the peers (even if the application does not ask for it), would indicate if it was the same peer. Julien> Thus I think the latches shouldn't Julien> be broken automatically when DPD concludes a peer is Julien> dead. They should only be broken in case it's not possible Julien> to re-establish a BTNS IKE SA after DPD, or a BTNS IKE SA Julien> can be established but to a different peer. 1) "not possible to re-establish a BTNS IKE SA after DPD" this may be hard to define. 2) "BTNS IKE SA can be established but to a different peer." this is easy to define, and we are all in agreement about this. (And why treating it like a TCP RST may be appropriate) For (1) the best we can do is to let the ULP timeout, I think. -- ] Y'avait une poule de jammé dans l'muffler!!!!!!!!! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] h("Just another Debian GNU/Linux using, kernel hacking, ruby guy"); [
- [btns] Q: How to deal with connection latch break… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Julien Laganier
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams