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
- [btns] Q: How to deal with connection latch break… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Julien Laganier
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams