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

From: "MeiLing Chen" <[email-masked]>
Date: Mon, 6 May 2019 16:56:50 +0800

Hi Töma,
Please see inline,
>Peace,
 
>On Fri, Mar 29, 2019 at 12:15 PM 陈美玲 <[email-masked]> wrote:
>> I'd like to continue discussion of these topics in the mail
 
>For clarification, the quotations below that line are from the draft
>[1], not from the mailing list thread.

>> Therefore, it is necessary to unify the attack definition,
>> form a standard attack definition
 
>I do not anticipate that happening in the foreseeable future. Mainly,
>because of the differences between traffic classifying and filtering
>engines. Also, because the state of scientific research on the problem
>space is quite poor.
 
>> we give out a complete format for DDoS attacks as below
 
>From the text and also from the slides [2] it is not clear what
>exactly you list under "protocol level".
>It appears like something very close to the OSI layering, however,
[MeiLing] YES, that's mean the layer, I will modify it in the next version.

>a) in this case the proper word would be "layer", not "level",
>b) the attribution seems quite arbitrary.
[MeiLing]We tried a variety of classification methods, and if need to cover all the attack types, this attribute has to be an arbitary parameter. 

>E.g. ICMP flood is coupled with "Network_Layer" while it could also
>affect the data link layer if e.g. there's no "no arp packet-priority
>enable" on an interface in a Cisco switched network.
>The same with memcached reflection which could cause an effect on the
>layer 2 through 4 performance of a network (and I'd even go as far as
>to say that L4 being affected is the least likely case).
[MeiLing]the "protocol layer" Not mean the affected layer, but at the exploited protocol layer. 
***
 
>All in all, as I tried to point out during the session, I've
>personally seen a similar problem of conversion between different item
>classification methods being solved before in 3GPP world, where e.g.
>HP OpenView and Huawei M2000/J2000 had almost entirely different
>concepts of event type, status, and severity, yet communicated just
>fine through software-defined mapping tables provided by the
>respective vendors. Sometimes, it's best to follow that path, and a
>good thing is: you don't need a years-long IETF process for that to go
>live.
[MeiLing]that's really true, It is precisely because of the lack of uniform classification criteria that different classification names emerge.
use mapping tables are temporary solutions, However, it is still necessary to unify the types of classified attacks.

>References:
>[1]: https://tools.ietf.org/html/draft-meiling-dots-attack-type-expansion-00
>[2]: https://datatracker.ietf.org/meeting/104/materials/slides-104-dots-attack-bandwidth-and-attack-type-expansion-01
 
--
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 6 May 2019 12:18:54 +0300

On Mon, May 6, 2019, 11:57 AM MeiLing Chen <[email-masked]>
wrote:

> Not mean the affected layer, but at the exploited protocol layer.
>
>
a) Then the Memcached reflection would be layer 7, as the Memcached ASCII
protocol belongs to the application layer;
b) Honestly, I don't see how the "exploited protocol layer" could be of
*any* use for mitigation.

it is still necessary to unify the types of classified attacks.
Not only it is operationally close to impossible in the foreseeable
future,  it it is also really of questionable use.  You would still need a
device on your network which would be responsible for handling "the rest"
of DDoS attacks: not falling under any known type, 0-day, etc.

IMO the best you could *possibly* achieve is the classification similar to
what anti-virus vendors provide ("Win32/Conficker.A"-style, you know), but
even then no one tries to handle different malware with multiple anti-virus
installations on the same machine.  This architecture wouldn't really fly.

--
Töma

---

From: "MeiLing Chen" <[email-masked]>
Date: Mon, 6 May 2019 18:10:40 +0800

>On Mon, May 6, 2019, 11:57 AM MeiLing Chen <[email-masked]> wrote:

>a) Then the Memcached reflection would be layer 7, as the Memcached ASCII protocol belongs to the application layer;
>b) Honestly, I don't see how the "exploited protocol layer" could be of *any* use for mitigation.
[MeiLing]Actually, It is more inclined to use TCP/IP four-layer protocol. 
use "exploited protocol layer" for attack type classification and unified naming, then use the parameter of attack type for faster mitigation response, that's mean if Reporting sources are credible for attack type, the mitigator can use directly to dispatch the clean devices.

>Not only it is operationally close to impossible in the foreseeable future,  it it is also really of questionable use.  You would still need a device on your network which would be >responsible for handling "the rest" of DDoS attacks: not falling under any known type, 0-day, etc.
[MeiLing]The attack type here refers to DDoS attacks, Indeed, as you said, we did consider scalability to deal with possible types of attacks in the future.

>IMO the best you could *possibly* achieve is the classification similar to what anti-virus vendors provide ("Win32/Conficker.A"-style, you know), but even then no one tries to >handle different malware with multiple anti-virus installations on the same machine.  This architecture wouldn't really fly.

--
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 6 May 2019 13:52:58 +0300

On Mon, May 6, 2019 at 1:10 PM MeiLing Chen <[email-masked]> 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

---

From: Nik Teague <[email-masked]>
Date: Mon, 06 May 2019 10:59:25 +0000

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

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

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 6 May 2019 14:03:28 +0300

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

Exactly my point.

Understanding which layers are affected in the network during a
complex DDoS incident could help to speed up the mitigation procedure,
but never more than that.

--
Töma

---

From: "MeiLing Chen" <[email-masked]>
Date: Thu, 9 May 2019 11:28:00 +0800

Hi, Töma
please see inline;

 

>layers".  As attractive as it is academically, it makes operational
 
[MeiLing]What we pay more attention to here is the method of attack;"protocol layer" is a field that we design for classification and definition; Because for different layers of protocol, the required parsing power and times are not the same.
For example, the DNS protocol can be resolved to the UDP layer or to the application (DNS) layer. The same problem applies to TCP and HTTP; In order to better analyze attacks and defend against attacks, we think it is more explicit and helpful with the indication of  the layer and type of protocol.

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: "MeiLing Chen" <[email-masked]>
Date: Thu, 9 May 2019 11:33:30 +0800

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 < [email-masked]> wrote:

--
Töma

-----

---

From: Nik Teague <[email-masked]>
Date: Fri, 10 May 2019 07:33:40 +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 --------

--
Töma

-----