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

[Kyle Rose <[e-mail]>]

Funny you should mention that. :-)

When Aaron and I were talking about this earlier, we were basically
throwing ideas around. When we got to this one, I mentioned how it would
neuter BCP 38, but that DoS protection might be achievable via some other
mechanism on a hypothetical future internet (especially since source
address verification only helps with a subset of DoS attacks: the most
difficult kind to deal with are those that are indistinguishable from
legitimate traffic).

At any rate, mentioning obscuring source addresses was not intended as a
well-thought-out proposal to be drafted tomorrow and standardized next
year, only as the kind of thing that might be appealing to privacy
advocates, and possibly feasible on an internet that looks very different
from today's. Just because I can't figure out how to do something doesn't
mean it's impossible.

Kyle


On Wed, Jul 27, 2016 at 4:31 PM, Dave Dolson <[e-mail]> wrote:

> 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.
>
>
>
>
>
> -Dave
>
>
>
>
>
>
>
> *From:* Spud [mailto:[e-mail]] *On Behalf Of *Kyle Rose
> *Sent:* Wednesday, July 27, 2016 10:48 AM
> *To:* Mirja Kühlewind
> *Cc:* [e-mail]
> *Subject:* Re: [Spud] Thoughts on the privacy concerns expressed at the
> BoF
>
>
>
> On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind <
> [e-mail]> 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.)
>
>
>
> Kyle
>