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

"MeiLing Chen" <chenmeiling@chinamobile.com> Thu, 09 May 2019 03:33 UTC

Return-Path: <chenmeiling@chinamobile.com>
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 7A6681201DA for <dots@ietfa.amsl.com>; Wed, 8 May 2019 20:33:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 HWA-WYrH-Irb for <dots@ietfa.amsl.com>; Wed, 8 May 2019 20:33:31 -0700 (PDT)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 06E81120103 for <dots@ietf.org>; Wed, 8 May 2019 20:33:30 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee65cd39f89cb7-3085a; Thu, 09 May 2019 11:33:29 +0800 (CST)
X-RM-TRANSID: 2ee65cd39f89cb7-3085a
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[10.2.51.72]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee75cd39f87f7e-3d6f6; Thu, 09 May 2019 11:33:28 +0800 (CST)
X-RM-TRANSID: 2ee75cd39f87f7e-3d6f6
Date: Thu, 09 May 2019 11:33:30 +0800
From: MeiLing Chen <chenmeiling@chinamobile.com>
To: Nik Teague <nik-ietf@0x46.uk>, Töma Gavrichenkov <ximaera@gmail.com>
Cc: dots <dots@ietf.org>
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>, <F_U6GM3POUZ8TzoLKG37aO51HRo18XoifZME_ETIGh9LsF_6wC68n4y-dcHHmxNDKPk55FOaNG2cGRdJ3MV2om9m-1fhL9y7P_-Ln4x128k=@0x46.uk>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.115[cn]
Mime-Version: 1.0
Message-ID: <2019050911333026699515@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart644432017813_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/7TQVTn0uh47NAIpOWGyx7yK5oTQ>
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: Thu, 09 May 2019 03:33:34 -0000

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.

-------- Original Message --------
On May 6, 2019, 11:52 AM, Töma Gavrichenkov < ximaera@gmail.com> 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.