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

"Laganier, Julien" <julienl@qualcomm.com> Tue, 11 August 2009 18:11 UTC

Return-Path: <julienl@qualcomm.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 5C28B3A68A4 for <btns@core3.amsl.com>; Tue, 11 Aug 2009 11:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.741
X-Spam-Level:
X-Spam-Status: No, score=-105.741 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 91gzUk25k2Kn for <btns@core3.amsl.com>; Tue, 11 Aug 2009 11:11:34 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 0B8513A6BD7 for <btns@ietf.org>; Tue, 11 Aug 2009 11:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1250014298; x=1281550298; 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<julienl@qualcomm.com> |To:=20Nicolas=20Williams=20<Nicolas.Williams@sun.com>, =0D=0A=20=20=20=20=20=20=20=20"btns@ietf.org"=0D=0A=09<bt ns@ietf.org>|CC:=20"Eisler,=20Michael"=20<Michael.Eisler@ netapp.com>|Date:=20Tue,=2011=20Aug=202009=2011:09:41=20- 0700|Subject:=20RE:=20[btns]=20Q:=20How=20to=20deal=20wit h=20connection=20latch=20breaks?|Thread-Topic:=20[btns] =20Q:=20How=20to=20deal=20with=20connection=20latch=20bre aks?|Thread-Index:=20AcoXJ+3sI5I4DEVeQfStzQW7aQmF/wDhqGxw |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C22ACD3D 7@NALASEXMB04.na.qualcomm.com>|References:=20<5D4C4002AC7 C3340987C37B1E4B66A54029A9076@SACMVEXC2-PRD.hq.netapp.com >=0D=0A=09<20090806215107.GB10982@Sun.COM>=20<20090807061 512.GG1035@Sun.COM>|In-Reply-To:=20<20090807061512.GG1035 @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=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5706"=3B=20a=3D"21961721"; bh=SS/AtiMuQZ/Ieh6sfDNOdJwq7lBDl8xKdUmNSVAESVg=; b=ozVcmIpKj0SdnecYwI7uxghAPyV4xaLq+N/2PhadHhjc6tGAadgggN8a tWoY2VJkYvz5p0oAGssjvQMKgm7Qm6bdWpzrcis6B2yGj5Qry+5ajNfdv yA+a/b3b3f2ehV1YDJbl8mKPl1MtX2rIx2M5bA+9jPyUcH1tzIxAV1jul c=;
X-IronPort-AV: E=McAfee;i="5300,2777,5706"; a="21961721"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Aug 2009 11:09:45 -0700
Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7BI9itp023364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Aug 2009 11:09:44 -0700
Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7BI9iGP006655 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Aug 2009 11:09:44 -0700
Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 11 Aug 2009 11:09:44 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 11 Aug 2009 11:09:43 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Nicolas Williams <Nicolas.Williams@sun.com>, "btns@ietf.org" <btns@ietf.org>
Date: Tue, 11 Aug 2009 11:09:41 -0700
Thread-Topic: [btns] Q: How to deal with connection latch breaks?
Thread-Index: AcoXJ+3sI5I4DEVeQfStzQW7aQmF/wDhqGxw
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C22ACD3D7@NALASEXMB04.na.qualcomm.com>
References: <5D4C4002AC7C3340987C37B1E4B66A54029A9076@SACMVEXC2-PRD.hq.netapp.com> <20090806215107.GB10982@Sun.COM> <20090807061512.GG1035@Sun.COM>
In-Reply-To: <20090807061512.GG1035@Sun.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Eisler, Michael" <Michael.Eisler@netapp.com>
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: Tue, 11 Aug 2009 18:11:35 -0000

Thanks Michael, Mike and Nico for working on resolving this issue. 

Unless someone objects to the proposed resolution below before end of the week, let's call it a WG consensus and publish an update of the draft accordingly.

--julien

