Hi Brian, Please see inline. Cheers, Med > -----Message d'origine----- > De : Brian Trammell (IETF) [mailto:ietf@xxxxxxxxxxx] > Envoyé : lundi 25 mars 2019 08:32 > À : BOUCADAIR Mohamed TGI/OLN > Cc : tsv-art@xxxxxxxx; draft-ietf-dots-data-channel.all@xxxxxxxx; > ietf@xxxxxxxx; dots@xxxxxxxx > Objet : Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-data- > channel-27 > > 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? > [Med] It is based on the cdid. 'cdid' is assumed to be supplied by a trusted gateway: DOTS servers MUST ignore 'cdid' attributes that are directly supplied by source DOTS clients or client-domain DOTS gateways. This implies that first server-domain DOTS gateways MUST strip 'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD support a configuration parameter to identify DOTS gateways that are trusted to supply 'cdid' attributes. > > 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. > [Med] While assuming that name resolution is deployment-specific, I added this NEW text to avoid misbehaviors: When FQDNs are used as targets, the DOTS server MUST rely upon DNS privacy enabling protocols (e.g., DNS over TLS [RFC7858], DoH [RFC8484]) to prevent eavesdroppers from possibly identifying the target resources protected by the DDoS mitigation service and means to ensure the target FQDN resolution is authentic (e.g., DNSSEC [RFC4034]). Thank you for the review. > 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
