Subject: [Dots] A few suggestions for draft-ietf-dots-use-cases-07

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

Hi!

Here's the subj. I believe, some of the issues I'm raising were
discussed already, but I'm not able to find the relevant e-mail
threads. Sorry for that.

==
3.1.1.
- Paragraph 3: "is performed" -> "are performed".
- I propose changing the use case title:
  "End-customer with a single upstream transit provider offering DDoS
  mitigation services"
  ->
  "End-customer with a single upstream transit provider offering DDoS
  mitigation services on demand"
- I propose adding two new paragraphs after paragraph 7, as follows:

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

==
3.1.2.
I propose a new paragraph (IPaNP), after 2. The motivation: this is
what already happens now, ad-hoc, via phone or instant messaging,
without DOTS and/or any mutual agreements between ISPs. Therefore, it
makes sense to cover this case in the process of designing a DDoS
mitigation control protocol:

   In case there's no such agreement between the upstream transit
   providers, the DOTS client may still decide to share the information
   and statistics obtained from one or more of the upstream transit
   providers to others by unicasting or broadcasting the status messages.
   An upstream transit provider receiving this kind of data may then plan
   the allocation of its mitigation facilities with accordance to the
   current risk level, as seen by other upstream transit providers or the
   enterprise itself.

==
3.1.4.
IPaNP, after 5:

   The MSSP receiving a request to end the mitigation may be unable to
   act accordingly due to reasons similar to what is discussed in 3.1.1.
   In such case, the enterprise may react with diversion of Internet
   traffic destined for its network back from the MSSP network
   facilities, or may wait for MSSP to effectively stop the mitigation.

==
3.1.5.
I propose changing the paragraph 2 to the following:

   The DOTS client built into the Web server has been configured to
   request DDoS mitigation services from an upstream transit provider or
   overlay MSSP once specific attack traffic thresholds have been
   reached, or certain network traffic conditions prevail, or the Web
   application behind the Web server becomes unable to successfully
   handle all the incoming HTTP requests on time due to the limited CPU
   power or RAM amount and there's a pattern in some those HTTP requests
   which is qualified as typical for a DDoS attack by the Web
   application.  Once the specified conditions have been met, the DOTS
   communications dialogue and subsequent DDoS mitigation initiation and
   termination actions described above take place.

==
3.1.6.
I propose a change to the paragraph 1:
 "router, layer-3 switch, firewall, or load-balance"
 ->
 "router, layer 3 switch, firewall, IDS, IPS, Web application firewall,
 or load balancer".

==
3.1.8.
IPaNP, after 3:

   Note that only the messages directly related to the DDoS attack and
   mitigation status should be passed between the DDoS MSSPs via DOTS,
   both in the request for an assistance and during the course of the
   attack.  The exchange of the rest of the information that may be of
   use in this scenario, which includes interconnection metadata,
   logging, authorization rules, geo-blocking restriction policies, and
   similar data, falls out of scope for this document and must be
   implemented by the means of other protocols and interfaces, such as
   Content Delivery Network Interconnection (CDNI) Logging interface
   [RFC7937] or CDNI Metadata interface [RFC8006].

==
I propose adding two more use cases, as follows:

3.1.9.  End-customer with an upstream transit provider or MSSP
        offering DDoS mitigation services on the permanent basis

   This scenario shares almost all characteristics with 3.1.1, except
   that due to the lack of a capable local IDMS solution, strict uptime
   requirements, or other reasons the enterprise has previously requested
   its hosting provider, upstream transit provider or MSSP in
   its place to provide the DDoS mitigation services permanently,
   without a need to detect and explicitly turn the mitigation
   on in case a DDoS attack has started.

   In this case, when an attack is in place, the DOTS server on the
   upstream transit provider network immediately notifies the DOTS client
   on the enterprise network about the attack and periodically signals
   the DOTS client in order to provide mitigation status information and
   related information.  The enterprise security and network operations
   departments may then use this information to take care of the network
   status, to plan maintenance windows and routing policies, and to share
   it with CSIRT if applicable (see 3.1.10).

3.1.10.  Community member notifying CSIRT about the attack

   A Computer Security Incident Response Team (CSIRT) [RFC2350] is
   responsible for assisting members of a community within its
   constituency in implementing proactive measures to reduce the risks
   of computer security incidents, and to assist the community in
   responding to such incidents when they occur.  The community may
   consist of sites, networks or organizations, such as enterprises
   operating in one industry, regional transit providers or DDoS
   mitigation MSSPs.

   Typically, a Computer Security Incident Response Team would need an
   information about ongoing DDoS attack on a member of the community as
   soon as possible to act accordingly, issuing notifications,
   recommendations and policies for the rest of its community.

   A member of the community implements a DOTS client while the
   corresponding CSIRT implements a DOTS server.  The DOTS client signals
   the DOTS server on the CSIRT network that an attack had started.
   During the course of the attack, the DOTS client frequently updates
   the information about the status of mitigation, provided by the DDoS
   mitigation solution deployed by the member as well as its upstream
   transit providers or MSSPs.  In turn, the DOTS server on the CSIRT
   side periodically signals the DOTS client in order to provide
   information about similar attacks currently ongoing on other community
   members, so that the DOTS client could make an informed decision to
   whether maintain or terminate the mitigation via other means.

==
Also, please consider updating the Github repo for the Use Cases draft.
It's now on the version 05 while the most recent one is 07.

| 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:44:55 +0300

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