Re: [Dots] Target-Attack-type expansion: more discussion

Nik Teague <> Fri, 10 May 2019 07:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56A8F120178 for <>; Fri, 10 May 2019 00:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wJtkjwiOggRn for <>; Fri, 10 May 2019 00:33:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 632E9120177 for <>; Fri, 10 May 2019 00:33:49 -0700 (PDT)
Date: Fri, 10 May 2019 07:33:40 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=protonmail; t=1557473626; bh=5CbhkvHqNSywOwlhWTNmfb80VvOYuvxOX8ODBfVnHw4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=ODRPMhCmoBhCBIPx7dywT/ACxhMII9MoYNPQzzgXdmsIqM1ghvyX3t3vaeRrnMC4a MmGekJ0JAGVySUkKj+QIZ0IMr73mScKDboaPueVOOg3S+vh3RpGd0lSVpSzEupKniH Prvx1ulikuMqmOvj9G6ovNBFEWhu5pSUtqOWS2HM=
From: Nik Teague <>
Reply-To: Nik Teague <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Feedback-ID: Y91J0Zr2tpkE2KpleD3ti1ZrR04h6-F6NTTavVNwZ9GVklA9qvQM6vy4qrECIh7ulSHz17JKDFAAnkqRqLmlTg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_9016ab334de281a78ba0b382b9247207"
Archived-At: <>
Subject: Re: [Dots] Target-Attack-type expansion: more discussion
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 May 2019 07:33:53 -0000

-------- Original Message --------
On 9 May 2019, 04:33, MeiLing Chen wrote:
body { line-height: 1.5; }blockquote { margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em; }div.FoxDiv20190509112907302659 { }body { font-size: 10.5pt; font-family: 微软雅黑; color: rgb(0, 0, 0); line-height: 1.5; }
Hi, Nik and Töma,
"procotol layer" is a field designed for attack type definition and classification, but the actual mitigation operation depends on the mitigation method provided by mitigators.

I'm not sure of the value then - from a reporting standpoint the information may be inferred from other characteristics. Taking memcached again, If I'm classifying that I would probably drop it in the reflection bucket not application. That rings true of most if not all reflection attacks - an application weakness may be exploited but the attack in that instance is volumetric - the payload is somewhat secondary to the goal of making lots of big things and throwing them at systems.

-------- Original Message --------
On May 6, 2019, 11:52 AM, Töma Gavrichenkov wrote:

On Mon, May 6, 2019 at 1:10 PM MeiLing Chen wrote:
> Actually, It is more inclined to use TCP/IP four-layer protocol.

Which layer is QUIC then?

The Internet protocol suite is not really layered. OSI model is, but
the IETF as a whole tends to slip away from the layered model. To
quote Christian Huitema:

"There is also beauty in *not* having a layered architecture [..]. It
is great to see transport functions like acknowledgement or flow
control fully contained in the Quic transport. Quic is about transport
innovation, and that pretty much requires direct access to the network
API. In practice, layered implementation hide that API, so the
transport developers have to constantly negotiate with the
intermediate layer developers."

I would strongly oppose a classification based on "exploited protocol
layers". As attractive as it is academically, it makes operational
issues more opaque.


Layers have no real relevance... Using the memcached example - the exploitation may be at the application but the mitigation could easily be handled by a standard ACL.