Re: [apps-discuss] AD Fail - MPTCP API

Ned Freed <ned.freed@mrochek.com> Thu, 15 November 2012 03:19 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA3C21F8514 for <apps-discuss@ietfa.amsl.com>; Wed, 14 Nov 2012 19:19:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhktuDbNHcgR for <apps-discuss@ietfa.amsl.com>; Wed, 14 Nov 2012 19:19:55 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 29FA321F8512 for <apps-discuss@ietf.org>; Wed, 14 Nov 2012 19:19:55 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMMH6H9UVK001O0E@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 14 Nov 2012 19:14:51 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OMGB2WUMLC00008S@mauve.mrochek.com>; Wed, 14 Nov 2012 19:14:49 -0800 (PST)
Message-id: <01OMMH6GA83U00008S@mauve.mrochek.com>
Date: Wed, 14 Nov 2012 19:06:32 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 14 Nov 2012 15:48:19 -0600" <50A411A3.6060600@qti.qualcomm.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format="flowed"
References: <50A411A3.6060600@qti.qualcomm.com>
To: Pete Resnick <presnick@qti.qualcomm.com>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] AD Fail - MPTCP API
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 03:19:55 -0000

I noted this text:

   As this address may not be valid any more if the first subflow is
   closed, the MPTCP stack MAY close the whole MPTCP connection if the
   first subflow is closed (i.e. fate sharing between the initial
   subflow and the MPTCP connection as a whole).  Whether to close the
   whole MPTCP connection by default SHOULD be controlled by a local
   policy.  Further experiments are needed to investigate its
   implications.

Presumably this "local policy" would be set system-wide? If so, that's a poor
choice. Such choices need to be able to be made at a finer granularity than
this, because in many cases not all connections a system handles have the same
security considerations.

The lack of user control for things like this has rendered other protocols
a lot less useful than they might otherwise have been. 

				Ned