[Dots] Tsvart last call review of draft-ietf-dots-data-channel-27

Brian Trammell via Datatracker <noreply@ietf.org> Sat, 16 March 2019 10: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 2F52C129A87; Sat, 16 Mar 2019 03:27:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Brian Trammell via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
Cc: draft-ietf-dots-data-channel.all@ietf.org, ietf@ietf.org, dots@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Brian Trammell <ietf@trammell.ch>
Message-ID: <155273205205.32728.8738595851481147876@ietfa.amsl.com>
Date: Sat, 16 Mar 2019 03:27:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Z16r6X0j5AYZ3B3oRfD_ENacYG4>
Subject: [Dots] Tsvart last call review of draft-ietf-dots-data-channel-27
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 16 Mar 2019 10:27:32 -0000

Reviewer: Brian Trammell
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

Apologies for missing the last call deadline; however I hope the input is useful.

This document is basically ready; some issues and questions for the WG below.

General Considerations, Data Channel Design

On its own this document is okay from a transport considerations standpoint: 
the data channel does not have to operate in a degraded environment (i.e.,. on an 
interface under attack) and makes perfectly reasonable use of RESTCONF. The 
companion signal channel document will require (much) more careful attention 
from the transport directorate.

Please pay attention to whatever your SECDIR review says anything about the 
use of TLS client authentication (as specified with mutual authentication). 

I suppose the use of mutual auth was inherited from RESTCONF, though? 
I'd be curious to know whether other client authentication schemes were considered.

The use of cdid as a client rate association token and rate-limiter seems open to 
misconfiguration or misuse. Is there a concept for protecting against this beyond

Data Model Design

The target-fqdn element in the alias definition seems prone to cause 
confusing results if used naïvely (indeed the document itself points
this out). On the other hand, in dynamic service environments it is quite useful
for an alias to refer to a name as opposed to a set of addresses. Did the working 
group consider including some further context for the resoultion of these into 
IP addresses (for example, by providing a link to a DoT/DoH server to update 
the resolutions periodically)? If not, perhaps some text about doing this out
of band would be helpful.

Thanks, cheers,