Skip to main content

Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)
draft-ietf-dots-multihoming-13

Discuss


Yes

Roman Danyliw

No Objection

Alvaro Retana

No Record

Andrew Alston
Francesca Palombini
John Scudder
Murray Kucherawy
Warren Kumari

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

Erik Kline Discuss

Discuss (2022-04-20 for -11)
## Discuss

### S5.1

* RFC 6724 source address selection is not sufficient.  Many complexities
  are captured in RFC 8678.  As RFC 8475 notes, what's really required to
  make this work for some nodes is proper next-hop selection in conjunction
  with source address selection.  Either that, or some kind of source-aware
  routing for forwarding nodes.

  For originating packets, depending on the topology, the following options
  can in theory be made to work:

    * implementing RFC 6724 rule 5.5, but it's not currently mandatory

    * implementing RFC 6724 section 4 recommendation "that the candidate
      source addresses be the set of unicast addresses assigned to the
      interface that will be used to send to the destination (the "outgoing"
      interface)" -- but this is highly dependent upon interface config

    * use of PVD Options (RFC 8801) throughout the interior (and, ideally, an
      IETF-defined PVD End System model)

  I'm don't think that it's worth going into all this detail in this document,
  necessarily.  You might see if a mix of references to and/or quotations from
  8678, 8475, and/or mention of the issue of next-hop selection in conjunction
  with source address selection yields sufficiently concise text to warn the
  IPv6-multihoming-unfamiliar reader: "here be dragons (hic sunt dracones)".
Comment (2022-04-20 for -11)
## Comments

### S1

* I feel like there's probably a more accurate term than "forking".
  "Replicating"?  "Repeating"?

Paul Wouters (was Discuss) Yes

Comment (2022-04-21 for -12)
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

Alvaro Retana No Objection

Lars Eggert No Objection

Comment (2022-04-20 for -11)
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)
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)
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)
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)
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.

Andrew Alston No Record

Francesca Palombini No Record

John Scudder No Record

Murray Kucherawy No Record

Warren Kumari No Record