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

From: kaname nishizuka <[email-masked]>
Date: Wed, 4 Jul 2018 15:38:41 +0900

Hi Daniel,

I'd like to propose one change and one nit.

3.1
To improve the clarity of our purpose, the
    targeted network will be designated as enterprise network, but the
    same scenario applies to any downstream network, including
    residential network **and cloud hosting network**.

I'm seeing a lot of DDoS attacks towards cloud type of hosting services.
It would be helpful to include the example, which will not change the story of this usecase(3.1)

Figure 1 to 3
- Entreprise
+ Enterprise

I support the latest draft.

thanks,
Kaname

On 2018/06/27 23:53, Daniel Migault wrote:
> Thanks Tiru for the feed back. I support the idea of your draft. I will publish the agreed version [1]. The diiff can be seen there [2] if there is anything I missed, please let me know.
>
> Additional comments are welcome!
> Yours
> Daniel
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/
> [2] https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-13
>
> On Wed, Jun 27, 2018 at 2:27 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Daniel,
>
>     Thanks for addressing all the comments, Please see inline [TR3]
>
>     *From:* [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf Of *Daniel Migault
>     *Sent:* Tuesday, June 26, 2018 8:10 PM
>     *To:* Konda, Tirumaleswar Reddy <[email-masked]>
>     *Cc:* Tobias Gondrom <[email-masked] <mailto:[email-masked]>>; Roman Danyliw <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [Dots] WGLC for use cases draft - until July-1.
>
>     *CAUTION*:External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>     Hi Tiru,
>
>     Please see my response inline. I believe we are close to reaching a consensus.
>
>     Yours,
>
>     Daniel
>
>     On Tue, Jun 26, 2018 at 7:02 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Daniel,
>
>         Please see inline [TR2]
>
>         *From:* [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf Of *Daniel Migault
>         *Sent:* Tuesday, June 26, 2018 8:33 AM
>         *To:* Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>
>         *Cc:* Tobias Gondrom <[email-masked] <mailto:[email-masked]>>; Roman Danyliw <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>         *Subject:* Re: [Dots] WGLC for use cases draft - until July-1.
>
>         *CAUTION*:External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>         ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>         Hi,
>
>         Thanks for the feed backs. IN my opinion the only issues that remain open are issues 1 and 15 . These are copied below. I provided also inline the status of each issues - for further details. Once we are clear with these two issues, I will publish a new version.
>
>         Thanks you very much for teh comments.
>
>         Yours,
>
>         Daniel
>
>                 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.
>
>             [TR] The above text is not completely clear. The above text assumes hosts in the enterprise network are not behind NAT. Further, DMS in the enterprise network should be monitoring both incoming and outgoing traffic and capable of detecting outgoing DDoS attacks. I think the use case should only focus on volumetric attack exceeding the capacity of the DMS in the Enterprise network and not discuss multiple attack vectors (You may also want to look into the requirement GEN-004 (Mitigation hinting) in the requirements draft).
>
>             </mglt>
>
>         <mglt>
>
>         I understand your comment for the hints. These were example of information provided. I agree to mention as GEN-004 that information is a hints that may be interpreted.
>
>         What is not clear to me is that I do not see how volumetric attacks can be addressed in this case. A volumetric attack whose target is in the Enterprise Network woudl be detected by the DMS of that Enterprise network. In that case the DMS of the Enterprise network will have a DOTS client sending a request to the DOTS Server of the ITP..  This is not the case we consider here as it has already been described as the primary alternative.The reason for a ITP DMS to send a request to the DMS of the Enterprise could be 1) the Enterprise network is taking part of a DDoS atatck, 2) the ITP DMS delegate the DDoS mitigation to the DMS Enterprise network. I see 1) as informing that hosts of the network are being infected and being part of a botnet. I am confused by 2) as I see ITP DMS with ways more resource than the Enterprise network. Could you elaborate a bit on the scenario ?
>
>         [TR2] I meant don’t club incoming and outgoing attacks in the same use case, my suggestion is to focus only on the incoming volumetric attack in this use case.
>
>         If you plan to discuss outgoing attack from the Enterprise network, please add more details why the Enterprise DMS cannot detect the outgoing attacks and how will the additional information provided by the ITP DMS help the Enterprise DMS to detect outgoing DDoS attacks, and how this additional information is useful when the compromised hosts in the Enterprise networks are behind NAT ?
>
>         </mglt>
>
>     <mglt3>
>
>     OK got it. Actually I added this use case after our discussion in the IETF. I believe also its is going a bit beyong the volumetric attacks. I am ok removing it. It has been removed on my local version.
>
>     [TR3] Thanks.  I am facing problems with detecting all types of outgoing DDoS attacks on home routers (only few packets are punted to the slow path for inspection) and I think DOTS can help to punt traffic from compromised devices to slow path for outgoing DDoS traffic detection. Further, additional information like source IP and source ports conveyed in the DOTS signal channel to identify the hosts behind NAT, and the call home feature discussed in https://tools.ietf.org/html/rfc8071 <https://tools.ietf.org/html/rfc8071> is required for DOTS signal channel, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client in the access network, and then the roles get reversed.
>
>     I will try to publish a draft before the DOTS WG meeting at IETF 102.
>
>     </mglt3>
>
>                 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
>
>             [TR] I don’t understand the multiple administrative domain use case. Why would multiple ISPs use the same orchestrator ?
>
>             </mglt>
>
>         <mglt>
>
>         The use case considers the following administrative domains: ITP and Enterprise Network. I propose to simply replace "internal" by Enterprise Network and "external" by ITP.
>
>         [TR2] Okay, but why would the upstream ITP and Enterprise network use the same orchestrator ?
>
>     <mglt3>
>
>     The orchestrator is in the Enterprise Network
>
>     and decides between different DDoS Mitigation Serviec Provider. One of those is hosted in the NEterprise NEtwork, the other one is in the ITP.. Sure they share the same orchestrator, but in my opinion that is the otherway around, the orchestrator got access to multiple providers. How do you think we should clarify this ?
>
>     [TR3] Updated figure looks good to me, Thanks for the clarification.
>
>     Cheers,
>
>     -Tiru
>
>     The figure I am proposing is as below:
>
>                +----------+
>                | network  |C (Enterprise Network)
>                | adminis  |<-+
>                | trator   |  |
>                +----------+  |
>     |
>                +----------+  | S+--------------+     +-----------+
>                |telemetry/| +->|              |C   S| DDoS |+
>                |monitoring|<--->| Orchestrator |<--->| mitigation||
>                |systems   |C S|              |<-+  | systems   ||
>                +----------+ +--------------+C |  +-----------+|
>     |    +----------+
>     -----------------------------------|-----------------
>     |
>     |
>                   (Internet Transit Provider)     |
>     |  +-----------+
>     | S| DDoS      |
>     +->| mitigation|
>     | systems   |
>     +-----------+
>                * C is for DOTS client functionality
>                * S is for DOTS server functionality
>
>        Figure 4: DDoS Orchestration
>
>     </mglt3>
>
>         -Tiru
>
>         </mglt>
>
>         On Sun, Jun 24, 2018 at 4:05 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Hi Daniel,
>
>             Please see inline [TR]
>
>             *From:* [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf Of *Daniel Migault
>             *Sent:* Thursday, June 21, 2018 1:28 AM
>             *To:* Konda, Tirumaleswar Reddy <[email-masked] <http://e.com>>
>             *Cc:* Tobias Gondrom <[email-masked] <mailto:[email-masked]>>; Roman Danyliw <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>             *Subject:* Re: [Dots] WGLC for use cases draft - until July-1.
>
>             *CAUTION*:External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>             ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>             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 <[email-masked] <mailto:[email-masked]>> 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.
>
>             [TR] The above text is not completely clear. The above text assumes hosts in the enterprise network are not behind NAT. Further, DMS in the enterprise network should be monitoring both incoming and outgoing traffic and capable of detecting outgoing DDoS attacks. I think the use case should only focus on volumetric attack exceeding the capacity of the DMS in the Enterprise network and not discuss multiple attack vectors (You may also want to look into the requirement GEN-004 (Mitigation hinting) in the requirements draft).
>
>             </mglt>
>
>         <mglt>
>
>         I understand your comment. These were example of information provided. I agree to mention as GEN-004 that information is a hints that may be interpreted. I do not see how volumetric attacks can be addressed in this case. A volumetric attack whose target is in the Entreprise Network woudl be detected by the DMS of that Enterprise network. In that case the DMS of the Enterprise network will have a DOTS client sending a request to the DOTS Server of the ITP.. This is not the case we consider here as it has already been described as the primary alternative.The reason for a ITP DMS to send a request to the DMS of the Enterprise could be 1) the Enterprise network is taking part of a DDoS atatck, 2) the ITP DMS delegate the DDoS mitigation to the DMS Enterprise network. I see 1) as informing that hosts of the network are being infected and being part of a botnet. I am confused by 2) as I see ITP DMS with ways more resource than the Enterprise network. Could you elaborate a
>         bit on the scenario you have in mind ?
>
>         </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.
>
>             [TR] You may want to simplify the above text as follows :
>
>             The DOTS server notifies the mitigation metrics to the DOTS client. If the DDoS attack has stopped or the severity of the attack has subsided, the DOTS client can request 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.
>
>             [TR] I am not sure about the above lines, DDoS mitigation service providers collaborating with each other does not look relevant to this use case. You may want to remove the above lines.
>
>             </mglt>
>
>         <mglt>
>
>         The reason for mentioning the collaboration was to indicate there are multiple reasons to stop the mitigation. You can be the one deciding given the status provided or your can can do that because you have been asked to do it. I am fine removing the latest case. Done.
>
>         </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>
>
>             [TR] Okay
>
>                 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>
>
>             [TR] Thanks.
>
>
>                 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>
>
>             [TR] Thanks.
>
>         <mglt>
>
>         done
>
>         </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>
>
>             [TR] Okay.
>
>         <mglt>
>
>         done
>
>         </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>
>
>             [TR] Looks good.
>
>         <mglt>
>
>         done
>
>         </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.
>
>             [TR] Looks good.
>
>         <mglt>
>
>         done
>
>         </mglt>
>
>             </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>
>
>             [TR] You may want to remove gender from the above line and simplify the text.
>
>             NEW:
>
>             If the network administrator decides to start the
>             mitigation, the network administrator triggers the DDoS mitigation request using the web interface of a DOTS client.
>
>         <mglt>
>
>         Done
>
>         </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.
>
>             [TR] NEW:
>
>             This request is expected to be associated with a context that provides sufficient information to the orchestrator to infer the DDoS Mitigation to elaborate and coordinate.
>
>             </mglt>
>
>         <mglt
>
>         done
>
>         </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.
>
>             [TR] I don’t think moving the target to a different network is easy. However, the orchestrator may select the DDoS mitigation provider based on the attack severity.
>
>             </mglt>
>
>         <mglt>
>
>         I agree MTD is not easy, but I wanted to stress that the orchestrator can be coordinate complex operations ,that is a bit more than delegating. I have added the following text:
>
>         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. The orchestrator may select the DDoS Mitigation Service Provider based on the attack severity. It may also coordinate the DDoS Mitigation performed by the DDoS Mitigation Service Provider with some other tasks such as for example,  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>
>
>             [TR] Okay
>
>          <mglt>
>
>         Done
>
>         </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.
>
>             [TR] Okay.
>
>             </mglt>
>
>          <mglt>
>
>         Done
>
>         </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.
>
>             [TR] Okay (Mitigation hints (“additional information”) are optional and is not mandatory to be conveyed in the mitigation request).
>
>             </mglt>
>
>         <mglt>
>
>         Done
>
>         The following text has been added:
>
>         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
>         some optional mitigation hints 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
>
>             [TR] I don’t understand the multiple administrative domain use case. Why would multiple ISPs use the same orchestrator ?
>
>             </mglt>
>
>         <mglt>
>
>         The use case considers teh following administrative domains: ITP and Enterprise Network. I propose to simply replace internal by Enterprise Network and external by ITP.
>
>         </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.
>
>             [TR] DNS redirection and BGP routing are two different diversion techniques, DNS redirection is not required after BGP announcement.
>
>             [TR]
>
>             NEW:
>
>             Redirection to the DDoS
>             Mitigation Service Provider typically involves BGP prefix
>             announcement or DNS redirection, while re-injection of the scrubbed traffic to the enterprise network may be performed via tunneling mechanisms such as GRE for
>             example.
>
>             </mglt>
>
>         <mglt>
>
>         Done
>
>         </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.
>
>             [TR] Okay.
>
>             </mglt>
>
>         <mglt>
>
>         Done
>
>         </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.
>
>             [TR] You may want to rephrase the above line similar to the new text you have provided for (2).
>
>             Cheers,
>
>             -Tiru
>
>             </mglt>
>
>                 -Tiru
>
>                 _______________________________________________
>                 Dots mailing list
>                 [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/listinfo/dots <https://www.ietf.org/mailman/listinfo/dots>
>
>
>             _______________________________________________
>             Dots mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/dots <https://www.ietf.org/mailman/listinfo/dots>
>
>
>         _______________________________________________
>         Dots mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/dots <https://www.ietf.org/mailman/listinfo/dots>
>
>
>     _______________________________________________
>     Dots mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/dots <https://www.ietf.org/mailman/listinfo/dots>
>
>
>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Daniel Migault <[email-masked]>
Date: Wed, 4 Jul 2018 09:03:45 -0400

Thanks for the feed backs Kanama. I push the changes on the git repo:

https://github.com/dotswg/dots-use-cases/commit/049ae7370c54661b76feba56ddea7f6fc683b0d5

Yours,
Daniel

On Wed, Jul 4, 2018 at 2:38 AM, kaname nishizuka <[email-masked]> wrote:

> Thanks Tiru for the feed back. I support the idea of your draft. I will
> publish the agreed version [1]. The diiff can be seen there [2] if there is
> anything I missed, please let me know.
>
> On Wed, Jun 27, 2018 at 2:27 AM, Konda, Tirumaleswar Reddy <
> [email-masked]> wrote:
>
>> Hi Daniel,
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Daniel
>> Migault
>> *Cc:* Tobias Gondrom <[email-masked]>; Roman Danyliw <
>> [email-masked]>; [email-masked]
>> *CAUTION*: External email. Do not click links or open attachments unless
>> you recognize the sender and know the content is safe.
>> ------------------------------
>>
>> Hi Tiru,
>>
>>
>>
>> On Tue, Jun 26, 2018 at 7:02 AM, Konda, Tirumaleswar Reddy <
>> [email-masked]> wrote:
>>
>> Hi Daniel,
>>
>>
>>
>> Please see inline [TR2]
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]
>> <[email-masked]>] *On Behalf Of *Daniel Migault
>> *Cc:* Tobias Gondrom <[email-masked]>; Roman Danyliw <
>> [email-masked]>; [email-masked]
>> *CAUTION*: External email. Do not click links or open attachments unless
>> you recognize the sender and know the content is safe.
>> ------------------------------
>>
>> Hi,
>>
>>
>>
>> Thanks for the feed backs. IN my opinion the only issues that remain open
>> are issues 1 and 15 . These are copied below. I provided also inline the
>> status of each issues - for further details. Once we are clear with these
>> two issues, I will publish a new version.
>>
>>
>>
>> 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:
>>
>>    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
>> [TR] The above text is not completely clear. The above text assumes hosts
>> in the enterprise network are not behind NAT. Further, DMS in the
>> enterprise network should be monitoring both incoming and outgoing traffic
>> and capable of detecting outgoing DDoS attacks. I think the use case should
>> only focus on volumetric attack exceeding the capacity of the DMS in the
>> Enterprise network and not discuss multiple attack vectors (You may also
>> want to look into the requirement GEN-004 (Mitigation hinting) in the
>> requirements draft).
>>
>> </mglt>
>>
>>
>>
>> <mglt>
>>
>> I understand your comment for the hints. These were example of
>> information provided. I agree to mention as GEN-004 that information is a
>> hints that may be interpreted.
>>
>> What is not clear to me is that I do not see how volumetric attacks can
>> be addressed in this case. A volumetric attack whose target is in the
>> Enterprise Network woudl be detected by the DMS of that Enterprise network.
>> In that case the DMS of the Enterprise network will have a DOTS client
>> sending a request to the DOTS Server of the ITP..  This is not the case we
>> consider here as it has already been described as the primary
>> alternative.The reason for a ITP DMS to send a request to the DMS of the
>> Enterprise could be 1) the Enterprise network is taking part of a DDoS
>> atatck, 2) the ITP DMS delegate the DDoS mitigation to the DMS Enterprise
>> network. I see 1) as informing that hosts of the network are being infected
>> and being part of a botnet. I am confused by 2) as I see ITP DMS with ways
>> more resource than the Enterprise network. Could you elaborate a bit on the
>> scenario ?
>>
>>
>>
>> [TR2] I meant don’t club incoming and outgoing attacks in the same use
>> case, my suggestion is to focus only on the incoming volumetric attack in
>> this use case.
>>
>> If you plan to discuss outgoing attack from the Enterprise network,
>> please add more details why the Enterprise DMS cannot detect the outgoing
>> attacks and how will the additional information provided by the ITP DMS
>> help the Enterprise DMS to detect outgoing DDoS attacks, and how this
>> additional information is useful when the compromised hosts in the
>> Enterprise networks are behind NAT ?
>>
>>
>>
>> </mglt>
>>
>> <mglt3>
>>
>> OK got it. Actually I added this use case after our discussion in the
>> IETF. I believe also its is going a bit beyong the volumetric attacks. I am
>> ok removing it. It has been removed on my local version.
>>
>>
>>
>> [TR3] Thanks.  I am facing problems with detecting all types of outgoing
>> DDoS attacks on home routers (only few packets are punted to the slow path
>> for inspection) and I think DOTS can help to punt traffic from compromised
>> devices to slow path for outgoing DDoS traffic detection. Further,
>> additional information like source IP and source ports conveyed in the DOTS
>> signal channel to identify the hosts behind NAT, and the call home feature
>> discussed in https://tools.ietf.org/html/rfc8071 is required for DOTS
>> signal channel, though the CPE is acting as a DOTS server it will initiate
>> the connection (TLS or DTLS) to the DOTS client in the access network, and
>> then the roles get reversed.
>>
>>
>>
>> 15) Figure 4 (DDoS Orchestration) includes both internal and external
>> DDoS mitigation systems, but the usage of internal and external DDoS
>> mitigation systems in
>> devices spread over one or multiple administrative domains provides
>> health indicator of the network traffic to the orchestrator
>>
>>
>>
>> [TR] I don’t understand the multiple administrative domain use case. Why
>> would multiple ISPs use the same orchestrator ?
>>
>>
>>
>> </mglt>
>>
>>
>>
>> <mglt>
>>
>> The use case considers the following administrative domains: ITP and
>> Enterprise Network. I propose to simply replace "internal" by Enterprise
>> Network and "external" by ITP.
>>
>>
>>
>> and decides between different DDoS Mitigation Serviec Provider. One of
>> those is hosted in the NEterprise NEtwork, the other one is in the ITP..
>> Sure they share the same orchestrator, but in my opinion that is the
>> otherway around, the orchestrator got access to multiple providers. How do
>> you think we should clarify this ?
>>
>>
>>
>> On Sun, Jun 24, 2018 at 4:05 AM, Konda, Tirumaleswar Reddy <
>> [email-masked]> wrote:
>>
>> Hi Daniel,
>>
>>
>>
>> Please see inline [TR]
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]
>> <[email-masked]>] *On Behalf Of *Daniel Migault
>> *Cc:* Tobias Gondrom <[email-masked]>; Roman Danyliw <
>> [email-masked]>; [email-masked]
>> *CAUTION*: External email. Do not click links or open attachments unless
>> you recognize the sender and know the content is safe.
>> ------------------------------
>>
>> 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 <
>> [email-masked]> wrote:
>>
>> Hi Daniel,
>>
>> My comments and nits
>>
>> 1)
>>
>> 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:
>>
>>    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
>> [TR] The above text is not completely clear. The above text assumes hosts
>> in the enterprise network are not behind NAT. Further, DMS in the
>> enterprise network should be monitoring both incoming and outgoing traffic
>> and capable of detecting outgoing DDoS attacks. I think the use case should
>> only focus on volumetric attack exceeding the capacity of the DMS in the
>> Enterprise network and not discuss multiple attack vectors (You may also
>> want to look into the requirement GEN-004 (Mitigation hinting) in the
>> requirements draft).
>>
>> </mglt>
>>
>>
>>
>> <mglt>
>>
>> I understand your comment. These were example of information provided. I
>> agree to mention as GEN-004 that information is a hints that may be
>> interpreted. I do not see how volumetric attacks can be addressed in this
>> case. A volumetric attack whose target is in the Entreprise Network woudl
>> be detected by the DMS of that Enterprise network. In that case the DMS of
>> the Enterprise network will have a DOTS client sending a request to the
>> DOTS Server of the ITP..  This is not the case we consider here as it has
>> already been described as the primary alternative.The reason for a ITP DMS
>> to send a request to the DMS of the Enterprise could be 1) the Enterprise
>> network is taking part of a DDoS atatck, 2) the ITP DMS delegate the DDoS
>> mitigation to the DMS Enterprise network. I see 1) as informing that hosts
>> of the network are being infected and being part of a botnet. I am confused
>> by 2) as I see ITP DMS with ways more resource than the Enterprise network.
>> Could you elaborate a bit on the scenario you have in mind ?
>>
>>
>>
>> </mglt>
>>
>>
>> 2)
>> 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".
>> 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:
>>
>>    complexity which they can handle on their own, the Enterprise Network
>> may notify the DDoS Mitigation Service Provider to stop the DDoS
>> Mitigation.
>>
>>
>>
>>
>>
>> The DOTS server notifies the mitigation metrics to the DOTS client. If
>> the DDoS attack has stopped or the severity of the attack has subsided, the
>> DOTS client can request 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.
>>
>>
>>
>> [TR] I am not sure about the above lines, DDoS mitigation service
>> providers collaborating with each other does not look relevant to this use
>> case. You may want to remove the above lines.
>>
>>
>>
>> </mglt>
>>
>>
>>
>> <mglt>
>>
>> The reason for mentioning the collaboration was to indicate there are
>> multiple reasons to stop the mitigation. You can be the one deciding given
>> the status provided or your can can do that because you have been asked to
>> do it. I am fine removing the latest case. Done.
>>
>>
>>
>> </mglt>
>>
>> 3)
>>
>>  >>>>>>>>>>>>>>>>>>>>>>>>>>> Remove "to"
>> Comment> A MITM attacker can drop all the DOTS signal channel traffic,
>> designing the DOTS signal channel protocol for minimal data
>> 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>
>>
>>    Mitigation is starting while not effective. The DOTS client of the
>> orchestrator will later be notified that the DDoS Mitigation is effective.
>>
>>
>>
>> [TR] Looks good.
>>
>>
>>
>> <mglt>
>>
>> done
>>
>> </mglt>
>>
>>
>>
>>
>>
>> </mglt>
>>
>>
>> mitigation, the network administrator triggers the DDoS mitigation
>> request using the web interface of a DOTS client.
>>
>>
>>
>>
>>
>> <mglt>
>>
>> Done
>>
>> </mglt>
>>
>> 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.
>>
>> 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.
>>
>>
>>
>> [TR] NEW:
>>
>> This request is expected to be associated with a context that provides
>> sufficient information to the orchestrator to infer the DDoS Mitigation to
>> elaborate and coordinate.
>>
>>
>>
>>
>>
>> </mglt>
>>
>>
>>
>> <mglt
>>
>> done
>>
>> </mglt>
>>
>>
>> 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.
>>
>>
>>
>> [TR] I don’t think moving the target to a different network is easy.
>> However, the orchestrator may select the DDoS mitigation provider based on
>> the attack severity.
>>
>>
>>
>> </mglt>
>>
>>
>>
>> <mglt>
>>
>> I agree MTD is not easy, but I wanted to stress that the orchestrator can
>> be coordinate complex operations ,that is a bit more than delegating. I
>> have added the following text:
>>
>>
>>
>> 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. The orchestrator may select the
>> DDoS Mitigation Service  Provider based on the attack severity. It may also
>> coordinate the DDoS Mitigation performed by the DDoS Mitigation Service
>> Provider with some other tasks such as for example,  moving the target to
>> another network so new sessions will not be impacted.
>>
>>
>>
>>
>>
>> </mglt>
>>
>>
>> 12)
>> 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
>> The orchestrator begins collecting various information from various
>> telemetry systems in order to correlate the measurements and provide  an
>> analysis of the event.
>> 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.
>>
>>
>>
>> [TR] Okay.
>>
>>
>>
>> </mglt>
>>
>>
>>
>>  <mglt>
>>
>> Done
>>
>> </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:
>>
>>    mitigation request may be associated with additional information to
>> let the orchestrator know what has triggered the request.
>>
>>
>>
>> [TR] Okay (Mitigation hints (“additional information”) are optional and
>> is not mandatory to be conveyed in the mitigation request).
>>
>>
>>
>> </mglt>
>>
>>
>>
>>
>>
>> <mglt>
>>
>>
>>
>> Done
>>
>>
>>
>> 15) Figure 4 (DDoS Orchestration) includes both internal and external
>> DDoS mitigation systems, but the usage of internal and external DDoS
>> mitigation systems in
>> devices spread over one or multiple administrative domains provides
>> health indicator of the network traffic to the orchestrator
>>
>>
>>
>> [TR] I don’t understand the multiple administrative domain use case. Why
>> would multiple ISPs use the same orchestrator ?
>>
>>
>>
>> </mglt>
>>
>>
>>
>> <mglt>
>>
>> The use case considers teh following administrative domains: ITP and
>> Enterprise Network. I propose to simply replace internal by Enterprise
>> Network and external by ITP.
>>
>>
>>
>> </mglt>
>>
>> Comment> You may want to clarify the scrubbed traffic is re-directed to
>> the Enterprise network via the tunneling mechanism.
>>
>>
>>
>> <mglt>
>>
>> [TR] DNS redirection and BGP routing are two different diversion
>> techniques, DNS redirection is not required after BGP announcement.
>>
>>
>>
>> [TR]
>>
>> NEW:
>>
>> Redirection to the DDoS
>> announcement or DNS redirection, while re-injection of the scrubbed
>> traffic to the enterprise network may be performed via tunneling mechanisms
>> such as GRE for
>> example.
>>
>>
>>
>>
>>
>> </mglt>
>>
>>
>>
>> <mglt>
>>
>> Done
>>
>> </mglt>
>>
>>
>>
> Dots mailing [email-masked]://www.ietf.org/mailman/listinfo/dots
>
>
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 16 Jul 2018 09:16:52 +0000

