Re: [Spud] updated draft PLUS charter, rev. 1 June

Tom Herbert <tom@herbertland.com> Sat, 25 June 2016 21:32 UTC

Return-Path: <tom@herbertland.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 B7E4B12D181 for <spud@ietfa.amsl.com>; Sat, 25 Jun 2016 14:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 i0JRGZL_PHvI for <spud@ietfa.amsl.com>; Sat, 25 Jun 2016 14:32:56 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 B42E312D151 for <spud@ietf.org>; Sat, 25 Jun 2016 14:32:56 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id g13so118393842ioj.1 for <spud@ietf.org>; Sat, 25 Jun 2016 14:32:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4AOgFMwrhTTvyu8wvT9gAKs+Cs0D+rYuLID6R1Y8bxA=; b=OTlXaZ78+HnKk9Vt1cCYtfu4EOyaYF6mdwZi/ODUyz0dqk8IT4MNDluBZmSgCxyH4h LvmOrtHMqFynvnp+u9ADAmGfAdZg9TpNSAOe0wHXGtYytbwe2YsijXbSHhIiej01qkL0 zP9SvhU5KoePshsXuqmCt89KEVw2Sx5y0sOQYb3F8zdA0sos/0fvE7MHZv2B/2cLMaHO MMvrm45WFOY7jBnJeg5Xn7jwgf7tDqY3Nu1nvlxPVWfsynLC+jvvNeXGbWQb3uo6Teys h1P+xxb00G8EZShUJNkgt+N/FUR+GHpm9kc4LSovNfJz+Jplcg/CH5WLmOND5SczzlJI y/lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4AOgFMwrhTTvyu8wvT9gAKs+Cs0D+rYuLID6R1Y8bxA=; b=BiStWkQ9bhezkQrecr9JbI3TsqaF5SB/c0Yp+Mxj3TDAmcpaNNtpO/PZtwH3Mx3wxP FuX3a1SDz2w25k9evv4oyJuj2WEE+3zx5gaQf5Ctz7TOw5RpJijaHXXfdWSN8mjwYvBH z1KgGeZJk3Y6yV2ZLUEKXd8hxckldUSKqDkNJY//wlzLMCHt/eyfmUHl3BxxqTcge50z FZi2VNOkqhIi44gnIKPZLl2xYhNhxn1c4thKxQcA+tmrriBwIlX54BREvEU+DGjZW6U4 DzETZJz3mgHFgjS4n9EmdyQYuYtb9OwgNqonNLRLjeefN9c4q0gHM+uBW3xMQj0kvbzk VEHw==
X-Gm-Message-State: ALyK8tL8Lso05Tc7IUe6Fz94L3Oc84uYOoiJcwksKpq0/p7ueyzJOGr7aZNdIp7WUjLXW12fal4VWd2RpUO8KA==
X-Received: by 10.107.162.12 with SMTP id l12mr10828552ioe.84.1466890375843; Sat, 25 Jun 2016 14:32:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.31.134 with HTTP; Sat, 25 Jun 2016 14:32:54 -0700 (PDT)
In-Reply-To: <CAD6AjGSCdxk9pY8mX5gR1qoC_ck+ggKvCK7CyLkpp_4T1Th1QA@mail.gmail.com>
References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <CAD62q9UiLi1ffGPm=xEXOSH=sqZPv7hYiNBTGvAX52a9dhV8yg@mail.gmail.com> <CAD62q9U7XL8hDqY1VdzuvUvoz0Ec5DDLAS6=kaLxRExu7FY0Kg@mail.gmail.com> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <A4C63A75-9D7E-430E-B986-9981FB929D46@gmail.com> <CA+9kkMBhJ2oCJ1avnGUY4NYTX0VWA_g=YoJSiLcy6u9hJnH-eA@mail.gmail.com> <57573DCF.1030402@isi.edu> <F6BE4EE1-D320-421E-9D86-2F30B2A88792@tik.ee.ethz.ch> <CALx6S35Z7iEp2F7+1PHzAe0qu9st_CNXB9GCzF278HehFiv0Qg@mail.gmail.com> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <CALx6S35KXOioEK60p-m5tGE_H9MWbB=YhJ_sOcW0KP2vR80vvw@mail.gmail.com> <57574C38.6070402@isi.edu> <F44FFD3B-CE7E-45E8-9F04-233C56CA95A0@trammell.ch> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> <EA4C43BE752A194597B002779DF69BAE24100840@ESESSMB303.ericsson.se> <CAD6AjGTiSu7Lcfq_fdfva1Z5xM0ReQL+tk4UabE7=g7yjGG4CQ@mail.gmail.com> <DM2PR0301MB0655C4B5A3A7E4102D16DBC6A8540@DM2PR0301MB0655.namprd03.prod.outlook.com> <BB04CCB1-0CF6-437F-B4D1-4CED87DF9864@trammell.ch> <CAD6AjGSCdxk9pY8mX5gR1qoC_ck+ggKvCK7CyLkpp_4T1Th1QA@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 25 Jun 2016 14:32:54 -0700
Message-ID: <CALx6S37Sz6HkmGFPKcJmbTcnro9b4jaD7a+ix6Q1C9Td+ejLcg@mail.gmail.com>
To: Ca By <cb.list6@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/KA76haghOcQhz4bi1am0lr3q5mA>
Cc: Brian Trammell <ietf@trammell.ch>, Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>, spud <spud@ietf.org>, Christian Huitema <huitema@microsoft.com>, Joe Touch <touch@isi.edu>
Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June
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: Sat, 25 Jun 2016 21:33:00 -0000

