hi Med, Thanks for the reply, apologies for the delay, > On 18 Mar 2019, at 08:13, mohamed.boucadair@xxxxxxxxxx wrote: > > 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. Okay, thanks for the pointer. >> I'd be curious to know whether other client authentication schemes were >> considered. > > [Med] Which schemes do you have in mind? Nothing in particular; I'm just under the impression that client auth is seen as a second-class feature of TLS, so I wonder how the decision to use it impacts implementability and deployability of DOTS. Someone more up to date on the state of TLS can probably make a more authoritative statement here. >> 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). .... where the client identity is derived from cdid alone, or cdid / 3-tuple? > 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" so, "no". :) That's fine, this is a hard problem, and rate limitations are still one of the only tools that works consistently. Calling out which parts of the protocol are vulnerable to state space exhaustion on the server, though, would be sueful. > >> >> 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. Okay, as long as we think the uncertainty in resolution is something that will work as expected for DOTS clients. Cheers, Brian > > If not, perhaps some text about doing this out >> of band would be helpful. >> >> Thanks, cheers, >> >> Brian >> > > _______________________________________________ > Tsv-art mailing list > Tsv-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tsv-art
