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

Nik Teague <nik-ietf@0x46.uk> Mon, 06 May 2019 10:59 UTC

Return-Path: <nik-ietf@0x46.uk>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E46120144 for <dots@ietfa.amsl.com>; Mon, 6 May 2019 03:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=0x46.uk
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 KjDpauXPFBJ5 for <dots@ietfa.amsl.com>; Mon, 6 May 2019 03:59:32 -0700 (PDT)
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (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 80885120136 for <dots@ietf.org>; Mon, 6 May 2019 03:59:32 -0700 (PDT)
Date: Mon, 06 May 2019 10:59:25 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=0x46.uk; s=protonmail; t=1557140370; bh=Ru6sN74WL7obMsqHraqMoLwH5ZKk0EfHDwAjDKwO2b8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=dr1PQgcBrBVSjr09kEI7mjs/SZLFrhECHwQpnJLcf9IP12awrxK1y7kuKAulwQX5q YIYRlM6m6WLOvh/KiGM2z86bl7OpOTm+7t/Pbrcqs/RoHH1q3tciiNNfZT0tb6yZyJ zkHGYIoVtCZMs0FmRKAJVTNSTpkNnMUmCvBI5Rvc=
To: ximaera@gmail.com, chenmeiling@chinamobile.com
From: Nik Teague <nik-ietf@0x46.uk>
Cc: dots@ietf.org
Reply-To: Nik Teague <nik-ietf@0x46.uk>
Message-ID: <F_U6GM3POUZ8TzoLKG37aO51HRo18XoifZME_ETIGh9LsF_6wC68n4y-dcHHmxNDKPk55FOaNG2cGRdJ3MV2om9m-1fhL9y7P_-Ln4x128k=@0x46.uk>
In-Reply-To: <CALZ3u+b=RVT11dwN=2dHE9q6i6BCscs2PQmnygvBLPYy5QHqPA@mail.gmail.com>
References: <2afa5c9df0626fd-00007.Richmail.00004070460264152429@chinamobile.com> <CALZ3u+YTx2b=QMTM_UzgX254cgcgAWYxnwA=-VwHhD03ygragw@mail.gmail.com> <2019050616564984104217@chinamobile.com> <CALZ3u+Y43hR-CkyD6sjziiJEi3TVHJ7mNEgmUS-GpLGow8jxew@mail.gmail.com> <2019050618104036747536@chinamobile.com> <CALZ3u+b=RVT11dwN=2dHE9q6i6BCscs2PQmnygvBLPYy5QHqPA@mail.gmail.com>
Feedback-ID: Y91J0Zr2tpkE2KpleD3ti1ZrR04h6-F6NTTavVNwZ9GVklA9qvQM6vy4qrECIh7ulSHz17JKDFAAnkqRqLmlTg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_5fffa6d9805d1d3574b0cd4ab8de69ce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Krf8U5pTlKMa4-tlx78PWMrRQOc>
Subject: Re: [Dots] Target-Attack-type expansion: more discussion
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2019 10:59:35 -0000

-------- 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.

--
Töma

-----
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.