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

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.  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.  “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> 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>

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots