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

[Daniel Migault <[e-mail]>]

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 <
[e-mail]> wrote:

> Hi Daniel,
>
>
>
> Thanks for addressing all the comments, Please see inline [TR3]
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Daniel
> Migault
> *Sent:* Tuesday, June 26, 2018 8:10 PM
> *To:* Konda, Tirumaleswar Reddy <[e-mail]>
> *Cc:* Tobias Gondrom <[e-mail]>; Roman Danyliw <
> [e-mail]>; [e-mail]
> *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 <
> [e-mail]> wrote:
>
> Hi Daniel,
>
>
>
> Please see inline [TR2]
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Daniel
> Migault
> *Sent:* Tuesday, June 26, 2018 8:33 AM
> *To:* Konda, Tirumaleswar Reddy <[e-mail]>
> *Cc:* Tobias Gondrom <[e-mail]>; Roman Danyliw <
> [e-mail]>; [e-mail]
> *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 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 <
> [e-mail]> wrote:
>
> Hi Daniel,
>
>
>
> Please see inline [TR]
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Daniel
> Migault
> *Sent:* Thursday, June 21, 2018 1:28 AM
> *To:* Konda, Tirumaleswar Reddy <[e-mail]>
> *Cc:* Tobias Gondrom <[e-mail]>; Roman Danyliw <
> [e-mail]>; [e-mail]
> *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 <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots
>
>