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

<> Mon, 18 March 2019 07:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B489D1310EE; Mon, 18 Mar 2019 00:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BDs99Od12uXC; Mon, 18 Mar 2019 00:13:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65BE51277CD; Mon, 18 Mar 2019 00:13:29 -0700 (PDT)
Received: from (unknown [xx.xx.xx.69]) by (ESMTP service) with ESMTP id 44N6pv562Zz5w68; Mon, 18 Mar 2019 08:13:27 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by (ESMTP service) with ESMTP id 44N6pv1pC8zyQ2; Mon, 18 Mar 2019 08:13:27 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7%21]) with mapi id 14.03.0439.000; Mon, 18 Mar 2019 08:13:27 +0100
To: Brian Trammell <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Tsvart last call review of draft-ietf-dots-data-channel-27
Thread-Index: AQHU2+LfrKr0BWVJlEaZqwr/cHEGW6YQ7B3g
Date: Mon, 18 Mar 2019 07:13:26 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA3EF14@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-data-channel-27
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Mar 2019 07:13:32 -0000

Hi Brian, 

Thank you for the review. 

Please see inline. 


> -----Message d'origine-----
> De : Brian Trammell via Datatracker []
> Envoyé : samedi 16 mars 2019 11:28
> À :
> Cc :;;
> Objet : Tsvart last call review of draft-ietf-dots-data-channel-27
> 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
> 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?

[Med] No, this was a design requirement ( The same security profile is used for both signal and data channels.  

> I'd be curious to know whether other client authentication schemes were
> considered.

[Med] Which schemes do you have in mind?

> The use of cdid as a client rate association token and rate-limiter seems
> open to
> misconfiguration or misuse.

[Med] I guess you are referring to policies at the server (because rate-limits at the gateway rely upon the client identity).  

 Is there a concept for protecting against this
> beyond
> log-and-detect?

[Med] We do have the following generic recommendation (from the requirements I-D):

   "DOTS operators should carefully
   monitor and audit DOTS agents to detect misbehavior and to deter

> 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)?

[Med] The document states the following:  

      How a name is passed to an underlying name resolution library is
      implementation- and deployment-specific. 

We could include some text similar to RFC7969 (Section 7), but still this is deployment-specific.  

 If not, perhaps some text about doing this out
> of band would be helpful.
> Thanks, cheers,
> Brian