Re: [Spud] PLUS charter rev. 23 June

Martin Stiemerling <mls.ietf@gmail.com> Thu, 21 July 2016 15:00 UTC

Return-Path: <mls.ietf@gmail.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBE212D68A for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 08:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C-CUtvTzF2J for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 08:00:12 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09D412D67B for <spud@ietf.org>; Thu, 21 Jul 2016 08:00:11 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id f93so64451748lfi.2 for <spud@ietf.org>; Thu, 21 Jul 2016 08:00:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=/OnCfiOadxJFCTRU0qJbbh9lJyiZrjRnzi+pFNmZiYU=; b=c99SEHrXiaItQwMCqK4xjWXZKvb9qnf/2aW/nBErVgY4THHbj5BYKsZLTD4XUXTVQC yqi92rvFeMvlv8PLOjeeEr9PUDnMHLUmTZeXK/lZWb23KffeiMxMNXLxZuq9ZXg1Oyb4 2k5sEuelPDcIJ25SNqtbK31SbpHc9ZyyOyM26mUkCEINgj9UKlMEQ7LPYtInDzblDKAc p4wmGIgihp3L26dCYbRLWRzW8sunWPxVX8nOvMpjA5try2eSvSyET24lbtjz1fhqc50m eBKD4h4/mYPwN1OzQCZuxrAoiCdEKd//hJq9RqSXkMvNJXluhBfSzZJ+kTfe/gMgb5qP wXHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/OnCfiOadxJFCTRU0qJbbh9lJyiZrjRnzi+pFNmZiYU=; b=NBtserQEmVGHX3OA53WsWi/q5TWYGhNFFp2gXfRLBYu61gErVHDqL0LTS4Ygl/04wS b6FdVw0232f/pipLxsRlj5BxmevOK0pPDgCkmYqcxlC9H9/i5X7jGf8cbE4v7sVUPWbj JyIcb2ri0RdrTC7eYX6bJnjWznsadU3YFIuV8vhwD1ixHZ+CDuaBn0R1uJ6hdr/DlZcm HPV6yk6QH5kSVK2or+CNLhjwiPk5rOChihhwIoQHLWyMHBgn5OhWcJDqP87vnGUdAwJX 4sxFwiNegmbOgdWStmUnAPL4kW+34kEV1cLSkKDKlXDdCe5SR6wIUHn99yKeOAHm3uDw iZ6Q==
X-Gm-Message-State: ALyK8tIUH3vcZ1O4vav7gtzGGsdKAvypDp0bzzcsNUMcDPWtNBu0TLbGEVCsp6C/pS+xpw==
X-Received: by 10.25.163.132 with SMTP id m126mr25652570lfe.56.1469113209335; Thu, 21 Jul 2016 08:00:09 -0700 (PDT)
Received: from ?IPv6:2003:74:cf54:d255:8990:29d2:df8a:b967? (p20030006154B7555899029D2DF8AB967.dip0.t-ipconnect.de. [2003:6:154b:7555:8990:29d2:df8a:b967]) by smtp.googlemail.com with ESMTPSA id k63sm1939375lfe.48.2016.07.21.08.00.07 for <spud@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 08:00:08 -0700 (PDT)
To: spud <spud@ietf.org>
References: <32DC1941-126F-4513-801F-559617E85436@trammell.ch>
From: Martin Stiemerling <mls.ietf@gmail.com>
Message-ID: <92f8bd8e-f0d0-93ac-1e35-57c2222f7e4b@gmail.com>
Date: Thu, 21 Jul 2016 17:00:05 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <32DC1941-126F-4513-801F-559617E85436@trammell.ch>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/tKvgr-i81j-roWEdaMW8PmezAEo>
Subject: Re: [Spud] PLUS charter rev. 23 June
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2016 15:00:15 -0000

Hi all,

Here is my proposed addendum to the charter text with respect to prior 
work in the world of middlebox signalling.

This is not saying that I am endorsing any of them.
However, it is wise to check what has happened in the past in that space 
and to recoginize that signaling protocols coupled with the data path 
are a challenging topic -- still.

The proposed text (feel free to tweak it so that terminology matches):

"There are a number of protocols inside and outside to the IETF that 
deal with endpoint to network signaling, namely to talk with 
middleboxes. These protocols are, for instance, MIDCOM, PCP and NSIS. 
The PLUS WG can leverage knowdlegde out of these older activities with 
respect to endpoint to middlebox signaling."

Thanks,

   Martin



