Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
draft-ietf-dots-signal-filter-control-07

[Ballot comment]
I found this document well written and easy to read and understand, particularly through the use of clear examples, so thank you.

Regards,
Rob

[Ballot comment]
Thank you for the work put into this document.

I appreciated the clarity, the use of IPv6 examples, and the inclusion of the YANG model.

Only one minor suggestion about the title of section 1.2 as "The Solution" looks a little marketing ;-) I would prefer "Mitigation Technique" or something more 'engineering-oriented'

Regards

-éric

Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat today. No need anymore for a review (still welcome by the authors probably).

[Ballot comment]
[[ questions ]]

[ section 3.2.1 ]

* "If not, the polling mechanism ... has to be followed".  Should this use some
  actual 2119 language?

* Is the specified client behaviour in the event of a 5.03 really MUST? That
  would definitely seem like recommended behaviour to me, but does it perhaps
  risk being over-specified to say retries without parameters MUST be
  attempted? I.e., should it be a SHOULD?


[[ nits ]]

[ section 6 ]

* "entitled to access only to resources" ->
  "entitled to access only the resources"

[Ballot comment]
Thanks for responding to the SECDIR review (and thanks to Shawn Emery for conducting the review).

** Is there a reason why the meta-data header in this document doesn’t note this as an update to RFC8782 (especially since it is updating an operational gap)?

** Minor editorial nits:
-- Section 4.1. Editorial.  s/Some time/Sometime/

-- Section 5.1. Recommend against hard-coding the IANA registry URL

[Ballot comment]
Some minor stuff only:

Section 1.1:

OLD:

  A typical case is a conflict between filtering rules installed by a
  DOTS client and the mitigation actions of a DDoS mitigator.  Such
  case is a DOTS client which configures during 'idle' time (i.e., no
  mitigation is active) some filtering rules using the DOTS data
  channel protocol to permit traffic from accept-listed sources, but
  during a volumetric DDoS attack the DDoS mitigator identifies the
  source addresses/prefixes in the accept-listed filtering rules are
  attacking the target.  For example, an attacker can spoof the IP
  addresses of accept-listed sources to generate attack traffic or the
  attacker can compromise the accept-listed sources and program them to
  launch a DDoS attack.

NEW:

  A typical case is a conflict between filtering rules installed by a
  DOTS client and the mitigation actions of a DDoS mitigator.  Consider,
  for instance, a DOTS client that configures during 'idle' time (i.e., no
  mitigation is active) some filtering rules using the DOTS data
  channel protocol to permit traffic from accept-listed sources.  However,
  during a volumetric DDoS attack the DDoS mitigator identifies the
  source addresses/prefixes in the accept-listed filtering rules are
  attacking the target.  For example, an attacker can spoof the IP
  addresses of accept-listed sources to generate attack traffic or the
  attacker can compromise the accept-listed sources and program them to
  launch a DDoS attack.

Section 1.2:

* "An augment to the DOTS signal channel ..." -- s/augment/amendment/ ("augment" isn't a thing, it's an action)

Section 3.2.1:

* Although this section declares the acronym "ACE" for "Access Control Entry", that acronym is used nowhere else in the document.

* "... notifies that DOTS client with the change ..." -- s/with/of, I think?

Section 6:

* "... does not allow to create new filtering rules ..." -- s/to create/creation of/

* "... entitled to access only to resources ..." -- s/only to/only those/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dots-signal-filter-control-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the IANA DOTS Signal Channel CBOR Key Values registry on the Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel registry page located at:

https://www.iana.org/assignments/dots/

three new registrations are to be made as follows:

Parameter Name: ietf-dots-signal-control:activation-type
CBOR Key Value: [ TBD-at-Registration ]
CBOR Major Type: 0
Change Controller: IESG
Reference: [ RFC-to-be ]

Parameter Name: ietf-dots-signal-control:acl-list
CBOR Key Value: [ TBD-at-Registration ]
CBOR Major Type: 4
Change Controller: IESG
Reference: [ RFC-to-be ]

Parameter Name: ietf-dots-signal-control:acl-name
CBOR Key Value: [ TBD-at-Registration ]
CBOR Major Type: 3
Change Controller: IESG
Reference: [ RFC-to-be ]

IANA notes that the authors have requested the values 52, 53 and 54 for these three registrations respectively.

Second, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-dots-signal-control
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-dots-signal-control
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control
Prefix: dots-control
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-06-15):

