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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

The purpose of the gateway is to act as proxy or back to back user agent, see https://tools.ietf.org/html/draft-ietf-dots-architecture-14#section-2.2.3. Further, gateway may or may not be present between the DOTS client and server. The proposed mechanism in the draft does not require additional parameter and 1-RTT overhead to switch roles. We are using the technique similar to the one used in NETCONF/RESTCONF call home https://tools.ietf.org/html/rfc8071 .

Cheers,
-Tiru

From: Dots <[e-mail]> On Behalf Of Meiling Chen
Sent: Wednesday, July 3, 2019 6:56 AM
To: mohamed.boucadair <[e-mail]>; Panwei (William) <[e-mail]>
Cc: dots <[e-mail]>
Subject: Re: [Dots] Some comments on draft-ietf-dots-signal-call-home-02


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi med,

  *   if signal call home just exchange the role of client and server, why not just use gateway? gateway can play both client and server roles.
  *   signal call home parameters: source-prefix、source-port-range、source-icmp-type; source-prefix and source-port-range have no difference with target-prefix and target-port-range in form,
  *     If you want to make a clear distinction, why not just add a parameter in signal channel to indicate the general signal channel or call home signal channel?

From: [e-mail]<mailto:[e-mail]>
Date: 2019-07-02 19:24
To: MeiLing Chen<mailto:[e-mail]>; Panwei (William)<mailto:[e-mail]>
CC: dots<mailto:[e-mail]>
Subject: RE: Re: [Dots] Some comments on draft-ietf-dots-signal-call-home-02
Hi Meiling,

A scenario where both base and call home signal channels may co-exist is as follows:


•         A CPE embeds a dots client used to seek for help whenever incoming attacks are detected (base dots signal/data channels)

•         The same CPE embeds a DOTS server to interact with a DOTS client hosted by its network provider (signal call home): the network provide uses this channel to place mitigation requests for outbound attacks that are originating from the CPE’s network.



There is no call home extension defined for the data channel. If some ACLs needs to be communicated, for example, to the CPE, an option would be to use RFC8071 (RESTCONF/NETCONF Call Home)..



Cheers,

Med

De : MeiLing Chen [mailto:[e-mail]]
Envoyé : mardi 2 juillet 2019 08:46
À : Panwei (William); BOUCADAIR Mohamed TGI/OLN
Cc : dots
Objet : Re: Re: [Dots] Some comments on draft-ietf-dots-signal-call-home-02

Hi Med,
general signal channel and call home function can both exist in the same scene?
And I am also not so clear about how data channel used in call home scenerio?

From: Panwei (William)<mailto:[e-mail]>
Date: 2019-06-27 15:49
To: [e-mail]<mailto:[e-mail]>
CC: dots<mailto:[e-mail]>
Subject: Re: [Dots] Some comments on draft-ietf-dots-signal-call-home-02
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Wednesday, June 26, 2019 5:50 PM
To: Panwei (William) <[e-mail]<mailto:[e-mail]>>; dots <[e-mail]<mailto:[e-mail]>>
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:[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.