Subject: [Dots] A few suggestions for draft-ietf-dots-requirements-06

From: Artyom Gavrichenkov <[email-masked]>
Date: Mon, 2 Oct 2017 13:42:57 +0300

Hi!

Here are my two cents for the current draft.

==
2.2, SIG-005.

There's a concern my concern about limiting the size of the
active-but-terminating period. To quote my suggestions for the use
case document:

> It is understood that the upstream transit provider may be unable to
> end the mitigation in case the DOTS client has requested for the DDoS
> mitigation services to be terminated, but the attack is still ongoing.
> For example, the upstream transit provider may use Flow Specification
> Rules within its Border Gateway Protocol sessions [RFC5575] to filter
> the attack traffic by the means of indicating that some traffic
> patterns shouldn't be allowed to reach its border routers.  Therefore,
> the upstream transit provider may not be able to end the mitigation at
> the request, because its own network will be then flooded with
> malicious traffic, rendering it unusable for the enterprise as well as
> for nearly all other customers of the provider.  In such case, the
> DOTS server responds to the termination request with a message
> indicating that the request has been acknowledged, but cannot be
> currently fulfilled and will be addressed as soon as it is possible.
> The DOTS client may still request the mitigation status information,
> statistics and other related information beyond this point.  The DOTS
> client may cancel the termination request by issuing the mitigation
> request again.
>
> Another issue with Flow Specification Rules and other similar
> mechanisms is that the upstream transit provider may be unable to
> provide any reasonable information on the status of the attack, as
> this information is not available to the upstream transit provider
> itself.  In this case, in response to any request for mitigation
> status information, statistics and other related information the
> upstream transit provider should clearly indicate that it employs
> tools which can affect the quality of the provided information.  The
> DOTS client should then treat the statistics returned as a rough
> estimate at best, and should make his decision to request the
> mitigation termination based on other information available, for
> example, on the data received from other upstream transit providers
> (see 3.1.2) or from the local CSIRT (see 3.1.10).

What's important here are the consequences for a DOTS client which
decides to withdraw the mitigation request while an attack is still
ongoing. If the active-but-terminating period is initially 30 seconds
tops, then after 30 seconds the mitigator will either continue
filtering, yet making the DOTS client unable to track the mitigation
status, or it may just use a black hole community to drop the traffic
towards the victim completely, so the result is complete downtime for
the victim. But if the active-but-terminating period is unlimited,
then the client will still have full control on the situation. And, if
it's really eager to stop the mitigation no matter what, it may just
kill the BGP session towards the mitigator.

At least, it seems to be important to split those cases:
1) a DOTS client requests the DOTS server to end the mitigation, where
the server may acknowledge the request but refuse to comply for an
unlimited period of time;
2) a DOTS client requests the DOTS server to end the mitigation
completely (due to excessive costs, for instance), where the server
MUST comply but may start to drop the traffic completely.

I'll be happy to provide detailed requirements for both scenarios if
you want me to.

A side note: I can't find this in the mailing list, but why the
initial window is 30 seconds? What can a mitigation provider actually
do within this period? It's not enough even for BGP announcement to
propagate globally. I've seen a BGP announcement propagation taking up
to 2 minutes, for example. A brief RIPE Labs study (
https://labs.ripe.net/Members/vastur/the-shape-of-a-bgp-update )
showed that full visibility of an announcement took about 38 seconds,
while a subsequent withdrawal took more than 2 minutes to propagate.

Moreover, the architecture document even features the concept of
gateway and chaining. A request to end the mitigation may propagate
through the gateway, acting as a sort of proxy, towards the upper
level mitigation provider, which may take time on a saturated network
link. Then, this upper level provider is left with, like, 20 seconds
to comply. So I'd consider changing the MUST in the last paragraph of
SIG-005 to SHOULD.

==
2.2, SIG-007.

Under certain conditions, a DOTS client may be an awful decision
maker. Imagine a 80 Gbps DDoS attack with combined SYN flood, WP
Pingback and HTTPS flood towards a typical 200 Mbps link. The
congestion on the last mile will render any network service, including
the CPE with DOTS client in it, unable to come up with any sane
mitigation scope.

Thus, I propose changing the first MUST in SIG-007 to SHOULD.

==
2.2, SIG-009.

"Conflicting" or complementing? Note that different DOTS clients in an
enterprise network infrastructure may have different visibility
scopes, either per some subsets of IP addresses (which may of may not
form one continuous prefix range) or per OSI level. Using the previous
example, one DOTS client on an IDS/IPS will see a SYN flood while
another DOTS client on a Web server will see an HTTPS flood towards
the same network resource. The IDS (like Snort) will be unable to
track down HTTPS requests while the Web server wouldn't see the SYN
flood mostly mitigated on the IDS.

One may argue that in this case there must be a DOTS gateway at the
edge of the network, acting as a proxy and a decision maker, yet
again, in practical datacenter conditions it may be hard to set up and
maintain one.

==
2.3, DATA-004

It is unclear what should happen if a DOTS client adds an entry both
to the blacklist and to the whitelist. Either one of the lists should
be given priority over the other, or, say, adding an entry to the
blacklist should automatically force the deletion of the corresponding
entry from the whitelist (which may add computational complexity).
Leaving this up to the implementation may cause harm to
inter-operability of different clients and servers.

I'd consider adding a paragraph like that:

   A DOTS client MUST assume complete responsibility for maintaining
   all the entries it adds both to the blacklist and to the whitelist.
   In case of a collision (i. e. when an entry is added to the
   blacklist which is already present in the whitelist, or vice versa)
   the behaviour is undefined.

==
1.2.
It's not that important really, but I'd consider reviewing the
definition of DDoS attack.

Currently, DDoS is defined as "a distributed denial-of-service attack,
in which traffic originating from multiple sources are directed at a
target on a network". This lacks the definition of "source". Is it a
source IP address? Then, a SYN flood with a fixed spoofed IP source
doesn't qualify to be called DDoS, which is odd.

Or, is it a network source, like, a physical machine? Do virtual
instances count then? And, again, a SYN flood generated on a single
server somewhere on DEC-IX (which is actually what we faced once) is
not a DDoS attack?

I'd consider changing the definition towards the perceived effect and
the goal of an attacker. Something on the lines of:

   DoS:  an attack in which one or more machines target a victim and
   attempt to prevent the victim from doing useful work by rendering the
   victim unavailable, unresponsible, or unreachable.

   DDoS:  a DoS attack which achieves the goal of rendering the victim
   unavailable, unresponsible, or unreachable by the means of exhausting
   the finite resources of a network connected entity, which may or
   may not be the victim itself.  Denial-of-service considerations are
   discussed in detail in [RFC4732].

Or one can simply take the definition from one of Roland's
presentations, like that:
http://mirror.die.net/misc/defending-ddos/stateofdanger.pdf , slide 3.

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Sat, 14 Oct 2017 03:45:20 +0300

Hi again,

"
Hi,

I know, everyone is busy, but still, could I have any response on this?

Hereby I declare that I'm fine here with Crocker's rules, so, if you feel
I'm dumb or don't understand something, please don't hesitate to express
that. I'll just be really happy with some input that will help me move
forward.

Thanks, and have a good day,
"

| Artyom Gavrichenkov