Re: [Dots] WGLC for use cases draft - until July-1.

Daniel Migault <daniel.migault@ericsson.com> Wed, 20 June 2018 19:57 UTC

Return-Path: <mglt.ietf@gmail.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 37CBE1294D0 for <dots@ietfa.amsl.com>; Wed, 20 Jun 2018 12:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1ejx4xVARmuL for <dots@ietfa.amsl.com>; Wed, 20 Jun 2018 12:57:34 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DAAF130E0D for <dots@ietf.org>; Wed, 20 Jun 2018 12:57:33 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id d24-v6so1114516lfa.8 for <dots@ietf.org>; Wed, 20 Jun 2018 12:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8uLLPSjP7CWQAnPWLoSizV77zGlWE6NGXA+l/RQru08=; b=Oh2UItWg50Qt8WZFYKWey6Wr79a0aDNYMMzv84BBcQvORlIU18THabLl0zu09Mv6aP zQvro9vnKCd1tiSGS3qvVhviBVQ4n5c+K4N7dU2o4sejTlaNadQE7/RP/yOY6A5ZXzrC MUbmvQzC+zzdWW+fl8MAc/Py/Jc966uHs7IPzmPaAshYTfxLGi2rMyg3EY9U0nx/rMSe jTiv3wR25/JkXbOETRPgH8abHljeSm5PuHDe4WGpdKnKX/MMInf3QpzcabyCJYPCoI5L zkfuexNl5eb6gFk1Lv1TnxEkmk/r+Ncn0vNX7CGH+m8k7QfMu4lb/pgIbroxIFwvc3uo sR7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8uLLPSjP7CWQAnPWLoSizV77zGlWE6NGXA+l/RQru08=; b=JFjKORZwikIc7anTTeYJUHjd+EhfCj6i6/b44TQZaP8XhGA6f1/RsrkHLCmH/Fyrdc U57yz71l6geUGnDwsv5FL1pdi0FX52CdByOtZFyIMJdnhx/RKSdMVJB5pNnMIXbrCEmr h7kSKmTJipHHesEB4UFGoWUfkHSiPFy9SHPweA0LjNUNst86a939pc5u7sSuIeMKTSIh NYhDJqc1QJLcPBBKV+AZmOSsQS98cvzeXSJq2rffaiHHjnnb38CYPXEn3U/HzAFLY1eJ QNnciD/Hm5foLRkMrmO9+ZHCQnBoNB1n7GhBS78i1mbIxlPfVczJOojh9teFnWLDYt7N aUgQ==
X-Gm-Message-State: APt69E2ZHRTAScn52xJHBqqX7Pb8Ii8EEV6C7DhSwOIDlApIh5PqFKHM G5NspfvHyUkGhwb9LsaWHyU2qP432K0NTEpA9kc=
X-Google-Smtp-Source: ADUXVKLriAQTug2PhUF38y360IVoV/i1hmVdrx/s9bANtDp22XIDGSAOxymrUaF53WA+JA58Gkz0bMN0z0H5mVfNo50=
X-Received: by 2002:a19:7613:: with SMTP id c19-v6mr5461492lff.73.1529524651787; Wed, 20 Jun 2018 12:57:31 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:9ac5:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 12:57:30 -0700 (PDT)
In-Reply-To: <BN6PR16MB1425231C027D4C47A70A2B15EA700@BN6PR16MB1425.namprd16.prod.outlook.com>
References: <033d01d40353$ee542d90$cafc88b0$@gondrom.org> <CADZyTk=dquqzKkM5qWiOw=0FvQx0xWfbD-uGhNVg5ZebuxJNhg@mail.gmail.com> <BN6PR16MB1425231C027D4C47A70A2B15EA700@BN6PR16MB1425.namprd16.prod.outlook.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 20 Jun 2018 15:57:30 -0400
X-Google-Sender-Auth: I0oL_eruiFCLDDU_lXgmSX1OeJ4
Message-ID: <CADZyTknKS4p4j8uihVr9gWHyRnGy7oZT8dhiqR-ERwDvBrkp0w@mail.gmail.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: Tobias Gondrom <tobias.gondrom@gondrom.org>, Roman Danyliw <rdd@cert.org>, "dots@ietf.org" <dots@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008b8c85056f1835e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/3YxxJA_MlicKgCcYWTV6KHhSSvo>
Subject: Re: [Dots] WGLC for use cases draft - until July-1.
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 20 Jun 2018 19:57:39 -0000

