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

"Laganier, Julien" <> Wed, 12 August 2009 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88DB33A6A93 for <>; Wed, 12 Aug 2009 13:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.784
X-Spam-Status: No, score=-103.784 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1ShfeS3s-tof for <>; Wed, 12 Aug 2009 13:07:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D3113A6837 for <>; Wed, 12 Aug 2009 13:07:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1250107676; x=1281643676; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20<> |To:=20Nicolas=20Williams=20<>, =0D=0A=20=20=20=20=20=20=20=20Michael=20Richardson=0D=0A =09<>|CC:=20""=20<>|Date:=20Wed,=2012=20Aug=202009=2013:06:32 =20-0700|Subject:=20RE:=20[btns]=20Q:=20How=20to=20deal =20with=20connection=20latch=20breaks?|Thread-Topic:=20[b tns]=20Q:=20How=20to=20deal=20with=20connection=20latch =20breaks?|Thread-Index:=20AcobeSau+oZl47GdSnalWBCXoDEZqA ABASvQ|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C2>|References:=20<5D4C4 002AC7C3340987C37B1E4B66A54029A9076@SACMVEXC2-PRD.hq.neta>=0D=0A=09<20090806215107.GB10982@Sun.COM>=20<20090 807061512.GG1035@Sun.COM>=0D=0A=09<9561.1249662976@maraja>=20<20090812180608.GF10982@Sun.COM> |In-Reply-To:=20<20090812180608.GF10982@Sun.COM> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5707"=3B=20a=3D"22030886"; bh=XsY+XyVZNdDO8Xrksa4s4CHsxtcG73MyqPtQ3FIGh4A=; b=Fz1PJeKeCFKZTQCTUglOrc2MUTYF80XEeEq0b3uNKL9/vaefYthSjwBt G4tcTJtOhQ1OySbr+TK0mgpnp3zS+jXPZwlC4GQ6MEtI9Bz5ee5e5AnFx CvL3Voyw0YRAMpsaIMBbdd2Xq9zjy4k31C9gXHMkJlti0dsU9zRSDD3do w=;
X-IronPort-AV: E=McAfee;i="5300,2777,5707"; a="22030886"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Aug 2009 13:06:49 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id n7CK6nEZ022520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2009 13:06:49 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id n7CK6Ukd024429 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Aug 2009 13:06:48 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 12 Aug 2009 13:06:35 -0700
Received: from ([]) by ([]) with mapi; Wed, 12 Aug 2009 13:06:35 -0700
From: "Laganier, Julien" <>
To: Nicolas Williams <>, Michael Richardson <>
Date: Wed, 12 Aug 2009 13:06:32 -0700
Thread-Topic: [btns] Q: How to deal with connection latch breaks?
Thread-Index: AcobeSau+oZl47GdSnalWBCXoDEZqAABASvQ
Message-ID: <>
References: <> <20090806215107.GB10982@Sun.COM> <20090807061512.GG1035@Sun.COM> <> <20090812180608.GF10982@Sun.COM>
In-Reply-To: <20090812180608.GF10982@Sun.COM>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [btns] Q: How to deal with connection latch breaks?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Aug 2009 20:07:53 -0000


Pls. see below.

Nicolas Williams wrote:
> 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
> 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.

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.