Subject: Re: [Dots] New DOTS signal and data channel requirements

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Nov 2017 16:32:03 -0000

Hi there,

As I am moving back into getting the data channel functionally up and running, I need to revisit this – in particular something else that was in that original email thread just after what Tiru has quoted below.

“Even if the Filters are held on a per client identity basis, there no way to upload a set of different filters in peace time ready for selection as to which is be used in case of DDoS Attack.  White/Black lists are probably fairly static, it is the customizable filters that are the issue currently for me.” 

Do we need to be able to add in selectable ACL support?

Client-identifier is now supported in ietf-dots-access-control-list:access-lists, so filters / acls are now maintainable on a per original DOTS client basis.

If a DOTS client defines multiple acls (e.g. white list, black list and custom acls), there is now the possibility of them being sent to the DOTS mitigator in a sorted order.  https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ has added “interfaces” under “access-lists”, and under “interfaces” is “ingress” where you can define an ordered set of “acl-sets” in which each “set-name” refers back to the “acl-name” sitting under “acl”, sitting under “access-lists”.

module: ietf-access-control-list

     +--rw access-lists

        +--rw acl* [acl-type acl-name]

        |  +--rw acl-name    string

…

       +--rw interfaces

           +--rw interface* [interface-id]

              +--rw interface-id    if:interface-ref

              +--rw ingress

              |  +--rw acl-sets

              |     +--rw acl-set* [set-name type]

              |        +--rw set-name    -> ../../../../../../acl/acl-name

…

However, for each DOTS client, we can only have one ietf-dots-access-control-list which only allows for one ietf-access-control-list.  So it not possible to build up a library of different acls, one of which can be selected by the DOTS client as a “hint” to get forwarded onto  the DOTS mitigator.  During times of attack, it may be difficult / impossible to update the acl because of TCP failures.

I agree that we cannot expect there to be much intelligence in the DOTS client.  However in DOTS use cases, “3.1.1.  End-customer with a single upstream transit provider offering DDoS mitigation services” there is reference to the customer having an intelligent DDoS Mitigation system (IDMS).  This IDMS could give “hints”.

The DOTS signal mitigate protocol supports alias-names, but not filters or acls.  We could

1)      Add in filter invoking support into the DOTS signal mitigate protocol and extend ietf-dots-access-control-list

2)      Extend the alias definition in the data channel definitions to include other parameters supported by netmod-acl-model

Ideas / suggestions?

Regards

Jon

 

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 13:22
To: Jon Shallow; [email-masked]; [email-masked]; Roland Dobbins
Subject: [Dots] New DOTS signal and data channel requirements

Starting a new thread to discuss the below new requirement from Jon:

[Jon] I have re-read the requirements / architecture drafts.  I agree that currently the White/Black/Filter definitions have no dependency on the mitigation request – it is up to the DOTS server (GW or not) as to how the White/Black/Filter definitions get passed on to DOTS mitigator (out of spec), but the DOTS server needs to know which of the White/Black/Filter definitions are relevant when a mitigation request comes in.  Currently, it is possible for the DOTS Server to hold White/Black/Filter definitions on a per client identity.  When the White/Black/Filter definitions are passed from a GW Client side to a GW server side and on to the next DOTS server, GW server side has to convey also something about the clients on the GW client side for the DOTS server to maintain the White/Black/Filter definitions on a per pseudo “client identity” – so when the migration request is passed to the DOS server via a GW it knows what White/Black/Filter definitions to apply to that mitigation request.

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 8 Nov 2017 07:33:54 +0000

Hi Jon,

Your mail is discussing two different issues, I will focus on one of them in this thread:

1. The ACEs in a ACL can be ordered using the "insert" query parameter discussed in https://tools.ietf.org/html/rfc8040#section-4.8.5.
   The list "ace" in container "aces" has the 'ordered-by-user' statement, so ACEs in a ACL can ordered using RESTCONF.

2. However, list "acl" in container "access-lists" does not have the 'ordered-by-user' statement, but ACLs can be ordered when applied to an interface.

   The problem with DOTS data channel is, the DOTS client does not know the interface details
   on the DDoS mitigator, so using the yang model in draft-ietf-netmod-acl-model-14
   multiple ACLs from the DOTS client cannot be ordered.

3. If the WG agrees on the requirement to support multiple ordered ACLs from the DOTS client, I can
   extend the YANG model to order multiple ACLs from the DOTS client.

  Following is a simple extension to the yang model to handle ordering of ACLs:

  augment /ietf-acl:access-lists:
    +--rw acl-order
       +--rw acl-set* [set-name type]
          +--rw set-name    -> /ietf-acl:access-lists/acl/acl-name
          +--rw type        -> /ietf-acl:access-lists/acl/acl-type

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 10:02 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Roland Dobbins <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dots] New DOTS signal and data channel requirements

Hi there,

Ideas / suggestions?

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 10 October 2017 13:22
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Roland Dobbins
Subject: [Dots] New DOTS signal and data channel requirements

-Tiru