[Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)

Erik Nygren <erik+ietf@nygren.org> Thu, 28 July 2016 15:02 UTC

Return-Path: <nygren@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 8E3B112D5D2 for <spud@ietfa.amsl.com>; Thu, 28 Jul 2016 08:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 qR6bE7QFKiID for <spud@ietfa.amsl.com>; Thu, 28 Jul 2016 08:02:55 -0700 (PDT)
Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 7184812B042 for <spud@ietf.org>; Thu, 28 Jul 2016 08:02:55 -0700 (PDT)
Received: by mail-it0-x242.google.com with SMTP id j124so5079477ith.3 for <spud@ietf.org>; Thu, 28 Jul 2016 08:02:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=2k20kGG/j2b0HOGDLbU/ZDOvHdVyBREYiX3JaqUHp3M=; b=VjEaegV575VFZuPOWgsm2psrpvHUmhThMQ2V/fcHa9RAzvrKcxqwND4beSus9P28xX MDKLR/E0eUyhJjCLqH52DYiv3EzbpI8PkX++3vWLgrj97T5bSymYe76nzNM/4vDcadEc phVGjvKH4B1SW7JYSiiRFGd/yTyMuqmKqJ+GuiPM8q5taJsLH/k98rSIMd+/394hPZzQ UVeuJZElOaFuIpiKC7OJ2CMsph/dA6+4YSI6V24/AXNRQ6A2wtn27eyjN9INvApo0PoK Vx8LqvF7n5AB5c9IGDc1te/T1K07MEoOqsvfHTVGd0ZWK1c5aMfdkeqrqEjhwtyuTYtK iacw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=2k20kGG/j2b0HOGDLbU/ZDOvHdVyBREYiX3JaqUHp3M=; b=KNUrgEvk38FRc1fcLj/R6nHf2Nq8so8HjKHxccf9US6eh4dWYcv6ZbR5CJucfOSOEp 559Oa4O3aT1rL0wUhVuWjuShLWo0qJJuRvd40B5vhz/qsByY+byPjtPsjVkp8qVqKbWU pDLjGAS4x89d/GacfOvSpEtqXE1YJAE/rHM5s6li5+N0l9mTzOtrc9+chP0VonQfqkbF oIzzEM1coiS3Wjrpld5l1+RL3zCXJMQbqUR4A+nf+y5cnO+nlw9B8s4OKEoh0kbjmCCX ZUpxLwhNS4JPSSmm42OtYoDwqT+tQCPL6YoVtA2BWOUCdpefXiuUE6aEdBfcpDirCAT1 Xcxw==
X-Gm-Message-State: AEkoout124KVOq+dNPKWGrSOea6wSDoAwyIph799U6nePZGGwYUIwuQg64/tGzho3m+B462aor3z7Tu6j9rmKw==
X-Received: by 10.36.123.139 with SMTP id q133mr38652391itc.10.1469718174764; Thu, 28 Jul 2016 08:02:54 -0700 (PDT)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 10.107.137.69 with HTTP; Thu, 28 Jul 2016 08:02:54 -0700 (PDT)
From: Erik Nygren <erik+ietf@nygren.org>
Date: Thu, 28 Jul 2016 11:02:54 -0400
X-Google-Sender-Auth: Y79IIYOhKG7c6FDku0tVvIUuubg
Message-ID: <CAKC-DJjVF_mQb49BJmHNpt-VkJSX6JHXH8hTbYMm2bEYg3rgwA@mail.gmail.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Type: multipart/alternative; boundary=001a1147584cba40a30538b36de9
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/qilkh216kJZIzVF1mSebxUKahds>
Cc: Kyle Rose <krose@krose.org>, spud@ietf.org
Subject: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)
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, 28 Jul 2016 15:02:57 -0000

On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind <
mirja.kuehlewind@tik.ee.ethz.ch> wrote:

> As mentioned by Ted, this is actually not what we propose. The mechanism
> we propose is exposing information under endpoint control which is a very
> important point here. The endpoint has to add an option to send (or
> request) a specific bit of information (which also must be registered by
> IANA with IESG approval). This is just the same as TCP options or IP option
> headers. The only difference is that PLUS has a MAC which allows detection
> of middlebox manipulation (which is not the case for other existing
> protocols such as TCP options). This is another a very big and important
> aspect of what we propose with PLUS as our goal is to encrypt everything
> above PLUS including the TCP header and TCP options in future. Especially
> encrypting TCP option is important because TCP options provide much less
> control than what we propose with PLUS today which is a problem (especially
> as currently still unto 90% of the traffic is TCP). So I actually though we
> are on the same page here and have a common goal.
>

I'm not sure that we get enough value out of extensibility or being overly
generic here, at least for practical non-research purposes.  If there is a
tightly defined set of things allowed, we'll quickly ossify on these
anyways.  As firewall vendors will just bake in those registered by IANA
when they ship their product and then we'll be right back where we are
today with IPv6 extension headers.

I'd propose that it may make more sense to define a fixed header prefix
format that contains the right set of features needed to solve the problems
of QUIC and WebRTC (and other future UDP protocols).  Along with this, also
define a common set of requirements for protocols using this header prefix
(eg, around DDoS reflection prevention).

Having a toolkit for things like handling connection ids in a way that
support multipath mobility, stateless load-balancers, DDoS resiliance, and
which minimize linkability would also be a nice-to-have to prevent each UDP
protocol from having to come up with subtly different ways to solve this
set of problems.

For example, a bare minimum set of features might include:

* Opportunistic signalling to middle-boxes (NATs and Firewalls) for when
they can discard connection state.  Unless we want to declare that new UDP
protocols only work with IPv6 (worth seriously considering, but perhaps not
realistic yet), there just aren't enough {IPv4,port} tuples available for
NATs to support large numbers of users with large numbers of UDP
connections without having crazy-short keep-alive lifetimes.  Middle-boxes
will always need to be aware that this is best-effort (the FINs can be
dropped or lost or not sent by malicious clients, especially during
multipath transitions) but this could make life much better for
well-behaved clients and things like the existing NATs which use port
ranges per client might encourage clients to be well-behaved here on
average.

* Negotiating initial PMTU/MSS.  While clients will need to be able to
probe up/down and respond to routing changes that change the PMTU, the TCP
MSS mechanism and ability for middle boxes to decrement/clamp this value
makes a big difference in how quickly clients behind tunnels can converge
without losing round-trips or having very complicated probing.  Especially
if we want to be able to deploy jumbo-frames it will be important to have a
mechanism here.

* Sending signals in both directions that can be correlated to
connections.  Using ICMP/ICMPv6 may be a fine way to do this but having a
common prefix for connection information that can be included in the
message makes some things such as routing the messages through a
load-balancer much more viable).

* ... there may be a few others from the use-cases doc.

Having a fixed header prefix format might also make it much more viable to
implement with today's router/firewall hardware with just firmware/software
updates which might make a big difference for medium-term uptake.
It might be we can get away with something like:

   [MAGIC+VERSION] [CONNECTION_ID] [BITS_FOR_SYN_FIN]
   [MSS_DURING_NEGOTIATION_WHEN_SYN_IS_SET]
   [EXTENSION_SPACE_OSSIFICATION_MAY_NOT_PASS]

It might be reasonable to allow for some padding space for future extension
and research, but with the expectation that this will often get
dropped/filtered and thus would be something clients would need to probe
for (and is something people could find a way to do today regardless).

    Erik