Subject: [Dots] Feedback on draft-nishizuka-dots-inter-domain-mechanism-01

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 18 Jul 2016 13:03:01 +0000

Hello WG!

WG chair hat off ...

In reading through draft-nishizuka-dots-inter-domain-mechanism-01 I have the following feedback:

(1) When an updated use case document is released, I'd recommend removing Section 3 and 4 and focus this document on describing only the protocol

(2) I recommend including language somewhere in the draft describing which set of use cases in the WG UC draft are satisfied.  Currently Section 3-4 describe candidate use cases, but what about the other uses cases currently in the WG UC document?

(3) Section 5, I recommend citing the references to HTTPS and TLS

(4) Section 5, Provisioning stage, "A DOTS client should register itself to the DOTS server, as well as enable capacity building in advance." In the context of DOTS, what protocol support is expected to "enable capacity building in advance"?

(5) Section 5.1.1, customer_name, How should this name be generated?

(6) Section 5.1.1, ip_version, To what traffic does this version number refer?

(7) Section 5.1.1, BGP_route, countermeasures, tunnel_information, next_hop, What is the format of this field?

(8) Section 5.1.1., SIP_URI and E164_number, I would recommend citing the reference.

(9) Section 5.1.1, protected_ports, To clarify, is this the subset of ports possible to enumerate in future mitigation requests?

(10) Section 5.1.1, whitelist and blacklist, I would recommend being explicit on what the DOTS server is supposed to do with this list.

(11) Section 5.1.1, How is a registration request rejection signaled? 

(12) When is the Heartbeat message sent

(13) I recommend adding the version field used in the messages in 5.2.1 to the provisioning messages in 5.1.1.

(14) Section 5.2.1, DST_IP is used in the definition of multiple fields but is not defined.  Is this field the same as dst_ip from packet_header?

(15) Section 5.2.1, max_bandwidth, What is meant by the "max bandwidth the DOTS client can undertake"?  Could you please clarify the semantics of this field.

(16) Section 5.2.1, packet_header, This field is defined a "IP packet header contents used for a report".  What report is this definition referencing?

(17) Section 5.2.1, current_throughputs, What does it mean to have multiple CSV separated values in this field?

(18) Section 5.2.1, health, Is there a standardized way to calculate this value?  Is it pre-negotiated, out-of-band, between client/server?

(19) Section 5.2.1, payload, Should this be in the signal channel or the data channel?

(20) Section 5.2.1, hash, Is this hash calculated on the complete payload or the truncated value per the offset field?

Roman

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 20 Jul 2016 07:33:45 +0000

Hi Roman,
Thanks for the detailed comments. 
My response is inline:

B.R.
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Roman D. Danyliw
发送时间: 2016年7月18日 21:03
收件人: [email-masked]
主题: [Dots] Feedback on draft-nishizuka-dots-inter-domain-mechanism-01

Hello WG!

WG chair hat off ...

(1) When an updated use case document is released, I'd recommend removing Section 3 and 4 and focus this document on describing only the protocol
[Frank]: good point, that's what we are considering now. They should be in use cases or architecture drafts.

[Frank]: ok, we will.

[Frank]: will do.

(4) Section 5, Provisioning stage, "A DOTS client should register itself to the DOTS server, as well as enable capacity building in advance." In the context of DOTS, what protocol support is expected to "enable capacity building in advance"?
[Frank]: In section 5.1.2, we have the details: "The customers (DOTS client) registers to the operator controller with the configuration and capability building including protection methods, process capacity, protected zone, security profile, white/black-list, etc". Does it make sense?

(5) Section 5.1.1, customer_name, How should this name be generated?
[Frank]: it's generated by DOTS client itself, but the custom_id is the unique value generated by the DOTS server

(6) Section 5.1.1, ip_version, To what traffic does this version number refer?
[Frank]: the version of the DOTS client's all traffic

(7) Section 5.1.1, BGP_route, countermeasures, tunnel_information, next_hop, What is the format of this field?
[Frank]: we will describe them with details in next version, thanks for reminds.