Hi Daniel,

Few more comments and nits:

1.
OLD:
   Impersonation and traffic injection mitigation can be managed through
   current secure communications best practices.
NEW:
   Impersonation and traffic injection attacks can be mitigated through
   current secure communications best practices.

2. In this use case, one or more DDoS telemetry systems or monitoring

Comment> why do say “typically an ISP network” ? (DDoS telemetry systems can also be used by Large Data Centers and Enterprises).

3. The orchestrator analyses the various information it receives from

   specialized equipment, and elaborates one or multiple DDoS mitigation

   strategies.

Comment> What kind of “specialized equipment” ? (You may want to re-use the previously defined term “DDoS telemetry system” instead of using specialized equipment).
Comment> I think you mean “finalizes one or multiple DDoS mitigation strategies”.
Comment> You may want to give examples of the DDoS mitigation strategies.

4.

OLD:

In some case, a manual confirmation may also be required

to choose a proposed strategy or to initiate a DDoS Mitigation.

NEW:

In some cases, manual selection by a human operator may also be required

to choose a proposed strategy or to initiate a DDoS Mitigation.

5. The

   DDoS Mitigation may consist of multiple steps such as configuring the

   network, or updating already instantiated DDoS mitigation functions.

   In some cases, some specific DDoS mitigation functions must be

   instantiated and properly ordered.

