[Dots] Intdir telechat review of draft-ietf-dots-multihoming-12

Dave Thaler via Datatracker <noreply@ietf.org> Tue, 26 April 2022 23:27 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 822A5C1D1C61; Tue, 26 Apr 2022 16:27:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dave Thaler via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: dots@ietf.org, draft-ietf-dots-multihoming.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165101562152.2352.18090967987785867319@ietfa.amsl.com>
Reply-To: Dave Thaler <dthaler@microsoft.com>
Date: Tue, 26 Apr 2022 16:27:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/32kLbdGlfmASd1G1JeI7mb5mv04>
Subject: [Dots] Intdir telechat review of draft-ietf-dots-multihoming-12
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.34
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2022 23:27:01 -0000

Reviewer: Dave Thaler
Review result: Ready with Issues

I am an assigned INT directorate reviewer for
draft-ietf-dots-multihoming-12. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/

Technical comments potentially worth a discuss:
* Section 4.2: multiple PVDs is not synonymous with distinct administrative entities,
  as evidenced by section 4.1, so would recommend:
OLD: That router is connected to multiple provisioning domains (i.e., 
OLD: managed by distinct administrative entities).
NEW: That router is connected to multiple provisioning domains 
NEW: managed by distinct administrative entities.

* Section 5.2:
> when PI addresses/prefixes are assigned and absent any
> policy, the client-domain DOTS gateway MUST send mitigation requests
> to all its DOTS servers.  Otherwise, the attack traffic may still be
> delivered via the ISP which hasn't received the mitigation request.

If RPF checks are applied by policy to all inbound traffic, then I think
the attack could only come via a PVD that advertises to the client domain
prefixes covering the attack sources. In that case the MUST might be too
strong if no attack is coming from one of the PVDs (e.g., an IPv6-only
PVD).  Do we really want to require sending it to such networks?

Section 5.2:
> The use of anycast
> addresses to reach these DOTS servers is NOT RECOMMENDED.  If a well-
> known anycast address is used to reach multiple DOTS servers, the CPE
> may not be able to select the appropriate provisioning domain to
> which the mitigation request should be forwarded.  As a consequence,
> the request may not be forwarded to the appropriate DOTS server.

If each PVD uses a different anycast address for their own DOTS servers,
is there still a problem? If so, can the document explain what is the
problem?  The current text only seems to explain the case when the same
anycast address is used by different PVDs but the statement above about
NOT RECOMMENDED is not currently constrained to that case.

* Section 5.3:
> Note that anycast addresses cannot be
> used to establish DOTS sessions between DOTS clients and client-
> domain DOTS gateways because only one DOTS gateway will receive the
> mitigation request.

I wonder if this is too strongly worded.  I suspect you mean that G1 and G2
cannot use the same anycast address.  But if G1 and G1' both use the same
anycast address for redundancy in that topological location, is there a
problem? In contrast, I observe that the last paragraph of this section
says only "NOT RECOMMENDED", not "MUST NOT".

Editorial nits:
* Section 3: in the two definitions, either remove "are" after the colon
  or remove the colon so they're either sentences or definitions, not a weird mix.
* Section 3: re "Provider-Independent (PI) addresses:  are globally-unique addresses
  which are not assigned by a transit provider".  Change "which" to "that"
  per Chicago Manual of Style ("which" and "that" have the same meaning in
  British English but slightly different meanings in American English)
* Section 5.1: "DOTS signaling session to a given DOTS server must be established
  using the interface from which the DOTS server was provisioned."  Grammar:
  insert "A" at the start of the sentence
* Section 5.2: typo "One of more DOTS clients", s/of/or/
* Section 5.2: s/an unicast/a unicast/
* Section 5.2: "the attack traffic may still be delivered via the ISP which
  hasn't received the mitigation request", s/which/that/

Dave Thaler