Hi Tiru,

Thanks for the comments. Please see inline my responses. If the proposed
text is fine to youI will update the draft and publish a new version by the
end of the week.

Yours,
Daniel

On Tue, Jun 19, 2018 at 9:05 AM, Konda, Tirumaleswar Reddy <
TirumaleswarReddy_Konda@mcafee.com> wrote:

> Hi Daniel,
>
> My comments and nits
>
> 1)
>
>    The current scenario describes the case where the DDoS Target is in
>    the enterprise network while the secondary DMS is provided by the
>    upstream ITP.  An alternate use case may consider the scenario where
>    the ITP informs the enterprise network it is involved into an ongoing
>    attack or that infected machines have been identified.  In this case
>    the DOTS client and DOTS server roles are inverted.  The DOTS client
>    is located in the ITP network and the DOTS server is hosted in the
>    enterprise network.  The enterprise network is then responsible to
>    perform the DDoS Mitigation.  In some case the DDoS Mitigation may be
>    delegated back to the upstream ITP, as described in this section.
>
>

> Comment>  If the DMS in the enterprise network is not capable of detecting
> outgoing DDoS attack, how will the signaling from the DOTS client in the
> upstream ITP to the DOTS server in the enterprise network help it to detect
> and mitigate the outgoing DDoS attack ?
>
> <mglt>

While writing the use case the example I had in mind was that the ITP could
signal the network enterprise that some hosts are being infected and
belonging to a botnet. The ITP could provide a list of suspicious tagged
IPv6 or the indication that hosts are suspected to belong to a specific
botnet.
The network enterprise may then take the necessary action, monitoring
specific DNS requests, running specific scans over its hosts... At least
this what I had in mind. The specific signaling should be defined by DOTS.
Do you think the text should be updated as below ?


OLD:
[...] The enterprise network is then responsible to
   perform the DDoS Mitigation.  In some case the DDoS Mitigation may be
   delegated back to the upstream ITP, as described in this section.

NEW:
[...] The enterprise network is then responsible to
   perform the DDoS Mitigation.  Typically, the ITP could provide a list of
suspicious hosts with some additional information related the detected
attacks such as DDoS, Botnet, .... According to the type of attack, the
enterprise is likely to apply specific security policies which could
include security checks, updates on the tagged hosts as well as
instantiating specific monitoring traffic elements such as certain type of
DNS queries, traffic of specific destination...  In some case the DDoS
Mitigation may be
   delegated back to the upstream ITP, as described in this section.

</mglt>


> 2)
>    Once the requesting Enterprise Network is confident that the DDoS
>    attack has either ceased or has fallen to levels of traffic/
>    complexity which they can handle on their own or that it has received
>    a DOTS DDoS Mitigation termination request from a downstream
>    Enterprise Network or DDoS Mitigation Service Provider, the
>    requesting Enterprise Network DOTS client sends a DOTS DDoS
>    Mitigation termination request to the DDoS Mitigation Service
>    Provider.
>
> Comment> In the above line, I don't get "that it has received a DOTS DDoS
> Mitigation termination request from a downstream Enterprise Network or DDoS
> Mitigation Service Provider".
> I think you mean "or notified by the DDoS Mitigation Service Provider that
> the DDoS attack has stopped"
>
>
<mglt>
The text attempt to provide reasons for a DOTS Client to send a DOTS DDoS
Mitigation termination request. It could be that a) information received
from the upstream DMS indicates the attacks has been stopped or that the
attack is sufficiently low so that it can handle the attack on its own. On
the other hand, in the case of collaboration between DMS, a DMS may end the
collaboration with an upstream DMS because the downstream DMS has requested
so. I propose the follwoing clarification, please let me know if that is
fine with you:


