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

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

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

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.

Comment 2: The draft should specific the way that the DOTS server learns its own scope of domain.
Comment 3: The draft should extend the protocol to convey the scope of the DOTS server's domain to the DOTS client.
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.
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. If the configuration way is a better choice, the YANG module may be worth to be defined.
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.

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

Best Regards
Wei Pan