[Dots] Paul Wouters' Discuss on draft-ietf-dots-multihoming-11: (with DISCUSS and COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-dots-multihoming-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-multihoming/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for a clear document and thanks to Kathleen for the SecDir review. I
have one minor DISCUSS item that can probably be resolved easily by adding a
sentence or two.

[1]
   The DOTS client SHOULD use the certificate
   provided by a provisioning domain to authenticate itself to the DOTS
   server(s) provided by the same provisioning domain.

This sentence suggests there is either another authentication method, or it
allows for unauthenticated DOTS clients. If the latter, than I would expect a
significant Security Considerations section on how to avoid/reduce malicious
clients impact of such a setup. eg I could envision a compromised device from
falsely reporting a DDOS attack from a certain network to block the compromised
device/network from receiving traffic from certain remote networks.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some links seem broken in the rendering of the htmlized version in the
datatracker, for example "[RFC8174]" in Section 2.

It talks about DOTS clients, DOTS servers, and then suddenly DOTS agents. Are
those clients or servers or something else? "agents" are not mentioned in the
Introduction or Terminology sections. (Unfortunately, looking at RFC 8811 did
not help me as it has the exact same problem of only defining DOTS clients and
DOTS servers and then mentioning DOTS agents.

Similarly, the term "DOTS Gateway" appears without explanation. Is this a proxy
like DOTS server for clients and a DOTS client to the real DOTS server?

I'm a bit confused about the applicability of the enduser CPE case. Wouldn't a
lot of deployments have the CPE in bridging mode so that the customers own
favourite device gets the actual IP address on it instead of being behind the
CPE with NAT? Is there a deployment scenario possible for that?

I would move Figure 5 up to the start of the section. I now had to scroll down
a lot and then back up again, and then when done reading had to skip the figure
5.

   If PI addresses/prefixes are in use, the DOTS client MUST send a
   mitigation request to all the DOTS servers.  The use of anycast
   addresses to reach these DOTS servers is NOT RECOMMENDED.

Why is the recommendation about anycast addresses limited to PI space? Couldn't
there by multicast addresses in both PA and PI space?

   a prefix filter that will be against DDoS detection alarms

I don't quite parse/understand "will be against" ?