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

["Brian Trammell (IETF)" <[e-mail]>]

> On 25 Mar 2019, at 14:04, <[e-mail]> <[e-mail]> wrote:
> 
> 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.

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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tsv-art
> 
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art