> -----Original Message-----
> From: btns-bounces@ietf.org [mailto:btns-bounces@ietf.org] On Behalf Of
> Nicolas Williams
> Sent: Thursday, August 06, 2009 11:15 PM
> To: btns@ietf.org
> Cc: Eisler, Michael
> Subject: Re: [btns] Q: How to deal with connection latch breaks?
> 
> Michael Richardson, Mike Eisler and I have discussed this issue in
> e-mail and on the phone and we have come to a consensus.
> 
> We believe that the purist approach to latch breaks in the absence of
> new APIs (or their non-use) is to treat the situation as packet loss.
> However, the pragmatic default is to treat latch breaks as a reset (in
> the TCP case) or ICMP destination unreachable (in the SCTP case, when
> there are multi-homed end-points, so that path failover may take place
> sooner).
> 
> The pragmatic approach allows an on-path DoS, but not an off-path DoS.
> This seems acceptable given that an on-path attacker that can pull off
> a
> connection reset attack by causing a latch break can also cause bits to
> stop moving in the "purist" alternative anyways.  I.e., there's an
> on-path DoS attack not matter what, and resetting the connection
> (or causing failover to another path) sooner seems better than forcing
> the ULP or the application to timeout first.
> 
> So we will say that implementors SHOULD provide APIs and MUST choose a
> default behavior in case of latch breaks when no APIs are available (or
> can't be used), and we list the set of behaviors that implementors may
> choose from.  We also specify a default behavior: the "pragmatic"
> one described above.  Finally, we combine the relevant text from
> sections 5.1 and 5.4 into a single new section.
> 
> The new text, to replace the last paragraph of sections 5.1 and 5.4:
> 
>    See section 5.5.
> 
> New section 5.5 text (modulo xml2rfc formatting):
> 
> 5.5 Handling of BROKEN state for TCP and SCTP
> 
>    There are several ways to handle connection latch transitions to the
>    BROKEN state in the case of connection-oriented ULPs like TCP or
>    SCTP:
> 
>    a) Wait for a possible future transition back to the ESTABLISHED
>       state, until which time the ULP will not move data between the
> two
>       end-points of the connection.  ULP and application timeout
>       mechanisms will, of course, trigger in the event of too lengthy a
>       stay in the BROKEN state.  SCTP can detect these timeouts and
>       initiate failover, in the case of multi-homed associations.
> 
>    b) Act as though the connection has been reset (RST message
>       received, in TCP, or ABORT message received, in SCTP).
> 
>    c) Act as though an ICMP destination unreachable message had been
>       received (in SCTP such messages can trigger path failover in the
>       case of multi-homed associations).
> 
>    Implementors SHOULD provide APIs for either informing applications
>    (asynchronously or otherwise) of latch breaks, so that they may
>    choose a disposition (wait, close, or proceed with path failover),
> or
>    by which applications can select a specific disposition a priori
>    (before a latch break happens).
> 
>    Implementors MUST provide a default disposition in the event of a
>    connection latch break.  Though (a) is clearly the purist default,
> we
>    RECOMMEND (b) for TCP and SCTP associations where only a single path
>    remains (one 5-tuple), and (c) for multi-homed SCTP associations.
>    The rationale for this recommendation is as follows: a conflicting
> SA
>    most likely indicates that the original peer is gone and has been
>    replaced by another, and it's not likely that the original peer will
>    return, thus failing faster seems reasonable.
> 
>    Note that our recommended default behavior does not create off-path
>    reset denial-of-service (DoS) attacks: to break a connection latch
> an
>    attacker would first have to successfully establish an SA, with one
>    of the connection's end-points, that conflicts with the connection
>    latch, and that requires multiple messages to be exchanged between
>    that end-point and the attacker.  Unless the attacker's chosen
> victim
>    end-point allows the attacker to claim IP address ranges for its SAs
>    then the attacker would have to actually take over the other
>    end-point's addresses, which rules out off-path attacks.
> 
> Comments?
> 
> Nico
> --
> _______________________________________________
> btns mailing list
> btns@ietf.org
> https://www.ietf.org/mailman/listinfo/btns