From julienl@qualcomm.com  Tue Aug  4 08:13:21 2009
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 4FF1028C3C1 for <btns@core3.amsl.com>; Tue,  4 Aug 2009 08:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.299
X-Spam-Level: 
X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 Iswmi2IhFqFS for <btns@core3.amsl.com>; Tue,  4 Aug 2009 08:13:20 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id EDB0828C3E7 for <btns@ietf.org>; Tue,  4 Aug 2009 08:13:19 -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=1249398803; x=1280934803; 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:=20Michael=20Richardson=20<mcr@sandelman.ottawa.on.ca >,=0D=0A=20=20=20=20=20=20=20=20Mike=20Eisler=0D=0A=09<mr e-ietf@eisler.com>|CC:=20"btns@ietf.org"=20<btns@ietf.org >|Date:=20Tue,=204=20Aug=202009=2008:12:38=20-0700 |Subject:=20RE:=20[btns]=20Q:=20How=20to=20deal=20with=20 connection=20latch=20breaks?|Thread-Topic:=20[btns]=20Q: =20How=20to=20deal=20with=20connection=20latch=20breaks? |Thread-Index:=20AcoRCgFkruNT/c1ES+uYz4ZY5mecEAEC660Q |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C22ACD07 C@NALASEXMB04.na.qualcomm.com>|References:=20<e2cf27e9875 7db0c8561baadfb3ca335.squirrel@webmail.eisler.com>=0D=0A =09<20090726221331.GS1020@Sun.COM>=09<9481.1248714083@mar ajade.sandelman.ca>=0D=0A=09<a0459a6daa0f2f67ff64eb0b2e32 8a58.squirrel@webmail.eisler.com>=0D=0A=20=20<16755.12489 53791@marajade.sandelman.ca>|In-Reply-To:=20<16755.124895 3791@marajade.sandelman.ca>|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"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5697"=3B=20a=3D"21641610"; bh=65NOYeUjCCm+sQp6rcbta2IlcFUfYudV45FLR9/X3Nk=; b=A5XIfBlNA02+XglxIJzPFHJfKhcdT0k1HolLn+3B2WGKAm/0ZOWbWohU UzJsPZav0HosdR7is6FVqv8vb/D2K9SQNximL8j4286nmRPno00TGuiMS um4A6cRsnte+nK4Odf4Vm57BMBfpTkgkgbUYQtADKvVjzDcTZshfGRlS1 8=;
X-IronPort-AV: E=McAfee;i="5300,2777,5697"; a="21641610"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Aug 2009 08:12:45 -0700
Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n74FCj22032179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2009 08:12:45 -0700
Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n74FCeUJ010860 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Aug 2009 08:12:40 -0700
Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 4 Aug 2009 08:12:39 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Tue, 4 Aug 2009 08:12:40 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>, Mike Eisler <mre-ietf@eisler.com>
Date: Tue, 4 Aug 2009 08:12:38 -0700
Thread-Topic: [btns] Q: How to deal with connection latch breaks?
Thread-Index: AcoRCgFkruNT/c1ES+uYz4ZY5mecEAEC660Q
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C22ACD07C@NALASEXMB04.na.qualcomm.com>
References: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com> <20090726221331.GS1020@Sun.COM>	<9481.1248714083@marajade.sandelman.ca> <a0459a6daa0f2f67ff64eb0b2e328a58.squirrel@webmail.eisler.com> <16755.1248953791@marajade.sandelman.ca>
In-Reply-To: <16755.1248953791@marajade.sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 04 Aug 2009 15:13:21 -0000

Folks,

We really need to get to closure on this, as I've been told that NFS v4.1 h=
as been on hold for 26 weeks because of this, so let's do our best to move =
forward.

I understand the remaining issue is how is an application informed that a c=
onnection latch transitioned to BROKEN as per:

   When a connection latch transitions to the BROKEN state and the
   application requested (or system policy dictates it) that the
   connection be broken, then SCTP should inform the application, if
   there is a way to do so, or else it should wait, allowing SCTP path/
   endpoint failure detection (and/or application-layer keepalive
   strategy) to timeout the connection.  When a connection latch is
   administratively transitioned to the CLOSED state then SCTP should
   act as though an ABORT chunk has been received.
=20
It was discussed whether ETIMEOUT or ELATCHBROKEN shall be returned to the =
app, and I proposed that ETIMEOUT be returned to the application that didn'=
t used a BTNS API to request the connection be broken when the latch transi=
tion to BROKEN, and ETIMEOUT otherwise.

Is this satisfactory? If yes let's document that in a more implementation a=
gnostic way and try to move forward the draft to Approved state.

--julien


