Hi Brian, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Brian Trammell via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : samedi 16 mars 2019 11:28 > À : tsv-art@xxxxxxxx > Cc : draft-ietf-dots-data-channel.all@xxxxxxxx; ietf@xxxxxxxx; dots@xxxxxxxx > 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 >