On Wed, Jun 15, 2016 at 5:17 AM, Ca By <cb.list6@gmail.com> wrote:
>
>
> On Tuesday, June 14, 2016, Brian Trammell <ietf@trammell.ch> wrote:
>>
>> hi Christian,
>>
>> > On 14 Jun 2016, at 21:47, Christian Huitema <huitema@microsoft.com>
>> > wrote:
>> >
>> > On Tuesday, June 14, 2016 5:46 AM, Ca By wrote:
>> >
>> >>
>> >> All my concerns with spud and quic would be solved by using a
>> >> new protocol number since it would allow for the network to,
>> >> at scale, identify good spud/quic traffic from the known bad  udp ddos
>> >> mess
>> >
>> > I think we need to dig a bit further there. Botnets could issue
>> > spud/quic traffic just fine. Granted, it will take them some time to adapt,
>> > but history shows that they will adapt. So, I don't see how painting a fixed
>> > set of bits in the packets would help in the long run. Botnets engaged in
>> > DOS will just set the same bits, be it a protocol number or a header field.
>>
>> Agreed.
>>
>> > There may be something specific to do about differentiation from UDP
>> > reflection attacks. I am aware that a lot of these are DNS packets. There
>> > may be some other UDP services as well.
>>
>> Reflection attacks tend to follow the amplification factor: more
>> amplification, bigger win. NTP (due, I think, to a widely deployed
>> configuration that was amplification-friendly) was the champion here; DNS
>> with DNSSEC looms as the next one (see the work of Roland van Rijswijk-Deij,
>> Anna Sperotto, and Aiko Pras here: [1, 2]).
>>
>> > But the general characteristic is that such attacks reuse a deployed
>> > infrastructure to their benefits, and thus have specific markers. The
>> > infrastructure is not going to change, so the markers will stay. The new
>> > protocols should certainly try to differentiate from these existing attacks.
>>
>> This is the rationale behind the selection of the magic number in the SPUD
>> prototype, and the presence of a magic number in the requirements derived
>> therefrom.
>>
>
> Magic numbers do no work on existing router. Just like the constraint you
> have that we must work with the intall base so we must use udp. The solution
> space is "no change"
>
>>
>> I am also intrigued by Tom's earlier suggestion that using IPv6 DO headers
>> might have reflection-reducing properties, given the installed base. We
>> should look into that more deeply.
>>
>> None of this does *anything* against direct botnet attacks -- there are
>> maybe things you could do in a world with ubiquitous PLUS-speaking
>> middleboxes that distinguished a PLUS magic number flood from a bot from
>> real PLUS-encapsulated traffic.
>>
>>
>
> Is there anyone from a middle box vendor here? Do you want to hear what PLUS
> is telling you? Or will middleboxes keep doing what they want?
>
+1, these are very important questions to be answered for PLUS effort.

> I am concerned plus is saying things nobody is listening to.
>
Unless somebody's listening, there's no reason to believe applications
are going to bother to say anything.

Tom

>>
>>
>> But relying on both ubiquitous deployment (a decade out in the wildly
>> optimistic case) and the kindness of strangers to actually deploy egress
>> filtering (which has worked oh so well in the past) isn't what I'd call a
>> security plan.
>>
>>
>> >> This network operator concern has been repeatedly ignored since
>> >> it is easier to access udp in userspace.
>> >
>> > As many said, user space is just one of the problems. The other is the
>> > installed base of NATs that won't pass anything else than TCP and UDP. Do we
>> > have studies indicating whether that changes with IPv6?
>>
>> No direct numbers, in part because the measurement infrastructures
>> available to us give us much smaller population sizes for v6 measurement.
>> Anecdotally, taken from analysis of the data in [3, 4, 5], I can say that
>> the magnitude of brokenness on v6 in general is lower, but the kinds of
>> brokenness you run into is weirder. Slide 9 in [5] is v4 only because we
>> still haven't been able to explain anomalies in the MTU curve for UDP on
>> IPv6; in both [3] and the detailed analysis linked from [4] we see ECN
>> negotiation anomalies five times more often for v6 than v4.
>>
>> If I had to make up an explanation for that, I'd say that v6 traffic does
>> indeed tend to pass through fewer middleboxes, but that the v6 functionality
>> in those middleboxes is far less well tested. Happy eyeballs works so well
>> because it quite effectively hides a multitude of sins.
>>
>> Cheers,
>>
>> Brian
>>
>>
>> [1] DNSSEC and its potential for DDoS attacks at IMC '14
>> https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/imc101-vanrijswijk.pdf
>>
>> [2] Making the case for elliptic curves in DNSSEC in CCR, Oct '15
>> https://wwwhome.ewi.utwente.nl/~rijswijkrm/pub/ccr-ecdsa-2015.pdf
>>
>> [3] Enabling Internet-wide deployment of ECN, PAM '15
>> http://ecn.ethz.ch/ecn-pam15.pdf
>>
>> [4] 70% of popular Web sites support ECM, blog post
>>
>> https://mami-project.eu/index.php/2016/06/13/70-of-popular-web-sites-support-ecn/
>>
>> [5] Can we run the Internet over UDP, MAPRG presentation
>> https://www.ietf.org/proceedings/95/slides/slides-95-maprg-3.pdf
>
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>