Re: [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:56 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 D90FD12D755 for <spud@ietfa.amsl.com>; Thu, 28 Jul 2016 08:56:58 -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 FAFxlVfvw384 for <spud@ietfa.amsl.com>; Thu, 28 Jul 2016 08:56:56 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 3C00412D0DC for <spud@ietf.org>; Thu, 28 Jul 2016 08:56:56 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id q83so104027015iod.1 for <spud@ietf.org>; Thu, 28 Jul 2016 08:56:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nU09KPfypBW3/7E/CAdiZIBHJ1engxn+iX4FclcxXow=; b=S/fljSkHximpRcM2zxwx2qQZ4gJ/rYK2Y95KzReT9n38RJbLP0CJ3ZrpotxTq1uLrY zg47rD4+ExuSOPqwpW7hzBxGGZd+WmdJIE6p483dAIboFlmUPXbOrSF9/m6IDcJE2OQ5 baJNpSZ5zIWV8IBij+H7weBXp3SVUi2AfMTm8mLXgCepJiMUC3XPTUgo8quFlDU+A9vK 4vva50+DeKe44DwSe6eSjgPMfg4ZLgNAM+R5TiIedzWTR8G1q2FtdqBmfm895MtVWi6Z 4Y0I7ULyI7x0JGPIa6x2wBejJj8zFY0dijcVBztOnBYtY+unpvdiEGSUiwAo5gcmZXyY Pj3w==
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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nU09KPfypBW3/7E/CAdiZIBHJ1engxn+iX4FclcxXow=; b=FPVWDT41HL+M41IfWVnMYmh0yju4UcxTKqy9s3Bw9AZ68w4Q4j4wm+6sIbLGFUVFCW o65ZzXwiGbvbMhZzXSO1ZKrBS+mebfWymZc9DESeySlMe+8Gfy8w19L4utPf6SWn/I2O wFvJQEJAmyAgMRfwwDwlSRvyQn1e72CL6gf7sOf4Eb+HKbGu1NWL0diJKyvCKYYIvmOW ZqJzkI99pKBBFkxo4jytDROl/bngthIjs0chf1bDkHYB2DPD5NXa6pzP8EdOz+DA1qNj AiSLhF8om7LOxLshplgcq+fBhk6oMZcnlepVWLkPo+hXVVP48Hf8qVepUsvlB1OkwZbO aYoA==
X-Gm-Message-State: AEkoouvivkAXSL63vOJxNuZRbzTEbPyfeAkwAILLrJo/hZQJGuqdWBzcJjZhwqys4Q6JQSTLNMjA0fuHaCtM9g==
X-Received: by 10.107.44.66 with SMTP id s63mr39563161ios.186.1469721415531; Thu, 28 Jul 2016 08:56:55 -0700 (PDT)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 10.107.137.69 with HTTP; Thu, 28 Jul 2016 08:56:54 -0700 (PDT)
In-Reply-To: <E8355113905631478EFF04F5AA706E9831045CD8@wtl-exchp-2.sandvine.com>
References: <CAKC-DJjVF_mQb49BJmHNpt-VkJSX6JHXH8hTbYMm2bEYg3rgwA@mail.gmail.com> <E8355113905631478EFF04F5AA706E9831045CD8@wtl-exchp-2.sandvine.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Thu, 28 Jul 2016 11:56:54 -0400
X-Google-Sender-Auth: QCmcqNotmA6bcQkN4L8tECNFHwc
Message-ID: <CAKC-DJiKynAhrodZLvvGB62u19TTxr5BxT6RkS8OOOUAurWcZA@mail.gmail.com>
To: Dave Dolson <ddolson@sandvine.com>
Content-Type: multipart/alternative; boundary=001a11393e16e445c30538b42e1f
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/4dAdiF5XKfSzEKyS-MG_cIRBx_0>
Cc: Kyle Rose <krose@krose.org>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [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:56:59 -0000

This is exactly the sort of thing that I think demonstrates the value of
defining something here so we can have one mechanism that a bunch of UDP
protocols can use to allow for several minute state timeouts.

With TCP you need the sequence/ack numbers to get enough entropy due to the
port number being only 16 bits.  If the connection-id is 64 bits (or there
are two 64-bit connection-ids in the packet, one contributed by each
end-point) does this contribute enough entropy to prevent passive adversary
close/reset attacks?  It seems like active adversary close/reset attacks
aren't possible to reliably defend against (without crypto between middle
boxes and endpoint).

A pattern that has been discussed that seems quite valuable would be to
distribute additional connection-ids for mobility and resumption within the
encrypted channel.  This would allow for resumption, mobility, and
periodically cranking the connection-id without linkability.

Having a server-contributed component of the connection-id (perhaps an
initial one in clear-text and later ones through the encrypted channel)
could allow for stateless packet distribution by server-side load balancers
and could also form part of a proof-of-address-ownership
three-way-handshake mechanism to mitigate against DDoS reflection and
spoofed source address attacks.

      Erik



On Thu, Jul 28, 2016 at 11:23 AM, Dave Dolson <ddolson@sandvine.com> wrote:

> Regarding the state kept by middle-boxes such as firewalls:
>
> The timeout should be short (a few seconds) until a three-way handshake is
> complete. This is required to defend against attacks on state memory of the
> firewall.
>
>
>
> In the three-way handshake:
>
> - The server’s SYN-ACK indicates the server is real and willing to talk to
> the client.
>
> - the client’s ACK of the server’s SYN-ACK provides evidence the client is
> real (vs. spoofed) and has witnessed the SYN-ACK
>
>
>
> The random sequence numbers and ack numbers are valuable in this regard.
> E.g., a spoofing device cannot simply send the first and third packets
> because the third packet must correctly ACK the second packet from the
> server.
>
>
>
> Once a three-way handshake is witnessed, TCP state timeout can be several
> minutes.
>
>
>
> The proposal below doesn’t seem to contain enough information for a
> firewall to know the client is real.
>
> Consider adding a random number that each side can echo back? Perhaps a
> different connection-ID per direction?
>
>
>
> -Dave
>
>
>
>
>
>
>
> *From:* Spud [mailto:spud-bounces@ietf.org] *On Behalf Of *Erik Nygren
> *Sent:* Thursday, July 28, 2016 11:03 AM
> *To:* Mirja Kühlewind
> *Cc:* Kyle Rose; spud@ietf.org
> *Subject:* [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy
> concerns expressed at the BoF)
>
>
>
> 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
>
>
>
>
>