Am 23.06.16 um 11:29 schrieb Brian Trammell:
> Greetings, all,
>
> We've updated the proposed PLUS charter based on outstanding issues (Christian's comment on threat modeling and mitigations) and added a list of things we believe to be out of scope based on list discussion.
>
> New charter, as always, at https://github.com/ietf-plus/charter/blob/master/charter-plus.txt, and inline below.
>
> Cheers,
>
> Brian
>
>
> Path Layer UDP Substrate (PLUS)
> ===============================
>
> The PLUS working group's goal is to define a common shim layer atop the User
> Datagram Protocol (UDP) to provide a transport-independent method to signal
> flow semantics under transport and application control, necessary to enable
> the deployment of new, encrypted transport protocols within the existing
> Internet. UDP provides compatibility with currently deployed middleboxes as
> well as ubiquitous support in endpoints, and supports userspace implementation
> of new transport protocols. The working group will not specify any new
> transport protocols.
>
> The current Internet protocol stack does not provide explicit, in-band,
> transport-independent signaling to on-path network devices. This has led to
> the deployment of devices which perform implicit discovery of transport
> semantics and traffic characteristics via inspection of protocol headers and
> payload, a practice made possible when these are sent in the clear.
>
> In order to support more ubiquitous deployment of encryption, and the
> encryption of transport headers to allow deployment of new transport
> protocols, explicit in-band signaling must be added to the stack. This
> signaling must be transport protocol independent, and the types of information
> signaled must be based on characteristics that can be independently verified
> by devices on path, or that can be usefully applied without requiring a trust
> relationship between endpoints and the path. Further, a feedback channel that
> provides information from on-path devices back to endpoints and applications,
> e.g. for error handling, is essential for the deployment and success of an
> explicit cooperation approach.
>
> While IP would seem to be the natural home for this facility, both IPv4 and
> IPv6 options and extensions have deployment problems on their own, which makes
> it hard to include any additional information in these protocols.
>
> The PLUS working group will specify a new protocol as a Path Layer
> UDP Substrate (PLUS), to support experimental deployment of
> explicit cooperation between endpoints and devices on path, with the following goals:
>
> - enable ubiquitous deployment of encrypted higher layer protocols
>   by providing exposure of basic TCP-like semantics (e.g. SYN, FIN,
>   RST flags) to devices on path (e.g. NATs and firewalls).
>
> - allow applications and transport protocols to explicitly provide
>   limited information with integrity protection to devices on path
>
> - allow devices on path to provide unencrypted feedback and information
>   about the path directly to sending endpoints, under sending endpoint
>   control
>
> - allow devices on path to provide unencrypted information about the
>   path to receiving endpoints, with encrypted feedback to the
>   sending endpoint, under sending endpoint control
>
> This approach explicitly gives the control of information exposure back the
> application and/or transport layer protocol on the end host. It is the goal of
> PLUS to minimize the information exposed, to make information exposure
> transparent, and to limit the level of detail to that useful for network
> treatment, while encrypting everything else. Endpoint verification of
> signaling integrity, careful design of minimal data structures, and
> restrictive policies for registration of signals can help to meet this goal.
> This is important to avoid future implicit treatment and resulting
> ossification, as well as to minimize the privacy risks presented by explicit
> cooperation.
>
> Given that the primary goal of PLUS is to enable the deployment of transport
> protocols with encrypted headers, we assume that the higher-layer protocol can
> provide an encryption context that can be used by PLUS to provide
> authentication, integrity, and encryption where needed. The primary threat
> model to defend against will be modification or deletion of exposed
> information by middleboxes and other devices on path, by allowing a remote
> endpoint to detect modifications.
>
> The working group will start with an initial set of use cases (see draft-
> kuehlewind-spud-use-cases) and requirements (see draft-trammell-spud-req),
> taken from experience with the Substrate Protocol for User Datagrams (SPUD)
> prototype. The working group's main output will be an experimental protocol
> specification, together with an initial registry of types of information that
> can be exposed using PLUS, clearly aligned to the use cases determined by the
> working group. This specification will consider potential attacks against the
> protocol, both arising from the encapsulation chosen as well as new attacks
> made possible by the protocol, and propose mitigations for these attacks.
>
> The working group will close if it is not able to come to consensus on a
> protocol design to meet these requirements.
>
> The working group will additionally aim to identify and work with other
> working groups that could address parts of these requirements within existing
> protocols, e.g. by specifying new protocol extensions, or as input for on-
> going standardization work. It will aim to work with working groups defining
> encryption protocols (e.g. DTLS) which could be used for encryption of
> transport protocols running over PLUS.
>
> Out of scope for the working group are:
>
> - The design and specification of new transport protocols running over PLUS.
> - Mechanisms for signaling among multiple devices on path between two endpoints
> - Mechanisms for key exchange or cryptographic context establishment between endpoints and devices on path
>
>
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>