Hi Brian, Great. FWIW, the only required change from this thread is implemented in https://tools.ietf.org/html/draft-ietf-dots-data-channel-28 Cheers, Med > -----Message d'origine----- > De : Brian Trammell (IETF) [mailto:ietf@xxxxxxxxxxx] > Envoyé : lundi 25 mars 2019 14:13 > À : 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 > > > > > On 25 Mar 2019, at 14:04, <mohamed.boucadair@xxxxxxxxxx> > <mohamed.boucadair@xxxxxxxxxx> wrote: > > > > 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. > > ahhh... Okay, this is good, thanks. > > >>> 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]). > > While this doesn't fix the resolution-context problem (which is in the > general case anyway probably unfixable), it is a very welcome addition. :) > > Thanks, cheers, > > Brian > > > > 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 > > > > _______________________________________________ > > Tsv-art mailing list > > Tsv-art@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/tsv-art
