DDoS Open Threat Signaling
charter-ietf-dots-01

[Ballot comment]
This might be part of "* Document or Documents describing the problem space, use cases, protocol requirements and other qualifying information as the WG sees fit." but since you listed some deliverables and milestones, it might be worth specifically mentioning an applicatibility statement (or architecture) document explaining how all these elements should communicate together for a complete DDoS service.

[Ballot comment]
Based one the fact that DDOS systems within different ISPs already discuss together today (but with a proprietary protocol), as mentioned by Kathleen, I'm clearing my DISCUSS.
For documentation purposes, the BLOCK was:
More of DISCUSS-DISCUSS for the telechat than a BLOCK.

"These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for connection oriented approaches and more generalized
signaling and telemetry solutions."

"Document or Documents describing the problem space, use cases, protocol
requirements and other qualifying information as the WG sees fit."

I would strongly encourage the group to focus first on the intra-domain: this is already a huge problem. The inter-domain use cases will lead to different set of requirements (sending telemetry info across domains, potential synchronization of the collecting infrastructure).
Sharing IPFIX data between domains is not a reality today, and and when I see "Feedback between participating elements is required for increased awareness supporting effective decision making.", it remains to be seen if elements from different domains will communicate...
Don't make the scope too big.


========================
Btw, any link with BGP Flow Spec to block the attack?

[Ballot comment]
Based one the fact that DDOS systems within different ISPs already discuss together today (but with a proprietary protocol), I'm clearing my DISCUSS.
For documentation purposes, the BLOCK was:
More of DISCUSS-DISCUSS for the telechat than a BLOCK.

"These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for connection oriented approaches and more generalized
signaling and telemetry solutions."

"Document or Documents describing the problem space, use cases, protocol
requirements and other qualifying information as the WG sees fit."

I would strongly encourage the group to focus first on the intra-domain: this is already a huge problem. The inter-domain use cases will lead to different set of requirements (sending telemetry info across domains, potential synchronization of the collecting infrastructure).
Sharing IPFIX data between domains is not a reality today, and and when I see "Feedback between participating elements is required for increased awareness supporting effective decision making.", it remains to be seen if elements from different domains will communicate...
Don't make the scope too big.


========================
Btw, any link with BGP Flow Spec to block the attack?

[Ballot block]
More of DISCUSS-DISCUSS for the telechat than a BLOCK.

"These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for connection oriented approaches and more generalized
signaling and telemetry solutions."

"Document or Documents describing the problem space, use cases, protocol
requirements and other qualifying information as the WG sees fit."

I would strongly encourage the group to focus first on the intra-domain: this is already a huge problem. The inter-domain use cases will lead to different set of requirements (sending telemetry info across domains, potential synchronization of the collecting infrastructure).
Sharing IPFIX data between domains is not a reality today, and and when I see "Feedback between participating elements is required for increased awareness supporting effective decision making.", it remains to be seen if elements from different domains will communicate...
Don't make the scope too big.

[Ballot comment]
One consistent issue that I have found with pushing  telemery and then mitigation upstream is the loss of visibility into the attack. so while downstream customers may be senders of information at some point they also need any telemetry generated upstream.

[Ballot comment]
The first thing that grabbed me was impact of DOTS on a system/network that is under attack. I think Martin has raised it well, so I won't belabour the point.

I wonder if this, in the nature of the work, is going to be of a far more experimental nature than it is a standards track body of work? I can foresee _multiple_ iterations (presuming the proponents move passed talking about the problem) over implementation and design principles. As a WG outputting experimental documents it will mean that they will have an interesting time modifying existing RFCs within the WG, but will be able to still collaborate with other WGs as necessary.

[Ballot comment]
I have the same question Martin has, in his BLOCK. If there are any requirements for the transport protocol that would disqualify TCP (or, for extra credit, SCTP or MP-TCP),  it would be great to know that at charter time.

Thank you for addressing Stephen's BLOCK-light.

[Ballot block]
[updated to DISCUSS, after the email discussion with Tobias]

The charter has to document the fact that the WG might be required to evaluate what transport protocol should be used for transporting DOTS.

My next question would be: Is there the assumption that the DOTS signaling is travelling the reverse path of the DoS attack? Or is the DOTS signaling ok travelling a different path from one NE under attack the an upstream NE under attack?

My original question is below:
I support the chartering, but I have a question about this paragraph:

"These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for connection oriented approaches and more generalized
signaling and telemetry solutions."

Is this text trying to make a statement that, for instance,  TCP cannot be used for transporting threat signaling?  As this text says "hostile conditions for connection oriented". And if so, what would be the intended alternative, if any?

[Ballot comment]
I support the chartering, but I have a question about this paragraph:

"These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for connection oriented approaches and more generalized
signaling and telemetry solutions."

Is this text trying to make a statement that, for instance,  TCP cannot be used for transporting threat signaling?  As this text says "hostile conditions for connection oriented". And if so, what would be the intended alternative, if any?

[Ballot comment]
The text says that the WG will reuse or extend existing standard protocols and mechanisms, which is great!  However, is the intent for dots to standardize those extensions (if needed)?  IOW, if an existing protocol (for signaling, for example) is extended, I think that the WG responsible for that protocol should be the one driving the standardization based on the requirements from dots.  The text mentions ipfix as an example; I know the ipfix WG is closed, so it can't take ownership of the extensions, but the OPS area should at  least be consulted.

After saying all that, I would suggest adding something explicit about consulting, coordinating, etc. with other WGs that may be responsible for any protocols being extended.  Maybe something like this:

"Any modification of or extension to existing protocols must be carried out in the working groups responsible for the protocol being modified and in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible Area Directors."

[Ballot comment]
This is not a BLOCK but I'd like to chat about it and may consider
it being a BLOCK at the next stage, depending on the discussion.
The text says "providing for privacy in operation" but I think it
ought say "providing for privacy in operation, with privacy-friendly
choices being the default in all cases" (or similar). This kind of
reporting can easily end up privacy-unfriendly, especially when
we're saying the WG should consider "network security applications
beyond the DDoS problem space" which could be interpreted by
some to include very privacy-unfriendly applications. So I think
explicitly calling for the default to be whatever privacy-friendly
choices exist and are usable is important here.

[Ballot comment]
There is likely significant overlap here with deployed stuff , and M3AAWG would know about that.  I will talk with people about that during the upcoming week  at M3AAWG in Dublin, and I will make sure that the external review message is posted to the M3AAWG Technical Committee.  But I would appreciate it if the charter explicitly called out collaboration with M3AAWG.