Comment> What kind of update is required for the instantiated DDoS mitigation function ?

Comment> What do you mean by “properly ordered” ?

6.

OLD:

   The communications used to trigger a DDoS Mitigation between the

   telemetry and monitoring systems and the orchestrator is performed

   using DOTS.

NEW:

   The communications used to trigger DDoS Mitigation between the

   DDoS telemetry systems and the orchestrator is performed

   using DOTS.

-Tiru

From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Wednesday, June 27, 2018 8:24 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Tobias Gondrom <[email-masked]>; Roman Danyliw <[email-masked]>; [email-masked]
Subject: Re: [Dots] WGLC for use cases draft - until July-1.

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Thanks Tiru for the feed back. I support the idea of your draft. I will publish the agreed version [1]. The diiff can be seen there [2] if there is anything I missed, please let me know.

On Wed, Jun 27, 2018 at 2:27 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Daniel Migault
Sent: Tuesday, June 26, 2018 8:10 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
Cc: Tobias Gondrom <[email-masked]<mailto:[email-masked]>>; Roman Danyliw <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] WGLC for use cases draft - until July-1.

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi Tiru,

Yours,
Daniel

On Tue, Jun 26, 2018 at 7:02 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

Please see inline [TR2]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Daniel Migault
Sent: Tuesday, June 26, 2018 8:33 AM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
Cc: Tobias Gondrom <[email-masked]<mailto:[email-masked]>>; Roman Danyliw <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] WGLC for use cases draft - until July-1.

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi,

