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

From: Brian Trammell via Datatracker <[email-masked]>
Date: Sat, 16 Mar 2019 03:27:32 -0700

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? 
I'd be curious to know whether other client authentication schemes were considered.

The use of cdid as a client rate association token and rate-limiter seems open to 
misconfiguration or misuse. Is there a concept for protecting against this beyond
log-and-detect?

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)? If not, perhaps some text about doing this out
of band would be helpful.

Thanks, cheers,

Brian

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 18 Mar 2019 05:42:32 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Brian Trammell via
> Datatracker
> Sent: Saturday, March 16, 2019 3:58 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Dots] Tsvart last call review of draft-ietf-dots-data-channel-27
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> Reviewer: Brian Trammell
> 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.
> 

Yes, the TLS protocol profile for DOTS protocols is discussed in https://tools.ietf.org/html/draft-ietf-dots-signal-channel-30#section-7.1 

> 
> The use of cdid as a client rate association token and rate-limiter seems open
> to misconfiguration or misuse. Is there a concept for protecting against this
> beyond log-and-detect?

cdid is generated from the client identity (e.g. hash of the public key in the client certificate), DOTS server can detect if the client 
is frequently changing the 'cdid'.

> 
> 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)? If not, perhaps some text about doing this out of band would be
> helpful.

Good point. We can add the following text:
DNSSEC must be used to ensure target FQDN resolution is authentic, and DNS privacy protocols (DoT or DoH) must be used to resolve the target FQDN to prevent eavesdroppers 
from possibly identifying the target resources protected by the DDoS mitigation service.

Cheers,
-Tiru

> 
> Thanks, cheers,
> 
> Brian
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Mon, 18 Mar 2019 07:13:26 +0000

Hi Brian, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Brian Trammell via Datatracker [mailto:[email-masked]]
> Envoyé : samedi 16 mars 2019 11:28
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked]
> Objet : Tsvart last call review of draft-ietf-dots-data-channel-27
> 
> Reviewer: Brian Trammell

[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.  

> I'd be curious to know whether other client authentication schemes were

[Med] Which schemes do you have in mind?

> 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).  

 Is there a concept for protecting against this
> beyond

[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"

> 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.  

 If not, perhaps some text about doing this out

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 25 Mar 2019 08:31:53 +0100

hi Med,

Thanks for the reply, apologies for the delay,

> On 18 Mar 2019, at 08:13, [email-masked] wrote:
> 
> Hi Brian, 
> 

Okay, thanks for the pointer.

> [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.

> [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?

>   monitor and audit DOTS agents to detect misbehavior and to deter

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.

> 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.

Cheers,

Brian

> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: <[email-masked]>
Date: Mon, 25 Mar 2019 13:04:08 +0000

Hi Brian,

Please see inline.

Cheers,
Med

> De : Brian Trammell (IETF) [mailto:[email-masked]]
> Envoyé : lundi 25 mars 2019 08:32
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-data-
> channel-27
> 
> hi Med,
> 
> >> the data channel does not have to operate in a degraded environment
> (i.e.,.
> >> on an
> > [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.
> 
> 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.
> 
> > [Med] I guess you are referring to policies at the server (because rate-
> limits at the gateway rely upon the client identity).
> 

[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.

> 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
> >> --------------------
> >>

[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]).

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 25 Mar 2019 14:13:23 +0100

> On 25 Mar 2019, at 14:04, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Brian,
> 
> Please see inline.
> 
> Cheers,
> Med
> 

ahhh... Okay, this is good, thanks.

>   to ensure the target FQDN resolution is authentic (e.g., DNSSEC

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

---

From: <[email-masked]>
Date: Fri, 29 Mar 2019 05:57:16 +0000

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

> Envoyé : lundi 25 mars 2019 14:13
> >>>> authors and WG to allow them to address any issues raised and also to
> the
> >>>> IETF
> >>>> Apologies for missing the last call deadline; however I hope the input
> is
> >>>> useful.
> >>>>
> >>>> The use of cdid as a client rate association token and rate-limiter
> seems
> >>>> open to
> >>>> 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
> 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
> 
>