Re: [btns] Q: How to deal with connection latch breaks?

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 12 August 2009 21:49 UTC

Return-Path: <Nicolas.Williams@sun.com>
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 3DE953A6C27 for <btns@core3.amsl.com>; Wed, 12 Aug 2009 14:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.83
X-Spam-Level:
X-Spam-Status: No, score=-5.83 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 1yh5ZJ8NawDM for <btns@core3.amsl.com>; Wed, 12 Aug 2009 14:49:43 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id B696A3A6D15 for <btns@ietf.org>; Wed, 12 Aug 2009 14:49:42 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7CLmnEr017331 for <btns@ietf.org>; Wed, 12 Aug 2009 21:48:49 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7CLmnRN002466 for <btns@ietf.org>; Wed, 12 Aug 2009 15:48:49 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7CLc8Gs013184; Wed, 12 Aug 2009 16:38:08 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CLc8DG013183; Wed, 12 Aug 2009 16:38:08 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 12 Aug 2009 16:38:08 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: "Laganier, Julien" <julienl@qualcomm.com>
Message-ID: <20090812213808.GL10982@Sun.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C22ACD505@NALASEXMB04.na.qualcomm.com>
User-Agent: Mutt/1.5.7i
Cc: "btns@ietf.org" <btns@ietf.org>
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 21:49:44 -0000

On Wed, Aug 12, 2009 at 01:06:32PM -0700, Laganier, Julien wrote:
> Not sure I caught all the details of the discussion, but just to make
> sure I understand correctly: If a peer restarts, DPD will eventually
> detect it, and then the peers can proceed with re-establishing IKE and
> CHILD SAs. In the BTNS case where the BTNS IKE SA gets re-established
> after DPD, each of the BTNS peers can verify that they're talking to
> the same peer right? Thus I think the latches shouldn't be broken
> automatically when DPD concludes a peer is dead. They should only be
> broken in case it's not possible to re-establish a BTNS IKE SA after
> DPD, or a BTNS IKE SA can be established but to a different peer.

If a peer has restarted then, yes, we could immediately transition the
affected latches to BROKEN (without a way to get back to ESTABLISHED).
That's presuming that peer restart -> all connections to it are reset.
But there's no need to do this since the lack of valid SAs will quickly
be discovered, new SAs will be negotiated, and then TCP RSTs / SCTP
ABORTs will follow (there's no equiv for UDP though, so breaking UDP
latches in the case of peer restart makes sense).  We need to be careful
to distinguish restart of IKE daemon processes from peer reboots.

DPD also looks for peers that are simply not there anymore.  That's a
heuristic mechanism (liveness check -> <crickets for more than N seconds>
-> dead peer).  I'm not sure that it would be appropriate to let IKE
heuristically decide that a peer is dead when the ULP and app can do
that themselves.  In fact, I'd say that would not be appropriate.

OK, so I've convinced myself: we need not say anything about DPD, though
we could add that when peer restarts (reboots) are detected then all
affected latches SHOULD transition to BROKEN.

Nico
--