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

"Panwei (William)" <william.panwei@huawei.com> Thu, 27 June 2019 07:49 UTC

Return-Path: <william.panwei@huawei.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2E1201E9 for <dots@ietfa.amsl.com>; Thu, 27 Jun 2019 00:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, PRICES_ARE_AFFORDABLE=0.551, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABJwKLZGRfgr for <dots@ietfa.amsl.com>; Thu, 27 Jun 2019 00:49:17 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34581201CB for <dots@ietf.org>; Thu, 27 Jun 2019 00:49:16 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DCA25729F778B237E28E for <dots@ietf.org>; Thu, 27 Jun 2019 08:49:14 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 08:49:14 +0100
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 27 Jun 2019 08:49:13 +0100
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 27 Jun 2019 08:49:13 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.66]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Thu, 27 Jun 2019 15:49:07 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
CC: dots <dots@ietf.org>
Thread-Topic: Some comments on draft-ietf-dots-signal-call-home-02
Thread-Index: AdUr91M58CI2IhUhRwChDCyonAL/hQABLXWwACLkISA=
Date: Thu, 27 Jun 2019 07:49:06 +0000
Message-ID: <30E95A901DB42F44BA42D69DB20DFA6A69FA69EC@nkgeml513-mbx.china.huawei.com>
References: <30E95A901DB42F44BA42D69DB20DFA6A69FA5E84@nkgeml513-mbx.china.huawei.com> <787AE7BB302AE849A7480A190F8B93302EAADB9E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAADB9E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.37.117]
Content-Type: multipart/alternative; boundary="_000_30E95A901DB42F44BA42D69DB20DFA6A69FA69ECnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/YZXqBPLjIImdxRgqDpDjORE-YS8>
Subject: Re: [Dots] Some comments on draft-ietf-dots-signal-call-home-02
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 07:49:22 -0000

Hi Med,

Thank you for your reply. For the sake of convenience, I move the discussion to the front.

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.
[Wei] The base spec defines that Port 4646 is used for ordinary Signal Channel, if this port is also configured as Signal Channel Call Home Port Number, can the two signal channels be established simultaneously by both using Port 4646? Will these two signal channel work perfectly without mutual interference? If one port is enough for using, I don’t think another port need to be assigned? If different ports are needed, then the draft should explain the reason and add some normative requirements.

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.
[Wei] In call home scenario, can the DOTS server (home gateway) establish a Data Channel with the DOTS client (ISP or DMS) ?
If can, 1) What’s the Call Home Data Channel used for? 2) How does it work? Is there any difference between Call Home Data Channel and ordinary Data Channel? 3) When home gateway acts both as DOTS server and DOTS client, there are two data channels with different directions, how to distinguish these two data channels? Will these two date channels work perfectly without any modification to data-channel-specification?
If can’t, Why? And How to prevent it?

In conclusion, my point of the above two comments is about the compatibility between the call home scenario and basic DOTS Signal/Data Channel. I don’t know whether you have considered the compatibility already. If not, these my preliminary thoughts may offer some help for considering about compatibility. I suggest a section can be added to clarify the compatibility. If you allow I’m willing to contribute more.

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?
[Wei] It works for me.

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.
[Wei] OK, I’ll check the base spec for details. Maybe you can also add some references or guidance to the base spec in the call home draft.


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

From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, June 26, 2019 5:50 PM
To: Panwei (William) <william.panwei@huawei.com>;; dots <dots@ietf.org>;
Subject: RE: Some comments on draft-ietf-dots-signal-call-home-02

Hi Pan,

Thank you for the comments.
Please see inline.

Cheers,
Med

De : Dots [mailto:dots-bounces@ietf.org] 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.