From mre-ietf@eisler.com Wed Jul 1 17:36:48 2009 Return-Path: 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 C48CD28C0D8 for ; Wed, 1 Jul 2009 17:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 wPme4bb-TMWE for ; Wed, 1 Jul 2009 17:36:47 -0700 (PDT) Received: from webmail5.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) by core3.amsl.com (Postfix) with ESMTP id 9A7993A6811 for ; Wed, 1 Jul 2009 17:36:47 -0700 (PDT) Received: from webmail.eisler.com (localhost [127.0.0.1]) by webmail5.dreamhost.com (Postfix) with ESMTP id F38655B70B; Wed, 1 Jul 2009 17:37:09 -0700 (PDT) Received: from 75.70.132.213 (proxying for 75.70.132.213) (SquirrelMail authenticated user mre-ietf@eisler.com) by webmail.eisler.com with HTTP; Wed, 1 Jul 2009 17:37:10 -0700 Message-ID: Date: Wed, 1 Jul 2009 17:37:10 -0700 From: "Mike Eisler" To: btns@ietf.org, lars.eggert@nokia.com User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 00:36:48 -0000 Note: This is my first email to this list. The catalyst for this email was that several documents that I'm authoring indirectly depend on draft-ietf-btns-connection-latching moving forward ... > The last DISCUSS on draft-ietf-btns-connection-latching-10 > concerns what the WG thinks is the best way for ULPs to > handle connection latch transitions to the BROKEN state in > the _absence_ of connection latching APIs for applications > (or when apps are not aware of such APIs). Isn't this DISCUSS specific to SCTP? Russ writes in the DISCUSS: I am unsure that the SCTP section defines behavior which is consistent with application expectations. The last paragraph of 5.4 implies that the whole connection terminates if one of the latches breaks. This has an impact on the semantics of the application socket API. While connection latching is transparent when everything is working, there are new failures that ripple to the application. That is, the application will observe different behavior on a connection with and without latching. My conclusion is that the API ought to provide information for the application about the connection latching, and it just does not seem to be there. If you can point me to a discussion of this topic on the WG mail list, then I'll clear. I'm not trying to alter consensus, but I do want to make sure that this topic was considered. ====================== The laat paragraph of section 5.4 says: "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." Note the inconsistency between what Russ wrote in his DISCUSS: "The last paragraph of 5.4 implies that the whole connection terminates if one of the latches breaks." and this excerpt from the last paragraph of section 5.4: "When a connection latch transitions to the BROKEN state and the application requested (or system policy dictates it) that the connection be broken," So actually the last paragraph is unequivocal: the connection does terminate if two conditions are met: - the latch goes to BROKEN - the app or policy has previously dictated that a latch break produces a connection break. Earlier in Section 5.4, two alternatives to mapping latches to multi-homed SCTP connections: "We can represent the multiplicity of SCTP association end-point addresses as a multiplicity of 5-tuples, each of which with its own a connection latch. Alternatively we can extend the connection latch object to support a multiplicity of addresses for each end-point. The first approach is used throughout this document, therefore we will assume that representation." Perhaps the second approach is what should be used for SCTP. However, as the last sentence above notes, the first approach is used in the rest of the document. I gather what Russ is saying is that approach might not be appropriate for SCTP and he wants to know if the WG thoroughly considered it. In the event the WG did not thoroughly consider the implications of multi-homed SCTP connections and latching, here is a pragmatic suggestion: - remove the SCTP discussion from the I-D. Most this means removing section 5.4, but there are a couple sentences that mention SCTP that would also need to be removed. - if there is sufficient interest in SCTP and connection latching, channel binding, etc., then start a new work item to deal with the issue of connection latching with multi-homed connection-oriented transports. ------------------------------------------------------- Nico wrote: * From: Nicolas Williams * To: btns at ietf.org * Date: Wed, 24 Jun 2009 15:17:07 -0500 The last DISCUSS on draft-ietf-btns-connection-latching-10 concerns what the WG thinks is the best way for ULPs to handle connection latch transitions to the BROKEN state in the _absence_ of connection latching APIs for applications (or when apps are not aware of such APIs). The two options are: a) The ULP MAY/SHOULD/MUST pretend that the equivalent of a TCP reset occurred and the connection latch is transition to the CLOSED state (and destroyed/cleaned up); b) The ULP MAY/SHOULD/MUST act as though bits aren't moving and let ULP and/or application-layer timeout processing decide if and when to close the connection (and underlying connection latch). (b) means potentially hanging forever, but that's generally true now with existing ULPs. The I-D says (b), with "SHOULD". I'd be just as happy with (a), SHOULD, (b) MAY. I would not be happy with (a), MUST, nor with (b), MUST. Comments? Nico -- -- Mike Eisler, Senior Technical Director, NetApp, 719 599 9026, http://blogs.netapp.com/eislers_nfs_blog/ -- Mike Eisler, Senior Technical Director, NetApp, 719 599 9026, http://blogs.netapp.com/eislers_nfs_blog/ From mcr@marajade.sandelman.ca Sun Jul 12 16:15:46 2009 Return-Path: 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 395993A67FF for ; Sun, 12 Jul 2009 16:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, MANGLED_TEXT=2.3] 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 xIvq3MHdh1bu for ; Sun, 12 Jul 2009 16:15:45 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 42D1B3A65A5 for ; Sun, 12 Jul 2009 16:15:43 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 974F534254; Sun, 12 Jul 2009 23:16:13 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 62FDE3EC3; Sun, 12 Jul 2009 14:54:24 -0400 (EDT) From: Michael Richardson To: "Mike Eisler" In-Reply-To: References: 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: Sun, 12 Jul 2009 14:54:24 -0400 Message-ID: <26232.1247424864@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: btns@ietf.org, lars.eggert@nokia.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 23:15:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Mike" =3D=3D Mike Eisler writes: >> The last DISCUSS on draft-ietf-btns-connection-latching-10 >> concerns what the WG thinks is the best way for ULPs to handle >> connection latch transitions to the BROKEN state in the _absence_ >> of connection latching APIs for applications (or when apps are >> not aware of such APIs). Mike> Isn't this DISCUSS specific to SCTP?=20 I don't think so.=20 I think it's just that SCTP tries to get around other network connection failures by switching to working end-points, while TCP and UDP do not, so those applications are already more suspectible to network failures. (First, if you are using channel binding, then you have to be aware of it, so it is possible that we haven't thought through the non-channel binding case well enough) Mike> I am unsure that the SCTP section defines behavior which is Mike> consistent with application expectations. The last paragraph Mike> of 5.4 implies that the whole connection terminates if one of Mike> the latches breaks. This has an impact on the semantics of Mike> the application socket API. While connection latching is Mike> transparent when everything is working, there are new failures Mike> that ripple to the application. That is, the application will Mike> observe different behavior on a connection with and without Mike> latching. I agree that this is the case for SCTP. For TCP, it looks like a normal network failure, do you agree? I think that how the latch breaks when the SA breaks depends upon whether there are in fact multiple SAs, (the simple NxM approach), or if the connection latch object is represented as a the N+M object, with underlying SAs negotiated as needed. Mike> Perhaps the second approach is what should be used for Mike> SCTP. However, as the last sentence above notes, the first Mike> approach is used in the rest of the document. I gather what Mike> Russ is saying is that approach might not be appropriate for Mike> SCTP and he wants to know if the WG thoroughly considered it. I think that we did not consider it enough. Nico> a) The ULP MAY/SHOULD/MUST pretend that the equivalent of a Nico> TCP reset occurred and the connection latch is transition to Nico> the CLOSED state (and destroyed/cleaned up); Nico> b) The ULP MAY/SHOULD/MUST act as though bits aren't moving Nico> and let ULP and/or application-layer timeout processing decide Nico> if and when to close the connection (and underlying connection Nico> latch). Nico> (b) means potentially hanging forever, but that's generally Nico> true now with existing ULPs. Nico> The I-D says (b), with "SHOULD". Nico> I'd be just as happy with (a), SHOULD, (b) MAY. I would not Nico> be happy with (a), MUST, nor with (b), MUST. Nico> Comments? Tell me why the connection latch broke? I do not like layers that kill connections unlaterally because *they* think they know what my application's timeout is.=20=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")= ; [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSloxWICLcPvd0N1lAQJ85Qf+MyRCh4x7Rt/EDvqh4haa2jaVqGnadnOA I3K2CbROKibly3QgRa6wN51nKWuPWyFcs1/dk8PzjRa6L/wnSL505cFTu30tVJ2j 89B1ykdodfXfTmyxR3j0rMysP13dHaiL+CizZiu/B9w/chhExYSuE/Jyw7SHy0uH jbBJV2lXHRgD8dWYQ1qey+fLmjwp/HhVtZm4+epMhlsECsFIGmZktkiW9UjeTakh 6rXJmmaF7lNAzq4eGJTKjNSQQSy+bq+b1UOR0sYJguNC0W8yH5xX/g3/lBLPxVH9 yb+3X+6dUsW8zRXgJ9w7gSAhbJ0FvN7VxInZ9vzCkt97eLk7I37QnA=3D=3D =3DY4Mx -----END PGP SIGNATURE----- From mre-ietf@eisler.com Mon Jul 20 11:01:47 2009 Return-Path: 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 BA86B3A6BD5 for ; Mon, 20 Jul 2009 11:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MANGLED_TEXT=2.3] 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 8EWJBbeAGb7N for ; Mon, 20 Jul 2009 11:01:39 -0700 (PDT) Received: from webmail4.sd.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) by core3.amsl.com (Postfix) with ESMTP id D76753A6A78 for ; Mon, 20 Jul 2009 11:01:39 -0700 (PDT) Received: from webmail.eisler.com (localhost [127.0.0.1]) by webmail4.sd.dreamhost.com (Postfix) with ESMTP id 153973024C; Mon, 20 Jul 2009 11:00:59 -0700 (PDT) Received: from 198.95.226.230 (proxying for 198.95.226.230) (SquirrelMail authenticated user mre-ietf@eisler.com) by webmail.eisler.com with HTTP; Mon, 20 Jul 2009 11:00:59 -0700 Message-ID: <560cfa55891f0b72ce284f1454fa5d50.squirrel@webmail.eisler.com> In-Reply-To: <26232.1247424864@marajade.sandelman.ca> References: <26232.1247424864@marajade.sandelman.ca> Date: Mon, 20 Jul 2009 11:00:59 -0700 From: "Mike Eisler" To: "Michael Richardson" 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, lars.eggert@nokia.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 18:01:47 -0000 On Sun, July 12, 2009 11:54 am, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Mike" == Mike Eisler writes: > >> The last DISCUSS on draft-ietf-btns-connection-latching-10 > >> concerns what the WG thinks is the best way for ULPs to handle > >> connection latch transitions to the BROKEN state in the _absence_ > >> of connection latching APIs for applications (or when apps are > >> not aware of such APIs). > > Mike> Isn't this DISCUSS specific to SCTP? > > I don't think so. > I think it's just that SCTP tries to get around other network > connection failures by switching to working end-points, while TCP and > UDP do not, so those applications are already more suspectible to > network failures. My point was that because SCTP gets around connection drops, and TCP doesn't, the issue is specific to TCP. Apps that use TCP are used to TCP dropping connections. Apps that use SCTP are not used a total failure because of the "get around" behavior of SCTP. > (First, if you are using channel binding, then you have to be aware of > it, so it is possible that we haven't thought through the non-channel > binding case well enough) > > Mike> I am unsure that the SCTP section defines behavior which is > Mike> consistent with application expectations. The last paragraph > Mike> of 5.4 implies that the whole connection terminates if one of > Mike> the latches breaks. This has an impact on the semantics of > Mike> the application socket API. While connection latching is > Mike> transparent when everything is working, there are new failures > Mike> that ripple to the application. That is, the application will > Mike> observe different behavior on a connection with and without > Mike> latching. Note that above is the content of the IESG DISCUSS from Russ. > > I agree that this is the case for SCTP. > For TCP, it looks like a normal network failure, do you agree? I agree. Hence the DISCUSS looks specific to SCTP to me. > > I think that how the latch breaks when the SA breaks depends upon > whether there are in fact multiple SAs, (the simple NxM approach), or if > the connection latch object is represented as a the N+M object, with > underlying SAs negotiated as needed. > > Mike> Perhaps the second approach is what should be used for > Mike> SCTP. However, as the last sentence above notes, the first > Mike> approach is used in the rest of the document. I gather what > Mike> Russ is saying is that approach might not be appropriate for > Mike> SCTP and he wants to know if the WG thoroughly considered it. > > I think that we did not consider it enough. Fair enough. So given that, perhaps connection latching for SCTP should be deferred to another work item? > > Nico> a) The ULP MAY/SHOULD/MUST pretend that the equivalent of a > Nico> TCP reset occurred and the connection latch is transition to > Nico> the CLOSED state (and destroyed/cleaned up); > > Nico> b) The ULP MAY/SHOULD/MUST act as though bits aren't moving > Nico> and let ULP and/or application-layer timeout processing decide > Nico> if and when to close the connection (and underlying connection > Nico> latch). > > Nico> (b) means potentially hanging forever, but that's generally > Nico> true now with existing ULPs. > > Nico> The I-D says (b), with "SHOULD". > > Nico> I'd be just as happy with (a), SHOULD, (b) MAY. I would not > Nico> be happy with (a), MUST, nor with (b), MUST. > > Nico> Comments? > > Tell me why the connection latch broke? > > I do not like layers that kill connections unlaterally because *they* > think they know what my application's timeout is. > > - -- > ] 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 > > iQEVAwUBSloxWICLcPvd0N1lAQJ85Qf+MyRCh4x7Rt/EDvqh4haa2jaVqGnadnOA > I3K2CbROKibly3QgRa6wN51nKWuPWyFcs1/dk8PzjRa6L/wnSL505cFTu30tVJ2j > 89B1ykdodfXfTmyxR3j0rMysP13dHaiL+CizZiu/B9w/chhExYSuE/Jyw7SHy0uH > jbBJV2lXHRgD8dWYQ1qey+fLmjwp/HhVtZm4+epMhlsECsFIGmZktkiW9UjeTakh > 6rXJmmaF7lNAzq4eGJTKjNSQQSy+bq+b1UOR0sYJguNC0W8yH5xX/g3/lBLPxVH9 > yb+3X+6dUsW8zRXgJ9w7gSAhbJ0FvN7VxInZ9vzCkt97eLk7I37QnA== > =Y4Mx > -----END PGP SIGNATURE----- > -- Mike Eisler, Senior Technical Director, NetApp, 719 599 9026, http://blogs.netapp.com/eislers_nfs_blog/ From julien.laganier.ietf@googlemail.com Mon Jul 20 12:04:07 2009 Return-Path: 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 1D8273A6A74 for ; Mon, 20 Jul 2009 12:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 vxbxlH2MiKwU for ; Mon, 20 Jul 2009 12:04:06 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 617D628C233 for ; Mon, 20 Jul 2009 12:03:58 -0700 (PDT) Received: by fxm18 with SMTP id 18so2170480fxm.37 for ; Mon, 20 Jul 2009 12:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A/O79gSn8VS/c6qPDNsCbZvuI/W6BvUHpdYGBkuTkCE=; b=wX0hOC3T0uVw5VKAb3CNIyxuWruQJYUIC+m/aIH48FPGVaBhvU2BndHOZnGhuyFE6k y2hWTBpBxxAF0ULChiZS77u5rkfKY6Vr/regskrjCxE2jnnZYBxMwGg3nB+X3moo77km iPV4mTJwG560iv1CplOQHcEvdVxb7ZMMojs6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UuAWMRJh6T4kJd6SAKBmm/7PqC/8PwYszS0E+Z3ueikkPFs8VRBFVOjkE/u+8FoPnw OUlvEtaE+anJGA2OsL3s7BXmMDqoA2gdQ+a3e1qF4D/Rc53k2v7zje7Qymz9aFQJoBol F91BhgNQ84dNdp3tcITS0eTs3V9OblTSKnhk0= MIME-Version: 1.0 Received: by 10.204.117.203 with SMTP id s11mr4424585bkq.153.1248116633899; Mon, 20 Jul 2009 12:03:53 -0700 (PDT) In-Reply-To: <560cfa55891f0b72ce284f1454fa5d50.squirrel@webmail.eisler.com> References: <26232.1247424864@marajade.sandelman.ca> <560cfa55891f0b72ce284f1454fa5d50.squirrel@webmail.eisler.com> Date: Mon, 20 Jul 2009 12:03:53 -0700 Message-ID: <7ad6d6db0907201203y12cc245al767b1cc9114ea618@mail.gmail.com> From: Julien Laganier To: Mike Eisler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: btns@ietf.org, lars.eggert@nokia.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 19:04:07 -0000 Hello, On Mon, Jul 20, 2009 at 11:00 AM, Mike Eisler wrote: > > On Sun, July 12, 2009 11:54 am, Michael Richardson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >>>>>>> "Mike" =3D=3D Mike Eisler writes: >> =A0 =A0 >> The last DISCUSS on draft-ietf-btns-connection-latching-10 >> =A0 =A0 >> concerns what the WG thinks is the best way for ULPs to handl= e >> =A0 =A0 >> connection latch transitions to the BROKEN state in the _abse= nce_ >> =A0 =A0 >> of connection latching APIs for applications (or when apps ar= e >> =A0 =A0 >> not aware of such APIs). >> >> =A0 =A0 Mike> Isn't this DISCUSS specific to SCTP? >> >> =A0 I don't think so. >> =A0 I think it's just that SCTP tries to get around other network >> connection failures by switching to working end-points, while TCP and >> UDP do not, so those applications are already more suspectible to >> network failures. > > My point was that because SCTP gets around connection drops, and TCP > doesn't, the issue is specific to TCP. Apps that use TCP are used > to TCP dropping connections. Apps that use SCTP are not used a total > failure because of the "get around" behavior of SCTP. > >> =A0 (First, if you are using channel binding, then you have to be aware = of >> it, so it is possible that we haven't thought through the non-channel >> binding case well enough) >> >> =A0 =A0 Mike> I am unsure that the SCTP section defines behavior which i= s >> =A0 =A0 Mike> consistent with application expectations. =A0The last para= graph >> =A0 =A0 Mike> of 5.4 implies that the whole connection terminates if one= of >> =A0 =A0 Mike> the latches breaks. =A0This has an impact on the semantics= of >> =A0 =A0 Mike> the application socket API. =A0While connection latching i= s >> =A0 =A0 Mike> transparent when everything is working, there are new fail= ures >> =A0 =A0 Mike> that ripple to the application. =A0That is, the applicatio= n will >> =A0 =A0 Mike> observe different behavior on a connection with and withou= t >> =A0 =A0 Mike> latching. > > Note that above is the content of the IESG DISCUSS from Russ. > >> >> =A0 I agree that this is the case for SCTP. >> =A0 For TCP, it looks like a normal network failure, do you agree? > > I agree. Hence the DISCUSS looks specific to SCTP to me. I think that's indeed the case. >> =A0 I think that how the latch breaks when the SA breaks depends upon >> whether there are in fact multiple SAs, (the simple NxM approach), or if >> the connection latch object is represented as a the N+M object, with >> underlying SAs negotiated as needed. >> >> =A0 =A0 Mike> Perhaps the second approach is what should be used for >> =A0 =A0 Mike> SCTP. However, as the last sentence above notes, the first >> =A0 =A0 Mike> approach is used in the rest of the document. I gather wha= t >> =A0 =A0 Mike> Russ is saying is that approach might not be appropriate f= or >> =A0 =A0 Mike> SCTP and he wants to know if the WG thoroughly considered = it. >> >> =A0 I think that we did not consider it enough. > > Fair enough. So given that, perhaps connection latching for SCTP > should be deferred to another work item? IIRC, as a result from requesting publication we were asked (during IETF LC, maybe as a TSV directorate review) to cover SCTP and not only TCP and UDP. So while we maybe didn't considered all the implications of specifying SCTP behavior, it is my understanding that not covering it is not an option on the table. --julien From mre-ietf@eisler.com Fri Jul 24 13:04:00 2009 Return-Path: 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 36E413A69C1 for ; Fri, 24 Jul 2009 13:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599] 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 8FJ6g9X9Pa+b for ; Fri, 24 Jul 2009 13:03:59 -0700 (PDT) Received: from webmail2.sd.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) by core3.amsl.com (Postfix) with ESMTP id 1B26D3A67FD for ; Fri, 24 Jul 2009 13:03:30 -0700 (PDT) Received: from webmail.eisler.com (localhost [127.0.0.1]) by webmail2.sd.dreamhost.com (Postfix) with ESMTP id 9257BDC8B4; Fri, 24 Jul 2009 13:01:55 -0700 (PDT) Received: from 83.241.234.2 (proxying for 83.241.234.2) (SquirrelMail authenticated user mre-ietf@eisler.com) by webmail.eisler.com with HTTP; Fri, 24 Jul 2009 13:01:55 -0700 Message-ID: <9c45826044715435bb0be450d87679e7.squirrel@webmail.eisler.com> In-Reply-To: <7ad6d6db0907201203y12cc245al767b1cc9114ea618@mail.gmail.com> References: <26232.1247424864@marajade.sandelman.ca> <560cfa55891f0b72ce284f1454fa5d50.squirrel@webmail.eisler.com> <7ad6d6db0907201203y12cc245al767b1cc9114ea618@mail.gmail.com> Date: Fri, 24 Jul 2009 13:01:55 -0700 From: "Mike Eisler" To: "Julien Laganier" 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, lars.eggert@nokia.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 20:04:00 -0000 Jilien, thanks for respondin. Inline ... On Mon, July 20, 2009 12:03 pm, Julien Laganier wrote: > Hello, > > On Mon, Jul 20, 2009 at 11:00 AM, Mike Eisler wrote: >> >> On Sun, July 12, 2009 11:54 am, Michael Richardson wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>>>>>>> "Mike" == Mike Eisler writes: >>>     >> The last DISCUSS on draft-ietf-btns-connection-latching-10 >>>     >> concerns what the WG thinks is the best way for ULPs to handle >>>     >> connection latch transitions to the BROKEN state in the >>> _absence_ >>>     >> of connection latching APIs for applications (or when apps are >>>     >> not aware of such APIs). >>> >>>     Mike> Isn't this DISCUSS specific to SCTP? >>> >>>   I don't think so. >>>   I think it's just that SCTP tries to get around other network >>> connection failures by switching to working end-points, while TCP and >>> UDP do not, so those applications are already more suspectible to >>> network failures. >> >> My point was that because SCTP gets around connection drops, and TCP >> doesn't, the issue is specific to TCP. Apps that use TCP are used >> to TCP dropping connections. Apps that use SCTP are not used a total >> failure because of the "get around" behavior of SCTP. >> >>>   (First, if you are using channel binding, then you have to be aware >>> of >>> it, so it is possible that we haven't thought through the non-channel >>> binding case well enough) >>> >>>     Mike> I am unsure that the SCTP section defines behavior which is >>>     Mike> consistent with application expectations.  The last paragraph >>>     Mike> of 5.4 implies that the whole connection terminates if one of >>>     Mike> the latches breaks.  This has an impact on the semantics of >>>     Mike> the application socket API.  While connection latching is >>>     Mike> transparent when everything is working, there are new >>> failures >>>     Mike> that ripple to the application.  That is, the application >>> will >>>     Mike> observe different behavior on a connection with and without >>>     Mike> latching. >> >> Note that above is the content of the IESG DISCUSS from Russ. >> >>> >>>   I agree that this is the case for SCTP. >>>   For TCP, it looks like a normal network failure, do you agree? >> >> I agree. Hence the DISCUSS looks specific to SCTP to me. > > I think that's indeed the case. > >>>   I think that how the latch breaks when the SA breaks depends upon >>> whether there are in fact multiple SAs, (the simple NxM approach), or >>> if >>> the connection latch object is represented as a the N+M object, with >>> underlying SAs negotiated as needed. >>> >>>     Mike> Perhaps the second approach is what should be used for >>>     Mike> SCTP. However, as the last sentence above notes, the first >>>     Mike> approach is used in the rest of the document. I gather what >>>     Mike> Russ is saying is that approach might not be appropriate for >>>     Mike> SCTP and he wants to know if the WG thoroughly considered it. >>> >>>   I think that we did not consider it enough. >> >> Fair enough. So given that, perhaps connection latching for SCTP >> should be deferred to another work item? > > IIRC, as a result from requesting publication we were asked (during > IETF LC, maybe as a TSV directorate review) to cover SCTP and not only > TCP and UDP. So while we maybe didn't considered all the implications > of specifying SCTP behavior, it is my understanding that not covering > it is not an option on the table. OK. So how about text (specific places to add this and wording, pending if/when we have consensus) that says: For UDP and TCP, the implementation SHOULD provide an unambiguous indication that the connection drop was due to "unlatching" the connection. For SCTP, the implementation MUST provide an unambiguous indication that the connection drop was due to "unlatching" the connection. Rationale: SCTP is a transport that is "multi-homed"; connection drops should thus be rare, and applications using SCTP will be better able to cope with a drop across all end-points with an unambiguous error indicating an unlatch. (Obviously, I am not sure if the verb to "unlatch" is the correct term here). [My responses on this threa dhave been tardy due to holiday and getting reading to go to Stockholm ... and will be boarding the plane for Stockholm in about an hour]. > > --julien > _______________________________________________ > 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 Nicolas.Williams@sun.com Sun Jul 26 15:31:29 2009 Return-Path: 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 3F4A03A683C for ; Sun, 26 Jul 2009 15:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.377 X-Spam-Level: X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[AWL=0.669, 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 WhOFHd-5R48D for ; Sun, 26 Jul 2009 15:31:28 -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 4126D3A6B87 for ; Sun, 26 Jul 2009 15:31:28 -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 n6QMVS0L009200 for ; Sun, 26 Jul 2009 22:31:28 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 n6QMVSpf037593 for ; Sun, 26 Jul 2009 16:31:28 -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 n6QMDWtQ006214; Sun, 26 Jul 2009 17:13:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6QMDVON006213; Sun, 26 Jul 2009 17:13:31 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 26 Jul 2009 17:13:31 -0500 From: Nicolas Williams To: Mike Eisler Message-ID: <20090726221331.GS1020@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: btns@ietf.org, lars.eggert@nokia.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 22:31:29 -0000 On Wed, Jul 01, 2009 at 05:37:10PM -0700, Mike Eisler wrote: > Isn't this DISCUSS specific to SCTP? Russ writes in the DISCUSS: Sortof. Russ wrote, at one point: | This is the point. I do not think that hangs until killed or | restarted should be on this menu. with respect to the default handling of latch breaks when no additional APIs are available (or used by the application). IMO it's a generic issue. My earlier opinion was that pretending that bits aren't moving is the right thing to do because applications ought to have timeout handling, if not even ULPs (think of SO_KEEPALIVE). After all, latch break is not fatal -- state transitions from BROKEN to ESTABLISHED are allowed. But reasonable people can disagree about that. A latch break is likely to be permanent in practice, and in any case, acting as though the connection has been reset (as in valid RST received) is no more or less harmful than acting as though bits aren't moving. Also, a latch break may be indicative of an attack, and so resetting the connection may be a better action[*]. To a reply along those likes Russ wrote back: | I'm happy with a SHOULD statement that the WG agrees is appropriate | to handle the situation gracefully. This thread is all about obtaining WG consensus on this issue, so we can clear this DISCUSS. All we need is consensus. I'll be happy with either possible default behavior on the face of latch breaks: act as if the connection was reset, or act as if bits aren't moving. I'd also be happy to require that implementors pick and implement one of those two, without us giving a recommendation. After all, neither default affects interoperability, so why should we recommend or require one or the other? > I am unsure that the SCTP section defines behavior which is consistent > with application expectations. The last paragraph of 5.4 implies that > the whole connection terminates if one of the latches breaks. This > has an impact on the semantics of the application socket API. While > connection latching is transparent when everything is working, there > are new failures that ripple to the application. That is, the > application will observe different behavior on a connection with and > without latching. Surely SCTP, and any connection-oriented ULP, must have a way to reset connections, just like TCP does. A latch break causing a connection reset would not be new behavior as far as applications go. > My conclusion is that the API ought to provide information for the > application about the connection latching, and it just does not seem > to be there. If you can point me to a discussion of this topic on the > WG mail list, then I'll clear. I'm not trying to alter consensus, but > I do want to make sure that this topic was considered. APIs are nice, but existing apps won't use them until updated, and anyways, connection latching adds value even without adding APIs, which means we need a default response to latch breaks in the absence of new APIs (either because not implemented or not used). [*] Or not -- if the app is not doing authentication at all and the user is not doing leap-of-faith, then resetting the connection would be bad. But then, the user can always interrupt the application and try again. Nico -- From mcr@marajade.sandelman.ca Mon Jul 27 09:59:20 2009 Return-Path: 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 3250E3A681D for ; Mon, 27 Jul 2009 09:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[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 CZ6eVOlU8dUn for ; Mon, 27 Jul 2009 09:59:19 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 699D728C31A for ; Mon, 27 Jul 2009 09:59:02 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 0229334263; Mon, 27 Jul 2009 16:59:02 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id B85333EC5; Mon, 27 Jul 2009 12:59:01 -0400 (EDT) From: Michael Richardson To: "Mike Eisler" In-Reply-To: <9c45826044715435bb0be450d87679e7.squirrel@webmail.eisler.com> References: <26232.1247424864@marajade.sandelman.ca> <560cfa55891f0b72ce284f1454fa5d50.squirrel@webmail.eisler.com> <7ad6d6db0907201203y12cc245al767b1cc9114ea618@mail.gmail.com> <9c45826044715435bb0be450d87679e7.squirrel@webmail.eisler.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: Mon, 27 Jul 2009 12:59:01 -0400 Message-ID: <9303.1248713941@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: btns@ietf.org, lars.eggert@nokia.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:59:20 -0000 >>>>> "Mike" =3D=3D Mike Eisler writes: Mike> So how about text (specific places to add this and wording, Mike> pending if/when we have consensus) that says: Mike> For UDP and TCP, the implementation SHOULD provide an Mike> unambiguous indication that the connection drop was due to Mike> "unlatching" the connection. Mike> For SCTP, the implementation MUST provide an unambiguous Mike> indication that the connection drop was due to "unlatching" Mike> the connection. Rationale: SCTP is a transport that is Mike> "multi-homed"; connection drops should thus be rare, and Mike> applications using SCTP will be better able to cope with a Mike> drop across all end-points with an unambiguous error Mike> indicating an unlatch. So, if my stack said EUNLATCHED instead of ETIMEOUT, you'd be happy? (Of course, if you unplug all the "cables" to any ULP, and there is some kind of make-dead process in the ULP, then you get ETIMEOUT eventually, regardless of any wizardry that SCTP provides...) --=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 mcr@marajade.sandelman.ca Mon Jul 27 10:01:24 2009 Return-Path: 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 6983928C245 for ; Mon, 27 Jul 2009 10:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[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 67Os2Ce6KH5L for ; Mon, 27 Jul 2009 10:01:23 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B0F2228C2F8 for ; Mon, 27 Jul 2009 10:01:23 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 030B634263; Mon, 27 Jul 2009 17:01:24 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id EFAC23EC5; Mon, 27 Jul 2009 13:01:23 -0400 (EDT) From: Michael Richardson To: Nicolas Williams In-Reply-To: <20090726221331.GS1020@Sun.COM> References: <20090726221331.GS1020@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: Mon, 27 Jul 2009 13:01:23 -0400 Message-ID: <9481.1248714083@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: btns@ietf.org, Mike Eisler , lars.eggert@nokia.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:01:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Nicolas" =3D=3D Nicolas Williams writes: >> My conclusion is that the API ought to provide information for >> the application about the connection latching, and it just does >> not seem to be there. If you can point me to a discussion of >> this topic on the WG mail list, then I'll clear. I'm not trying >> to alter consensus, but I do want to make sure that this topic >> was considered. Nicolas> APIs are nice, but existing apps won't use them until Nicolas> updated, and anyways, connection latching adds value even Nicolas> without adding APIs, which means we need a default response Nicolas> to latch breaks in the absence of new APIs (either because Nicolas> not implemented or not used). 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 ] 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")= ; [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSm3dYoCLcPvd0N1lAQLnNQf8CNCa4TWJY5I/TvtAH4+eyLbHzyO+I/dp /l5Zcs3Ld16qhYh9OeWogBT2wCeicdx3cL1PdoyibTOfMw/PPxUSY+HKWyR78Ky5 afHA8JxRypvpLqULU7i2jCfwNJZbQi4wojPYl9oeQGAKKmwX3hsBQxKtWY5OWLh+ ExHXfZpGfvauG+LVYHMSNATJEveESpgqRXQyxUqGEChblWVFANHjX/OLJTRCZ7vQ xXhI2rGIlBOwl9ssAx4vejDR0js8vQ98RXy7XiVJhGZq6+hklOuZfmW44T4iHUNk emB7EpEWwO7MshVPRCxARIXjICaG2xnQ0XR9ZwSvbtNMsS1vCGVeVg=3D=3D =3D5max -----END PGP SIGNATURE----- From Nicolas.Williams@sun.com Mon Jul 27 11:13:11 2009 Return-Path: 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 1A65E3A6A30 for ; Mon, 27 Jul 2009 11:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.473 X-Spam-Level: X-Spam-Status: No, score=-5.473 tagged_above=-999 required=5 tests=[AWL=0.573, 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 W8D5CfnGt1oW for ; Mon, 27 Jul 2009 11:13:10 -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 CF19F3A6974 for ; Mon, 27 Jul 2009 11:13:09 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6RICZ9C013435 for ; Mon, 27 Jul 2009 18:12:35 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 n6RICZwH060257 for ; Mon, 27 Jul 2009 12:12:35 -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 n6RHsdrl006863; Mon, 27 Jul 2009 12:54:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6RHsajI006862; Mon, 27 Jul 2009 12:54:36 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 27 Jul 2009 12:54:36 -0500 From: Nicolas Williams To: Michael Richardson Message-ID: <20090727175436.GA1020@Sun.COM> References: <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9481.1248714083@marajade.sandelman.ca> User-Agent: Mutt/1.5.7i Cc: btns@ietf.org, Mike Eisler , lars.eggert@nokia.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 18:13:11 -0000 On Mon, Jul 27, 2009 at 01:01:23PM -0400, Michael Richardson wrote: > Nicolas> APIs are nice, but existing apps won't use them until > Nicolas> updated, and anyways, connection latching adds value even > Nicolas> without adding APIs, which means we need a default response > Nicolas> to latch breaks in the absence of new APIs (either because > Nicolas> not implemented or not used). > > So, errno value from write(2) is not a new API. > A new errno value should provide enough information, I think. If an API's definition has a closed set of error codes, then no. That said, I believe that's not the case for write(2) and friends. And, of course, there may be implementors for whom it's not possible to add new error codes for existing APIs, thus we must provide a recommendation or requirement for such implementors. > However, an application might know what to do with ETIMEOUT, while it > would not know what to do with EUNLATCHED or some such.... There's nothing unreasonable about returning ECONNRESET (an existing error) when the latch breaks IF the application did not use any APIs to indicate that it knows about latching. If the errno set for I/O syscalls is not a closed set then there's also nothing unreasonable about adding EUNLATCHED. Note that if a latch never breaks then the connection should never reset. So EUNLATCHED would only distinguish latch breaks from peer reboots -- not exactly Earth shaking for an application that is unaware of latching in the first place. But for apps that use new APIs distinguishing latch breaks is important. I think I/O syscalls return ETIMEDOUT when SO_KEEPALIVE is set and the connection times out. Again, distinguishing timeout from latch break in the application-is-not-using-new-APIs case doesn't seem all that important. Nico -- From mre-ietf@eisler.com Thu Jul 30 03:41:18 2009 Return-Path: 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 92E493A6857 for ; Thu, 30 Jul 2009 03:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.183, 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 ZwOsoLQ1q27x for ; Thu, 30 Jul 2009 03:41:17 -0700 (PDT) Received: from webmail6.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) by core3.amsl.com (Postfix) with ESMTP id 385773A67D7 for ; Thu, 30 Jul 2009 03:41:17 -0700 (PDT) Received: from webmail.eisler.com (localhost [127.0.0.1]) by webmail6.dreamhost.com (Postfix) with ESMTP id 8E86C60559 for ; Thu, 30 Jul 2009 03:41:18 -0700 (PDT) Received: from 216.240.24.140 (proxying for 216.240.24.140) (SquirrelMail authenticated user mre-ietf@eisler.com) by webmail.eisler.com with HTTP; Thu, 30 Jul 2009 03:41:19 -0700 Message-ID: In-Reply-To: <9481.1248714083@marajade.sandelman.ca> References: <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca> Date: Thu, 30 Jul 2009 03:41:19 -0700 From: "Mike Eisler" To: btns@ietf.org User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 10:41:18 -0000 On Mon, July 27, 2009 10:01 am, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Nicolas" == Nicolas Williams writes: > >> My conclusion is that the API ought to provide information for > >> the application about the connection latching, and it just does > >> not seem to be there. If you can point me to a discussion of > >> this topic on the WG mail list, then I'll clear. I'm not trying > >> to alter consensus, but I do want to make sure that this topic > >> was considered. > > Nicolas> APIs are nice, but existing apps won't use them until > Nicolas> updated, and anyways, connection latching adds value even > Nicolas> without adding APIs, which means we need a default response > Nicolas> to latch breaks in the absence of new APIs (either because > Nicolas> not implemented or not used). > > 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.... Isn't the application the entity that decided to enable latching? If so, the application (or its author) needs to be prepared to deal with new error indication. If not, what is the model for enabling latching? > > - -- > ] 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 > > iQEVAwUBSm3dYoCLcPvd0N1lAQLnNQf8CNCa4TWJY5I/TvtAH4+eyLbHzyO+I/dp > /l5Zcs3Ld16qhYh9OeWogBT2wCeicdx3cL1PdoyibTOfMw/PPxUSY+HKWyR78Ky5 > afHA8JxRypvpLqULU7i2jCfwNJZbQi4wojPYl9oeQGAKKmwX3hsBQxKtWY5OWLh+ > ExHXfZpGfvauG+LVYHMSNATJEveESpgqRXQyxUqGEChblWVFANHjX/OLJTRCZ7vQ > xXhI2rGIlBOwl9ssAx4vejDR0js8vQ98RXy7XiVJhGZq6+hklOuZfmW44T4iHUNk > emB7EpEWwO7MshVPRCxARIXjICaG2xnQ0XR9ZwSvbtNMsS1vCGVeVg== > =5max > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Thu Jul 30 04:30:39 2009 Return-Path: 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 16A533A67FE for ; Thu, 30 Jul 2009 04:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 5rFDpBq-RZWx for ; Thu, 30 Jul 2009 04:30:38 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 087223A6FF5 for ; Thu, 30 Jul 2009 04:30:38 -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=1248953440; x=1280489440; 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 |To:=20Mike=20Eisler=20,=20"btns@iet f.org"=20|Date:=20Thu,=2030=20Jul=202009 =2004:30:21=20-0700|Subject:=20RE:=20[btns]=20Q:=20How=20 to=20deal=20with=20connection=20latch=20breaks? |Thread-Topic:=20[btns]=20Q:=20How=20to=20deal=20with=20c onnection=20latch=20breaks?|Thread-Index:=20AcoRAkvtq3Ae/ ITzRDWwcEJJ4HpadgABmjkg|Message-ID:=20 |References:=20=0D=0A=09<20090726221331.GS1020@Sun.C OM>=09<9481.1248714083@marajade.sandelman.ca>=0D=0A=20|In-Reply-To:=20|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,5692"=3B=20a=3D"21447015"; bh=wMzDqTWWYtcIX5xfU8e08+FV1pEuz/qguTX2O3VfN9I=; b=iU2C0COYGyZE98Vdpba9Wm4eehH9u1v5GCsM/xHyg9B37YtdArpkNvl8 wVrJkfbGI1BaX5Eep8lBoh1NYEbVl7lU66vJAa3mc3y/CLNRNXUyG3qqp AESRa6c8XJ1l0juDshZaB+EjoqanabDeNcDbBySFAESXlD1H8J3CL0v5e A=; X-IronPort-AV: E=McAfee;i="5300,2777,5692"; a="21447015" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jul 2009 04:30:24 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6UBUO7f000689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Jul 2009 04:30:24 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n6UBUNj1017856 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jul 2009 04:30:23 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 30 Jul 2009 04:30:23 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 30 Jul 2009 04:30:23 -0700 From: "Laganier, Julien" To: Mike Eisler , "btns@ietf.org" Date: Thu, 30 Jul 2009 04:30:21 -0700 Thread-Topic: [btns] Q: How to deal with connection latch breaks? Thread-Index: AcoRAkvtq3Ae/ITzRDWwcEJJ4HpadgABmjkg Message-ID: References: <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca> In-Reply-To: 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] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 11:30:39 -0000 > -----Original Message----- > From: btns-bounces@ietf.org [mailto:btns-bounces@ietf.org] On Behalf Of > Mike Eisler > Sent: Thursday, July 30, 2009 3:41 AM > To: btns@ietf.org > Subject: Re: [btns] Q: How to deal with connection latch breaks? >=20 >=20 > On Mon, July 27, 2009 10:01 am, Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > >>>>>> "Nicolas" =3D=3D Nicolas Williams write= s: > > >> My conclusion is that the API ought to provide information for > > >> the application about the connection latching, and it just > does > > >> not seem to be there. If you can point me to a discussion of > > >> this topic on the WG mail list, then I'll clear. I'm not > trying > > >> to alter consensus, but I do want to make sure that this topic > > >> was considered. > > > > Nicolas> APIs are nice, but existing apps won't use them until > > Nicolas> updated, and anyways, connection latching adds value > even > > Nicolas> without adding APIs, which means we need a default > response > > Nicolas> to latch breaks in the absence of new APIs (either > because > > Nicolas> not implemented or not used). > > > > 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 > Isn't the application the entity that decided to enable latching? If > so, > the application (or its author) needs to be prepared to deal with new > error indication. >=20 > If not, what is the model for enabling latching? The current draft says " Implementations SHOULD create IPsec channels autom= atically by default when the application does not explicitly request an IPsec channel. = Implemenations MAY provide a way to disable automatic creation of connecti= on latches." Thus the application might not know what is EUNLATCHED. Would it be possible that the application gets ETIMEOUT, unless it has used= a BTNS connction latching API of some sort, in which case it presumably kn= ows about latching and can be returned an EUNLATCHED? --julien From mcr@marajade.sandelman.ca Thu Jul 30 04:36:31 2009 Return-Path: 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 7CF6F3A6C38 for ; Thu, 30 Jul 2009 04:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[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 uG1f--awxnt2 for ; Thu, 30 Jul 2009 04:36:30 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id CBA633A6BB1 for ; Thu, 30 Jul 2009 04:36:30 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 1F5213425D; Thu, 30 Jul 2009 11:36:32 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 188683EC5; Thu, 30 Jul 2009 07:36:31 -0400 (EDT) From: Michael Richardson To: "Mike Eisler" In-Reply-To: References: <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca> 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: Thu, 30 Jul 2009 07:36:31 -0400 Message-ID: <16755.1248953791@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 11:36:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Mike" =3D=3D Mike Eisler writes: >> So, errno value from write(2) is not a new API. A new errno >> value should provide enough information, I think. >>=20 >> 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. - --=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")= ; [ -----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=3D=3D =3DrlxH -----END PGP SIGNATURE-----