Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
draft-ietf-dots-signal-filter-control-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-09-01
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-08-21
|
07 | (System) | RFC Editor state changed to AUTH48 |
2021-06-07
|
07 | (System) | RFC Editor state changed to REF from EDIT |
2021-06-04
|
07 | (System) | RFC Editor state changed to EDIT from MISSREF |
2020-10-01
|
07 | (System) | RFC Editor state changed to MISSREF from AUTH48 |
2020-10-01
|
07 | (System) | RFC Editor state changed to AUTH48 from MISSREF |
2020-09-17
|
07 | (System) | RFC Editor state changed to MISSREF from AUTH48 |
2020-09-17
|
07 | (System) | RFC Editor state changed to AUTH48 from MISSREF |
2020-09-17
|
07 | (System) | RFC Editor state changed to MISSREF from AUTH48 |
2020-09-11
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-07-08
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-07-06
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-07-06
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-07-06
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-07-02
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-06-30
|
07 | (System) | RFC Editor state changed to EDIT |
2020-06-30
|
07 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-06-30
|
07 | (System) | Announcement was received by RFC Editor |
2020-06-29
|
07 | (System) | IANA Action state changed to In Progress |
2020-06-29
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-06-29
|
07 | Amy Vezza | IESG has approved the document |
2020-06-29
|
07 | Amy Vezza | Closed "Approve" ballot |
2020-06-29
|
07 | Amy Vezza | Ballot approval text was generated |
2020-06-25
|
07 | Benjamin Kaduk | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2020-06-25
|
07 | Mohamed Boucadair | New version available: draft-ietf-dots-signal-filter-control-07.txt |
2020-06-25
|
07 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-06-25
|
07 | Mohamed Boucadair | Uploaded new revision |
2020-06-25
|
06 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2020-06-25
|
06 | Roman Danyliw | [Ballot comment] Thanks for responding to the SECDIR review (and thanks to Shawn Emery for conducting the review). Thanks for addressing my COMMENTs. |
2020-06-25
|
06 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2020-06-25
|
06 | Robert Wilton | [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, … [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 |
2020-06-25
|
06 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-06-25
|
06 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-06-25
|
06 | Éric Vyncke | [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 … [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 |
2020-06-25
|
06 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-06-25
|
06 | Éric Vyncke | Request closed, assignment withdrawn: Zhen Cao Telechat INTDIR review |
2020-06-25
|
06 | Éric Vyncke | 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 … 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). |
2020-06-24
|
06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-06-24
|
06 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-06-24
|
06 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-06-23
|
06 | Erik Kline | [Ballot comment] [[ questions ]] [ section 3.2.1 ] * "If not, the polling mechanism ... has to be followed". Should this use some … [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" |
2020-06-23
|
06 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-06-23
|
06 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-06-23
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-06-22
|
06 | Roman Danyliw | [Ballot comment] Thanks for responding to the SECDIR review (and thanks to Shawn Emery for conducting the review). ** Is there a reason why the … [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 |
2020-06-22
|
06 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-06-22
|
06 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Zhen Cao |
2020-06-22
|
06 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Zhen Cao |
2020-06-21
|
06 | Murray Kucherawy | [Ballot comment] Some minor stuff only: Section 1.1: OLD: A typical case is a conflict between filtering rules installed by a DOTS client … [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/ |
2020-06-21
|
06 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-06-18
|
06 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-06-17
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-06-17
|
06 | Mohamed Boucadair | New version available: draft-ietf-dots-signal-filter-control-06.txt |
2020-06-17
|
06 | (System) | New version approved |
2020-06-17
|
06 | (System) | Request for posting confirmation emailed to previous authors: Kaname Nishizuka , Mohamed Boucadair , "Tirumaleswar Reddy.K" , Takahiko Nagata |
2020-06-17
|
06 | Mohamed Boucadair | Uploaded new revision |
2020-06-16
|
05 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-06-16
|
05 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-06-16
|
05 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK |
2020-06-16
|
05 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-06-15
|
05 | Cindy Morgan | Placed on agenda for telechat - 2020-06-25 |
2020-06-15
|
05 | Benjamin Kaduk | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-06-15
|
05 | Benjamin Kaduk | Ballot has been issued |
2020-06-15
|
05 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2020-06-15
|
05 | Benjamin Kaduk | Created "Approve" ballot |
2020-06-15
|
05 | Benjamin Kaduk | Ballot writeup was changed |
2020-06-15
|
05 | Tim Chown | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Chown. Sent review to list. |
2020-06-15
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-06-15
|
05 | Mohamed Boucadair | New version available: draft-ietf-dots-signal-filter-control-05.txt |
2020-06-15
|
05 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-06-15
|
05 | Mohamed Boucadair | Uploaded new revision |
2020-06-15
|
04 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-06-12
|
04 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-06-12
|
04 | Sabrina Tanamal | (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 … (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 |
2020-06-11
|
04 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery. Submission of review completed at an earlier date. |
2020-06-06
|
04 | Christer Holmberg | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg. Sent review to list. |
2020-06-05
|
04 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery. |
2020-06-05
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2020-06-05
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2020-06-04
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2020-06-04
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2020-06-03
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2020-06-03
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2020-06-01
|
04 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-06-01
|
04 | Cindy Morgan | 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 … 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. |
2020-06-01
|
04 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-06-01
|
04 | Cindy Morgan | Last call announcement was changed |
2020-05-30
|
04 | Benjamin Kaduk | Last call was requested |
2020-05-30
|
04 | Benjamin Kaduk | Last call announcement was generated |
2020-05-30
|
04 | Benjamin Kaduk | Ballot approval text was generated |
2020-05-30
|
04 | Benjamin Kaduk | Ballot writeup was generated |
2020-05-30
|
04 | Benjamin Kaduk | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-05-27
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-05-27
|
04 | Mohamed Boucadair | New version available: draft-ietf-dots-signal-filter-control-04.txt |
2020-05-27
|
04 | (System) | New version accepted (logged-in submitter: Mohamed Boucadair) |
2020-05-27
|
04 | Mohamed Boucadair | Uploaded new revision |
2020-05-12
|
03 | Benjamin Kaduk | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2020-05-12
|
03 | Benjamin Kaduk | IESG state changed to AD Evaluation from Publication Requested |
2020-03-02
|
03 | Mohamed Boucadair | New version available: draft-ietf-dots-signal-filter-control-03.txt |
2020-03-02
|
03 | (System) | New version approved |
2020-03-02
|
03 | (System) | Request for posting confirmation emailed to previous authors: Takahiko Nagata , Mohamed Boucadair , "Tirumaleswar Reddy.K" , Kaname Nishizuka |
2020-03-02
|
03 | Mohamed Boucadair | Uploaded new revision |
2019-10-21
|
02 | Amy Vezza | Changed consensus to Yes from Unknown |
2019-10-21
|
02 | Amy Vezza | Intended Status changed to Proposed Standard from None |
2019-10-18
|
02 | Liang Xia | 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 … 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. |
2019-10-18
|
02 | Liang Xia | Responsible AD changed to Benjamin Kaduk |
2019-10-18
|
02 | Liang Xia | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-10-18
|
02 | Liang Xia | IESG state changed to Publication Requested from I-D Exists |
2019-10-18
|
02 | Liang Xia | IESG process started in state Publication Requested |
2019-10-18
|
02 | Liang Xia | 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 … 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. |
2019-10-18
|
02 | Liang Xia | 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 … 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. |
2019-09-17
|
02 | Liang Xia | Tag Doc Shepherd Follow-up Underway set. |
2019-09-17
|
02 | Liang Xia | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2019-09-17
|
02 | Mohamed Boucadair | New version available: draft-ietf-dots-signal-filter-control-02.txt |
2019-09-17
|
02 | (System) | New version approved |
2019-09-17
|
02 | (System) | Request for posting confirmation emailed to previous authors: Takahiko Nagata , Mohamed Boucadair , Reddy K , Kaname Nishizuka |
2019-09-17
|
02 | Mohamed Boucadair | Uploaded new revision |
2019-07-22
|
01 | Valery Smyslov | Notification list changed to Valery Smyslov <valery@smyslov.net>, Liang Xia <frank.xialiang@huawei.com> from Valery Smyslov <valery@smyslov.net> |
2019-07-22
|
01 | Valery Smyslov | Document shepherd changed to Liang Xia |
2019-05-24
|
01 | Mohamed Boucadair | New version available: draft-ietf-dots-signal-filter-control-01.txt |
2019-05-24
|
01 | (System) | New version approved |
2019-05-24
|
01 | (System) | Request for posting confirmation emailed to previous authors: Takahiko Nagata , Mohamed Boucadair , Reddy K , Kaname Nishizuka |
2019-05-24
|
01 | Mohamed Boucadair | Uploaded new revision |
2019-04-23
|
00 | Valery Smyslov | Notification list changed to Valery Smyslov <valery@smyslov.net> |
2019-04-23
|
00 | Valery Smyslov | Document shepherd changed to Valery Smyslov |
2019-04-23
|
00 | Valery Smyslov | This document now replaces draft-nishizuka-dots-signal-control-filtering instead of None |
2019-04-23
|
00 | Mohamed Boucadair | New version available: draft-ietf-dots-signal-filter-control-00.txt |
2019-04-23
|
00 | (System) | WG -00 approved |
2019-04-23
|
00 | Mohamed Boucadair | Set submitter to "Mohamed Boucadair ", replaces to draft-nishizuka-dots-signal-control-filtering and sent approval email to group chairs: dots-chairs@ietf.org |
2019-04-23
|
00 | Mohamed Boucadair | Uploaded new revision |