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

["Xialiang (Frank)" <[e-mail]>]

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

B.R.
Frank

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

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
[Frank]: good point, that's what we are considering now. They should be in use cases or architecture drafts.

(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?
[Frank]: ok, we will.

(3) Section 5, I recommend citing the references to HTTPS and TLS
[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.

(8) Section 5.1.1., SIP_URI and E164_number, I would recommend citing the reference.
[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.

(13) I recommend adding the version field used in the messages in 5.2.1 to the provisioning messages in 5.1.1.
[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
[e-mail]
https://www.ietf.org/mailman/listinfo/dots