Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-data-channel-27

[<[e-mail]>]

Hi Brian,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Brian Trammell (IETF) [mailto:[e-mail]]
> Envoyé : lundi 25 mars 2019 08:32
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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, [e-mail] wrote:
> >
> > Hi Brian,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Brian Trammell via Datatracker [mailto:[e-mail]]
> >> Envoyé : samedi 16 mars 2019 11:28
> >> À : [e-mail]
> >> Cc : [e-mail]; [e-mail];
> [e-mail]
> >> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tsv-art