From: The IESG
To: IETF-Announce
CC: Liang Xia , kaduk@mit.edu, frank.xialiang@huawei.com, Valery Smyslov , dots-chairs@ietf.org, draft-ietf-dots-signal-filter-control@ietf.org, dots@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel) to Proposed Standard


The IESG has received a request from the DDoS Open Threat Signaling WG (dots)
to consider the following document: - 'Controlling Filtering Rules Using
Distributed Denial-of-Service Open
  Threat Signaling (DOTS) Signal Channel'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-06-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies an extension to the DOTS signal channel
  protocol so that DOTS clients can control their filtering rules when
  an attack mitigation is active.

  Particularly, this extension allows a DOTS client to activate or de-
  activate existing filtering rules during a DDoS attack.  The
  characterization of these filtering rules is supposed to be conveyed
  by a DOTS client during an idle time by means of the DOTS data
  channel protocol.

Editorial Note (To be removed by RFC Editor)

  Please update these statements within the document with the RFC
  number to be assigned to this document:

  o  "This version of this YANG module is part of RFC XXXX;"

  o  "RFC XXXX: Controlling Filtering Rules Using Distributed Denial-
      of-Service Open Threat Signaling (DOTS) Signal Channel";

  o  reference: RFC XXXX

  o  [RFCXXXX]

  Please update the "revision" date of the YANG module.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control/



No IPR declarations have been submitted directly on this I-D.

1.Summary
The document shepherd is Liang Xia. The responsible Area Director is Benjamin Kaduk.
This document specifies an extension to the DOTS signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active. Particularly, this extension allows a DOTS client to activate or de-activate existing filtering rules during a DDoS attack. The working group has the consensus to publish it as a Proposed Standard since it is a protocol draft, which is stable in technical aspect and gets enough community interest to be considered as valuable.

2. Review and Consensus
The issue which led to this extension defined in the draft was found in IETF103 DOTS hackathon: https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00. The consensus for adopting to specification was solid. No controversial issues was raised during the development of the document. And since then, the specification went through many iterations to take into account the comments from WG. Right now, two interoperable implementations are available (NTT, NCC) and the interoperability testing (e.g., IETF104 at https://datatracker.ietf.org/meeting/104/materials/slides-104-dots-interoperability-and-hackathon-report-00) has justify and improve the specification.

This draft firstly proposes the identified problem which the DOTS Server cannot modify the filtering rules by data channel during the volumetric attack, then defines the according solution by counting on the signal channel messages. The detailed augments to the signal channel data model and the related protocol behaviors are also described. Besides, some examples are given at last to give more evidence about the solution necessity and value. The overall solution is relatively straightforward and simple.

In summary, this draft has been extensively reviewed and discussed within the working group by mailing list and github, and I believe all technical issues raised have been resolved till this version (-02).


3. Intellectual Property
Each author has confirmed conformance with BCPs 78 and 79.  There are no IPR disclosures on the document. See:
*      Kaname:  https://mailarchive.ietf.org/arch/msg/dots/sVkZIxf_0eWXCFMmJCMGuzwEjd0
*      Med: https://mailarchive.ietf.org/arch/msg/dots/KWlaAg5r8bqRxTch99NBqbugyQQ
*      Tiru: https://mailarchive.ietf.org/arch/msg/dots/l_UFT1A0gUk5acHA6fPNEGWOOzE
*      Takahiko: https://mailarchive.ietf.org/arch/msg/dots/WuVe0246nJlbhbWeRm2yy5zBfoY


4. Other Points
By performing the idnits check, there are no problem.

In general, I believe the IANA Considerations are clear and ready. There are totally 2 IANA requests:

1) one added 'activation-type' parameter in the existing DOTS signal channel CBOR mappings registry
2) a new URI in "IETF XML Registry" (urn:ietf:params:xml:ns:yang:ietf-dots-signal-control) for a new "YANG Module Names" registry (ietf-dots-signal-control);

No early expert review has been requested for the above IANA allocation.

1.Summary
The document shepherd is Liang Xia. The responsible Area Director is Benjamin Kaduk.
This document specifies an extension to the DOTS signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active. Particularly, this extension allows a DOTS client to activate or de-activate existing filtering rules during a DDoS attack. The working group has the consensus to publish it as a Proposed Standard since it is a protocol draft, which is stable in technical aspect and gets enough community interest to be considered as valuable.

