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

"Mike Eisler" <mre-ietf@eisler.com> Mon, 20 July 2009 18:01 UTC

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 BA86B3A6BD5 for <btns@core3.amsl.com>; 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 <btns@core3.amsl.com>; 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 <btns@ietf.org>; 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: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com> <26232.1247424864@marajade.sandelman.ca>
Date: Mon, 20 Jul 2009 11:00:59 -0700
From: "Mike Eisler" <mre-ietf@eisler.com>
To: "Michael Richardson" <mcr@sandelman.ottawa.on.ca>
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 <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, 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 <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.

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/