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");  [