> -----Original Message-----
> From: btns-bounces@ietf.org [mailto:btns-bounces@ietf.org] On Behalf Of
> Michael Richardson
> Sent: Thursday, July 30, 2009 4:37 AM
> To: Mike Eisler
> Cc: btns@ietf.org
> Subject: Re: [btns] Q: How to deal with connection latch breaks?
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
> >>>>> "Mike" =3D=3D Mike Eisler <mre-ietf@eisler.com> writes:
>     >> So, errno value from write(2) is not a new API.  A new errno
>     >> value should provide enough information, I think.
>     >>
>     >> However, an application might know what to do with ETIMEOUT,
>     >> while it would not know what to do with EUNLATCHED or some
>     >> such....
>=20
>     Mike> Isn't the application the entity that decided to enable
>     Mike> latching?  If so, the application (or its author) needs to be
>     Mike> prepared to deal with new error indication.
>=20
>   It may be enabled by system-policy, in particularly for the passive
> open
> side ("bind()/accept()" side). It could also be enabled by the "inetd"
> equivalent, and then pass that descriptor on.
>=20
> - --
> ]     Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!!        |
> firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
> ]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby
> guy");  [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>=20
> iQEVAwUBSnGFvYCLcPvd0N1lAQJXagf/eo91+crzqoWgKGDNbStD5nd1xiDkAH4h
> 3bgr4VqkFoxHD7WZExSAM3TNVGPo3209Yerd8fCRrb6EDlXdSxa4ksqksxmdhLl/
> 7sTlbQREvG/x11rE6u0sEZNSUqpQteyDwxG1L5z3lJM3dR5BBKHb/x9uUWD68dla
> 8wJdt4RioUDT4hFos+FilNhUef14ITWBTMIs5B9M5prLXKrmXkiRffSJ0JqIorIX
> vYZfdfr7V6cSKxhDNLXFYp62K5h3vXU2z+1Tp2aE6187zQQX/paIsGa1DCedexbG
> 6RlhXgenQTRnMZbRHDeTNDX+fqY/Pyfk6nDCdFt4hN5BJXMh/Ltj8g=3D=3D
> =3DrlxH
> -----END PGP SIGNATURE-----
> _______________________________________________
> btns mailing list
> btns@ietf.org
> https://www.ietf.org/mailman/listinfo/btns