Yours,
Daniel

1)

OLD:

<mglt>

</mglt>
<mglt3>

[TR3] Thanks.  I am facing problems with detecting all types of outgoing DDoS attacks on home routers (only few packets are punted to the slow path for inspection) and I think DOTS can help to punt traffic from compromised devices to slow path for outgoing DDoS traffic detection. Further, additional information like source IP and source ports conveyed in the DOTS signal channel to identify the hosts behind NAT, and the call home feature discussed in https://tools.ietf.org/html/rfc8071 is required for DOTS signal channel, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client in the access network, and then the roles get reversed.

</mglt3>

OLD:

NEW:

</mglt>

<mglt>

Cheers,
-Tiru

           +----------+

</mglt3>

-Tiru

</mglt>

On Sun, Jun 24, 2018 at 4:05 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

Please see inline [TR]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Daniel Migault
Sent: Thursday, June 21, 2018 1:28 AM
To: Konda, Tirumaleswar Reddy <[email-masked]<http://e.com>>
Cc: Tobias Gondrom <[email-masked]<mailto:[email-masked]>>; Roman Danyliw <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] WGLC for use cases draft - until July-1.

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi Tiru,

Yours,
Daniel

On Tue, Jun 19, 2018 at 9:05 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

My comments and nits

1)

OLD:

<mglt>
I understand your comment. These were example of information provided. I agree to mention as GEN-004 that information is a hints that may be interpreted. I do not see how volumetric attacks can be addressed in this case. A volumetric attack whose target is in the Entreprise Network woudl be detected by the DMS of that Enterprise network. In that case the DMS of the Enterprise network will have a DOTS client sending a request to the DOTS Server of the ITP..  This is not the case we consider here as it has already been described as the primary alternative.The reason for a ITP DMS to send a request to the DMS of the Enterprise could be 1) the Enterprise network is taking part of a DDoS atatck, 2) the ITP DMS delegate the DDoS mitigation to the DMS Enterprise network. I see 1) as informing that hosts of the network are being infected and being part of a botnet. I am confused by 2) as I see ITP DMS with ways more resource than the Enterprise network. Could you elaborate a bit on the scenario you have in mind ?

</mglt>

2)

<mglt>

OLD:

NEW:

</mglt>

<mglt>

</mglt>
3)

<mglt>
Done
</mglt>

[TR] Okay

4)

<mglt>
Done
</mglt>

[TR] Thanks.

5)

<mglt>

[TR] Thanks.

<mglt>
done
</mglt>

6)

</mglt>

[TR] Okay.

<mglt>
done
</mglt>
7)

<mglt>

OLD:

NEW:

[TR] Looks good.
<mglt>
done
</mglt>

8)

<mglt>

OLD:

NEW:

[TR] Looks good.

<mglt>
done
</mglt>

</mglt>

OLD:

NEW:

<mglt>
Done
</mglt>

<mg;t>

OLD:

NEW:

[TR] NEW:

</mglt>

<mglt
done
</mglt>

NEW:

</mglt>

<mglt>

NEW:

</mglt>

12)

"""
The status of the DDoS

[TR] Okay

 <mglt>
Done
</mglt>
13)

OLD:

NEW:

[TR] Okay.

</mglt>

 <mglt>
Done
</mglt>

OLD:

NEW:

</mglt>

<mglt>

Done

OLD:

NEW:

</mglt>

<mglt>

</mglt>

<mglt>

OLD:
Redirection to the DDoS

NEW:
Redirection to the DDoS

[TR]
NEW:
Redirection to the DDoS

</mglt>

<mglt>
Done
</mglt>

I am fine removing it.

[TR] Okay.

</mglt>
<mglt>
Done
</mglt>

Cheers,
-Tiru

</mglt>
-Tiru
_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

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

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

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

---

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Jul 2018 13:20:19 -0400

Hi Tiru,

Please find my comments inline. Most of your comments have been addressed,
I am waiting for your answer before updating and publishing the draft.

Yours,
Daniel

>    current secure communications best practices.
<mglt>
corrected
</mglt>

> Comment> why do say “typically an ISP network” ? (DDoS telemetry systems
> can also be used by Large Data Centers and Enterprises).
>
>
>
<mglt>
enterprise network and data centers have been added.
</mglt>

> Comment> What kind of “specialized equipment” ? (You may want to re-use
> the previously defined term “DDoS telemetry system” instead of using
> specialized equipment).
>
<mglt>
done
</mglt>

Comment> I think you mean “finalizes one or multiple DDoS mitigation
> strategies”.

<mglt>
I think you propose to replace "ellaborate" by "finalize". I think finalize
mena sthat mitigation has already started, which may not be the case. Maybe
"initiate" may be better ?
</mglt>

> Comment> You may want to give examples of the DDoS mitigation strategies.
<mglt>
I am happy to see what level of granularity or type of example you are
willing to put. I have the impression that sky is the limit, and thus any
example would be very specific. I am happy to add the text you are willing
to see ;-)
</mglt>

> to choose a proposed strategy or to initiate a DDoS Mitigation.
proposed text:
selection or confirmation
</mglt>

> Comment> What kind of update is required for the instantiated DDoS mitigation function ?
by update I meant using the appropriated functions. More specifically,
depending on the information you monitor you may use different anti DDoS
function -- specific to the protocols. Ordered refers to the potential way
functions are "orchetsrated". This means that you may have one SFC with
multiple functions organized, this organization may change dynamically
depending on the measurements.
</mglt>

>    DDoS telemetry systems and the orchestrator is performed
telemetry has been changed to DDoS throughout the doc.
</mglt>

> *Sent:* Wednesday, June 27, 2018 8:24 PM
> 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>
>
>
>
> I understand your comment for the hints. These were example of information
> provided. I agree to mention as GEN-004 that information is a hints that
> may be interpreted.
>
> What is not clear to me is that I do not see how volumetric attacks can be
> addressed in this case. A volumetric attack whose target is in the
> If you plan to discuss outgoing attack from the Enterprise network, please
> add more details why the Enterprise DMS cannot detect the outgoing attacks
> and how will the additional information provided by the ITP DMS help the
> Enterprise DMS to detect outgoing DDoS attacks, and how this additional
> information is useful when the compromised hosts in the Enterprise networks
> are behind NAT ?
>
>
>
> </mglt>
>
> <mglt3>
>
> 15) Figure 4 (DDoS Orchestration) includes both internal and external DDoS
> mitigation systems, but the usage of internal and external DDoS mitigation
> systems in
> devices spread over one or multiple administrative domains provides health
> indicator of the network traffic to the orchestrator
>
>
>
> 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>
>
>
>
> The DOTS server notifies the mitigation metrics to the DOTS client. If the
> DDoS attack has stopped or the severity of the attack has subsided, the
> mitigation, the network administrator triggers the DDoS mitigation request
> using the web interface of a DOTS client.
>
>
>
>
>
> <mglt>
>
> Done
>
> </mglt>
>
> the DDoS mitigation selected.
>
>
>
> NEW:
>
> 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 request may be associated with additional information to let
> the orchestrator know what has triggered the request.
>
>
>
> [TR] Okay (Mitigation hints (“additional information”) are optional and is
> not mandatory to be conveyed in the mitigation request).
>
>
>
> </mglt>
>
>
>
>
>
> <mglt>
>
>
>
> Done
>
>
>
> 15) Figure 4 (DDoS Orchestration) includes both internal and external DDoS
> mitigation systems, but the usage of internal and external DDoS mitigation
> systems in
> devices spread over one or multiple administrative domains provides health
> indicator of the network traffic to the orchestrator
>
>
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 18 Jul 2018 09:05:30 +0000

Hi Daniel,

Please see inline [TR]

Sent: Tuesday, July 17, 2018 10:50 PM

Please find my comments inline. Most of your comments have been addressed, I am waiting for your answer before updating and publishing the draft.

Yours,
Daniel

On Mon, Jul 16, 2018 at 5:16 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

1.
OLD:

<mglt>
corrected
</mglt>

<mglt>

   strategies.

<mglt>
I think you propose to replace "ellaborate" by "finalize". I think finalize mena sthat mitigation has already started, which may not be the case. Maybe "initiate" may be better ?

[TR] Yes.

</mglt>
Comment> You may want to give examples of the DDoS mitigation strategies.
<mglt>
I am happy to see what level of granularity or type of example you are willing to put. I have the impression that sky is the limit, and thus any example would be very specific. I am happy to add the text you are willing to see ;-)

[TR] In this use case, the orchestrator can either select the DDoS mitigation system in the Enterprise network or the one provided by the Internet transit provider and the mitigation technique will depend on the type of DDoS attack.
As pre my understanding, Mitigation strategy is a pro-active step to enhance the mitigation infrastructure to handle sophisticated DDoS attacks (e.g. handle large scale DDoS attacks by adding more scrubbing centers).

</mglt>

4.

OLD:

NEW:

<mglt>
proposed text:

[TR] Okay.

</mglt>

5. The

Comment> What kind of update is required for the instantiated DDoS mitigation function ?
<mglt>
by update I meant using the appropriated functions. More specifically, depending on the information you monitor you may use different anti DDoS function -- specific to the protocols. Ordered refers to the potential way functions are "orchetsrated". This means that you may have one SFC with multiple functions organized, this organization may change dynamically depending on the measurements.

[TR] The above text  looks specific to SFC, DDoS mitigation provider may or may not use SFC.  You may want explicitly discuss the above line in the context of SFC.  DDoS attack can evolve into a multi-vector attack and the DDoS mitigator has to handle the attack traffic spanning multiple layers.

</mglt>

6.

OLD:

   using DOTS.

NEW:

   using DOTS.

<mglt>

[TR] Okay.

Thanks,
-Tiru

</mglt>
-Tiru

Yours,
Daniel

Please see inline [TR2]

Yours,
Daniel

1)

OLD:

<mglt>

</mglt>
<mglt3>

</mglt3>

OLD:

NEW:

</mglt>

<mglt>

Cheers,
-Tiru

           +----------+

</mglt3>

-Tiru

</mglt>

Please see inline [TR]

Yours,
Daniel

My comments and nits

1)

OLD:

<mglt>

</mglt>

2)

<mglt>

OLD:

NEW:

</mglt>

<mglt>

</mglt>
3)

<mglt>
Done
</mglt>

[TR] Okay

4)

<mglt>
Done
</mglt>

[TR] Thanks.

5)

<mglt>

[TR] Thanks.

<mglt>
done
</mglt>

6)

</mglt>

[TR] Okay.

<mglt>
done
</mglt>
7)

<mglt>

OLD:

NEW:

[TR] Looks good.
<mglt>
done
</mglt>

8)

<mglt>

OLD:

NEW:

[TR] Looks good.

<mglt>
done
</mglt>

</mglt>

OLD:

NEW:

<mglt>
Done
</mglt>

<mg;t>

OLD:

NEW:

[TR] NEW:

</mglt>

<mglt
done
</mglt>

NEW:

</mglt>

<mglt>

NEW:

</mglt>

12)

"""
The status of the DDoS

