Subject: Re: [Dots] New Version Notification for draft-reddy-dots-transport-00.txt

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 03 Jul 2015 20:37:39 +0700

On 1 Jul 2015, at 0:35, Scott Barvick wrote:

> I'd encourage you to join the DOTS efforts and help make DOTS support 
> this use case as well as the other use cases that we are developing.

Concur.  This is a good architectural and operational model of the 
mechanics of DDoS mitigation which would be the ultimate output of DOTS 
signaling from an organization under attack to an organization 
performing DDoS mitigation for the targeted organization.

If we can update this to include the initial signaling from the targeted 
organization to the mitigation organization - i.e., the portion of the 
mitigation chain which is the mandate of this WG - I think this could 
prove an excellent example of how DOTS fits into that mitigation chain.

There's no requirement for a DOTS supplicant node to have any organic 
detection/classification/traceback mechanism; if a supplicant has that 
capability, that's potentially useful, but our initial focus with the 
first phase of this effort is simply to standardize upon a protocol 
which allows either automated or manually-triggered mitigation requests 
to be signaled either inter- or intra-organizationally in order to 
request that DDoS mitigation activities be initiated on an on-demand 
basis, and which also allows for useful feedback regarding the efficacy 
and status of said mitigation activities to be signaled back to the 
requestor.  It should be designed so that it can easily be extended to 
incorporate other desired functionality in future phases of development.

Very specifically, this statement:

    Enterprises typically deploy DDoS monitoring appliances that are
    capable of inspecting and monitoring traffic to detect potential 
DDoS
    threats and generate alarms when some thresholds have been reached.

while reflecting a very desirable state of affairs, is somewhat 
aspirational in nature, at this juncture.  While more and more endpoint 
networks are beginning to investigate and deploy systems which provide 
these capabilities, it isn't the norm, today.  One of the purposes of 
the DOTS signaling effort is to provide organizations which 
haven't/can't deploy these types of systems with a signaling mechanism 
they can utilize to request DDoS mitigation assistance as required.

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

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 6 Jul 2015 07:11:24 +0000

Hi Roland,
I tend to agree this work is an important part of the whole migration chain. But I am not sure where this configuration related work should be done: DOTS or I2NSF?

B.R
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2015年7月3日 21:38
收件人: [email-masked]
抄送: Tirumaleswar Reddy (tireddy)
主题: Re: [Dots] New Version Notification for draft-reddy-dots-transport-00.txt

> this use case as well as the other use cases that we are developing.

Concur.  This is a good architectural and operational model of the mechanics of DDoS mitigation which would be the ultimate output of DOTS signaling from an organization under attack to an organization performing DDoS mitigation for the targeted organization.

If we can update this to include the initial signaling from the targeted organization to the mitigation organization - i.e., the portion of the mitigation chain which is the mandate of this WG - I think this could prove an excellent example of how DOTS fits into that mitigation chain.

There's no requirement for a DOTS supplicant node to have any organic detection/classification/traceback mechanism; if a supplicant has that capability, that's potentially useful, but our initial focus with the first phase of this effort is simply to standardize upon a protocol which allows either automated or manually-triggered mitigation requests to be signaled either inter- or intra-organizationally in order to request that DDoS mitigation activities be initiated on an on-demand basis, and which also allows for useful feedback regarding the efficacy and status of said mitigation activities to be signaled back to the requestor.  It should be designed so that it can easily be extended to incorporate other desired functionality in future phases of development.

    Enterprises typically deploy DDoS monitoring appliances that are
    capable of inspecting and monitoring traffic to detect potential DDoS
    threats and generate alarms when some thresholds have been reached.

while reflecting a very desirable state of affairs, is somewhat aspirational in nature, at this juncture.  While more and more endpoint networks are beginning to investigate and deploy systems which provide these capabilities, it isn't the norm, today.  One of the purposes of the DOTS signaling effort is to provide organizations which haven't/can't deploy these types of systems with a signaling mechanism they can utilize to request DDoS mitigation assistance as required.

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 06 Jul 2015 20:38:21 +0700

On 6 Jul 2015, at 14:11, Xialiang (Frank) wrote:

> But I am not sure where this configuration related work should be 
> done: DOTS or I2NSF?

At the appropriate juncture, it will be necessary to provide 
architectural and functional examples to guide implementors and 
operators.  And as you note, it will also be necessary to make scoping 
determinations with regards to potentially complementary efforts such as 
I2NSF.