OLD:
Once the requesting Enterprise Network is confident that the DDoS
   attack has either ceased or has fallen to levels of traffic/
   complexity which they can handle on their own or that it has received
   a DOTS DDoS Mitigation termination request from a downstream
   Enterprise Network or DDoS Mitigation Service Provider, the
   requesting Enterprise Network DOTS client sends a DOTS DDoS
   Mitigation termination request to the DDoS Mitigation Service
   Provider.

NEW:
Once the requesting Enterprise Network has been notified by the DDoS
Mitigation Service
   Provider. the attack has been stopped, or that the level of the attack
has fallen to levels of traffic/
   complexity which they can handle on their own, the Enterprise Network
may notify the DDoS Mitigation Service Provider to stop the DDoS
Mitigation. Similarly, when DDoS Mitigation Service
   Providers are collaborating, a DDoS Mitigation Service Provider may
relay the request for terminating a DDoS MItigation to the upstream DoS
Mitigation Service Provider upon request from a downstream  DoS Mitigation
Service Provider. In any case the termination of a DDoS Mitigation is
requested by the Network Enterprise DOTS client sending a DOTS DDoS
Mitigation termination request to the DDoS Mitigation Service Provider.

</mglt>

3)
>
>    The pre-arrangement typically includes the agreement on the
>    mechanisms used to redirect the traffic to the DDoS Mitigation
>    Service Provider, as well as the mechanism to to re-inject the
>
>  >>>>>>>>>>>>>>>>>>>>>>>>>>> Remove "to"
>
> <mglt>
Done
</mglt>

4)
>
>    o  DDoS Mitigation Service: designates a DDoS service provided to a
>       customer and which is scoped to mitigate DDoS attacks.  Services
>       usually involve Service Level Agreement (SLA) that have to be met.
>       It is the responsibility of the service provider to instantiate
>       the DDoS Mitigation System to meet these SLAs.
>
>    o  DDoS Mitigation System (DMS): A system that performs DDoS
>       mitigation.  The DDoS Mitigation System may be composed by a
>       cluster of hardware and/or software resources, but could also
>       involve an orchestrator that may take decisions such as
>       outsourcing partial or more of the mitigation to another DDoS
>       Mitigation System.
>
> Nit> For better readability you may want to define "DMS" followed by "DDoS
> Mitigation Service"
>

<mglt>
Done
</mglt>

>
> 5)
>    DOTS is at risk from three primary attacks: DOTS agent impersonation,
>    traffic injection, and signaling blocking.  The DOTS protocol must be
>    designed for minimal data transfer to address the blocking risk.
>
> Comment> A MITM attacker can drop all the DOTS signal channel traffic,
> designing the DOTS signal channel protocol for minimal data
> transfer will not address the MITM attack.
>

<mglt>
 Agree. I propose to remove:
"""
The DOTS protocol must be
   designed for minimal data transfer to address the blocking risk.
"""
</mglt>

>
> 6)
>    One consideration could be to minimize the security technologies in use
> at any one
>    time.  The more needed, the greater the risk of failures coming from
>    assumptions on one technology providing protection that it does not
>    in the presence of another technology.
>
> Comment> The DOTS signal and data channels are using TLS for mutual
> authentication, confidentiality and data integrity. I don't see the need
> for the above lines.
>
> <mglt>
Agree.  I propose to remove the following lines:
"""
 One consideration could be to minimize the security technologies in use at
any one
   time.  The more needed, the greater the risk of failures coming from
   assumptions on one technology providing protection that it does not
   in the presence of another technology.
"""

</mglt>

