> 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
