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

"Smith, Donald" <Donald.Smith@CenturyLink.com> Thu, 06 December 2018 20:00 UTC

Return-Path: <Donald.Smith@CenturyLink.com>
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 7BD721311B5; Thu, 6 Dec 2018 12:00:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 b6pIOwPLmysS; Thu, 6 Dec 2018 12:00:10 -0800 (PST)
Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693A21311A0; Thu, 6 Dec 2018 12:00:10 -0800 (PST)
Received: from lxomp90v.corp.intranet (lxomp90v.corp.intranet [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id wB6K070L059813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 6 Dec 2018 14:00:07 -0600
Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6K01Oq013105; Thu, 6 Dec 2018 14:00:01 -0600
Received: from lxdnp32k.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6K01sR012694 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Thu, 6 Dec 2018 14:00:01 -0600
Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6K01lR021559; Thu, 6 Dec 2018 13:00:01 -0700
Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6K01sx021549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2018 13:00:01 -0700
Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([151.119.128.28]) with mapi id 14.03.0399.000; Thu, 6 Dec 2018 13:00:01 -0700
From: "Smith, Donald" <Donald.Smith@CenturyLink.com>
To: "C. M. Heard" <heard@pobox.com>, Jared Mauch <jared@puck.nether.net>
CC: IETF <ietf@ietf.org>, "draft-ietf-opsec-ipv6-eh-filtering.all@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>
Thread-Topic: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]
Thread-Index: AQHUjPjzcvm/Mjyn00OZLnlEXIoAFKVx6HMAgACeLICAAAPqAIAACDkA//+N6hw=
Date: Thu, 06 Dec 2018 20:00:00 +0000
Message-ID: <68EFACB32CF4464298EA2779B058889D53E5B811@PDDCWMBXEX503.ctl.intranet>
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> <F69B9DEA-1C23-4FBD-952D-ACC65780F320@puck.nether.net>, <CACL_3VEbp6bWBbBWd-qsHa6szjHBw50BtOMc3y0PD2k=iuC_gQ@mail.gmail.com>
In-Reply-To: <CACL_3VEbp6bWBbBWd-qsHa6szjHBw50BtOMc3y0PD2k=iuC_gQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [151.119.128.8]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/uQqOkUjZ9rfOw5yXKfPOyZoVXkc>
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 20:00:24 -0000

In the past nearly all UPD:443 traffic was part of an attack. Frequently it is the src port for a reflective attack towards UPD:1900, 123, … pick a reflector port that amplifies well.

UDP:80 same.

Those are the two most common trigger packet src ports for RA attacks.

It is my belief that the bad guys choose that because some (many?) filters are port based only not protocol based.
I have no evidence of that (you would have to ask a bad guy... DDoS for hire) but it is common.

 Don't take my word for it :)
https://asert.arbornetworks.com/ddos-attacks-iot-botnets-dont-mean-game/

" As most (not all) UDP reflection/amplification attacks tend to target UDP/80 or UDP/443 in order to confuse defenders who might not notice that the attackers are using UDP instead of TCP (TCP/80 is typically used for non-encrypted Web servers, and TCP/443 for SSL-/TLS-encrypted Web servers), "



if (initial_ttl!=255) then (rfc5082_compliant==0)
Donald.Smith@centurylink.com

________________________________________
From: OPSEC [opsec-bounces@ietf.org] on behalf of C. M. Heard [heard@pobox.com]
Sent: Thursday, December 06, 2018 12:41 PM
To: Jared Mauch
Cc: IETF; draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org; OPSEC; TSV-ART; Brian E Carpenter
Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

On Thu, Dec 6, 2018 at 11:12 AM Jared Mauch wrote:
> 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.

I do get the need for self-defense. But ...

Does this apply to all UDP or just specific UDP-based protocols?

What I commented on specifically was UDP/443 (QUIC), something
that people are actually trying to deploy.

If you block it, is that based on evidence of actual UDP/443 attacks?

Mike Heard

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.