[TR] Okay

 <mglt>
Done
</mglt>
13)

OLD:

NEW:

[TR] Okay.

</mglt>

 <mglt>
Done
</mglt>

OLD:

NEW:

</mglt>

<mglt>

Done

OLD:

NEW:

</mglt>

<mglt>

</mglt>

<mglt>

OLD:
Redirection to the DDoS

NEW:
Redirection to the DDoS

[TR]
NEW:
Redirection to the DDoS

</mglt>

<mglt>
Done
</mglt>

I am fine removing it.

[TR] Okay.

</mglt>
<mglt>
Done
</mglt>

Cheers,
-Tiru

</mglt>
-Tiru

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Jul 2018 09:57:12 -0400

Thanks for the feed back. I should be able to update the document
appropriately. I will clarify by mentioning SFC as a possible way/example
to have more complex,  fine-tuned DDoS Mitigation strategies.

Thanks you for the comments! Will do that hopefully this week.

Yours,
Daniel

On Wed, Jul 18, 2018 at 5:05 AM, Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> *Sent:* Tuesday, July 17, 2018 10:50 PM
> I think you propose to replace "ellaborate" by "finalize". I think
> finalize mena sthat mitigation has already started, which may not be the
> case. Maybe "initiate" may be better ?
>
>
>
> [TR] Yes.
>
>
>
> </mglt>
>
> [TR] In this use case, the orchestrator can either select the DDoS
> mitigation system in the Enterprise network or the one provided by the
> Internet transit provider and the mitigation technique will depend on the
> type of DDoS attack.
>
> As pre my understanding, Mitigation strategy is a pro-active step to
> enhance the mitigation infrastructure to handle sophisticated DDoS attacks
> (e.g. handle large scale DDoS attacks by adding more scrubbing centers).
>
>
>
> </mglt>
>
>
>
>
>
> 4.
>
>
>
> OLD:
>
>
>
> [TR] The above text  looks specific to SFC, DDoS mitigation provider may
> or may not use SFC.  You may want explicitly discuss the above line in the
> context of SFC.  DDoS attack can evolve into a multi-vector attack and the
> DDoS mitigator has to handle the attack traffic spanning multiple layers.
>
>
>
> </mglt>
>
> ...
> [Message clipped]

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Jul 2018 11:00:45 -0400

Hi Tiru,

I believe the text below addresses your concerns:

"""
The orchestrator analyses the various information it receives from DDoS
telemetry system, and initiates one or multiple DDoS mitigation
strategies. For example, the orchestrator could select the DDoS
mitigation system in the Enterprise network or one provided by the ITP.
Selection and technique may depends on the type of DDoS attack. In some
cases, the orchestrator may proceed to a coordination that could occurs
at a finer granularity such as the service functions involved into the
DDoS Mitigation. Such orchestration is especially targeting DDoS attacks
that evolves into mutli-vector attacks and could typically be
implemented in a Service Function Chaining (SFC) {{?RFC7665}} context.
In some case, a manual confirmation or selection may also be required to
choose a proposed strategy or to initiate a DDoS Mitigation.  The DDoS
Mitigation may consist of multiple steps such as configuring the
network, or updating already instantiated DDoS mitigation functions.  In
some SFC context, some specific  DDoS mitigation functions must be
instantiated and properly ordered. Eventually, the coordination of the
mitigation may involve external DDoS resources such as a transit
provider or a DDoS Mitigation Service Provider.
"""

Yours,
Daniel

> </mglt>Comment> What do you mean by “properly ordered” ?
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 18 Jul 2018 15:35:35 +0000

Hi Daniel,

Please see inline [TR]

Sent: Wednesday, July 18, 2018 8:31 PM

"""
Selection and technique may depends on the type of DDoS attack.

[TR] I think you mean “The DDoS mitigation system selection and mitigation technique depends on the type of the DDoS attack”.

In some

[TR] On second thought, I suggest removing rest of the above lines (discussing SFC and instantiation of DDOS mitigation functions looks like distraction to me)

-Tiru

"""

Yours,
Daniel

On Wed, Jul 18, 2018 at 5:05 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

Please see inline [TR]

Yours,
Daniel

1.
OLD:

<mglt>
corrected
</mglt>

<mglt>

   strategies.

<mglt>

[TR] Yes.

</mglt>

</mglt>

4.

OLD:

NEW:

<mglt>
proposed text:

[TR] Okay.

</mglt>

5. The

6.

OLD:

   using DOTS.

NEW:

   using DOTS.

<mglt>

[TR] Okay.

Thanks,
-Tiru

</mglt>
-Tiru

Yours,
Daniel

Please see inline [TR2]

Yours,
Daniel

1)

OLD:

<mglt>

</mglt>
<mglt3>

</mglt3>

OLD:

NEW:

</mglt>

<mglt>

Cheers,
-Tiru

           +----------+

</mglt3>

-Tiru

</mglt>

Please see inline [TR]

Yours,
Daniel

My comments and nits

1)

OLD:

<mglt>

</mglt>

2)

<mglt>

OLD:

NEW:

</mglt>

<mglt>

</mglt>
3)

<mglt>
Done
</mglt>

