Re: [Spud] Thoughts on the privacy concerns expressed at the BoF

Dave Dolson <> Wed, 27 July 2016 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EC6812D8E2 for <>; Wed, 27 Jul 2016 13:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.206
X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J2kNHCURSfGV for <>; Wed, 27 Jul 2016 13:38:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BE0C12D935 for <>; Wed, 27 Jul 2016 13:31:02 -0700 (PDT)
Received: from ([fe80::68ac:f071:19ff:3455]) by ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Wed, 27 Jul 2016 16:31:01 -0400
From: Dave Dolson <>
To: Kyle Rose <>, =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <>
Thread-Topic: [Spud] Thoughts on the privacy concerns expressed at the BoF
Thread-Index: AQHR5aL1133o2aIqhUudmizaaMH5m6Ap276AgALH54CAABFdEA==
Date: Wed, 27 Jul 2016 20:31:00 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9831044800wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [Spud] 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: Wed, 27 Jul 2016 20:38:16 -0000

Kyle Rose said:
“…I became hopeful that much more information about data flows could be obscured in a PLUS-enabled internet than is possible today, perhaps even to the point of obscuring source addresses and making flows and maybe even individual packets to busy endpoints hard to correlate…”

The ability to obscure source addresses opens a huge attack surface for DDoS attacks, since there is no way to implement BCP 38 (Network Ingress Filtering).

Furthermore, to my knowledge, DDoS attacks are most effectively scrubbed precisely by correlating inbound packets with outbound packets that are evidence the protected service desires to communicate with the sender.
(I suppose a scrubber could simply discard most source-obscured traffic.)

Privacy is one side of security, but the ability to resist attacks is another important aspect. As far as I know, no one has figured out how to mitigate DDoS attacks at the receiving end-point.

I’m hoping this group can at least agree that mitigating DDoS attacks is a legitimate role of devices in the network.


From: Spud [] On Behalf Of Kyle Rose
Sent: Wednesday, July 27, 2016 10:48 AM
To: Mirja Kühlewind
Subject: Re: [Spud] 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.

As you probably know from tcpinc discussions it is today not possible to just encrypt the whole TCP header because this will lead to huge deployment problem (and incentive people to actively block encryption), however, providing a replacement mechanism that actually gives the control really back to the endpoint and provides the needed (not privacy sensitive) information in the network is the goal here. (This also enables protocol innovation again because at this point the network does not need to know anymore which protocol is used, which makes it even more save).

Of course this can be used to also add additional information that we don’t have today in the TCP header (however, we can also define new TCP options or IP headers or HTTP extension... and there are existing bad examples… or just use them with out an RFC or simply register an experimental TCP Option and use it forever and ship products with it... or... or... or…). However, the goals is to provide information which can actually be used make the network work better. Similar as some information that we are exposing today (such as port numbers and/or timestamps), the information we are looking for should in it self not be privacy sensitive and by using a new approach for exposing we can even take additional care now to make sure this information cannot be used in such a way (which is not the case for TCP timestamps today as the clock used might identify the client). Designing this now with a strong privacy awareness can also just improve the situation compared to what we have right now.

I totally buy the positives here, and I think maybe more language pitching and justifying this as at-worst an even trade of privacy concerns by removing some existing, completely-unprotected covert/side channels and replacing them with only exactly what the path needs to know (humbly, from our always limited technical perspective) in order to manage flows in a world in which the entire internet is running over UDP is part of what is missing from the proposed charter.
I had a long talk about my post with Aaron Falk on Monday, and as a result of that conversation I became hopeful that much more information about data flows could be obscured in a PLUS-enabled internet than is possible today, perhaps even to the point of obscuring source addresses and making flows and maybe even individual packets to busy endpoints hard to correlate without tap points at every router on the internet doing collective traffic analysis. That's a long way off, but that is a future many would like to see.
"We don't think this has any additional privacy impact" is a much weaker statement than "This can be the foundation for much greater privacy of metadata, not just of payload", and is more prone to FUD because it puts you on a defensive footing against many possible (and vague) lines of attack, and the burden of proof is always on those proposing changes. Thinking ahead to what we want the internet to look like in 20 years is a prerequisite to making sure that what we're doing lays just enough groundwork to make that possible, and is something that I think many privacy advocates could get on board with.
(I do also want to add that I recognize a bit of cognitive dissonance in myself, as I've repeatedly expressed skepticism about adding real privacy at the routing layers on the public internet, versus private networks on top of that, like TOR. That said, the antecedents of that skepticism may not be true in a 2036 internet, so systematically strengthening the desirable properties of the internet's foundations is likely not to be wasted work, as long as we have a reasonable idea of where we're headed.)