> 7)
>    When the DDoS mitigation is finished on the DMS, the orchestrator
>    indicates to the telemetry systems as well as to the network
>    administrator the DDoS mitigation is finished.
>
> Comment> I think you mean the DDoS attack has stopped. You may want to
> rephrase the line.
>

<mglt>
I propose the following text:

OLD:
When the DDoS mitigation is finished on the DMS, the orchestrator
   indicates to the telemetry systems as well as to the network
   administrator the DDoS mitigation is finished.

NEW:
When the DDoS attack has stopped, the orchestrator
   indicates to the telemetry systems as well as to the network
   administrator the end of the DDoS Mitigation.
</mglt>


> 8)
>    Upon receiving the DOTS request for DDoS mitigation from the network
>    administrator, the orchestrator coordinates the DDoS mitigation
>    according to a specified strategy.  Its status indicates the DDoS
>    mitigation is starting while not effective.
>
> Comment> You may want to clarify the DOTS client will later be notified
> that the DDoS mitigation is effective.
>

<mglt>
I propose the following text:

OLD:
Upon receiving the DOTS request for DDoS mitigation from the network
   administrator, the orchestrator coordinates the DDoS mitigation
   according to a specified strategy.  Its status indicates the DDoS
   mitigation is starting while not effective.

NEW:
Upon receiving the DOTS request for DDoS mitigation from the network
   administrator, the orchestrator coordinates the DDoS Mitigation
   according to a specified strategy.  Its status indicates the DDoS
   Mitigation is starting while not effective. The DOTS client of the
orchestrator will later be notified that the DDoS Mitigation is effective.


</mglt>

>
> 9) If the network administrator decides to start the
>    mitigation, they order through her web interface a DOTS client to
>    send a request for DDoS mitigation.
>
> Nit> The above line is not clear, who are "they" in the above line ?
>
> <mglt>
I propose the followin text:

OLD:
If the network administrator decides to start the
   mitigation, they order through her web interface a DOTS client to
   send a request for DDoS mitigation.

NEW:
If the network administrator decides to start the
   mitigation, the network administrator orders through her web interface a
DOTS client to
   send a request for DDoS mitigation.
</mglt>


> 10) This request is expected to be associated with a context that
> identifies the DDoS mitigation selected.
>
> Comment> I don't understand the context of the above line.
>

<mg;t>
The context constitutes of elements, indications that provides sufficient
information to the orchestrator to know what needs to be done. in other
words, the DDoS Mitigation.
I propose the following text:

OLD:
This request is expected to be associated with a context that identifies
the DDoS mitigation selected.

NEW:
This request is expected to be associated with a context that identifies or
provide sufficient information to the orchestrator to in fer the DDoS
Mitigation to elaborate and coordinate.

</mglt>


>
> 11)   Upon receiving the DOTS request for DDoS mitigation from the network
>    administrator, the orchestrator coordinates the DDoS mitigation
>    according to a specified strategy.
>
> Comment> What is the specified strategy (you may want to give an example) ?
>
<mglt>
I propose to add the follwoing text, but I am happy if you are willing to
provide a more specific example.

NEW:
Upon receiving a request to mitigate a DDoS attack performed over a target,
the orchestrator, may evaluate the volumetry of the attack as well as the
value that represent the target. Then it may also request an upstream DMS
Provider to filter the traffic while moving the target to another network
so new sessions will not be impacted.

</mglt>


>
> 12)
> The status of the DDoS mitigation indicates the orchestrator is in an
> analyzing phase.
>


> Comment> DOTS signal channel draft does not indicate the mitigation status
> is in analyzing phase (Please see "Table 2: Values of 'status' Parameter"
> in the draft).
>
> <mglt>
I propose to remove:

"""
The status of the DDoS
mitigation indicates the orchestrator is in an analyzing phase.
"""
</mglt>

13)
> The orchestrator begins collecting various information from various
> telemetry systems in order to correlate the measurements and provide  an
> analysis of the event.
> Comment> The orchestrator would anyway be collecting data from various
> telemetry systems for correlation.
>
> <mglt>
Agree. I think what I wanted to say that we may move to a state where finer
information is being monitored. I porposed the follwoing text:

OLD:
The orchestrator begins collecting various information from various
telemetry systems in order to correlate the measurements and provide  an
analysis of the event.

NEW:
The orchestrator may begin collecting additional fined grain and specific
information from various  telemetry systems in order to correlate the
measurements and provide an analysis of the event.

</mglt>

14) These systems are configured so that when an
>    event or some measurement indicators reach a predefined level to
>    report a DOTS mitigation request to the orchestrator.  The DOTS
>    mitigation request may be associated with some element such as
>    specific reporting.
>
> Comment> what do you mean by "some measurement indicators" and "specific
> reporting" (looks vague to me) ?
>
> <mglt>

measurement indicators means to me, some variables that we believe
representative for threat detection, this typically involved the traffic
load, the number of SYNs...Specific reporting here indicates what the DOTS
client refers to while triggering teh DDoS Mitigation request. I propose
teh follwointext:

OLD:
These systems are configured so that when an
   event or some measurement indicators reach a predefined level to
   report a DOTS mitigation request to the orchestrator.  The DOTS
   mitigation request may be associated with some element such as
   specific reporting.

NEW:
These systems are configured so that when an
   event or some measurement indicators reach a predefined level to
  send DOTS mitigation request to the orchestrator.  The DOTS
   mitigation request may be associated with additional information to let
the orchestrator know what has triggered the request. .

</mglt>

15) Figure 4 (DDoS Orchestration) includes both internal and external DDoS
> mitigation systems, but the usage of internal and external DDoS mitigation
> systems in
>        not discussed in section 3.3.
>
> <mglt>
I propose the following change in teh beginign of teh section:

OLD:
In this use case, one or more DDoS telemetry systems or monitoring
devices monitor a network - typically an ISP network.

NEW:
In this use case, one or more DDoS telemetry systems or monitoring
devices spread over one or multiple administrative domains provides health
indicator of the network traffic to the orchestrator

I also propose to indicate on the figure ( orchetsrator adinistrative
domain / other administraiev domains

</mglt>

16) Redirection to the DDoS
>    Mitigation Service Provider typically involves BGP prefix
>    announcement eventually combined with DNS redirection, while re-
>    injection may be performed via tunneling mechanisms such as GRE for
>    example.
>
> Comment> You may want to clarify the scrubbed traffic is re-directed to
> the Enterprise network via the tunneling mechanism.
>

<mglt>
I propose the following text:

OLD:
Redirection to the DDoS
   Mitigation Service Provider typically involves BGP prefix
   announcement eventually combined with DNS redirection, while re-
   injection may be performed via tunneling mechanisms such as GRE for
   example.

NEW:
Redirection to the DDoS
   Mitigation Service Provider typically involves BGP prefix
   announcement eventually combined with DNS redirection, while re-
   injection to the enterprise network may be performed via tunneling
mechanisms such as GRE for
   example.

</mglt>

>
> 17) Of course, such mechanisms needs to be regularly tested and
>    evaluated.
>
> Comment> The above line does not look relevant to this document.
>
> <mglt>

I am fine removing it.

</mglt>

18)   Once the requesting Enterprise Network is confident that the DDoS
>    attack has either ceased or has fallen to levels of traffic/
>    complexity which they can handle on their own or that it has received
>    a DOTS DDoS Mitigation termination request from a downstream
>    Enterprise Network or DDoS Mitigation Service Provider, the
>    requesting Enterprise Network DOTS client sends a DOTS DDoS
>    Mitigation termination request to the DDoS Mitigation Service
>    Provider.
>
> Comment> It's not clear how the requesting Enterprise network will learn
> the DDoS attack has ceased ?
>
> <mglt>
DOTS status may be used for example. I hope teh text provided for (2)
clarifies this.
</mglt>

> -Tiru
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>