[Dots] Some comments on draft-ietf-dots-signal-call-home-02

["Panwei (William)" <[e-mail]>]

Hi authors,

I’ve read the latest version draft, and I have the following comments:

Some nits:
1. In Section 1.1, the second paragraph, s/at affordable price/at affordable prices/.
2. In Section 1.1, the second last paragraph, s/a IPv6 home network/an IPv6 home network/.
3. In Section 2, the reference I-D.ietf-dots-requirements should be changed to RFC8612.
4. In Section 3.3.1, Figure 4 and Figure 5, s/NAT Embeded in a CPE/NAT Embedded in a CPE/.
5. In section 5, the third paragraph, s/inspect all the traffic from the compromised to the target/inspect all the traffic from the compromised device to the target/.

Comments:
1. The Section 3.3.1 contains three things: the new parameters of the mitigation request, the considerations of NAT deployment, the extension of conflict-clause. These 3 things make this section too long. For a better structure and readability, my suggestion is to split this section into 3 sections, or at least to put the NAT considerations into a separate section.
2. In Section 3.3.1, when describing the source-port-range, it says:
For TCP, UDP, Stream Control Transmission Protocol (SCTP)
[RFC4960], or Datagram Congestion Control Protocol (DCCP)
[RFC4340], a range of ports can be, for example, 0-1023,
1024-65535, or 1024-49151.
My understanding of these 3 examples is that they want to show the readers the ports can range from 0 to 65535. It’s better to say this explicitly before listing the examples.
3. In Section 3.3.1, it uses ‘source-icmp-type’ when explaining this new parameter, while other places using ‘source-icmp-type-range’. I think ‘source-icmp-type-range’ should be used here too.
4. In Section 4.1, it requests the IANA to assign a separate port number to the DOTS Signal Channel Call Home Protocol. In Section 3.3.1, it says Signal Channel Call Home can use not only this assigned port number but also some other port numbers configured by the administrator. So can the Signal Channel Port Number (4646) be configured as the Signal Channel Call Home Port Number? The draft should add some normative requirements about this.
5. In Section 3.3.1, it says ‘source-prefix’ is an optional attribute, and it also says:
The ’source-prefix’ parameter is a mandatory attribute when the
attack traffic information is signaled by a DOTS client in the Call
Home scenario.
5.1. Can the ordinary signal channel use the call home extension? For example, if the signal channel is established by using the Signal Channel Port Number (4646), can the mitigation request contain the source-prefix, source-port-range and source-icmp-type-range? (I guess YES, so for ordinary signal channel these parameters are optional)
5.2. Can the call home signal channel not use the call home extension? For example, if the signal channel is established by using the Signal Channel Call Home Port Number (4647), can the mitigation request not contain the source-prefix? (I guess NO, so for call home signal channel the ’source-prefix‘ is mandatory)
5.3. Even if the ordinary signal channel can use the call home extension, a separate call home signal channel can also be helpful for the case that home gateway acts as both DOTS client and DOTS server simultaneously. Any other reasons to invent the separate call home signal channel?
5.4. How to identify the ‘Call Home scenario’ ? By the signal channel port number?
5.5. I prefer to make all the above things explicit and clear in the draft.
6. For this call home scenario, the draft doesn’t contain anything about data channel, is the data channel omitted by mistake? Does the data channel need to extend in the call home scenario? For the case that the home gateway acts as both DOTS client and DOTS server simultaneously, will it need two data channels just like it needs the two signal channels?
7. In Section 4.2, it says:
This specification registers the ’source-prefix’ and ’source-port-
range’ parameters in the IANA "DOTS Signal Channel CBOR Mappings"
registry established by [I-D.ietf-dots-signal-channel].
Here mentions ‘source-prefix’ and ‘source-port-range’, but the ‘source-icmp-type-range’ is missing.
8. In Section 4.2, the IANA registry “DOTS Signal Channel CBOR Mappings” can’t be find in the signal channel draft by searching the quoted name directly. (Should be “DOTS Signal Channel CBOR Key Values”?)
9. In Section 4.2, the table is better to be given a number and name. In terms of format, this table matches Table 4 of the signal channel draft, and doesn't match any of the IANA registries of the signal channel draft.
10. In Section 4.3, the registry name should be “DOTS Signal Channel Conflict Cause Codes” (this name is from the signal channel draft).
11. In Section 4.3, is the name “request-rejected” good enough? Because comparing to the names of other conflict causes, it seems this name can’t represent this specific conflict case, DOTS server can ‘reject the request’ in all the conflict cases.
12. In NAT considerations of Section 3.3.1, for the case that the NAT translator deployed in the source network, the DOTS client should send the external IP address of the attacker and the DOTS server should find the correspondent internal IP address. Comparing to the CGN case, I suggest that some normative words can also be used here.
13. In Section 3.1.1, it says “the DOTS client MUST validate that attacker prefixes are within the scope of the DOTS server domain”. But how should the DOTS client know the scope of each DOTS server domain? In the call home scenario, there might be tens of thousands of DOTS servers, are there some easy methods to let the DOTS client know the scope of each DOTS server domain? In addition, I think this is critical for deploying DOTS call home, and we need to address this in the draft.

Regards & Thanks!
潘伟 Wei Pan
华为技术有限公司 Huawei Technologies Co., Ltd.