Re: [Dots] Signal / Data / Alias / Filter Implementation

["Konda, Tirumaleswar Reddy" <[e-mail]>]

draft-ietf-dots-data-channel-02 extends the base ACL model defined in draft-ietf-netmod-acl-model to support filtering based on fragments. Filtering rules based on ICMP type and code is supported in latest revision of draft-ietf-netmod-acl-model.
I don’t see a need to update the DOTS data channel draft.

-Tiru

From: Dots [mailto:[e-mail]] On Behalf Of kaname nishizuka
Sent: Thursday, August 3, 2017 10:51 AM
To: Dobbins, Roland <[e-mail]>; Jon Shallow <[e-mail]>
Cc: [e-mail]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Jon,

I'm implementing the DOTS protocol based on current specifications.
The DOTS protocol can handle source-* information in a mitigation signal request.
For example, the DOTS server can enable BGP Flowspec from 5-tuple information derived from mitigation request message from DOTS client, that is actually we are planning to add to our software.
Destination information is used to validate whether the mitigation-scope is really the property of the DOTS client's organization or not.
So, if the request is only including source-* information, how to validate the request is another problem because it can cause unintended side effect to other customers/services (but could be implementation specific)

* How do we handle specific ICMP types  in a mitigation signal request?

Tiru wrote:
> Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8).
> I will extend the ACL YANG model in the next revision.

And the latest version of draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,)
I think we should update the draft.

* How do we handle fragmentation in a mitigation signal request?
fragmentation can be represented as port=0. Is this a sufficient representation?

thanks,
Kaname


On 2017/08/03 3:27, Dobbins, Roland wrote:

On Aug 2, 2017, at 22:25, Jon Shallow <[e-mail]<mailto:[e-mail]>> wrote:
In draft-ietf-dots-use-cases-07
3.1.6.  End-customer operating a CPE network infrastructure device with
       an integrated DOTS client

3.1.6 from idraft-ietf-dots-use-cases-07 in full:



3.1.6.  End-customer operating a CPE network infrastructure device with

        an integrated DOTS client



   Similar to the above use-case featuring applications or services with

   built-in DDoS attack detection/classification and DOTS client

   capabilities, in this scenario, an end-customer network

   infrastructure CPE device such as a router, layer-3 switch, firewall,

   or load-balance incorporates both the functionality required to

   detect and classify incoming DDoS attacks as well as DOTS client

   functionality.



   The subsequent DOTS communications dialogue and resultant DDoS

   mitigation initiation and termination activities take place in the

   same manner as the use-cases described above.

-----------------------------------

Roland Dobbins <[e-mail]<mailto:[e-mail]>>




_______________________________________________

Dots mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/dots