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

Hi Jon,

On 2017/08/03 16:56, Jon Shallow wrote:
>
> Hi Kaname,
>
> So as I read this, you are either extending the ietf-dot-signal definition to include source-* (and icmp, fragmentation and possibly rate-limiting) information or you are using Filters over the data channel (which is what Tiru is referring to). If it is an extension to ietf-dot-signal, then this needs to be formalised for interoperability between different suppliers.
>
The latter is my intention.  I'll check whether the alias mechanism which couples the data-channel and signal-channel works well.

> Similarly, ietf-dots-data-channel-identifier needs to be extended – but I do think the naming (e.g. target-ip instead of just ip) needs to be consistent between ietf-dot-signal and ietf-dots-data-channel-identifier.
>
+1.
a consistency of naming is important for readers.

thanks,
Kaname

> “5.3.1” of draft-ietf-dots-signal-channel would also need to reflect the ietf-dot-signal change. “6.” and “10.1.2” of draft-ietf-dots-signal-channel would also need CBOR to be updated with source-* etc. definitions.
>
> I am of the firm opinion that destination-ip is REQUIRED and MUST be within the mitigation scope of the DOTS Client to prevent taking out someone else’s IP.  This is true for ietf-dot-signal, ietf-dots-data-channel-identifier and ietf-dots-access-control-list.
>
> I do not think fragmentation represented as port=0 is sufficient (and is not necessarily intuitive – it could be read as just take out the subsequent packets of a fragmented sequence if the layer 4 header is not there and hence no port). I think it should have its own ietf-dot-signal definition.
>
> It is unclear to me the usage of alias in the ietf-dot-signal – is it the DOTS client uses just  the alias when requesting mitigation, or if extra parameters are provided (e.g. alias plus target-port-range) are the extra parameters a replacement or in addition to what is in the ietf-dots-data-channel-identifier or are the extra parameters ignored altogether?
>
> Regards
>
> Jon
>
> *From:*Dots [mailto: dots-bounces@ietf.org] *On Behalf Of *kaname nishizuka
> *Sent:* 03 August 2017 06:21
> *To:* Dobbins, Roland; Jon Shallow
> *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