From mre-ietf@eisler.com  Wed Aug  5 00:12:39 2009
Return-Path: <mre-ietf@eisler.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 9BC3B3A716C for <btns@core3.amsl.com>; Wed,  5 Aug 2009 00:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.861
X-Spam-Level: 
X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.138,  BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
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 Grl7IxnH6p2P for <btns@core3.amsl.com>; Wed,  5 Aug 2009 00:12:38 -0700 (PDT)
Received: from webmail1.sd.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) by core3.amsl.com (Postfix) with ESMTP id 9D8DB28C4CE for <btns@ietf.org>; Wed,  5 Aug 2009 00:12:38 -0700 (PDT)
Received: from webmail.eisler.com (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id 54EB92C197; Wed,  5 Aug 2009 00:06:58 -0700 (PDT)
Received: from 202.3.112.9 (proxying for 202.3.112.9) (SquirrelMail authenticated user mre-ietf@eisler.com) by webmail.eisler.com with HTTP; Wed, 5 Aug 2009 00:06:58 -0700
Message-ID: <bce30b84d39f3c1868a8bc75a5458b3b.squirrel@webmail.eisler.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C22ACD07C@NALASEXMB04.na.qualcomm.com>
References: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com> <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca> <a0459a6daa0f2f67ff64eb0b2e328a58.squirrel@webmail.eisler.com> <16755.1248953791@marajade.sandelman.ca> <BF345F63074F8040B58C00A186FCA57F1C22ACD07C@NALASEXMB04.na.qualcomm.com>
Date: Wed, 5 Aug 2009 00:06:58 -0700
From: "Mike Eisler" <mre-ietf@eisler.com>
To: "Laganier, Julien" <julienl@qualcomm.com>
User-Agent: SquirrelMail/1.4.19
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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, 05 Aug 2009 07:12:39 -0000

On Tue, August 4, 2009 8:12 am, Laganier, Julien wrote:
> Folks,
>
> We really need to get to closure on this, as I've been told that NFS v4.1
> has been on hold for 26 weeks because of this, so let's do our best to
> move forward.
>
> I understand the remaining issue is how is an application informed that a
> connection latch transitioned to BROKEN as per:
>
>    When a connection latch transitions to the BROKEN state and the
>    application requested (or system policy dictates it) that the
>    connection be broken, then SCTP should inform the application, if
>    there is a way to do so, or else it should wait, allowing SCTP path/
>    endpoint failure detection (and/or application-layer keepalive
>    strategy) to timeout the connection.  When a connection latch is
>    administratively transitioned to the CLOSED state then SCTP should
>    act as though an ABORT chunk has been received.
>
> It was discussed whether ETIMEOUT or ELATCHBROKEN shall be returned to the
> app, and I proposed that ETIMEOUT be returned to the application that
> didn't used a BTNS API to request the connection be broken when the latch
> transition to BROKEN, and ETIMEOUT otherwise.

Julien,

Your above text suggests returning ETIMEOUT for both cases.
Is that what you intended, or is ELATCHBROKEN to be returned for one
of those cases, and if so, which one?

>
> Is this satisfactory? If yes let's document that in a more implementation
> agnostic way and try to move forward the draft to Approved state.
>
> --julien
>
>
>> -----Original Message-----
>> From: btns-bounces@ietf.org [mailto:btns-bounces@ietf.org] On Behalf Of
>> Michael Richardson
>> Sent: Thursday, July 30, 2009 4:37 AM
>> To: Mike Eisler
>> Cc: btns@ietf.org
>> Subject: Re: [btns] Q: How to deal with connection latch breaks?
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> >>>>> "Mike" == Mike Eisler <mre-ietf@eisler.com> writes:
>>     >> So, errno value from write(2) is not a new API.  A new errno
>>     >> value should provide enough information, I think.
>>     >>
>>     >> However, an application might know what to do with ETIMEOUT,
>>     >> while it would not know what to do with EUNLATCHED or some
>>     >> such....
>>
>>     Mike> Isn't the application the entity that decided to enable
>>     Mike> latching?  If so, the application (or its author) needs to be
>>     Mike> prepared to deal with new error indication.
>>
>>   It may be enabled by system-policy, in particularly for the passive
>> open
>> side ("bind()/accept()" side). It could also be enabled by the "inetd"
>> equivalent, and then pass that descriptor on.
>>
>> - --
>> ]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |
>> firewalls  [
>> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
>> architect[
>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
>> driver[
>> ]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby
>> guy");  [
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Finger me for keys
>>
>> iQEVAwUBSnGFvYCLcPvd0N1lAQJXagf/eo91+crzqoWgKGDNbStD5nd1xiDkAH4h
>> 3bgr4VqkFoxHD7WZExSAM3TNVGPo3209Yerd8fCRrb6EDlXdSxa4ksqksxmdhLl/
>> 7sTlbQREvG/x11rE6u0sEZNSUqpQteyDwxG1L5z3lJM3dR5BBKHb/x9uUWD68dla
>> 8wJdt4RioUDT4hFos+FilNhUef14ITWBTMIs5B9M5prLXKrmXkiRffSJ0JqIorIX
>> vYZfdfr7V6cSKxhDNLXFYp62K5h3vXU2z+1Tp2aE6187zQQX/paIsGa1DCedexbG
>> 6RlhXgenQTRnMZbRHDeTNDX+fqY/Pyfk6nDCdFt4hN5BJXMh/Ltj8g==
>> =rlxH
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> btns mailing list
>> btns@ietf.org
>> https://www.ietf.org/mailman/listinfo/btns
> _______________________________________________
> btns mailing list
> btns@ietf.org
> https://www.ietf.org/mailman/listinfo/btns
>


-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/




From julienl@qualcomm.com  Wed Aug  5 03:47:23 2009
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 B202328C544 for <btns@core3.amsl.com>; Wed,  5 Aug 2009 03:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.653
X-Spam-Level: 
X-Spam-Status: No, score=-105.653 tagged_above=-999 required=5 tests=[AWL=0.946, 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 iaBpKn7+ULMw for <btns@core3.amsl.com>; Wed,  5 Aug 2009 03:47:22 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 99F533A71A1 for <btns@ietf.org>; Wed,  5 Aug 2009 03:47:22 -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=1249469245; x=1281005245; 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:=20Mike=20Eisler=20<mre-ietf@eisler.com>|CC:=20Michae l=20Richardson=20<mcr@sandelman.ottawa.on.ca>,=0D=0A=20 =20=20=20=20=20=20=20"btns@ietf.org"=0D=0A=09<btns@ietf.o rg>|Date:=20Wed,=205=20Aug=202009=2003:47:15=20-0700 |Subject:=20RE:=20[btns]=20Q:=20How=20to=20deal=20with=20 connection=20latch=20breaks?|Thread-Topic:=20[btns]=20Q: =20How=20to=20deal=20with=20connection=20latch=20breaks? |Thread-Index:=20AcoVm2MrSB04RvwzSR680B1xkbgcigAHl91Q |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C22ACD10 7@NALASEXMB04.na.qualcomm.com>|References:=20<e2cf27e9875 7db0c8561baadfb3ca335.squirrel@webmail.eisler.com>=0D=0A =20=20=20=20<20090726221331.GS1020@Sun.COM>=20<9481.12487 14083@marajade.sandelman.ca>=0D=0A=20=20=20=20<a0459a6daa 0f2f67ff64eb0b2e328a58.squirrel@webmail.eisler.com>=0D=0A =20=20=20=20<16755.1248953791@marajade.sandelman.ca>=0D =0A=20=20=20=20<BF345F63074F8040B58C00A186FCA57F1C22ACD07 C@NALASEXMB04.na.qualcomm.com>=0D=0A=20<bce30b84d39f3c186 8a8bc75a5458b3b.squirrel@webmail.eisler.com>|In-Reply-To: =20<bce30b84d39f3c1868a8bc75a5458b3b.squirrel@webmail.eis ler.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,5698"=3B=20a=3D"21688608"; bh=y76blsycmFGc4ivx5OS352j9Z4mUwsmxZjfFpOCoLm0=; b=JEz10QrqJJbNPuPu49fMpeBkhz4izdpR08wotGZYEmz60SmWqcI9muhm R/E4CjGTGp5bPohUeYg8GotY/WuQ/KVIb8COMlEOZjHCAeyl3Gk8w5HT8 FW+44fpwBZ6owgtzDwvh3/4JS54E57NmCygif13S7roCwYCvbzM6cKCLw o=;
X-IronPort-AV: E=McAfee;i="5300,2777,5698"; a="21688608"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Aug 2009 03:47:22 -0700
Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n75AlMt1026801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Aug 2009 03:47:23 -0700
Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n75AlIrY026954 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Aug 2009 03:47:18 -0700
Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 5 Aug 2009 03:47:18 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Wed, 5 Aug 2009 03:47:17 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Mike Eisler <mre-ietf@eisler.com>
Date: Wed, 5 Aug 2009 03:47:15 -0700
Thread-Topic: [btns] Q: How to deal with connection latch breaks?
Thread-Index: AcoVm2MrSB04RvwzSR680B1xkbgcigAHl91Q
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C22ACD107@NALASEXMB04.na.qualcomm.com>
References: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com> <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca> <a0459a6daa0f2f67ff64eb0b2e328a58.squirrel@webmail.eisler.com> <16755.1248953791@marajade.sandelman.ca> <BF345F63074F8040B58C00A186FCA57F1C22ACD07C@NALASEXMB04.na.qualcomm.com> <bce30b84d39f3c1868a8bc75a5458b3b.squirrel@webmail.eisler.com>
In-Reply-To: <bce30b84d39f3c1868a8bc75a5458b3b.squirrel@webmail.eisler.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: "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, 05 Aug 2009 10:47:23 -0000

> From: Mike Eisler [mailto:mre-ietf@eisler.com]
>=20
> On Tue, August 4, 2009 8:12 am, Laganier, Julien wrote:
> > Folks,
> >
> > We really need to get to closure on this, as I've been told that NFS
> v4.1
> > has been on hold for 26 weeks because of this, so let's do our best
> to
> > move forward.
> >
> > I understand the remaining issue is how is an application informed
> that a
> > connection latch transitioned to BROKEN as per:
> >
> >    When a connection latch transitions to the BROKEN state and the
> >    application requested (or system policy dictates it) that the
> >    connection be broken, then SCTP should inform the application, if
> >    there is a way to do so, or else it should wait, allowing SCTP
> path/
> >    endpoint failure detection (and/or application-layer keepalive
> >    strategy) to timeout the connection.  When a connection latch is
> >    administratively transitioned to the CLOSED state then SCTP should
> >    act as though an ABORT chunk has been received.
> >
> > It was discussed whether ETIMEOUT or ELATCHBROKEN shall be returned
> to the
> > app, and I proposed that ETIMEOUT be returned to the application that
> > didn't used a BTNS API to request the connection be broken when the
> latch
> > transition to BROKEN, and ETIMEOUT otherwise.
>=20
> Julien,
>=20
> Your above text suggests returning ETIMEOUT for both cases.
> Is that what you intended, or is ELATCHBROKEN to be returned for one
> of those cases, and if so, which one?

Sorry I messed up. It should read:

ETIMEOUT be returned to the application that didn't used a BTNS API to requ=
est the connection be broken when the latch transition to BROKEN, and ELATC=
HBROKEN otherwise (i.e., the application did use the BTNS API and thus know=
s what a BROKEN latch and ELACTHBROKEN are, and what to do.)

--julien

From mcr@marajade.sandelman.ca  Wed Aug  5 07:55:16 2009
Return-Path: <mcr@marajade.sandelman.ca>
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 56F5628C599 for <btns@core3.amsl.com>; Wed,  5 Aug 2009 07:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level: 
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6]
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 HPx163XhioVr for <btns@core3.amsl.com>; Wed,  5 Aug 2009 07:55:15 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id EBF9A28C5AA for <btns@ietf.org>; Wed,  5 Aug 2009 07:54:57 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 7A253343F2 for <btns@ietf.org>; Wed,  5 Aug 2009 14:55:00 +0000 (UTC)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 362C93EC5 for <btns@ietf.org>; Wed,  5 Aug 2009 10:54:59 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: "btns@ietf.org" <btns@ietf.org>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C22ACD107@NALASEXMB04.na.qualcomm.com>
References: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com> <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca> <a0459a6daa0f2f67ff64eb0b2e328a58.squirrel@webmail.eisler.com> <16755.1248953791@marajade.sandelman.ca> <BF345F63074F8040B58C00A186FCA57F1C22ACD07C@NALASEXMB04.na.qualcomm.com> <bce30b84d39f3c1868a8bc75a5458b3b.squirrel@webmail.eisler.com> <BF345F63074F8040B58C00A186FCA57F1C22ACD107@NALASEXMB04.na.qualcomm.com>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 05 Aug 2009 10:54:59 -0400
Message-ID: <7131.1249484099@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
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, 05 Aug 2009 14:55:16 -0000

>>>>> "Julien" =3D=3D Julien Laganier <Laganier> writes:
    Julien> Sorry I messed up. It should read:

    Julien> ETIMEOUT be returned to the application that didn't used a
    Julien> BTNS API to request the connection be broken when the latch
    Julien> transition to BROKEN, and ELATCHBROKEN otherwise (i.e., the
    Julien> application did use the BTNS API and thus knows what a
    Julien> BROKEN latch and ELACTHBROKEN are, and what to do.)

I concur.
Let's write:
      ETIMEOUT SHOULD be returned to applications when a broken connection
      latch causes communications to fail.  This is consistent with what
      would happen if a cable was unplugged, etc.

      Applications which have used a BTNS API to request a latched
      connection MAY receive a more detailed error to indicate if=20
      the communication failure is a result of a connection latch
      being broken.  The details of this process are defined in an API
      document.

(I am hoping that we can find a way to avoid a direct reference to the
API document, as that would hold things up further)

--=20
]     Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!!        |  firewa=
lls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net archit=
ect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri=
ver[
]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby  guy")=
;  [


From Nicolas.Williams@sun.com  Thu Aug  6 23:25:51 2009
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 0C54A3A6AAB for <btns@core3.amsl.com>; Thu,  6 Aug 2009 23:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.79
X-Spam-Level: 
X-Spam-Status: No, score=-5.79 tagged_above=-999 required=5 tests=[AWL=0.256,  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 YSSyWPsyJ-ZJ for <btns@core3.amsl.com>; Thu,  6 Aug 2009 23:25:50 -0700 (PDT)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id CCF8F3A6863 for <btns@ietf.org>; Thu,  6 Aug 2009 23:25:45 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n776Pk08023287 for <btns@ietf.org>; Fri, 7 Aug 2009 06:25:46 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n776PkxU044435 for <btns@ietf.org>; Fri, 7 Aug 2009 00:25:46 -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 n776FDGA011220; Fri, 7 Aug 2009 01:15:13 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n776FC4B011219;  Fri, 7 Aug 2009 01:15:12 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 7 Aug 2009 01:15:12 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: btns@ietf.org
Message-ID: <20090807061512.GG1035@Sun.COM>
References: <5D4C4002AC7C3340987C37B1E4B66A54029A9076@SACMVEXC2-PRD.hq.netapp.com> <20090806215107.GB10982@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090624201707.GY1308@Sun.COM>
User-Agent: Mutt/1.5.7i
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: Fri, 07 Aug 2009 06:25:51 -0000

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
-- 

From mcr@marajade.sandelman.ca  Fri Aug  7 09:36:15 2009
Return-Path: <mcr@marajade.sandelman.ca>
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 2D9A03A6A89 for <btns@core3.amsl.com>; Fri,  7 Aug 2009 09:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.448
X-Spam-Level: 
X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_11=1, J_CHICKENPOX_15=0.6]
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 NEtnRcht4n4i for <btns@core3.amsl.com>; Fri,  7 Aug 2009 09:36:14 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 4D5073A6D7E for <btns@ietf.org>; Fri,  7 Aug 2009 09:36:14 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 52E0534580 for <btns@ietf.org>; Fri,  7 Aug 2009 16:36:17 +0000 (UTC)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 2AD703EC5 for <btns@ietf.org>; Fri,  7 Aug 2009 12:36:16 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: btns@ietf.org
In-Reply-To: <20090807061512.GG1035@Sun.COM> 
References: <5D4C4002AC7C3340987C37B1E4B66A54029A9076@SACMVEXC2-PRD.hq.netapp.com> <20090806215107.GB10982@Sun.COM> <20090807061512.GG1035@Sun.COM> 
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Fri, 07 Aug 2009 12:36:16 -0400
Message-ID: <9561.1249662976@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
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: Fri, 07 Aug 2009 16:36:15 -0000

>>>>> "Nicolas" =3D=3D Nicolas Williams <Nicolas.Williams@sun.com> writes:
    Nicolas> We believe that the purist approach to latch breaks in the
    Nicolas> absence of new APIs (or their non-use) is to treat the
    Nicolas> situation as packet loss.  However, the pragmatic default
    Nicolas> is to treat latch breaks as a reset (in the TCP case) or
    Nicolas> ICMP destination unreachable (in the SCTP case, when there
    Nicolas> are multi-homed end-points, so that path failover may take
    Nicolas> place sooner).

I wanted to post that I am in agreement, but it took me awhile to get
why TCP RESET makes sense sometimes.

The is the scenario. Assume a stable system (i.e. web server) (W), and an
end-point which is mobile (C).

C<->W do connection latching (perhaps facilitated by BTNS) and transfer
      some data.=20
System C goes away (moves, shuts down, etc) from IP-C before it closes
       all it's TCP/SCTP sessions nicely.
System D is now at IP-D.=20

Now, in the absense of BTNS, system W would send a TCP/SCTP segment to=20
     IP-C, and system D would return with a TCP RST since it would not
     recognize the data.

Due to connection-latching, one of two things occur:
    1) system W sends TCP segments inside ESP, and system D sees it
       and has no idea what to do. (IKE-INITIAL-CONTACT could kill that
       SA, as could various birth-certificate proposals)

    2) system W's SA with system C expires (or is deleted by
       INITIAL-CONTACT), and system W sees that has a broken latch.

If system D is not doing IPsec (BTNS or otherwise), then the TCP/SCTP
just tries until the SA expires.  If the ULP times out, then it does
ETIMEOUT as it would when a cable is unplugged.

If system D is doing IPsec (BTNS), then system C recognizes that the SA
is broken to IP-C, and never sends anything. Since it never sends the
TCP segment, it never gets a TCP RST.  This is why is makes sense for an
implementation to pretend a TCP RST has been received if in fact the
latch is broken.

This is really an on-path TCP RST.

In the BGP situation, where TCP RSTs are of concern, this situation can
only occur if:
  a) one router (BGP-speaker) replaces another router at the same IP.
  b) the new router does IPsec/BTNS and system W is willing to permit
     the new router's key to assert the old router's IP.

(a) points to the fact that the IX has no layer-2/3 security. (i.e. ARP
    is insecure. Use SEND, or hard code ARP entries...)

(b) points to a misconfigured/unsecured PAD for this use.

Many in the BGP situation want to use BTNS to create the initial
relationships, and then lock the results down (which ceases to be BTNS)
via telephone/etc. communication....=20

--=20
]     Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!!        |  firewa=
lls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net archit=
ect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri=
ver[
]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby  guy")=
;  [
=09=20=20=20
=09=09

From julienl@qualcomm.com  Tue Aug 11 11:11:35 2009
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.=20

Unless someone objects to the proposed resolution below before end of the w=
eek, let's call it a WG consensus and publish an update of the draft accord=
ingly.

--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?
>=20
> Michael Richardson, Mike Eisler and I have discussed this issue in
> e-mail and on the phone and we have come to a consensus.
>=20
> 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).
>=20
> 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.
>=20
> 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.
>=20
> The new text, to replace the last paragraph of sections 5.1 and 5.4:
>=20
>    See section 5.5.
>=20
> New section 5.5 text (modulo xml2rfc formatting):
>=20
> 5.5 Handling of BROKEN state for TCP and SCTP
>=20
>    There are several ways to handle connection latch transitions to the
>    BROKEN state in the case of connection-oriented ULPs like TCP or
>    SCTP:
>=20
>    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.
>=20
>    b) Act as though the connection has been reset (RST message
>       received, in TCP, or ABORT message received, in SCTP).
>=20
>    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).
>=20
>    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).
>=20
>    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.
>=20
>    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.
>=20
> Comments?
>=20
> Nico
> --
> _______________________________________________
> btns mailing list
> btns@ietf.org
> https://www.ietf.org/mailman/listinfo/btns