[TR] Okay

4)

<mglt>
Done
</mglt>

[TR] Thanks.

5)

<mglt>

[TR] Thanks.

<mglt>
done
</mglt>

6)

</mglt>

[TR] Okay.

<mglt>
done
</mglt>
7)

<mglt>

OLD:

NEW:

[TR] Looks good.
<mglt>
done
</mglt>

8)

<mglt>

OLD:

NEW:

[TR] Looks good.

<mglt>
done
</mglt>

</mglt>

OLD:

NEW:

<mglt>
Done
</mglt>

<mg;t>

OLD:

NEW:

[TR] NEW:

</mglt>

<mglt
done
</mglt>

NEW:

</mglt>

<mglt>

NEW:

</mglt>

12)

"""
The status of the DDoS

[TR] Okay

 <mglt>
Done
</mglt>
13)

OLD:

NEW:

[TR] Okay.

</mglt>

 <mglt>
Done
</mglt>

OLD:

NEW:

</mglt>

<mglt>

Done

OLD:

NEW:

</mglt>

<mglt>

</mglt>

<mglt>

OLD:
Redirection to the DDoS

NEW:
Redirection to the DDoS

[TR]
NEW:
Redirection to the DDoS

</mglt>

<mglt>
Done
</mglt>

I am fine removing it.

[TR] Okay.

</mglt>
<mglt>
Done
</mglt>

Cheers,
-Tiru

</mglt>
-Tiru

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Jul 2018 11:44:37 -0400

The reason I would rather leave the SFC is to show that orchestration may
be a bit more complex than selecting a DDoS Service Provider and can be
used to deploy your own orchestration. That said, if the WG prefers to
removes this I am fine removing it. If you have an opinion, please raise
you opinion asap!

Yours,
Daniel

On Wed, Jul 18, 2018 at 11:35 AM, Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> *Sent:* Wednesday, July 18, 2018 8:31 PM
> [TR] I think you mean “The DDoS mitigation system selection and mitigation
> technique depends on the type of the DDoS attack”.
>
>
>
> In some
> [TR] On second thought, I suggest removing rest of the above lines
> (discussing SFC and instantiation of DDOS mitigation functions looks like
> distraction to me)
>
>
>
> -Tiru
>
>
>
> """
>
>
>
> Yours,
>
> Daniel
>
>
>

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 19 Jul 2018 03:02:34 +0900

I  prefers to remove this.
An orchestrator may or may not use SFC technology.
The text itself seems correct, but I feel reference to SFC in this context is distraction.

regards,
Kaname

On 2018/07/19 0:44, Daniel Migault wrote:
> The reason I would rather leave the SFC is to show that orchestration may be a bit more complex than selecting a DDoS Service Provider and can be used to deploy your own orchestration. That said, if the WG prefers to removes this I am fine removing it. If you have an opinion, please raise you opinion asap!
>
> Yours,
> Daniel
>
> On Wed, Jul 18, 2018 at 11:35 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Daniel,
>
>     Please see inline [TR]
>
>     On Wed, Jul 18, 2018 at 5:05 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Daniel,
>
>         Please see inline [TR]
>
>         On Mon, Jul 16, 2018 at 5:16 AM, Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Hi Daniel,
>
>             *From:* [email-masked]<mailto:[email-masked]>[mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Daniel Migault
>             *To:* Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
>             *Cc:* Tobias Gondrom <[email-masked]<mailto:[email-masked]>>; Roman Danyliw <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>             [1] https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/<https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/>
>
>             [2] https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-13<https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-13>
>
>                 *From:* [email-masked]<mailto:[email-masked]>[mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Daniel Migault
>                 *To:* Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
>                 *Cc:* Tobias Gondrom <[email-masked]<mailto:[email-masked]>>; Roman Danyliw <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>                     *From:* [email-masked]<mailto:[email-masked]>[mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Daniel Migault
>                     *To:* Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
>                     *Cc:* Tobias Gondrom <[email-masked]<mailto:[email-masked]>>; Roman Danyliw <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>                     What is not clear to me is that I do not see how volumetric attacks can be addressed in this case. A volumetric attack whose target is in the Enterprise Network woudl be detected by the DMS of that Enterprise network. In that case the DMS of the Enterprise network will have a DOTS client sending a request to the DOTS Server of the ITP...  This is not the case we consider here as it has already been described as the primary alternative.The reason for a ITP DMS to send a request to the DMS of the Enterprise could be 1) the Enterprise network is taking part of a DDoS atatck, 2) the ITP DMS delegate the DDoS mitigation to the DMS Enterprise network. I see 1) as informing that hosts of the network are being infected and being part of a botnet. I am confused by 2) as I see ITP DMS with ways more resource than the Enterprise network. Could you elaborate a bit on the scenario ?
>
>                 [TR3] Thanks.  I am facing problems with detecting all types of outgoing DDoS attacks on home routers (only few packets are punted to the slow path for inspection) and I think DOTS can help to punt traffic from compromised devices to slow path for outgoing DDoS traffic detection. Further, additional information like source IP and source ports conveyed in the DOTS signal channel to identify the hosts behind NAT, and the call home feature discussed in https://tools.ietf.org/html/rfc8071<https://tools.ietf.org/html/rfc8071>is required for DOTS signal channel, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client in the access network, and then the roles get reversed.
>
>                     I understand your comment. These were example of information provided. I agree to mention as GEN-004 that information is a hints that may be interpreted. I do not see how volumetric attacks can be addressed in this case. A volumetric attack whose target is in the Entreprise Network woudl be detected by the DMS of that Enterprise network. In that case the DMS of the Enterprise network will have a DOTS client sending a request to the DOTS Server of the ITP..  This is not the case we consider here as it has already been described as the primary alternative.The reason for a ITP DMS to send a request to the DMS of the Enterprise could be 1) the Enterprise network is taking part of a DDoS atatck, 2) the ITP DMS delegate the DDoS mitigation to the DMS Enterprise network. I see 1) as informing that hosts of the network are being infected and being part of a botnet. I am confused by 2) as I see ITP DMS with ways more resource than the Enterprise network. Could
>                     you elaborate a bit on the scenario you have in mind ?
>
>                     </mglt>
>
>
>                             2)

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Jul 2018 16:21:08 -0400

fine, I removed the text associated with SFC.
Here is the text that seems to reach consensus.
Yours,
Daniel

The orchestrator analyses the various information it receives from DDoS
telemetry system, and initiates one or multiple DDoS mitigation
strategies. For example, the orchestrator could select the DDoS
mitigation system in the Enterprise network or one provided by the ITP.
DDoS Mitigation System selection and DDoS Mitigation technique may
depends on the type of DDoS attack.  In some case, a manual confirmation
or selection may also be required to choose a proposed strategy or to
initiate a DDoS Mitigation.  The DDoS Mitigation may consist of multiple
steps such as configuring the network, or updating already instantiated
DDoS mitigation functions.  Eventually, the coordination of the
mitigation may involve external DDoS resources such as a transit
provider or a DDoS Mitigation Service Provider.

On Wed, Jul 18, 2018 at 2:02 PM, kaname nishizuka <[email-masked]> wrote:

>> [TR] I think you mean “The DDoS mitigation system selection and
>> mitigation technique depends on the type of the DDoS attack”.
>>
>>
>>
>> In some
>> Please find my comments inline. Most of your comments have been
>> addressed, I am waiting for your answer before updating and publishing the
>> draft.
>>
>>
>>
>> Yours,
>>
>> Daniel
>>
>>
>>
>> sending a request to the DOTS Server of the ITP...  This is not the case we

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 19 Jul 2018 06:18:35 +0000

Please see inline [TR]

