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

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 03 Nov 2017 19:38:06 +0700

On 2 Oct 2017, at 17:38, Artyom Gavrichenkov wrote:

> ==
> 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"

This is a needless change which does not offer additional clarity.

> - I propose adding two new paragraphs after paragraph 7, as follows:

In earlier drafts, we had a scenario in which the upstream mitigation 
provider couldn't immediately fulfill the mitigation request.  It makes 
sense to revive this use-case, minus all the speculative and 
situationally-specific flowspec details posited in your sample text.

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

There are no plans to unicast or 'broadcast' DOTS messages except within 
the context of a DOTS peering relationship.

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

No diversion takes place unless the mitigation request has been 
accepted.  DOTS clients are always free to request mitigation 
termination.

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

This level of detail is unnecessary and does not add to comprehension of 
the base scenario.

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

This makes sense.

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

This is already understood and there is no need to reference CDNI or any 
similar protocols or interfaces.

> ==
> 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 makes sense.

> 3.1.10.  Community member notifying CSIRT about the attack

This application is outside the scope of DOTS in its present 
incarnation; exchanging flow telemetry information, would be required in 
order to provide the requisite information to make such an information 
exchange practicable.

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

Yes, will do.

-----------------------------------
Roland Dobbins <[email-masked]>