From Nicolas.Williams@sun.com  Wed Aug 12 11:17:12 2009
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
-- 

From julienl@qualcomm.com  Wed Aug 12 13:07:53 2009
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 88DB33A6A93 for <btns@core3.amsl.com>; Wed, 12 Aug 2009 13:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.784
X-Spam-Level: 
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ShfeS3s-tof for <btns@core3.amsl.com>; Wed, 12 Aug 2009 13:07:52 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5D3113A6837 for <btns@ietf.org>; Wed, 12 Aug 2009 13:07:52 -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=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<julienl@qualcomm.com> |To:=20Nicolas=20Williams=20<Nicolas.Williams@sun.com>, =0D=0A=20=20=20=20=20=20=20=20Michael=20Richardson=0D=0A =09<mcr@sandelman.ottawa.on.ca>|CC:=20"btns@ietf.org"=20< btns@ietf.org>|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 2ACD505@NALASEXMB04.na.qualcomm.com>|References:=20<5D4C4 002AC7C3340987C37B1E4B66A54029A9076@SACMVEXC2-PRD.hq.neta pp.com>=0D=0A=09<20090806215107.GB10982@Sun.COM>=20<20090 807061512.GG1035@Sun.COM>=0D=0A=09<9561.1249662976@maraja de.sandelman.ca>=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 pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Aug 2009 13:06:49 -0700
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (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 nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by totoro.qualcomm.com (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 nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 12 Aug 2009 13:06:35 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 12 Aug 2009 13:06:35 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Nicolas Williams <Nicolas.Williams@sun.com>, Michael Richardson <mcr@sandelman.ottawa.on.ca>
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: <BF345F63074F8040B58C00A186FCA57F1C22ACD505@NALASEXMB04.na.qualcomm.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>
In-Reply-To: <20090812180608.GF10982@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: "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 20:07:53 -0000

Nico,

Pls. see below.

Nicolas Williams wrote:
>=20
> 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.
>=20
> 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.
>=20
> 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".
>=20
> Possible wrinkle:
>=20
>  - 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!
>=20
>    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?
>=20
> 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.
>=20
> Rationale:
>=20
>  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 t=
he BTNS case where the BTNS IKE SA gets re-established after DPD, each of t=
he 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-es=
tablish a BTNS IKE SA after DPD, or a BTNS IKE SA can be established but to=
 a different peer.

--julien

From mcr@marajade.sandelman.ca  Wed Aug 12 13:40:41 2009
Return-Path: <mcr@marajade.sandelman.ca>
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 2C5173A6EBE for <btns@core3.amsl.com>; Wed, 12 Aug 2009 13:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.937
X-Spam-Level: 
X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=0.417,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6]
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 ofd-OoCL48Kp for <btns@core3.amsl.com>; Wed, 12 Aug 2009 13:40:40 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 43AE13A6EB3 for <btns@ietf.org>; Wed, 12 Aug 2009 13:40:39 -0700 (PDT)
Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 188B834949 for <btns@ietf.org>; Wed, 12 Aug 2009 20:40:01 +0000 (UTC)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 162743EC5 for <btns@ietf.org>; Wed, 12 Aug 2009 16:39:58 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
To: "btns@ietf.org" <btns@ietf.org>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C22ACD505@NALASEXMB04.na.qualcomm.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>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Aug 2009 16:39:58 -0400
Message-ID: <10677.1250109598@marajade.sandelman.ca>
Sender: mcr@marajade.sandelman.ca
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 20:40:41 -0000

>>>>> "Julien" =3D=3D Julien Laganier <Laganier> writes:
    Julien> Not sure I caught all the details of the discussion, but
    Julien> just to make sure I understand correctly: If a peer
    Julien> restarts, DPD will eventually detect it, and then the peers
    Julien> can proceed with re-establishing IKE and CHILD SAs. In the
    Julien> BTNS case where the BTNS IKE SA gets re-established after
    Julien> DPD, each of the BTNS peers can verify that they're talking
    Julien> to the same peer right?=20

yes. The channel-binding information that would be maintained by at
least one of the peers (even if the application does not ask for it),
would indicate if it was the same peer.

    Julien> Thus I think the latches shouldn't
    Julien> be broken automatically when DPD concludes a peer is
    Julien> dead. They should only be broken in case it's not possible
    Julien> to re-establish a BTNS IKE SA after DPD, or a BTNS IKE SA
    Julien> can be established but to a different peer.

1) "not possible to re-establish a BTNS IKE SA after DPD"
this may be hard to define.

