Subject: [Dots] Benoit Claise's No Objection on charter-ietf-dots-00-02: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 11 Jun 2015 07:46:41 -0700

Benoit Claise has entered the following ballot position for
charter-ietf-dots-00-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-dots/

----------------------------------------------------------------------
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?

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 12 Jun 2015 15:51:35 +0700

On 11 Jun 2015, at 21:46, Benoit Claise wrote:

> Sharing IPFIX data between domains is not a reality today,

IPFIX (and NetFlow, and other flow telemetry) is in some cases shared 
between domains today; I think what you're saying here is that there's 
no AAA nor built-in mechanism for controlling what's exported.  It's 
done ad-hoc.

This is true, but it isn't a barrier to achieving the DOTS mandate.

The reference to IPFIX within the DOTS charter is in the context of the 
IPFIX traffic classification model and format being an example of a 
classification format which might be used within the context of a DOTS 
mitigation request and/or subsequent response.

> if elements from different domains will communicate...

Actually, this is a core requirement; for example, in the case of an 
endpoint enterprise network signaling southbound to an upstream transit 
provider or MSSP cloud overlay provider to initiate DDoS mitigation to 
protect the endpoint network's Internet-facing properties.  It is in 
fact the raison d'etre for DOTS.

Another example would be a transit provider signaling southbound to a 
downstream wireline broadband access provider to ask the access provider 
to squelch outbound DDoS traffic emanating from one of its 
end-customers.

> Don't make the scope too big.

There's a certain plateau of functionality required in order to make 
DOTS useful and deployable on production networks.  Inter-domain 
communications falls into that category - otherwise, there's little need 
for DOTS in the first place.

Flowspec, or S/RTBH, or IDMS, or other forms of mitigation would be a 
result of DOTS signaling, not part of DOTS itself.  For example, a 
hosting provider may initiate a DOTS request to its upstream transit 
providers to block DDoS traffic identifiable with certain classifiers 
within their networks; whether the upstreams respond via flowspec, or 
S/RTBH, or IDMS, or scripting-generated/-deployed ACLs, et. al. is a 
decision made by said upstreams outside of the scope of DOTS itself.

Without getting too far ahead of ourselves, we can speculate that there 
might be some form of abstracted requested mitigation action in a DOTS 
request - say, 'block sources', or 'block traffic matching the specified 
classifier based upon 5-tuple towards this particular destination IP 
address', or 'drop packets with the specified HTTP payload classifier 
originating from this particular netblock', or what-have-you.  These 
would be generic in nature, and the selection of suitable mitigation 
mechanisms in order to fulfill the parameters of the request would be 
determined by actual responder.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 12 Jun 2015 13:00:57 +0200

Roland,

Thanks for the clarification.

Regards, Benoit
> The reference to IPFIX within the DOTS charter is in the context of 
> the IPFIX traffic classification model and format being an example of 
> a classification format which might be used within the context of a 
> DOTS mitigation request and/or subsequent response.
>
> endpoint enterprise network signaling southbound to an upstream 
> transit provider or MSSP cloud overlay provider to initiate DDoS 
> mitigation to protect the endpoint network's Internet-facing 
> properties.  It is in fact the raison d'etre for DOTS.
>
> downstream wireline broadband access provider to ask the access 
> provider to squelch outbound DDoS traffic emanating from one of its 
> end-customers.
>
> communications falls into that category - otherwise, there's little 
> need for DOTS in the first place.
>
>> ========================
> Without getting too far ahead of ourselves, we can speculate that 
> there might be some form of abstracted requested mitigation action in 
> a DOTS request - say, 'block sources', or 'block traffic matching the 
> specified classifier based upon 5-tuple towards this particular 
> destination IP address', or 'drop packets with the specified HTTP 
> payload classifier originating from this particular netblock', or 
> what-have-you.  These would be generic in nature, and the selection of 
> suitable mitigation mechanisms in order to fulfill the parameters of 
> the request would be determined by actual responder.
>
> .