DDoS Open Threat Signaling (DOTS) Requirements
RFC 8612
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2019-05-28
|
22 | (System) | Received changes through RFC Editor sync (created alias RFC 8612, changed title to 'DDoS Open Threat Signaling (DOTS) Requirements', changed abstract to 'This document … Received changes through RFC Editor sync (created alias RFC 8612, changed title to 'DDoS Open Threat Signaling (DOTS) Requirements', changed abstract to 'This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.', changed standardization level to Informational, changed state to RFC, added RFC published event at 2019-05-28, changed IESG state to RFC Published) |
|
2019-05-28
|
22 | (System) | RFC published |
|
2019-05-23
|
22 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8612">AUTH48-DONE</a> from AUTH48 |
|
2019-05-20
|
22 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8612">AUTH48</a> from RFC-EDITOR |
|
2019-05-16
|
22 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2019-04-09
|
22 | (System) | RFC Editor state changed to EDIT |
|
2019-04-09
|
22 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2019-04-09
|
22 | (System) | Announcement was received by RFC Editor |
|
2019-04-09
|
22 | (System) | IANA Action state changed to No IANA Actions from In Progress |
|
2019-04-09
|
22 | (System) | IANA Action state changed to In Progress |
|
2019-04-09
|
22 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2019-04-09
|
22 | Cindy Morgan | IESG has approved the document |
|
2019-04-09
|
22 | Cindy Morgan | Closed "Approve" ballot |
|
2019-04-09
|
22 | Cindy Morgan | Ballot approval text was generated |
|
2019-04-09
|
22 | Benjamin Kaduk | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
|
2019-03-25
|
22 | Tirumaleswar Reddy.K | New version available: draft-ietf-dots-requirements-22.txt |
|
2019-03-25
|
22 | (System) | New version approved |
|
2019-03-25
|
22 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Robert Moskowitz <rgm@htt-consult.com>, Reddy K <tirumaleswarreddy_konda@mcafee.com>, Andrew Mortensen <andrewmortensen@gmail.com> |
|
2019-03-25
|
22 | Tirumaleswar Reddy.K | Uploaded new revision |
|
2019-03-23
|
21 | Eric Rescorla | [Ballot comment] I believe we have come to a satisfactory resolution and Benjamin will ensure that the correct changes are made. |
|
2019-03-23
|
21 | Eric Rescorla | [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss |
|
2019-03-18
|
21 | Mirja Kühlewind | [Ballot comment] Thanks for addressing my discuss. There is still my comment about references for SIG-002: For PLMTUD the correct reference is RFC4821, however, … [Ballot comment] Thanks for addressing my discuss. There is still my comment about references for SIG-002: For PLMTUD the correct reference is RFC4821, however, as commented by Joe, RFC1191 is less reliable and therefore usually not recommended. I would recommend to re-add a reference to RFC4821 and no reference to RFC1191 (or only with a warning that RFC4821 is preferred due to ICMP blocking). Further, the correct reference for datagram PLMTUD is draft-ietf-tsvwg-datagram-plpmtud. I would recommend to add a reference to this draft as well. And this general comment still holds: I understand that having wg consensus for this document is import to proceed the work of the group, however, I don't see the value in archiving this document in the IETF RFC series as a stand-alone document. If the group thinks documenting these requirements for consumption outside the group's work at a later point in time is valuable, I would rather recommend to add the respective requirements to the appendix of the respective protocol specs. |
|
2019-03-18
|
21 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
|
2019-03-08
|
21 | Tirumaleswar Reddy.K | New version available: draft-ietf-dots-requirements-21.txt |
|
2019-03-08
|
21 | (System) | New version approved |
|
2019-03-08
|
21 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Robert Moskowitz <rgm@htt-consult.com>, Reddy K <tirumaleswarreddy_konda@mcafee.com>, Andrew Mortensen <andrewmortensen@gmail.com> |
|
2019-03-08
|
21 | Tirumaleswar Reddy.K | Uploaded new revision |
|
2019-03-05
|
20 | Suresh Krishnan | [Ballot comment] Thanks for addressing my DISCUSS and COMMENTs. |
|
2019-03-05
|
20 | Suresh Krishnan | [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss |
|
2019-03-05
|
20 | Suresh Krishnan | [Ballot discuss] Thanks for addressing my DISCUSS and COMMENTs. |
|
2019-03-05
|
20 | Suresh Krishnan | Ballot comment and discuss text updated for Suresh Krishnan |
|
2019-02-28
|
20 | Tirumaleswar Reddy.K | New version available: draft-ietf-dots-requirements-20.txt |
|
2019-02-28
|
20 | (System) | New version approved |
|
2019-02-28
|
20 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Robert Moskowitz <rgm@htt-consult.com>, Reddy K <tirumaleswarreddy_konda@mcafee.com>, Andrew Mortensen <andrewmortensen@gmail.com> |
|
2019-02-28
|
20 | Tirumaleswar Reddy.K | Uploaded new revision |
|
2019-02-24
|
19 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2019-02-24
|
19 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2019-02-24
|
19 | Tirumaleswar Reddy.K | New version available: draft-ietf-dots-requirements-19.txt |
|
2019-02-24
|
19 | (System) | New version approved |
|
2019-02-24
|
19 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Robert Moskowitz <rgm@htt-consult.com>, Reddy K <tirumaleswarreddy_konda@mcafee.com>, Andrew Mortensen <andrewmortensen@gmail.com> |
|
2019-02-24
|
19 | Tirumaleswar Reddy.K | Uploaded new revision |
|
2019-02-23
|
18 | Benjamin Kaduk | Changed consensus to Yes from Unknown |
|
2019-02-21
|
18 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
|
2019-02-21
|
18 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
|
2019-02-21
|
18 | Eric Rescorla | [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3543 I only had a short time to read this, but I find myself confused about the … [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3543 I only had a short time to read this, but I find myself confused about the COMSEC requirements here. There is no COMSEC requirement for the signaling channel in S 2.2. DATA-002 requires a secure COMSEC protocol for the data channel. SEC-001 and SEC-002 require "peer mutual authentication" and "message confidentiality, integrity, and authentication" according to "industry best practices". This doesn't seem to be a requirement which I can verify or evaluate. If "industry best practices" were to use raw TCP, would such an implementation be conformant. I think what needs to be required here is cryptographic authentication of both sides and of the messages on both channels. Generally I would prefer to require confidentiality on both, but I could maybe see an argument for why that wasn't needed. DETAIL S 2.2. > free to attempt abbreviated security negotiation methods supported > by the protocol, such as DTLS session resumption, but MUST be > prepared to negotiate new security state with the redirection > target DOTS server. The authentication domain of the redirection > target DOTS server MUST be the same as the authentication domain > of the redirecting DOTS server. what is an "authentication domain"? S 2.4. > SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS > protocols MUST take steps to protect the confidentiality, > integrity and authenticity of messages sent between client and > server. While specific transport- and message-level security > options are not specified, the protocols MUST follow current > industry best practices for encryption and message authentication. This is not a verifiable conformance requirement |
|
2019-02-21
|
18 | Eric Rescorla | [Ballot comment] S 2.1. > proprietary DDoS defenses. Future extensions MUST be backward > compatible. Implementations of older protocol … [Ballot comment] S 2.1. > proprietary DDoS defenses. Future extensions MUST be backward > compatible. Implementations of older protocol versions MUST > ignore optional information added to DOTS messages as part of > newer protocol versions. Implementations of older protocol > versions MUST reject mandatory information added to DOTS messages > as part of newer protocol versions. MUST reject the information or MUST reject the messages. Conventionally, it's the latter. S 2.2. > discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot > be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for > IPv6. If IPv4 support on legacy or otherwise unusual networks is > a consideration and the PMTU is unknown, DOTS implementations MAY > rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in > [RFC0791] and [RFC1122]. I'm having trouble reading this text. You say above "MUST assume" and "MAY rely" here. Are you saying "send no more than 576" or "you can assume you can send at least 576 and we're not saying anything about the upper bound" S 2.2. > active DOTS client has not requested mitigation, in order to > control load. > > Following mutual authentication, a signal channel MUST be > considered active until a DOTS agent explicitly ends the session. > During peace time, signal channel MUST be considered active until "peace time" is probably not the right word here. After all, my country might be at peace but still subject to a DoS attack |
|
2019-02-21
|
18 | Eric Rescorla | [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla |
|
2019-02-21
|
18 | Alissa Cooper | [Ballot comment] I agree with others in that this document seems to have been overtaken by events. I agree with the Gen-ART reviewer that the … [Ballot comment] I agree with others in that this document seems to have been overtaken by events. I agree with the Gen-ART reviewer that the specification of the heartbeat requirements is so detailed that I suspect much of it will be essentially reproduced in the actual solution documents. |
|
2019-02-21
|
18 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
|
2019-02-21
|
18 | Suresh Krishnan | [Ballot discuss] I think SIG-002 is a bit underspecified. It points to draft-ietf-intarea-frag-fragile as the recommended mechanism for discovering PMTUD, but in fact draft-ietf-intarea-frag-fragile is … [Ballot discuss] I think SIG-002 is a bit underspecified. It points to draft-ietf-intarea-frag-fragile as the recommended mechanism for discovering PMTUD, but in fact draft-ietf-intarea-frag-fragile is designed to provide a list of potential solutions and recommendations for application and protocol developers (Section 7.1.). So I expect this document to specify what it intends to do for fragmentation instead of a vague reference. IPv4 does not support a minimum PMTU of 576 as claimed here. RFC791 clearly states that the minimum PMTU is 68 octets. I suggest rewording this to OLD: DOTS implementations MAY rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in [RFC0791] and [RFC1122]. NEW: DOTS implementations MAY assume on a PMTU of 576 bytes for IPv4 datagrams, as every IPv4 host must be capable of receiving a packet whose length is equal to 576 bytes as discussed in [RFC0791] and [RFC1122]. |
|
2019-02-21
|
18 | Suresh Krishnan | [Ballot comment] The recommendation of the 1280 byte minimum for IPv6 needs some reasoning and a reference to RFC8200. e.g. something like this would … [Ballot comment] The recommendation of the 1280 byte minimum for IPv6 needs some reasoning and a reference to RFC8200. e.g. something like this would work OLD: If the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for IPv6. NEW: If the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, as IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater as specified in [RFC8200]. |
|
2019-02-21
|
18 | Suresh Krishnan | [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan |
|
2019-02-21
|
18 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
|
2019-02-20
|
18 | Alvaro Retana | [Ballot comment] It seems to me that if "the requirements in this document are derived from [I-D.ietf-dots-use-cases] and [I-D.ietf-dots-architecture]", then those documents should be Normative … [Ballot comment] It seems to me that if "the requirements in this document are derived from [I-D.ietf-dots-use-cases] and [I-D.ietf-dots-architecture]", then those documents should be Normative references. Given that those documents haven't been published yet, and that the solutions (draft-ietf-dots-data-channel and draft-ietf-dots-signal-channel) have already passed WGLC, the publication value of this document may have been overtaken by events. I am not standing in the way of publication. |
|
2019-02-20
|
18 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2019-02-20
|
18 | Ben Campbell | [Ballot comment] - I'm curious what the archival value this has for publishing as an RFC. Did the WG consider alternative publication methods? (e.g., leave … [Ballot comment] - I'm curious what the archival value this has for publishing as an RFC. Did the WG consider alternative publication methods? (e.g., leave as a draft, publish in a WG wiki) §1.2: The draft uses 2119/8174 keywords to describe requirements for protocol design. That's not really how 2119 defines them. That doesn't prevent using them here, but it would be helpful to modify or add to the boilerplate to indicate this. |
|
2019-02-20
|
18 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
|
2019-02-20
|
18 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
|
2019-02-20
|
18 | Mirja Kühlewind | [Ballot discuss] Thanks for addressing the TSV-ART comments (and thanks Joe for the review)! In-line with Joe's comment, please see some additional comments below. 1) … [Ballot discuss] Thanks for addressing the TSV-ART comments (and thanks Joe for the review)! In-line with Joe's comment, please see some additional comments below. 1) One minor edit is required still for SIG-002: for PLMTUD the correct reference is RFC4821, however, as commented by Joe RFC1191 is less reliable and therefore usually not recommended. I would recommend to re-add a reference to RFC4821 and no reference to RFC1191 (or only with a warning that RFC4821 is preferred due to ICMP blocking). Further, the correct reference for datagram PLMTUD is draft-ietf-tsvwg-datagram-plpmtud. 2) Also on this text in SIG-004: "The heartbeat interval during active mitigation could be negotiable, but MUST be frequent enough to maintain any on-path NAT or Firewall bindings during mitigation. When TCP is used as transport, the DOTS signal channel heartbeat messages need to be frequent enough to maintain the TCP connection state." As Joe commented already, different heartbeats at different layers can be used at the same time for different purposes. You can use heartbeats at the application layer to check service availability while e.g. using a higher frequent heartbeat at the transport layer to maintain firewall and NAT state. The advantage to such an approach is that there is less application layer overhead/load e.g. in scenarios where it might be expensive to wake up the application or a server is already highly loaded. Also note that the time-outs values of NATs and firewalls on the path are usually unknown, therefore an application can never rely on heartbeats (no matter at which level) and must be prepared to try to reconnect on the application layer if the connection fails. Usually, the main reason for using heartbeats to maintain NAT or firewall state (vs. reconnect every time) in TCP is if the application is time-sensitive and a full TCP handshake takes too long for the desired service. I'm not sure that the case for DOTS, however, I understand it may be beneficial to have established state if an attack is on-going. For UDP I guess it's more complicated in your case. Time-outs are usually very short, however, state is created with the first packet of a flow (as there is no handshake in UDP). As you don't see blocking if state is expired as new state is created immediately, it's kind of impossible to measure the configured time-out values. Only if the firewall is under attack it would start blocking UDP traffic that is has no state for yet. So I understand why it is desirable to maintain UDP state for you, however, I don't understand how you can know that your frequency is high enough to actually keep the state open. Note that TCP time-outs are usually in the order of hours, while UDP time-outs are usually in range of tens of seconds, and might expire even quicker if a system is under attack. If that is a scenario that is important for you, and assuming that not all time-outs values on the path can be known, I guess it would be recommendable to use TCP instead. In any case this can not be a MUST requirement (as timers are usually not known). I would recommend to state something like: "MAY be frequent enough to maintain NAT or firewall state, if timer values are known, or if TCP is used, SHOULD use in addition TCP heartbeats to maintain the TCP connection state and reconnect immediately if a failure is detected." And also for this part it is different for TCP and UDP: "Because heartbeat loss is much more likely during volumetric attack, DOTS agents SHOULD avoid signal channel termination when mitigation is active and heartbeats are not received by either DOTS agent for an extended period." If TCP would be used and no ACKs are received, TCP would try to retransmit a few times and some point terminate the connection. However, UDP is a connection-less protocol, there is nothing to terminate. Also note that for reliable transports, it is sufficient if one end-hosts sends heartbeats as the other end is required to acknowledge the reception on the transport layer (and if no ack is received the connection is terminated on the transport layer). So I guess what you want to say above is that if a connection-less protocol is used, heartbeats should continuously be sent even if no heartbeats are received from the other end. However, I think you still need to define a termination criteria, as you for sure don't want to keep sending heartbeats forever. Also the next part: " * To handle possible DOTS server restart or crash, the DOTS clients MAY attempt to establish a new signal channel session, but MUST continue to send heartbeats on the current session so that the DOTS server knows the session is still alive. If the new session is successfully established, the DOTS client can terminate the current session." There is nothing like connection re-establishing in UDP, you just keep sending traffic. While in TCP, as explained above, the connection will be terminated at the transport layer and there is no way to keep sending heartbeats on the "old" session. Or do have something like DTLS in mind in this case? 3) In SIG-006 you say: " Due to the higher likelihood of packet loss during a DDoS attack, DOTS servers MUST regularly send mitigation status to authorized DOTS clients which have requested and been granted mitigation, regardless of client requests for mitigation status." Please note that this is only true if a not-reliable transport is used. If a reliable transport is used, data is received at the application level without loss (but maybe some delay) or the connection is terminated (if loss is too high to retransmit successfully). |
|
2019-02-20
|
18 | Mirja Kühlewind | [Ballot comment] One editorial comment on SEC-002: "A security mechanism at the network layer (e.g., TLS) is thus adequate to provide hop-by-hop … [Ballot comment] One editorial comment on SEC-002: "A security mechanism at the network layer (e.g., TLS) is thus adequate to provide hop-by-hop security. In other words, end-to-end security is not required for DOTS protocols." TLS is transport layer security (not network layer) and therefore known as providing end-to-end security while the term hop-by-hop is used for e.g. IPSec. I would recommend to change the wording here in order to avoid confusion, e.g. "A security mechanism at the transport layer (e.g., TLS) is thus adequate to provide security between different DOTS agents. In other words, a direct security association between the server and client, excluding any proxy, is not required for DOTS protocols." And finally one general comment: I understand that having wg consensus for this document is import to proceed the work of the group, however, I don't see the value in archiving this document in the IETF RFC series as a stand-alone document. If the group thinks documenting these requirements for consumption outside the group's work at a later point in time is valuable, I would rather recommend to add the respective requirements to the appendix of the respective protocol specs. |
|
2019-02-20
|
18 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
|
2019-02-13
|
18 | Robert Sparks | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Robert Sparks. Sent review to list. |
|
2019-02-07
|
18 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
|
2019-02-07
|
18 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
|
2019-02-06
|
18 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2019-02-05
|
18 | Amy Vezza | Placed on agenda for telechat - 2019-02-21 |
|
2019-02-04
|
18 | Benjamin Kaduk | IESG state changed to IESG Evaluation from Waiting for Writeup |
|
2019-02-04
|
18 | Benjamin Kaduk | Ballot has been issued |
|
2019-02-04
|
18 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
|
2019-02-04
|
18 | Benjamin Kaduk | Created "Approve" ballot |
|
2019-02-04
|
18 | Benjamin Kaduk | Ballot writeup was changed |
|
2019-02-04
|
18 | Tirumaleswar Reddy.K | New version available: draft-ietf-dots-requirements-18.txt |
|
2019-02-04
|
18 | (System) | New version approved |
|
2019-02-04
|
18 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Reddy K <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2019-02-04
|
18 | Tirumaleswar Reddy.K | Uploaded new revision |
|
2019-01-30
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2019-01-30
|
17 | Tirumaleswar Reddy.K | New version available: draft-ietf-dots-requirements-17.txt |
|
2019-01-30
|
17 | (System) | New version approved |
|
2019-01-30
|
17 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Reddy K <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2019-01-30
|
17 | Tirumaleswar Reddy.K | Uploaded new revision |
|
2018-11-24
|
16 | Scott Bradner | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Scott Bradner. Sent review to list. |
|
2018-11-23
|
16 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2018-11-21
|
16 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-dots-requirements-16, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-dots-requirements-16, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
|
2018-11-19
|
16 | Brian Weis | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Brian Weis. Sent review to list. |
|
2018-11-19
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
|
2018-11-19
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
|
2018-11-17
|
16 | Joseph Touch | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Joseph Touch. Sent review to list. |
|
2018-11-14
|
16 | Robert Sparks | Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
|
2018-11-03
|
16 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
|
2018-11-03
|
16 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-dots-requirements-16, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-dots-requirements-16, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
|
2018-11-02
|
16 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-11-23):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: dots@ietf.org, frank.xialiang@huawei.com, … The following Last Call announcement was sent out (ends 2018-11-23):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: dots@ietf.org, frank.xialiang@huawei.com, kaduk@mit.edu, dots-chairs@ietf.org, draft-ietf-dots-requirements@ietf.org, Liang Xia <frank.xialiang@huawei.com> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call Extended: <draft-ietf-dots-requirements-16.txt> (Distributed Denial of Service (DDoS) Open Threat Signaling Requirements) to Informational RFC The IESG has received a request from the DDoS Open Threat Signaling WG (dots) to consider the following document: - 'Distributed Denial of Service (DDoS) Open Threat Signaling Requirements' <draft-ietf-dots-requirements-16.txt> as Informational RFC 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 ietf@ietf.org mailing lists by 2018-11-23. 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 defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2744/ |
|
2018-11-02
|
16 | Cindy Morgan | Last call announcement was changed |
|
2018-10-31
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
|
2018-10-31
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
|
2018-10-30
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
|
2018-10-30
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
|
2018-10-29
|
16 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Joseph Touch |
|
2018-10-29
|
16 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Joseph Touch |
|
2018-10-26
|
16 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2018-10-26
|
16 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-11-09):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: dots@ietf.org, frank.xialiang@huawei.com, … The following Last Call announcement was sent out (ends 2018-11-09):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: dots@ietf.org, frank.xialiang@huawei.com, kaduk@mit.edu, dots-chairs@ietf.org, draft-ietf-dots-requirements@ietf.org, Liang Xia <frank.xialiang@huawei.com> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-dots-requirements-16.txt> (Distributed Denial of Service (DDoS) Open Threat Signaling Requirements) to Informational RFC The IESG has received a request from the DDoS Open Threat Signaling WG (dots) to consider the following document: - 'Distributed Denial of Service (DDoS) Open Threat Signaling Requirements' <draft-ietf-dots-requirements-16.txt> as Informational RFC 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 ietf@ietf.org mailing lists by 2018-11-09. 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 defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2744/ |
|
2018-10-26
|
16 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2018-10-26
|
16 | Benjamin Kaduk | Last call was requested |
|
2018-10-26
|
16 | Benjamin Kaduk | Last call announcement was generated |
|
2018-10-26
|
16 | Benjamin Kaduk | Ballot approval text was generated |
|
2018-10-26
|
16 | Benjamin Kaduk | Ballot writeup was generated |
|
2018-10-26
|
16 | Benjamin Kaduk | IESG state changed to Last Call Requested from AD Evaluation |
|
2018-10-22
|
16 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-16.txt |
|
2018-10-22
|
16 | (System) | New version approved |
|
2018-10-22
|
16 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Reddy K <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2018-10-22
|
16 | Andrew Mortensen | Uploaded new revision |
|
2018-10-16
|
15 | Benjamin Kaduk | IESG state changed to AD Evaluation from Publication Requested |
|
2018-08-30
|
15 | Liang Xia | 1. Summary The document shepherd is Liang Xia. The responsible Area Director is Benjamin Kaduk. This document defines the requirements for the Distributed Denial of … 1. Summary The document shepherd is Liang Xia. The responsible Area Director is Benjamin Kaduk. This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The working group has the consensus to publish it as an informational RFC since it is a requirements draft. 2. Review and Consensus The -00 version of this WG draft has been submitted in 2015-10, and it has evolved into its -15 version now. The co-authors are from the leading vendors in DDoS protection industry with extensive experience with the related technologies and implementations, they are also the core authors of the DOTS protocol WG drafts which guarantee the consistency among the requirements draft with them. It has been extensively reviewed and discussed within the working group by mailing list and github, and all technical issues raised have been resolved, most of them are before the -10 version. This draft covers different categories of requirements for: general, signal channel, data channel, security and data model. The signal channel requirements is the most important and complex one as it works during the attack time so that it requires the highest resilience, efficiency and fault tolerance. Specially, the heartbeat handling (SIG-004) and NAT traversal (SIG-010) issues are considered highly complicated as they include many corner cases, and are discussed mostly in the WG. So, careful review of them is needed. After long term discussion among the WG and enough iteration of update, the draft is mature enough and there is strong consensus in the WG to pass the WGLC and go to next stage. 3. Intellectual Property Each author has confirmed conformance with BCPs 78 and 79. Arbor Networks, Inc. has filed an IPR statement #2744 related with DOTS for this draft. This issue has been announced in the WG mailing list and there were no objections to proceeding with this work once the IPR disclosure was filed. 4. Other Points By performing the idnits check, there are no warning or error. |
|
2018-08-30
|
15 | Liang Xia | Responsible AD changed to Benjamin Kaduk |
|
2018-08-30
|
15 | Liang Xia | IETF WG state changed to Submitted to IESG for Publication from WG Document |
|
2018-08-30
|
15 | Liang Xia | IESG state changed to Publication Requested |
|
2018-08-30
|
15 | Liang Xia | IESG process started in state Publication Requested |
|
2018-08-30
|
15 | Liang Xia | Intended Status changed to Informational from None |
|
2018-08-30
|
15 | Liang Xia | Changed document writeup |
|
2018-08-30
|
15 | Liang Xia | Notification list changed to Liang Xia <frank.xialiang@huawei.com> |
|
2018-08-30
|
15 | Liang Xia | Document shepherd changed to Liang Xia |
|
2018-08-29
|
15 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-15.txt |
|
2018-08-29
|
15 | (System) | New version approved |
|
2018-08-29
|
15 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2018-08-29
|
15 | Andrew Mortensen | Uploaded new revision |
|
2018-08-11
|
14 | (System) | Document has expired |
|
2018-07-18
|
14 | Roman Danyliw | Added to session: IETF-102: dots Thu-1550 |
|
2018-03-19
|
14 | Roman Danyliw | Added to session: IETF-101: dots Tue-1550 |
|
2018-02-07
|
14 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-14.txt |
|
2018-02-07
|
14 | (System) | New version approved |
|
2018-02-07
|
14 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2018-02-07
|
14 | Andrew Mortensen | Uploaded new revision |
|
2018-02-07
|
13 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-13.txt |
|
2018-02-07
|
13 | (System) | New version approved |
|
2018-02-07
|
13 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2018-02-07
|
13 | Andrew Mortensen | Uploaded new revision |
|
2018-02-01
|
12 | Roman Danyliw | Added to session: interim-2018-dots-01 |
|
2018-01-25
|
12 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-12.txt |
|
2018-01-25
|
12 | (System) | New version approved |
|
2018-01-25
|
12 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2018-01-25
|
12 | Andrew Mortensen | Uploaded new revision |
|
2018-01-23
|
11 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-11.txt |
|
2018-01-23
|
11 | (System) | New version approved |
|
2018-01-23
|
11 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2018-01-23
|
11 | Andrew Mortensen | Uploaded new revision |
|
2018-01-02
|
10 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-10.txt |
|
2018-01-02
|
10 | (System) | New version approved |
|
2018-01-02
|
10 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2018-01-02
|
10 | Andrew Mortensen | Uploaded new revision |
|
2017-12-19
|
09 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-09.txt |
|
2017-12-19
|
09 | (System) | New version approved |
|
2017-12-19
|
09 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2017-12-19
|
09 | Andrew Mortensen | Uploaded new revision |
|
2017-12-05
|
08 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-08.txt |
|
2017-12-05
|
08 | (System) | New version approved |
|
2017-12-05
|
08 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2017-12-05
|
08 | Andrew Mortensen | Uploaded new revision |
|
2017-11-08
|
07 | Roman Danyliw | Added to session: IETF-100: dots Tue-1330 |
|
2017-10-30
|
07 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-07.txt |
|
2017-10-30
|
07 | (System) | New version approved |
|
2017-10-30
|
07 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2017-10-30
|
07 | Andrew Mortensen | Uploaded new revision |
|
2017-09-29
|
06 | Roman Danyliw | Added to session: interim-2017-dots-03 |
|
2017-07-13
|
06 | Roman Danyliw | Added to session: IETF-99: dots Thu-1550 |
|
2017-07-03
|
06 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-06.txt |
|
2017-07-03
|
06 | (System) | New version approved |
|
2017-07-03
|
06 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Robert Moskowitz <rgm@htt-consult.com>, Tirumaleswar Reddy <tirumaleswarreddy_konda@mcafee.com> |
|
2017-07-03
|
06 | Andrew Mortensen | Uploaded new revision |
|
2017-06-07
|
05 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-05.txt |
|
2017-06-07
|
05 | (System) | New version approved |
|
2017-06-07
|
05 | (System) | Request for posting confirmation emailed to previous authors: dots-chairs@ietf.org, Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tireddy@cisco.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2017-06-07
|
05 | Andrew Mortensen | Uploaded new revision |
|
2017-06-06
|
04 | Roman Danyliw | Added to session: interim-2017-dots-02 |
|
2017-03-27
|
04 | Roman Danyliw | Added to session: IETF-98: dots Tue-1640 |
|
2017-03-13
|
04 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-04.txt |
|
2017-03-13
|
04 | (System) | New version approved |
|
2017-03-13
|
04 | (System) | Request for posting confirmation emailed to previous authors: Andrew Mortensen <amortensen@arbor.net>, Tirumaleswar Reddy <tireddy@cisco.com>, Robert Moskowitz <rgm@htt-consult.com> |
|
2017-03-13
|
04 | Andrew Mortensen | Uploaded new revision |
|
2017-02-21
|
03 | Roman Danyliw | Added to session: interim-2017-dots-01 |
|
2016-11-15
|
03 | Roman Danyliw | Added to session: IETF-97: dots Fri-0930 |
|
2016-10-31
|
03 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-03.txt |
|
2016-10-31
|
03 | (System) | New version approved |
|
2016-10-31
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Andrew Mortensen" <amortensen@arbor.net>, "Tirumaleswar Reddy" <tireddy@cisco.com>, "Robert Moskowitz" <rgm@htt-consult.com> |
|
2016-10-31
|
02 | Andrew Mortensen | Uploaded new revision |
|
2016-07-08
|
02 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-02.txt |
|
2016-03-21
|
01 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-01.txt |
|
2016-01-28
|
Naveen Khan | Posted related IPR disclosure: Arbor Networks, Inc.'s Statement about IPR related to draft-ietf-dots-requirements | |
|
2015-10-19
|
00 | Andrew Mortensen | New version available: draft-ietf-dots-requirements-00.txt |