From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Thursday, July 19, 2018 1:51 AM
To: kaname nishizuka <[email-masked]>
Cc: Konda, Tirumaleswar Reddy <[email-masked]>; Tobias Gondrom <[email-masked]>; Roman Danyliw <[email-masked]>; [email-masked]
Subject: Re: [Dots] WGLC for use cases draft - until July-1.

The orchestrator analyses the various information it receives from DDoS
telemetry system, and initiates one or multiple DDoS mitigation
strategies. For example, the orchestrator could select the DDoS
mitigation system in the Enterprise network or one provided by the ITP.
DDoS Mitigation System selection and DDoS Mitigation technique may
depends on the type of DDoS attack.  In some case, a manual confirmation
or selection may also be required to choose a proposed strategy or to
[TR]>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> remove “or”
initiate a DDoS Mitigation.  The DDoS Mitigation may consist of multiple
steps such as configuring the network, or updating already instantiated
DDoS mitigation functions.
Eventually, the coordination of the
mitigation may involve external DDoS resources such as a transit
provider or a DDoS Mitigation Service Provider.
[TR] Replace “DDoS resources” with “DDoS mitigation resources”, and replace “DDoS Mitigation Service Provider” with “Third Party DDoS Mitigation Service Provider”

-Tiru

On Wed, Jul 18, 2018 at 2:02 PM, kaname nishizuka <[email-masked]<mailto:[email-masked]>> wrote:
I  prefers to remove this.
An orchestrator may or may not use SFC technology.
The text itself seems correct, but I feel reference to SFC in this context is distraction.

regards,
Kaname

Yours,
Daniel

On Wed, Jul 18, 2018 at 11:35 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

Please see inline [TR]

"""

In some

-Tiru

"""

Yours,
Daniel

Please see inline [TR]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Daniel Migault

Yours,
Daniel

1.
OLD:

<mglt>
corrected
</mglt>

<mglt>

   strategies.

<mglt>

[TR] Yes.

</mglt>

</mglt>

4.

OLD:

NEW:

<mglt>
proposed text:

[TR] Okay.

</mglt>

5. The

6.

OLD:

   using DOTS.

NEW:

   using DOTS.

<mglt>

[TR] Okay.

Thanks,
-Tiru

</mglt>
-Tiru

Yours,
Daniel

Please see inline [TR2]

Yours,
Daniel

1)

OLD:

<mglt>

</mglt>
<mglt3>

</mglt3>

OLD:

NEW:

</mglt>

<mglt>

Cheers,
-Tiru

           +----------+

</mglt3>

-Tiru

</mglt>

Please see inline [TR]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Daniel Migault

Yours,
Daniel

My comments and nits

1)

OLD:

<mglt>

</mglt>

2)

<mglt>

OLD:

NEW:

</mglt>

<mglt>

</mglt>
3)

<mglt>
Done
</mglt>

[TR] Okay

4)

<mglt>
Done
</mglt>

[TR] Thanks.

5)

<mglt>

[TR] Thanks.

<mglt>
done
</mglt>

6)

</mglt>

[TR] Okay.

<mglt>
done
</mglt>
7)

<mglt>

OLD:

NEW:

[TR] Looks good.
<mglt>
done
</mglt>

8)

<mglt>

OLD:

NEW:

[TR] Looks good.

<mglt>
done
</mglt>

</mglt>

OLD:

NEW:

<mglt>
Done
</mglt>

<mg;t>

OLD:

NEW:

[TR] NEW:

</mglt>

<mglt
done
</mglt>

NEW:

</mglt>

<mglt>

NEW:

</mglt>

12)

"""
The status of the DDoS

[TR] Okay

 <mglt>
Done
</mglt>
13)

OLD:

NEW:

[TR] Okay.

</mglt>

 <mglt>
Done
</mglt>

OLD:

NEW:

</mglt>

<mglt>

Done

OLD:

NEW:

</mglt>

<mglt>

</mglt>

<mglt>

OLD:
Redirection to the DDoS

NEW:
Redirection to the DDoS

[TR]
NEW:
Redirection to the DDoS

</mglt>

<mglt>
Done
</mglt>

I am fine removing it.

[TR] Okay.

</mglt>
<mglt>
Done
</mglt>

Cheers,
-Tiru

</mglt>
-Tiru

Dots mailing list

---

From: Daniel Migault <[email-masked]>
Date: Thu, 19 Jul 2018 16:52:32 +0000

Thanks, justed pushed. 😉
Yours,
Daniel

From: Konda, Tirumaleswar Reddy <[email-masked]>
Sent: Thursday, July 19, 2018 2:19 AM
To: Daniel Migault <[email-masked]>; kaname nishizuka <[email-masked]>
Cc: Tobias Gondrom <[email-masked]>; Roman Danyliw <[email-masked]>; [email-masked]
Subject: RE: [Dots] WGLC for use cases draft - until July-1.

Please see inline [TR]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Thursday, July 19, 2018 1:51 AM
To: kaname nishizuka <[email-masked]<mailto:[email-masked]>>
Cc: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Tobias Gondrom <[email-masked]<mailto:[email-masked]>>; Roman Danyliw <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] WGLC for use cases draft - until July-1.

-Tiru

regards,
Kaname

Yours,
Daniel

Please see inline [TR]

"""

In some

-Tiru

"""

Yours,
Daniel

Please see inline [TR]

Yours,
Daniel

1.
OLD:

<mglt>
corrected
</mglt>

<mglt>

   strategies.

<mglt>

[TR] Yes.

</mglt>

</mglt>

4.

OLD:

NEW:

<mglt>
proposed text:

[TR] Okay.

</mglt>

5. The

6.

OLD:

   using DOTS.

NEW:

   using DOTS.

<mglt>

[TR] Okay.

Thanks,
-Tiru

</mglt>
-Tiru

Yours,
Daniel

Please see inline [TR2]

Yours,
Daniel

1)

OLD:

<mglt>

</mglt>
<mglt3>

</mglt3>

OLD:

NEW:

</mglt>

<mglt>

Cheers,
-Tiru

           +----------+

</mglt3>

-Tiru

</mglt>

Please see inline [TR]

Yours,
Daniel

My comments and nits

1)

OLD:

<mglt>

</mglt>

2)

<mglt>

OLD:

NEW:

</mglt>

<mglt>

</mglt>
3)

<mglt>
Done
</mglt>

[TR] Okay

4)

<mglt>
Done
</mglt>

[TR] Thanks.

5)

<mglt>

[TR] Thanks.

<mglt>
done
</mglt>

6)

</mglt>

[TR] Okay.

<mglt>
done
</mglt>
7)

<mglt>

OLD:

NEW:

[TR] Looks good.
<mglt>
done
</mglt>

8)

<mglt>

OLD:

NEW:

[TR] Looks good.

<mglt>
done
</mglt>

</mglt>

OLD:

NEW:

<mglt>
Done
</mglt>

<mg;t>

OLD:

NEW:

[TR] NEW:

</mglt>

<mglt
done
</mglt>

NEW:

</mglt>

<mglt>

NEW:

</mglt>

12)

"""
The status of the DDoS

[TR] Okay

 <mglt>
Done
</mglt>
13)

OLD:

NEW:

[TR] Okay.

</mglt>

 <mglt>
Done
</mglt>

OLD:

NEW:

</mglt>

<mglt>

Done

OLD:

NEW:

</mglt>

<mglt>

</mglt>

<mglt>

OLD:
Redirection to the DDoS

NEW:
Redirection to the DDoS

[TR]
NEW:
Redirection to the DDoS

</mglt>

<mglt>
Done
</mglt>

I am fine removing it.

[TR] Okay.

</mglt>
<mglt>
Done
</mglt>

Cheers,
-Tiru

</mglt>
-Tiru

Dots mailing list