Re: [Tsv-art] [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

Jared Mauch <jared@puck.nether.net> Thu, 06 December 2018 19:12 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271FF130F39; Thu, 6 Dec 2018 11:12:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2wFeNu2cYn5D; Thu, 6 Dec 2018 11:12:05 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DA0130F24; Thu, 6 Dec 2018 11:12:05 -0800 (PST)
Received: from [IPv6:2603:3015:3606:cbe1:24ab:5e49:fa23:e739] (unknown [IPv6:2603:3015:3606:cbe1:24ab:5e49:fa23:e739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 3E51D5404E8; Thu, 6 Dec 2018 14:12:03 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CACL_3VGy6rjr10E4FK4xd4pq_-XSfP2VGhVqT+z-6Gm17z7okA@mail.gmail.com>
Date: Thu, 06 Dec 2018 14:12:02 -0500
Cc: Gert Doering <gert@space.net>, IETF <ietf@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC <opsec@ietf.org>, TSV-ART <tsv-art@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F69B9DEA-1C23-4FBD-952D-ACC65780F320@puck.nether.net>
References: <CACL_3VGeJPzDhS0RVAvpQs9W8b4EODft-qJRwBD6Xxm+X6BZ6A@mail.gmail.com> <CAL9jLabK0bZz2nki=oFNHT0OrpVAB8pw7emAj2BtkHRCzkfmqQ@mail.gmail.com> <cf64abbf-e447-71e3-b983-4e525cc139aa@gmail.com> <CAL9jLaYMRDGFa7Qzj4ukRV1FPbJM40qbuZ34SYxoA30Z+h3EWw@mail.gmail.com> <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <20181206093154.GF1543@Space.Net> <CACL_3VGy6rjr10E4FK4xd4pq_-XSfP2VGhVqT+z-6Gm17z7okA@mail.gmail.com>
To: "C. M. Heard" <heard@pobox.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/O3u_YVQZiihV3yXe-cS7RvlJLWc>
Subject: Re: [Tsv-art] [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2018 19:12:07 -0000


> On Dec 6, 2018, at 1:58 PM, C. M. Heard <heard@pobox.com> wrote:
> 
> On Thu, Dec 6, 2018 at 1:32 AM Gert Doering <gert@space.net> wrote:
>> On Thu, Dec 06, 2018 at 01:14:54PM +1300, Brian E Carpenter wrote:
>>>> Which implies that as soon as the evil guys out there find a way to
>>>> generate DDoS streams carrying EHs that our border routers will (have to)
>>>> apply very strict rate limiting to everything they do not understand.
>>>> 
>>>> - pass TCP
>>>> - rate-limit UDP on well-known reflective attacks port
>>>> - pass rest of UDP
>>>> - rate-limit ICMP
>>>> - rate-limit fragments
>>>> - rate-limit all the rest to something which can never exceed a
>>>>   customer's access-link
>>>> 
>>>> game over, EH
>>> 
>>> Just to point out that this is equivalent to saying "game over,
>>> any new layer 4 protocol" too. For example, you just killed SCTP.
>>> And the same goes for new protocols over IPv4.
>> 
>> Well.  Since nobody is using SCTP, it can nicely live in the
>> "rate-limit all the rest to something ..." bucket...
>> 
>> But yes, "any new layer 4 protocol" is likely to not work in an Internet
>> that is basically full of hostile packets *in high volumes*.
>> 
>> Trying to run large volume traffic over UDP/443 is going to be the next
>> excercise in "operators told you that is isn't going to work"...
> 
> Is that a prediction, or a self-fulfilling prophecy? I would certainly hope
> that filtering UDP/443 is not done preemptively without actual evidence that
> it is in fact a DDoS vector.

It is done as UDP is where the majority of the abuse has been.  I’ve been responsible for implementing these types of controls at operator networks due to the damage it does to our infrastructure.

People are very unhappy then their service is down because they’re staring down a cannon that took out their country/continent with UDP abuse.

I would say I find it shocking that the transport area folks seem to keep ignoring the feedback from operators, but this feeds into the longstanding meme of operators don’t show up at the IETF because they aren’t heard.

I’ve had folks at $dayjob say they “Well that network will then have poor performance and people will switch”.  This may be the case for those that have choice, but as was recently pointed out in home net, much of the complexity perhaps isn’t used or desired by the consumers.

Yes, the ad networks want to serve me ads faster.  I don’t expect the transport area to listen to those that operate networks as it’s been demonstrated the conversation about harm to the network by these behaviors isn’t listened to.

Let me state it clearly:

UDP is filtered or policed by network operators not because they want it, but as self-defense.  Nothing personal.  If you are on the end of a long subsea circuits, you may not be able to use UDP based protocols.  If you are trying to SNMP poll over public internet because you think you can e2e, you will become sad.  No operator wants to deploy these configurations, they must because of the problems.

- jared

(Feels like a broken record on this topic)