Re: [btns] Q: How to deal with connection latch breaks?
Michael Richardson <mcr@sandelman.ottawa.on.ca> Sun, 12 July 2009 23:15 UTC
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 395993A67FF for <btns@core3.amsl.com>;
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
<btns@core3.amsl.com>; 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 <btns@ietf.org>;
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 <mcr@sandelman.ottawa.on.ca>
To: "Mike Eisler" <mre-ietf@eisler.com>
In-Reply-To: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com>
References: <e2cf27e98757db0c8561baadfb3ca335.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: 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
<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: Sun, 12 Jul 2009 23:15:46 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Mike" == Mike Eisler <mre-ietf@eisler.com> 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. (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. - -- ] 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-----
- [btns] Q: How to deal with connection latch break… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Julien Laganier
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Mike Eisler
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams
- Re: [btns] Q: How to deal with connection latch b… Laganier, Julien
- Re: [btns] Q: How to deal with connection latch b… Michael Richardson
- Re: [btns] Q: How to deal with connection latch b… Nicolas Williams