Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home
draft-ietf-dots-signal-call-home-14

Thank you to Radia Perlman for the SECDIR review.

Thank you for addressing my DISCUSS and COMMENTs.

Thank you for the work put into this document. Congratulations for the many nice ASCII artworks ;-) Using the SVG alternate artwork could have even been nicer ;-)

Please find below  some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I will let the transport AD to decide on the IANA point.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Abstract --
I wonder whether the 2nd paragraph is really useful.

-- Section 1.1 --
Should the DOTS acronym be expanded before first use ?

Please add a reference to "Slowloris"

Did the authors/WG consider mentioning MUD in this lengthy discussion about IoT @ Home ?

-- Section 5.2.1 --
"When an outgoing attack that saturates the outgoing link", but, what about an "incoming attack" ?

-- Section 5.2.2 --
Thank you for using an IPv6-only example !

-- Section 5.3.1 --
Can source-prefix be a link-local address (normally not forwarded by a router but what if the CPE is a layer-2 node) ?

In figure 9, while "2001:db8:123::/128" is a valid node address but it looks like a prefix, may I suggest to use "2001:db8:123::1/128" that better suggest a host address ?

-- Section 5.3.2 --
Congratulations to the authors for describing the NAT64/MAP behaviors.

-- Section 8 --
"The DOTS Call Home can be misused " should probably include "server".

-- Section 9 --
How is the privacy among DOTS servers enforced ? E.g., how can the DOTS client only send mitigation information about subscriber A prefix(es) and not subscriber B prefix(es)? There could obviously be a link to RADIUS and DHCP servers but I did not read anything about this. Or is 'common sense' / implicit ?

== NITS ==

s/Figure 10 depictes/Figure 10 depicts/

I support Roman's DISCUSS.

Thanks for an easy-to-read document.  I understand Roman’s points, but conclude that while a primary use case is for home networks, it’s expected that the server for this will be a router that’s managed by the home user’s ISP, not by the average home user.  That setup is increasingly common, at least in the U.S., and it’s enabled many such functions that were not practical when users had to provide and manage their own routers.

I just have a few very minor comments:

— Section 1.1 —

   Such misbehaviors will have both a collateral
   damage that affects end users, and can harm the reputation of an
   Internet Service Provider (ISP) for being a source of attack traffic.

Nit: This sentence isn’t properly formed, as the two pieces of the “both” construction aren’t parallel.  I suggest this:

NEW
   Such misbehaviors can cause collateral damage
   that will affect end users, and can also harm the reputation of an
   Internet Service Provider (ISP) for being a source of attack traffic.
END

— Section 5.1 —

   enabling means for automating the
   provisioning of credentials on Call Home DOTS servers to authenticate
   to the Call Home DOTS client are encouraged.

Nit: the subject of this is the singular “enabling”, so “enabling <stuff> is encouraged,” not “are”.

— Section 7 —
Throughout the IANA Considerations, please make the contact points and change controller be “IETF” (not IESG nor IETF Chair), and use the email address <iesg@ietf.org>.  That’s what the IESG considers the best way to refer to items where the IETF has change control.

(5.3.1) Please clarify if the entire source-prefix needs to fall within the responsibility of the DOTS server.

e.g. If the client needs all of 1.2.3.0/24 to be squelched, and this prefix is split between two domains, can the client send the same request to both servers, or can it simply replicate the same message to both and expect them to administer the relevant portions?

Hi,

Thanks for this document.

I support both Roman's DISCUSS and Barry's comment, in the sense that the document could probably benefit from some more guidance about how it is expected to be deployed.  Perhaps the Applicability Scope should constrain where it is expected for this protocol to be deployed (e.g. only in an ISP managed device).  It might also be beneficial to understand when DOTS Signal Call Home should be deployed instead of the Base DOTS Signal Channel.

One other comment:  I found the introduction text to section 1.1 to be informative, but it seemed to be a bit of a jump to section 1.2 when it immediately starts describing call-home as the solution.  I.e. section 1.1 makes it clear as to why running DDOS mitigation in the source network is beneficial, but doesn't necessarily lead (at least to me) to the reason why that means adding a reverse control channel to DOTS is the solution.

Regards,
Rob

Balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem." sense of the term.