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

[<[e-mail]>]

Hi Brian, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Brian Trammell via Datatracker [mailto:[e-mail]]
> Envoyé : samedi 16 mars 2019 11:28
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; [e-mail]
> 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
> 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?

[Med] No, this was a design requirement (https://tools.ietf.org/html/draft-ietf-dots-requirements-21#section-2.4). 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
   misuse"

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