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

Hi Tiru,

I see draft-ietf-dots-data-channel-02 includes appropriate reference to the latest draft-ietf-netmod-acl-model.

thank you,
Kaname

On 2017/08/03 17:06, Konda, Tirumaleswar Reddy wrote:
>
> 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:dots-bounces@ietf.org] *On Behalf Of *kaname nishizuka
> *Sent:* Thursday, August 3, 2017 10:51 AM
> *To:* Dobbins, Roland <rdobbins@arbor.net>; Jon Shallow <supjps-ietf@jpshallow.com>
> *Cc:* dots@ietf.org
> *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 <supjps-ietf@jpshallow.com <mailto:supjps-ietf@jpshallow.com>> 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 <rdobbins@arbor.net <mailto:rdobbins@arbor.net>>
>
>
>
>
>     _______________________________________________
>
>     Dots mailing list
>
>     Dots@ietf.org <mailto:Dots@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/dots
>
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots