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

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 12 August 2009 18:17 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 5750D3A6A6C for <btns@core3.amsl.com>; Wed, 12 Aug 2009 11:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.801
X-Spam-Level:
X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[AWL=0.245, 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 5+tuoNOeVCEA for <btns@core3.amsl.com>; Wed, 12 Aug 2009 11:17:11 -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 39A093A6AC5 for <btns@ietf.org>; Wed, 12 Aug 2009 11:17:11 -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 n7CIGmie024473 for <btns@ietf.org>; Wed, 12 Aug 2009 18:16:48 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 n7CIGl7v062276 for <btns@ietf.org>; Wed, 12 Aug 2009 12:16:47 -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 n7CI69d5013091; Wed, 12 Aug 2009 13:06:09 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CI6881013090; Wed, 12 Aug 2009 13:06: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 13:06:08 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Message-ID: <20090812180608.GF10982@Sun.COM>
References: <5D4C4002AC7C3340987C37B1E4B66A54029A9076@SACMVEXC2-PRD.hq.netapp.com> <20090806215107.GB10982@Sun.COM> <20090807061512.GG1035@Sun.COM> <9561.1249662976@marajade.sandelman.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9561.1249662976@marajade.sandelman.ca>
User-Agent: Mutt/1.5.7i
Cc: 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 18:17:12 -0000

On Fri, Aug 07, 2009 at 12:36:16PM -0400, Michael Richardson wrote:
>     2) system W's SA with system C expires (or is deleted by
>        INITIAL-CONTACT), and system W sees that has a broken latch.

Just one clarification: "system W's SA with system C expires" does not
mean that "system W sees that has a broken latch".  That's because the
current I-D says that latch breaks occur only as a result of conflicts;
dead peer detection does not cause latch breaks.

It might be useful to say that dead peer detection does cause latch
breaks now that we have chosen to reset faster, so to speak.  But I
wouldn't want to have to specify any specific timeouts, or, really, any
details of dead peer detection -- those would take time to work out.
Fortunately we could leave those details to IKEv2 and just add that "if
IKEv2 DPD concludes a given peer is dead then all latches with that peer
SHOULD be transitioned to the BROKEN state".

Possible wrinkle:

 - Is it possible for an off-path attacker to DoS IKEv2 between two
   peers?  If so then we must not allow DPD to cause latch breaks!

   DNS poisoning is not an issue here, but ICMP redirects and ARP
   spoofing are.  If you can spoof ARP you're on link, so that's not an
   issue.  And ICMP redirects should be getting ignored.  Any other ways
   to trigger IKEv2 DPD via an off-path attack?

My preference: leave the text as-is on this; don't allow DPD to break
latches, or perhaps allow it as a MAY, but not a SHOULD, much less a
MUST.

Rationale:

 a) there's a fairly strong distinction between "dead peer" and
    "SA/policy conflict", with the latter being an absolutely necessary
    cause of latch breaks while the former is not;
 b) it's easy to show that to cause such an SA conflict one must be
    on-path (or be able to spoof routing protocol updates) and policies
    must permit the conflict to arise (e.g., BTNS is in use), whereas
    it's harder to show the same for IKEv2 DPD -- we'd have to spend
    some time working that out;
 c) ULP/app timeout timers will generally result in DPD at the
    ULP/app layer anyways;
 d) we can always add DPD->latch break rules later if we need them,
    or we could let it be a MAY now and later upgrade it to SHOULD or
    even MUST if it proves useful.

Nico
--