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

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@trammell.ch]
> Envoyé : lundi 25 mars 2019 14:13
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : tsv-art@ietf.org; draft-ietf-dots-data-channel.all@ietf.org;
> ietf@ietf.org; dots@ietf.org
> Objet : Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-data-
> channel-27
> 
> 
> 
> > On 25 Mar 2019, at 14:04, <mohamed.boucadair@orange.com>
> <mohamed.boucadair@orange.com> wrote:
> >
> > Hi Brian,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Brian Trammell (IETF) [mailto:ietf@trammell.ch]
> >> Envoyé : lundi 25 mars 2019 08:32
> >> À : BOUCADAIR Mohamed TGI/OLN
> >> Cc : tsv-art@ietf.org; draft-ietf-dots-data-channel.all@ietf.org;
> >> ietf@ietf.org; dots@ietf.org
> >> 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@orange.com wrote:
> >>>
> >>> Hi Brian,
> >>>
> >>> Thank you for the review.
> >>>
> >>> Please see inline.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : Brian Trammell via Datatracker [mailto:noreply@ietf.org]
> >>>> Envoyé : samedi 16 mars 2019 11:28
> >>>> À : tsv-art@ietf.org
> >>>> Cc : draft-ietf-dots-data-channel.all@ietf.org; ietf@ietf.org;
> >> dots@ietf.org
> >>>> 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@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tsv-art
> >
> > _______________________________________________
> > Tsv-art mailing list
> > Tsv-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/tsv-art