2) "BTNS IKE SA can be established but to a different peer."
this is easy to define, and we are all in agreement about this.
(And why treating it like a TCP RST may be appropriate)

For (1) the best we can do is to let the ULP timeout, I think.

--=20
]     Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!!        |  firewa=
lls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net archit=
ect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri=
ver[
]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby  guy")=
;  [





From Nicolas.Williams@sun.com  Wed Aug 12 14:49:44 2009
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
-- 

From root@core3.amsl.com  Thu Aug 13 16:00:01 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: btns@ietf.org
Delivered-To: btns@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 45A363A6D18; Thu, 13 Aug 2009 16:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090813230001.45A363A6D18@core3.amsl.com>
Date: Thu, 13 Aug 2009 16:00:01 -0700 (PDT)
Cc: btns@ietf.org
Subject: [btns] I-D Action:draft-ietf-btns-connection-latching-11.txt
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: Thu, 13 Aug 2009 23:00:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF.


	Title           : IPsec Channels: Connection Latching
	Author(s)       : N. Williams
	Filename        : draft-ietf-btns-connection-latching-11.txt
	Pages           : 30
	Date            : 2009-08-13

This document specifies, abstractly, how to interface applications
and transport protocols with IPsec so as to create "channels" by
latching "connections" (packet flows) to certain IPsec Security
Association (SA) parameters for the lifetime of the connections.
Connection latching is layered on top of IPsec and does not modify
the underlying IPsec architecture.

Connection latching can be used to protect applications against
accidentally exposing live packet flows to unintended peers, whether
as the result of a reconfiguration of IPsec or as the result of using
weak peer identity to peer address associations.  Weak association of
peer ID and peer addresses is at the core of Better Than Nothing
Security (BTNS), thus connection latching can add a significant
measure of protection to BTNS IPsec nodes.

Finally, the availability of IPsec channels will make it possible to
use channel binding to IPsec channels.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-btns-connection-latching-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-08-13154904.I-D@ietf.org>


--NextPart--

From Nicolas.Williams@sun.com  Thu Aug 13 17:05:51 2009
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 416253A6D98 for <btns@core3.amsl.com>; Thu, 13 Aug 2009 17:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.874
X-Spam-Level: 
X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.172,  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 kKatooLTvRMD for <btns@core3.amsl.com>; Thu, 13 Aug 2009 17:05:50 -0700 (PDT)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 915D53A6992 for <btns@ietf.org>; Thu, 13 Aug 2009 17:05:50 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7E05siS006501 for <btns@ietf.org>; Fri, 14 Aug 2009 00:05:55 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7E05sKA022904 for <btns@ietf.org>; Thu, 13 Aug 2009 18:05:54 -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 n7DNtFjI001303 for <btns@ietf.org>; Thu, 13 Aug 2009 18:55:15 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7DNtF7V001302 for btns@ietf.org; Thu, 13 Aug 2009 18:55:15 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 13 Aug 2009 18:55:15 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: btns@ietf.org
Message-ID: <20090813235515.GC1043@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Subject: [btns] Version 11 of draft-ietf-btns-connection-latching posted
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: Fri, 14 Aug 2009 00:05:51 -0000

http://www.ietf.org/id/draft-ietf-btns-connection-latching-11.txt

Diffs:

http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-btns-connection-latching-10.txt&url2=http://www.ietf.org/id/draft-ietf-btns-connection-latching-11.txt

Changes made:

 - Added section 5.5 and updated sections 5.2 and 5.4 to reflect the new
   consensus on how to handle latch stat transitions to the BROKEN state
   in the absence of new APIs.
 - Added recommendation to break latches when IKE DPD concludes their
   remote peers are dead or rebooted.
    - Updated the latch state diagram to mention DPD.
 - Added Security Considerations sub-section to cover DoS attacks.
 - While updating section 2.2 text about the BROKEN state I noticed that
   a MUST in section 2.3 was not reflected in 2.2, so I updated that
   section 2.2 text accordingly.

Nico
-- 

From wwwrun@core3.amsl.com  Mon Aug 17 11:18:33 2009
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: btns@ietf.org
Delivered-To: btns@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 733E73A6774; Mon, 17 Aug 2009 11:18:33 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20090817181833.733E73A6774@core3.amsl.com>
Date: Mon, 17 Aug 2009 11:18:33 -0700 (PDT)
Cc: Internet Architecture Board <iab@iab.org>, btns mailing list <btns@ietf.org>, btns chair <btns-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [btns] Protocol Action: 'IPsec Channels: Connection Latching' to Proposed Standard
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: Mon, 17 Aug 2009 18:18:33 -0000

The IESG has approved the following document:

- 'IPsec Channels: Connection Latching '
   <draft-ietf-btns-connection-latching-11.txt> as a Proposed Standard


This document is the product of the Better-Than-Nothing Security Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-11.txt

Technical Summary

  This document specifies, abstractly, how to interface applications
  and transport protocols with IPsec so as to create "channels" by
  latching "connections" (packet flows) to certain IPsec Security
  Association (SA) parameters for the lifetime of the connections.
  Connection latching is layered on top of IPsec and does not modify
  the underlying IPsec architecture.

  Connection latching can be used to protect applications against
  accidentally exposing live packet flows to unintended peers, whether
  as the result of a reconfiguration of IPsec or as the result of using
  weak peer identity to peer address associations.  Weak association of
  peer ID and peer addresses is at the core of Better Than Nothing
  Security (BTNS), thus connection latching can add a significant
  measure of protection to BTNS IPsec nodes.

  Finally, the availability of IPsec channels will make it possible to
  use channel binding to IPsec channels.

Working Group Summary

   This document is a product of the Better Than Nothing Security (BTNS)
   working group. 

Document Quality

   A version of Connection Latching is implemented in OpenSolaris. The
  document has been reviewed by Daniel McDonald who worked on the
  Connection Latching implementation in OpenSolaris.

Personnel

   The Document Shepherd for this document is Julien Laganier (BTNS
   WG co-chair).  The Responsible Area Director is Tim Polk (Security
   Area Director).


From julienl@qualcomm.com  Mon Aug 17 11:27:35 2009
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 1B26B3A6A0E for <btns@core3.amsl.com>; Mon, 17 Aug 2009 11:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.67
X-Spam-Level: 
X-Spam-Status: No, score=-105.67 tagged_above=-999 required=5 tests=[AWL=0.929, 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 SxL19rmPthOm for <btns@core3.amsl.com>; Mon, 17 Aug 2009 11:27:34 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 0C1F83A6F43 for <btns@ietf.org>; Mon, 17 Aug 2009 11:27:33 -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=1250533659; x=1282069659; h=from:to: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:=20btns=20mailing=20list=20<btns@ietf.org>|Date:=20Mo n,=2017=20Aug=202009=2011:27:35=20-0700|Subject:=20RE:=20 [btns]=20Protocol=20Action:=20'IPsec=20Channels:=20Connec tion=20Latching'=0D=0A=20to=09Proposed=20Standard |Thread-Topic:=20[btns]=20Protocol=20Action:=20'IPsec=20C hannels:=20Connection=20Latching'=0D=0A=20to=09Proposed =20Standard|Thread-Index:=20AcofZycCeBCIeRCnTtGubgMu1DJQZ QAARI1w|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C 24BE3E23@NALASEXMB04.na.qualcomm.com>|References:=20<2009 0817181833.733E73A6774@core3.amsl.com>|In-Reply-To:=20<20 090817181833.733E73A6774@core3.amsl.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-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5712"=3B=20a=3D"22216016"; bh=y/lJpYDt48+/GLQHteZDTajkJwCck2fYQ6xRmY1haok=; b=WiviXoCP2TrI0Yy2MD60dDoXZspF5vQ+zzj/yXj2PkkSjkXlywK83Gt+ kPxIWy9mgYZPAyvRGmJ+8l1jE8I728p5f+kIkL9+QfnPHsyZkv5IKi33l APTN+ot/zpq0f3RG5GQHY+vK0//rnhWTEUTnU5wycsiENc40vwC6chNdc M=;
X-IronPort-AV: E=McAfee;i="5300,2777,5712"; a="22216016"
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; 17 Aug 2009 11:27:38 -0700
Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7HIRclK002193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <btns@ietf.org>; Mon, 17 Aug 2009 11:27:38 -0700
Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7HIRchR012918 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <btns@ietf.org>; Mon, 17 Aug 2009 11:27:38 -0700
Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 17 Aug 2009 11:27:37 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 17 Aug 2009 11:27:37 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: btns mailing list <btns@ietf.org>
Date: Mon, 17 Aug 2009 11:27:35 -0700
Thread-Topic: [btns] Protocol Action: 'IPsec Channels: Connection Latching' to	Proposed Standard
Thread-Index: AcofZycCeBCIeRCnTtGubgMu1DJQZQAARI1w
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C24BE3E23@NALASEXMB04.na.qualcomm.com>
References: <20090817181833.733E73A6774@core3.amsl.com>
In-Reply-To: <20090817181833.733E73A6774@core3.amsl.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
Subject: Re: [btns] Protocol Action: 'IPsec Channels: Connection Latching' to	Proposed Standard
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: Mon, 17 Aug 2009 18:27:35 -0000

Thanks to everybody who helped made this happen!

--julien

> -----Original Message-----
>=20
> The IESG has approved the following document:
>=20
> - 'IPsec Channels: Connection Latching '
>    <draft-ietf-btns-connection-latching-11.txt> as a Proposed Standard
>=20
>=20
> This document is the product of the Better-Than-Nothing Security
> Working Group.
>=20
> The IESG contact persons are Tim Polk and Pasi Eronen.
>=20
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-
> latching-11.txt
>=20
> Technical Summary
>=20
>   This document specifies, abstractly, how to interface applications
>   and transport protocols with IPsec so as to create "channels" by
>   latching "connections" (packet flows) to certain IPsec Security
>   Association (SA) parameters for the lifetime of the connections.
>   Connection latching is layered on top of IPsec and does not modify
>   the underlying IPsec architecture.
>=20
>   Connection latching can be used to protect applications against
>   accidentally exposing live packet flows to unintended peers, whether
>   as the result of a reconfiguration of IPsec or as the result of using
>   weak peer identity to peer address associations.  Weak association of
>   peer ID and peer addresses is at the core of Better Than Nothing
>   Security (BTNS), thus connection latching can add a significant
>   measure of protection to BTNS IPsec nodes.
>=20
>   Finally, the availability of IPsec channels will make it possible to
>   use channel binding to IPsec channels.
>=20
> Working Group Summary
>=20
>    This document is a product of the Better Than Nothing Security
> (BTNS)
>    working group.
>=20
> Document Quality
>=20
>    A version of Connection Latching is implemented in OpenSolaris. The
>   document has been reviewed by Daniel McDonald who worked on the
>   Connection Latching implementation in OpenSolaris.
>=20
> Personnel
>=20
>    The Document Shepherd for this document is Julien Laganier (BTNS
>    WG co-chair).  The Responsible Area Director is Tim Polk (Security
>    Area Director).
>=20
> _______________________________________________
> btns mailing list
> btns@ietf.org
> https://www.ietf.org/mailman/listinfo/btns

From Nicolas.Williams@sun.com  Mon Aug 17 11:29:55 2009
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 43B733A6F66 for <btns@core3.amsl.com>; Mon, 17 Aug 2009 11:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.892
X-Spam-Level: 
X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.154,  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 znVCmdo9Lhpx for <btns@core3.amsl.com>; Mon, 17 Aug 2009 11:29:54 -0700 (PDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 58B773A68D8 for <btns@ietf.org>; Mon, 17 Aug 2009 11:29:49 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7HITsBD011421 for <btns@ietf.org>; Mon, 17 Aug 2009 18:29:54 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 n7HITrOb001441 for <btns@ietf.org>; Mon, 17 Aug 2009 12:29:53 -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 n7HIJBnM002990 for <btns@ietf.org>; Mon, 17 Aug 2009 13:19:11 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7HIJBwa002989 for btns@ietf.org; Mon, 17 Aug 2009 13:19:11 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 17 Aug 2009 13:19:11 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: btns mailing list <btns@ietf.org>
Message-ID: <20090817181910.GW1043@Sun.COM>
References: <20090817181833.733E73A6774@core3.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090817181833.733E73A6774@core3.amsl.com>
User-Agent: Mutt/1.5.7i
Subject: Re: [btns] Protocol Action: 'IPsec Channels: Connection Latching' to Proposed Standard
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: Mon, 17 Aug 2009 18:29:55 -0000

This I-D is, IMO, very important to the future of end-to-end IPsec, and
to future IPsec APIs.  Thanks to all who helped get it done!

Nico
--