[Frank]: ok.

(9) Section 5.1.1, protected_ports, To clarify, is this the subset of ports possible to enumerate in future mitigation requests?
[Frank]: Yes, I think so. I tend to think there should be some restriction here, which means dots server only protect those ports that have been registered.

(10) Section 5.1.1, whitelist and blacklist, I would recommend being explicit on what the DOTS server is supposed to do with this list.
[Frank]: In registration response message, it can indicate whether DOTS server can support it. Do you mean more information than this?

(11) Section 5.1.1, How is a registration request rejection signaled? 
[Frank]: we have the details in the last bullet of section 5.1.2. Are they good enough?

(12) When is the Heartbeat message sent
[Frank]: It's periodically sent to the peer DOTS agents right after the DOTS registration process is finished, and till the DOTS client cancels its registration to the DOTS server.

[Frank]: point taken.

(14) Section 5.2.1, DST_IP is used in the definition of multiple fields but is not defined.  Is this field the same as dst_ip from packet_header?
[Frank]: it should be the same.

(15) Section 5.2.1, max_bandwidth, What is meant by the "max bandwidth the DOTS client can undertake"?  Could you please clarify the semantics of this field.
[Frank]: The DOTS client tell its maximum bandwidth capability to the DOTS server for its better decision. Does it make sense?

(16) Section 5.2.1, packet_header, This field is defined a "IP packet header contents used for a report".  What report is this definition referencing?
[Frank]: I think it just simply means the mitigation request message~~ We need some improvement of the text.

(17) Section 5.2.1, current_throughputs, What does it mean to have multiple CSV separated values in this field?
[Frank]: good question. The reason we use multiple CSV is to send a set of attack information in one DOTS mitigation request message, for increasing the efficiency.

(18) Section 5.2.1, health, Is there a standardized way to calculate this value?  Is it pre-negotiated, out-of-band, between client/server?
[Frank]: yes we need it. We will specify it in next version. Any good suggestion?

(19) Section 5.2.1, payload, Should this be in the signal channel or the data channel?
[Frank]: this payload is the sampled content of the attack traffic, which is sent during that attack time. So, the signaling channel is more suitable.

(20) Section 5.2.1, hash, Is this hash calculated on the complete payload or the truncated value per the offset field?
[Frank]: the truncated part.

Roman

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

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 20 Jul 2016 17:18:29 +0000

Hi Frank!

Thanks for the response.  My comments are inline.  Where I removed a item, you answered my question (thanks).

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
> Sent: Wednesday, July 20, 2016 3:34 AM
> To: Roman D. Danyliw <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Dots] Feedback on draft-nishizuka-dots-inter-domain-
> mechanism-01
> 
> Hi Roman,

[snip]

> (4) Section 5, Provisioning stage, "A DOTS client should register itself to the
> DOTS server, as well as enable capacity building in advance." In the context
> of DOTS, what protocol support is expected to "enable capacity building in
> advance"?
> [Frank]: In section 5.1.2, we have the details: "The customers (DOTS client)
> registers to the operator controller with the configuration and capability
> building including protection methods, process capacity, protected zone,
> security profile, white/black-list, etc". Does it make sense?

It does but then I have a nit related to the use of the phrase "capacity building".  It doesn't seem to fit here for me.

> value generated by the DOTS server

If it's a free form value, I'd recommend stating that for clarify in the draft.
 
> [Frank]: the version of the DOTS client's all traffic

I still need a little help understanding.  This field tells the DOTS server that the DOTS client traffic will be IPv6 or v4?  If so, which traffic?  What happens if there is v4 and v6 traffic?  The one noted in the protected_zone, on the white/blacklist?  What happens if ip_version = "v4" and a ipv6_address is set in protected_zone.

[snip]

> (9) Section 5.1.1, protected_ports, To clarify, is this the subset of ports
> possible to enumerate in future mitigation requests?
> [Frank]: Yes, I think so. I tend to think there should be some restriction here,
> which means dots server only protect those ports that have been registered.

I'd recommend explicitly documenting this relationship between protected_ports and future mitigation requests.

> (10) Section 5.1.1, whitelist and blacklist, I would recommend being explicit
> on what the DOTS server is supposed to do with this list.
> [Frank]: In registration response message, it can indicate whether DOTS
> server can support it. Do you mean more information than this?

Based on the definition in the text of whitelist, it appeared that the client could send a characterization of particular traffic.  I was recommending that the text be explicit is saying something like (not precise language) -- "The DOTS server should ensure that traffic described in the 'whitelist' field set during registration time is not impacted in future mitigation requests by the DOTS client."  Some equivalent for blacklist. 

> [Frank]: It's periodically sent to the peer DOTS agents right after the DOTS
> registration process is finished, and till the DOTS client cancels its registration
> to the DOTS server.

Understood.  I didn't see that in the text.  How often is periodically?

> (14) Section 5.2.1, DST_IP is used in the definition of multiple fields but is not
> defined.  Is this field the same as dst_ip from packet_header?

I recommend using a consistent case.

> [Frank]: good question. The reason we use multiple CSV is to send a set of
> attack information in one DOTS mitigation request message, for increasing
> the efficiency.

Would there be timestamps with these rates?  Assuming this was a legal syntax, "3.5, 58.3, 48.3", how would that be interpreted?

[snip]

> (20) Section 5.2.1, hash, Is this hash calculated on the complete payload or
> the truncated value per the offset field?

I recommend explicitly stating the target of the hash as you clarified here.

Roman

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 21 Jul 2016 05:55:22 +0000

Hi Roman,
Points and questions are all taken, and we will address them in next version.
Thanks a lot!

B.R.
Frank

-----邮件原件-----
发件人: Roman D. Danyliw [mailto:[email-masked]] 
发送时间: 2016年7月21日 1:18
收件人: Xialiang (Frank)
抄送: [email-masked]
主题: RE: [Dots] Feedback on draft-nishizuka-dots-inter-domain-mechanism-01

Hi Frank!

[snip]

> (4) Section 5, Provisioning stage, "A DOTS client should register 
> itself to the DOTS server, as well as enable capacity building in 
> advance." In the context of DOTS, what protocol support is expected to 
> "enable capacity building in advance"?
> [Frank]: In section 5.1.2, we have the details: "The customers (DOTS 
> client) registers to the operator controller with the configuration 
> and capability building including protection methods, process 
> capacity, protected zone, security profile, white/black-list, etc". Does it make sense?

> [Frank]: it's generated by DOTS client itself, but the custom_id is 
> the unique value generated by the DOTS server

[snip]

> (9) Section 5.1.1, protected_ports, To clarify, is this the subset of 
> ports possible to enumerate in future mitigation requests?
> [Frank]: Yes, I think so. I tend to think there should be some 
> restriction here, which means dots server only protect those ports that have been registered.

> (10) Section 5.1.1, whitelist and blacklist, I would recommend being 
> explicit on what the DOTS server is supposed to do with this list.
> [Frank]: In registration response message, it can indicate whether 
> DOTS server can support it. Do you mean more information than this?

> [Frank]: It's periodically sent to the peer DOTS agents right after 
> the DOTS registration process is finished, and till the DOTS client 
> cancels its registration to the DOTS server.

> (14) Section 5.2.1, DST_IP is used in the definition of multiple 
> fields but is not defined.  Is this field the same as dst_ip from packet_header?

> (17) Section 5.2.1, current_throughputs, What does it mean to have 
> multiple CSV separated values in this field?
> [Frank]: good question. The reason we use multiple CSV is to send a 
> set of attack information in one DOTS mitigation request message, for 
> increasing the efficiency.

[snip]

> (20) Section 5.2.1, hash, Is this hash calculated on the complete 
> payload or the truncated value per the offset field?

Roman