2. Review and Consensus
The issue which led to this extension defined in the draft was found in IETF103 DOTS hackathon: https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00. The consensus for adopting to specification was solid. No controversial issues was raised during the development of the document. And since then, the specification went through many iterations to take into account the comments from WG. Right now, two interoperable implementations are available (NTT, NCC) and the interoperability testing (e.g., IETF104 at https://datatracker.ietf.org/meeting/104/materials/slides-104-dots-interoperability-and-hackathon-report-00) has justify and improve the specification.

This draft firstly proposes the identified problem which the DOTS Server cannot modify the filtering rules by data channel during the volumetric attack, then defines the according solution by counting on the signal channel messages. The detailed augments to the signal channel data model and the related protocol behaviors are also described. Besides, some examples are given at last to give more evidence about the solution necessity and value. The overall solution is relatively straightforward and simple.

In summary, this draft has been extensively reviewed and discussed within the working group by mailing list and github, and I believe all technical issues raised have been resolved till this version (-02).


3. Intellectual Property
Each author has confirmed conformance with BCPs 78 and 79.  There are no IPR disclosures on the document. See:
*      Kaname:  https://mailarchive.ietf.org/arch/msg/dots/sVkZIxf_0eWXCFMmJCMGuzwEjd0
*      Med: https://mailarchive.ietf.org/arch/msg/dots/KWlaAg5r8bqRxTch99NBqbugyQQ
*      Tiru: https://mailarchive.ietf.org/arch/msg/dots/l_UFT1A0gUk5acHA6fPNEGWOOzE
*      Takahiko: https://mailarchive.ietf.org/arch/msg/dots/WuVe0246nJlbhbWeRm2yy5zBfoY


4. Other Points
By performing the idnits check, there are no problem.

In general, I believe the IANA Considerations are clear and ready. There are totally 2 IANA requests:

1) one added 'activation-type' parameter in the existing DOTS signal channel CBOR mappings registry
2) a new URI in "IETF XML Registry" (urn:ietf:params:xml:ns:yang:ietf-dots-signal-control) for a new "YANG Module Names" registry (ietf-dots-signal-control);

No early expert review has been requested for the above IANA allocation.

1. Summary
The document shepherd is Liang Xia. The responsible Area Director is Benjamin Kaduk.
This document specifies an extension to the DOTS signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active. Particularly, this extension allows a DOTS client to activate or de-activate existing filtering rules during a DDoS attack. The working group has the consensus to publish it as a Proposed Standard since it is a protocol draft, which is stable in technical aspect and gets enough community interest to be considered as valuable.

2. Review and Consensus
The issue which led to this extension defined in the draft was found in IETF103 DOTS hackathon: https://datatracker.ietf.org/meeting/103/materials/slides-103-dots-interop-report-from-ietf-103-hackathon-00. The consensus for adopting to specification was solid. No controversial issues was raised during the development of the document. And since then, the specification went through many iterations to take into account the comments from WG. Right now, two interoperable implementations are available (NTT, NCC) and the interoperability testing (e.g., IETF104 at https://datatracker.ietf.org/meeting/104/materials/slides-104-dots-interoperability-and-hackathon-report-00) has justify and improve the specification.

This draft firstly proposes the identified problem which the DOTS Server cannot modify the filtering rules by data channel during the volumetric attack, then defines the according solution by counting on the signal channel messages. The detailed augments to the signal channel data model and the related protocol behaviors are also described. Besides, some examples are given at last to give more evidence about the solution necessity and value. The overall solution is relatively straightforward and simple.

In summary, this draft has been extensively reviewed and discussed within the working group by mailing list and github, and I believe all technical issues raised have been resolved till this version (-02).


3. Intellectual Property
Each author has confirmed conformance with BCPs 78 and 79.  There are no IPR disclosures on the document. See:
*      Kaname:  https://mailarchive.ietf.org/arch/msg/dots/sVkZIxf_0eWXCFMmJCMGuzwEjd0
*      Med: https://mailarchive.ietf.org/arch/msg/dots/KWlaAg5r8bqRxTch99NBqbugyQQ
*      Tiru: https://mailarchive.ietf.org/arch/msg/dots/l_UFT1A0gUk5acHA6fPNEGWOOzE
*      Takahiko: https://mailarchive.ietf.org/arch/msg/dots/WuVe0246nJlbhbWeRm2yy5zBfoY


4. Other Points
By performing the idnits check, there are no problem.

In general, I believe the IANA Considerations are clear and ready. There are totally 2 IANA requests:

1) one added 'activation-type' parameter in the existing DOTS signal channel CBOR mappings registry
2) a new URI in "IETF XML Registry" (urn:ietf:params:xml:ns:yang:ietf-dots-signal-control) for a new "YANG Module Names" registry (ietf-dots-signal-control);

No early expert review has been requested for the above IANA allocation.