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

[<[e-mail]>]

Hi Pan,

Thank you for the comments.
Please see inline.

Cheers,
Med

De : Dots [mailto:[e-mail]] De la part de Panwei (William)
Envoyé : mercredi 26 juin 2019 10:25
À : dots
Objet : [Dots] Some comments on draft-ietf-dots-signal-call-home-02

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/.

[Med] Fixed. Thanks

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.

[Med] OK to moved address sharing 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.

[Med] Those are examples of valid ranges. OK to add a mention that any subrange of 0-65535 is a valid range.

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.
[Med] Thank you for catching this. Fixed.

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.

[Med] It is up to the client/server to agree on the alternate port. IMO, we don’t need to elaborate on these deployment considerations.

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.

[Med] It is an optional attribute with regards to the base signal spec, but it is mandatory when used 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)

[Med] Yes, this is why these attributes are said to be 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)

[Med] The source-prefix is mandatory when used in call home.

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?

[Med] The home gateway will need to maintain two signal sessions as a function of its DOTS agent role.

5.4. How to identify the ‘Call Home scenario’ ? By the signal channel port number?
[Med] Yes, but also in the reversal of (D)TLS roles.

5.5. I prefer to make all the above things explicit and clear in the draft.
[Med] Will double check the text.

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?

[Med] No, that is on purpose. The data channel may fail when an attack is ongoing.

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.

[Med] Good catch.

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”?)
[Med] Agree. Fixed.

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.
[Med] OK.

10. In Section 4.3, the registry name should be “DOTS Signal Channel Conflict Cause Codes” (this name is from the signal channel draft).
[Med] Fixed.

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.
[Med] Do you have a preference? What about request-rejected-legitimate-traffic?

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.
[Med] Will double check the language.

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?
[Med] Following similar means for a dots server to do that validation in the base spec.

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.