Skip to main content

Multihoming Deployment Considerations for DDoS Open Threat Signaling (DOTS)
draft-ietf-dots-multihoming-13

Note: This ballot was opened for revision 11 and is now closed.

Paul Wouters
(was Discuss) Yes
Comment (2022-04-21 for -12) Sent
DISCUSS item and comments resolved

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


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" ?
Roman Danyliw
Yes
Erik Kline
(was Discuss) No Objection
Comment (2022-05-22) Sent
Understood that the multihoming is talking about the edge router itself and not hosts within the next.

Agreed this is simpler and not necessary to complicate the document.

Thanks.
Lars Eggert
No Objection
Comment (2022-04-20 for -11) Sent
Section 4, paragraph 1, comment:
> 4.  Multi-Homing Scenarios

I'm surprised to not see this section referring to any of the MULTI6 documents.
It's been a while since I read them, but IIRC, they dealt with many of these
scenarios and gave similar recommendations.

The datatracker state does not indicate whether the consensus boilerplate
should be included in this document.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "blindly"; alternatives might be "visually impaired", "unmindful of",
   "unconcerned about", "negligent of", "unaware", "uncomprehending",
   "unaware", "uncritical", "unthinking", "hasty", "blocked", "opaque"
Martin Duke
No Objection
Comment (2022-04-14 for -11) Sent
Thanks to Mirja Kuhlewind for the TSVART review.

There is nothing at all wrong with this document, but it is not what I expected. IIUC DOTS will often have different interfaces for its DOTS channel and the "data plane" where DoS attacks come in. I had thought the multihoming reference would refer to that, but it does not.
Robert Wilton
No Objection
Comment (2022-04-20 for -11) Sent
Hi,

Thanks for this document.

Two comments on section 5.1:

1.
   The DOTS client MUST resolve the DOTS server's name provided by each
   provisioning domain using either the DNS servers learned from the
   respective provisioning domain or from the DNS servers associated
   with the interface(s) for which a DOTS server was explicitly
   configured (Section 4).

It wasn't clear to me why the DNS lookup MUST be done relative to each provisioning domain?

2.
   DOTS signaling
   session to a given DOTS server must be established using the
   interface from which the DOTS server was provisioned.

If I have read and understood the draft correctly that it also seems that requests to ask a DOTS server to mitigate an attack must also be done on the same interface on which that attack is occurring.  Is my understanding correct, and if so, why is this a requirement?  I.e., communicating to a DOTS server via a separate link that isn't under attack would seem to be beneficial (when that is possible).  Is the reasoning here that these are stub networks and hence will only be routable via the interface provided by the ISP's gateway?

Regards,
Rob
Zaheduzzaman Sarker
No Objection
Comment (2022-04-20 for -11) Not sent
Thanks for working on this specification. Thanks to Mirja Kuhlewind for the TSVART review.

I agree with the my fellow TSV AD and TSVART reviewer that no TSV related issue is found in this specification.
Éric Vyncke
No Objection
Comment (2022-04-20 for -11) Sent
Thank you for the work put into this document: it is short, easy to read.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Valery Smyslov for the shepherd's write-up including the WG consensus (including "not too many reviews") *BUT* it lacks the justification of the intended status. 

Authors may also expect an internet directorate review by Dave Thaler, the delay in the review (caused by late addition of this document to the telechat agenda) should not hinder the publication process though.

I also second Erik Kline's DISCUSS about source address selection.

I hope that this helps to improve the document,

Regards,

-éric

Note for the shepherding AD: missing consensus boilerplate.

## Section 4.2

Suggest to state the obvious in bullet 2, i.e., that addresses from one PvD is used when communicating over this PvD (to be symmetric with bullet 1). This is purely cosmetic.

## Section 4.3

Another cosmetic suggestion: please use CPE1 and CPE2, again for symmetry.

## Section 5.1

I am always uneasy when I read normative MUST / SHOULD in an informational document but the authors may ignore this comment.

There is a "SHOULD use the certificate" without specifying when the SHOULD does not apply. 

## Section 5.2

Another cosmetic comment, the graphical convention of figures 7 & 8 (i.e., having the DOTS clients in a central dotted box) should also be used in figure 6.
Alvaro Retana Former IESG member
No Objection
No Objection (for -11) Not sent