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

Erik Nygren <> Thu, 28 July 2016 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D90FD12D755 for <>; Thu, 28 Jul 2016 08:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FAFxlVfvw384 for <>; Thu, 28 Jul 2016 08:56:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C00412D0DC for <>; Thu, 28 Jul 2016 08:56:56 -0700 (PDT)
Received: by with SMTP id q83so104027015iod.1 for <>; Thu, 28 Jul 2016 08:56:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id s63mr39563161ios.186.1469721415531; Thu, 28 Jul 2016 08:56:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 28 Jul 2016 08:56:54 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Erik Nygren <>
Date: Thu, 28 Jul 2016 11:56:54 -0400
X-Google-Sender-Auth: QCmcqNotmA6bcQkN4L8tECNFHwc
Message-ID: <>
To: Dave Dolson <>
Content-Type: multipart/alternative; boundary=001a11393e16e445c30538b42e1f
Archived-At: <>
Cc: Kyle Rose <>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>, "" <>
Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


On Thu, Jul 28, 2016 at 11:23 AM, Dave Dolson <> 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 [] *On Behalf Of *Erik Nygren
> *Sent:* Thursday, July 28, 2016 11:03 AM
> *To:* Mirja Kühlewind
> *Cc:* Kyle Rose;
> *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 <
>> 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:
> 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