Subject: [Dots] Hi, some comments to DOTS requirements draft:

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 11 May 2016 08:27:08 +0000

Hi authors,
By reviewing this draft recently, I have the following new comments:

1.       Inter-domain coordinated DDoS protection is the important part of the whole DOTS solution, but it seems that current DOTS requirements draft does not include enough contents about this part. Especially in the following sections:

1)       In Section 1.1: it only mentions the problem of missing the standard interface between clients and ddos protection providers (C2P scenario), totally misses describing the same problem for the providers to providers (P2P) scenario. Correspondingly, this section only emphasis the benefits of real-time response for the C2P scenario, do not mention other benefits of resource/capabilities sharing, worldwide optimized mitigation and near source mitigation for the P2P scenario. Please include this kind of contents in later version, and you can reference to other 2 DOTS drafts about inter-domain DOTS use cases and mechanisms;

2)       In Section 1.2: For clarity, I suggest to add a new terminology to specify what is the domain in ODTS scope. A domain can be a network domain, a SMB network, a DDoS protection provider network, etc;

2.       In Section 1.2, some modification should be made to the terminologies for DOTS client, DOTS server, Client signal and Server signal, as following:

1)       DOTS client: "..., as well as exchanging and updating other information with DOTS server or relay, such as mitigation scope, mitigation efficacy and mitigation status.";

2)       DOTS server: "..., as well as exchanging and updating other information with DOTS client or relay, such as mitigation scope, mitigation efficacy and mitigation status.";

3)       Client signal: "... Other signals include the messages for updating information with DOTS server or relay, such as mitigation scope and mitigation efficacy.";

4)       Server signal: "... The other server signal is mitigation termination notification ."

3.       A series of requirements for the DOTS relay are still missed in current draft. We need to consider how to incorporate them;

4.       In Section 2.3, suggest to add the requirement description for the DOTS client's registration and registration cancelling messages, DOTS server's registration response and registration cancelling response message, which are conveyed over the data channel.

Thanks!

B.R.
Frank

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 11 May 2016 11:10:01 +0000

Hi,

>1)       In Section 1.1: it only mentions the problem of missing the standard interface between clients and ddos protection providers (C2P scenario), totally misses describing the same problem for t…

I think its implied but maybe not described explicitly - imho a ‘p2p’ has little real distinction from 'c2p'.  One side is always a client and the other a server for a given set of customer assets and protection/mitigation requests.

I’m not sure its up to the requirements draft to call out benefits/pros/cons of any given application or for that matter give weight to any one deployment type but rather that should be a function of the primary use case draft (or its satellites).  

We should be able to match the requirements to the various use cases and then in turn map the protocol accordingly.  And that’s probably a good exercise for us to undertake prior to Berlin.

The suggestions for 1.2 with mitigation scope/efficacy/status called out… I would like to see further elaboration on these terms in these context before suggesting they go near the requirements.  From my perspective on the provider side I don’t care what the client did… just that they asked for protection. 

Thanks,

-Nik

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 11 May 2016 18:31:07 +0700

On 11 May 2016, at 18:10, Teague, Nik wrote:

> I would like to see further elaboration on these terms in these 
> context before suggesting they go near the requirements.  From my 
> perspective on the provider side I don’t care what the client did… 
> just that they asked for protection.

Concur 100% - we'll take a stab at it.

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

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Wed, 11 May 2016 08:26:07 -0400

Thanks! See my quick comment below.

On Wednesday, May 11, 2016, Xialiang (Frank) <[email-masked]>
wrote:

> 3.       A series of requirements for the DOTS relay are still missed in
> current draft. We need to consider how to incorporate them;
>
>
During the meeting I heard a call to get rid of DOTS relays, given the
operational complexity. Relayed signaling would remain a concept, but would
look more or less like what's currently called Recursive signaling in the
architecture draft. (I recall you pointing out that the Mitigator wouldn't
have to be the element recursing the signal in that case, and the DOTS
server could do it instead.)

andrew

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 11 May 2016 19:31:30 +0700

On 11 May 2016, at 19:26, Mortensen, Andrew wrote:

> Relayed signaling would remain a concept, but would
> architecture draft.

Essentially, a server and client grafted back-to-back.  So, we'll have a 
relay function, but it won't be a distinct node type for crypto/auth 
purposes.

I believe that's what Frank was alluding to - that we need to spell this 
out.
-----------------------------------
Roland Dobbins <[email-masked]>

---

From: Andrew Mortensen <[email-masked]>
Date: Wed, 11 May 2016 09:45:04 -0400

> On May 11, 2016, at 8:31 AM, Roland Dobbins <[email-masked]> wrote:
> 
> Essentially, a server and client grafted back-to-back.  So, we'll have a relay function, but it won't be a distinct node type for crypto/auth purposes.
> 
> I believe that's what Frank was alluding to - that we need to spell this out.

Agreed.

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 12 May 2016 01:54:10 +0000

Hi Nik,
Please see my comments inline:

-----邮件原件-----
发件人: Teague, Nik [mailto:[email-masked]] 
发送时间: 2016年5月11日 19:10
收件人: Xialiang (Frank); Andrew Mortensen; Robert Moskowitz; Tirumaleswar Reddy (tireddy)
抄送: [email-masked]
主题: Re: [Dots] Hi, some comments to DOTS requirements draft:

Hi,

I think its implied but maybe not described explicitly - imho a ‘p2p’ has little real distinction from 'c2p'.  One side is always a client and the other a server for a given set of customer assets and protection/mitigation requests.
[Frank]: Technically, you are right that it's implied. I just think more comprehensive descriptions of DOTS solution's applications and their values are better in the introduction part, especially for the very important use cases. But it's just my personal suggestion and I don't have strong opinions~~

[Frank]: sure.

[Frank]: ok, I agree.

B.R.
Frank

Thanks,

-Nik

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 12 May 2016 02:01:44 +0000

Hi Roland and Andrew,
Thanks for clarification and consideration.

B.R.
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
发送时间: 2016年5月11日 20:32
收件人: [email-masked]
主题: Re: [Dots] Hi, some comments to DOTS requirements draft:

On 11 May 2016, at 19:26, Mortensen, Andrew wrote:

> Relayed signaling would remain a concept, but would look more or less 
> like what's currently called Recursive signaling in the architecture 
> draft.

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