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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of Brian Trammell via
> Datatracker
> Sent: Saturday, March 16, 2019 3:58 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [Dots] Tsvart last call review of draft-ietf-dots-data-channel-27
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> 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.

Yes, the TLS protocol profile for DOTS protocols is discussed in https://tools.ietf.org/html/draft-ietf-dots-signal-channel-30#section-7.1 

> 
> 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 log-and-detect?

cdid is generated from the client identity (e.g. hash of the public key in the client certificate), DOTS server can detect if the client 
is frequently changing the 'cdid'.

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

Good point. We can add the following text:
DNSSEC must be used to ensure target FQDN resolution is authentic, and DNS privacy protocols (DoT or DoH) must be used to resolve the target FQDN to prevent eavesdroppers 
from possibly identifying the target resources protected by the DDoS mitigation service.

Cheers,
-Tiru

> 
> Thanks, cheers,
> 
> Brian
> 
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots