Re: [Dots] Some comments on draft-reddy-dots-home-network

[<[e-mail]>]

Hi Wei,

Thank you for the review.

Please see inline.

Cheers,
Med

De : Dots [mailto:[e-mail]] De la part de Panwei (William)
Envoyé : samedi 27 octobre 2018 05:43
À : [e-mail]
Cc : Xialiang (Frank, Network Integration Technology Research Dept)
Objet : [Dots] Some comments on draft-reddy-dots-home-network

Hi authors of draft-reddy-dots-home-network,

I've gone through the DOTS Signal Channel Call Home draft. In my opinion, the scenario described in this draft is important and the solution is very useful.
[Med] Thank you.

In this draft, you described the problem which IoT devices in home network faced and the corresponding solution. These IoT devices may be easily compromised to become the DDoS attackers. For this situation, the most effective ways to mitigate the attack are blocking the traffic from these IoT devices to the attack targets and quarantining the devices. We can also consider the ways as attack mitigation near the source.
[Med] Agree. IoT is only cited as a sample example.

For this draft I also have some comments as follows.

Comment 1: The draft can extend the scenario.
I think other scenarios may have the similar problems and the solution can be similar too. For example, the devices in the DC scenario may not only be the victims of DDoS attacks, but also can be compromised and used for launching DDoS attacks in some cases. If the latter situation happens, the solution described in the draft will be helpful too.

[Med] The solution is applicable each time an attack is issued from sources located in a domain hosting a DOTS server. So, it can be used to notify attacks from within a network. This network can be a home network, an enterprise network, a DC network, etc.

Comment 2: The draft should specific the way that the DOTS server learns its own scope of domain.
[Med] This is straightforward for the CPE case: IP addresses/prefixes managed by that CPE. This can be fed automatically (DHCP leases, prefix delegation) or be explicitly configured by an administrator. We may add a discussion about this in the draft.

Comment 3: The draft should extend the protocol to convey the scope of the DOTS server's domain to the DOTS client.
[Med] The scope of the DOTS server is supposed to be known because this is part of the "classic" DOTS operation. The signal channel I-D says the following:

   DOTS servers MUST verify that requesting DOTS clients are entitled to
   trigger actions on a given IP prefix.  That is, only actions on IP
   resources that belong to the DOTS client' domain MUST be authorized
   by a DOTS server.  The exact mechanism for the DOTS servers to
   validate that the target prefixes are within the scope of the DOTS
   client's domain is deployment-specific.

In the section 3.2.1, it says "the DOTS client MUST validate that attacker prefixes are within the scope of the DOTS server's domain". To achieve this goal, I think the two issues list above should be solved first.

[Med] Agree. This is covered in the base spec.

The scope of the DOTS server's domain may be configured by the administrator directly, or it can be learned by the DOTS server automatically if possible.
[Med] Agree.

If the configuration way is a better choice, the YANG module may be worth to be defined.

[Med] Can you please elaborate on this?

Without conveying the scopes of each DOTS server to the DOTS client, the DOTS client will not be able to find the exact DOTS server to send the mitigation request.
[Med] Please refer to the base DOTS signal channel specification.

Comment 4: The draft should consider more for Network Address Translation.
Due to the exhaustion of IP addresses, the NAT function has been used more and more widely, so the home network is very likely to be behind NAT equipment.
[Med] There are various flavors there: one single NAT at the CPE, no NAT at the CPE but a NAT in the network (DS-Lite), A+P (port-restricted NAT on the CPE), double NAT (NAT in the CPE and another NAT in the network), etc. We would like to avoid to dig into deployment-specific considerations, but identify key hurdles for NAT (and firewall) traversal.

With this background, I think we should consider more about the problems brought by NAT functions and the methods how we solve these problems, otherwise the whole solution will be very restricted in use.
[Med] We are happy to elaborate on this. Suggestions are more than welcome.

One problem has been described in section 3.2.1 where it says "When a translator is on-path, the DOTS server uses the attack traffic information to find the internal source IP address of the compromised device".
But before the DOTS server receives the mitigation request from the DOTS client, the DOTS client must know the DOTS server's external scope, otherwise the DOTS client can't find the correct DOTS server to send the mitigation request.
[Med] Yes, this is known as a side effect of the text quoted from the signal channel draft.

So the DOTS server should know its own external scope first, then convey the external scope to the DOTS client, and at last find the internal source IP address when receive a mitigation request.

Comment 5: The Attack Name/Type or ID is optional to be conveyed.
>From my point of view, the detailed information of the attack, like attack type, may be mainly helpful for diagnostic purpose. Its help for mitigating the attack is limited.
[Med] OK, thanks.

Best Regards
Wei Pan