Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 05 Feb 2020 21:45:46 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dots-architecture-16: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this well-written document!  It's a great high-level summary of
DOTS and I just have some fairly minor comments.

There might be a bit of mismatch between describing the signal channel
session as associated with "an ephemeral security association" in Section
3.1 and as "expected to be long-lived" in Section 3.2.4.1.

Section 2.2.3

   The DOTS gateway MUST perform full stack DOTS session termination and
   reorigination between its client and server side.  The details of how
   this is achieved are implementation specific.  The DOTS protocol does
   not include any special features related to DOTS gateways, and hence
   from a DOTS perspective, whenever a DOTS gateway is present, the DOTS
   session simply terminates/originates there.

Does the 'cdid' count as a "special feature"?

Section 2.3.1

   An example is a DOTS gateway at the network client's side, and
   another one at the server side.  The first gateway can be located at
   a CPE to aggregate requests from multiple DOTS clients enabled in an

nit: "CPE" does not appear as "well known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt and should be
expanded on first use.

Section 3.2.3

We could mention that the recursing gateway (e.g., Cn in Figure 12) must
still be authorized to request mitigation for the resources (also)
controlled by client Cc (though perhaps the closing discussion about there
typically being a SLA among client, recursed, and recursing domain suffices).

Section 3.2.4.1

   DOTS client to initialize a new DOTS session.  This challenge might
   in part be mitigated by use of resumption via a PSK in TLS 1.3
   [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in
   TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must
   be available to all DOTS servers sharing the anycast Service Address
   in that case.

"which has operational challenges of its own", perhaps.

   session may involve diverting traffic to a scrubbing center.  If the
   DOTS session flaps due to anycast changes as described above,
   mitigation may also flap as the DOTS servers sharing the anycast DOTS
   service address toggles mitigation on detecting DOTS session loss,
   depending on whether the client has configured mitigation on loss of
   signal.

I am not sure if we've mentioned configuring mitigation on loss of signal,
yet.  A forward reference to Section 3.3.3 might help.

Section 3.2.5

   Network address translators (NATs) are expected to be a common
   feature of DOTS deployments.  The Middlebox Traversal Guidelines in
   [RFC8085] include general NAT considerations for DOTS deployments
   when the signal channel is established over UDP.

nit: the guidelines in 8085 are not specifically about DOTS deployments, so
probably we should say "that are applicable to" DOTS deployments.

Section 3.2.5.1

   request accurate mitigation scopes.  To that aim, the DOTS client can
   rely on mechanisms, such as [RFC8512] to retrieve static explicit
   mappings.  This document does not prescribe the method by which

nit: no comma.

Section 3.3.3

   The impact of mitigating due to loss of signal in either direction
   must be considered carefully before enabling it.  Signal loss is not
   caused by links congested with attack traffic alone, and as such
   mitigation requests triggered by signal channel degradation in either

nit: I think this could be parsed as "links are congested by attack traffic
and other traffic", whereas we intend to say that "attack traffic is not the
only possible cause of link congestion".  Perhaps "Attack traffic congesting
links is not the only reason why signal could be lost" is more clear.

Section 5

   DOTS is at risk from three primary attack vectors: agent
   impersonation, traffic injection and signal blocking.  These vectors

We seem to only partially discuss countermeasures for these attacks in the
rest of the section; one piece that seems noteworthy in its absence is the
requirement (already described in the body text) to authenticate the peer
and perform authorization checks on client requests.  Mitigating against
signal blocking is in general hard, but we could consider mentioning again
that the automated mitigation on loss of signal discussed in Section 3.3.3
is an option, albeit one with risks of its own.

Section 8.2

One could perhaps argue that RFC 4033 and RFC 6887 should be normative
("[RFC4033] must be used where [...]", "[RFC6887] may be used to [...]").

There's a stronger case that RFC 4786 should be normative, as we use a BCP
14 keyword allowing its deployment.

---

From: <[email-masked]>
Date: Thu, 6 Feb 2020 06:47:03 +0000

Hi Ben, 

Please see one comment inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Benjamin Kaduk
> via Datatracker
> Envoyé : jeudi 6 février 2020 06:46
> À : The IESG
> Cc : Roman Danyliw; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-
> 16: (with COMMENT)
> 

[Med] Good catch. I suggest to delete the last sentence of the above excerpt. 
(we don't specify how the client and server sides are glued but we do have feature to avoid loops when GWs are involved, enforce policies on a per client or domain basis, etc.).

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 6 Feb 2020 09:12:44 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Thursday, February 6, 2020 12:17 PM
> To: Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16:
> (with COMMENT)
> 
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> Hi Ben,
> 
> > via Datatracker Envoyé : jeudi 6 février 2020 06:46 À : The IESG Cc :
> > Roman Danyliw; [email-masked]; [email-masked];
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Thanks for this well-written document!  It's a great high-level
> > summary of DOTS and I just have some fairly minor comments.
> >

Works for me.

Cheers,
-Tiru

> (we don't specify how the client and server sides are glued but we do have
> feature to avoid loops when GWs are involved, enforce policies on a per
> client or domain basis, etc.).
> 
> >
> > Section 2.3.1
> >
> > https://www.rfc-editor.org/materials/abbrev.expansion.txt and should
> > be expanded on first use.
> >
> > Section 3.2.3
> >
> > We could mention that the recursing gateway (e.g., Cn in Figure 12)
> > must still be authorized to request mitigation for the resources
> > (also) controlled by client Cc (though perhaps the closing discussion
> > about there typically being a SLA among client, recursed, and
> > recursing domain suffices).
> >
> > Section 3.2.4.1
> >
> > I am not sure if we've mentioned configuring mitigation on loss of
> > signal, yet.  A forward reference to Section 3.3.3 might help.
> >
> > Section 3.2.5
> >
> > nit: the guidelines in 8085 are not specifically about DOTS
> > deployments, so probably we should say "that are applicable to" DOTS
> > deployments.
> >
> > Section 3.2.5.1
> >
> > nit: I think this could be parsed as "links are congested by attack
> > traffic and other traffic", whereas we intend to say that "attack
> > traffic is not the only possible cause of link congestion".  Perhaps
> > "Attack traffic congesting links is not the only reason why signal
> > could be lost" is more clear.
> >
> > Section 5
> >
> > We seem to only partially discuss countermeasures for these attacks in
> > the rest of the section; one piece that seems noteworthy in its
> > absence is the requirement (already described in the body text) to
> > authenticate the peer and perform authorization checks on client
> > requests.  Mitigating against signal blocking is in general hard, but
> > we could consider mentioning again that the automated mitigation on
> > loss of signal discussed in Section
> > 3.3.3

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 6 Feb 2020 11:08:40 +0000

Hi Ben,

Please see inline

> From: Dots <[email-masked]> On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Thursday, February 6, 2020 11:16 AM
> To: The IESG <[email-masked]>
> Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16:
> (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 

Good catch, removed "ephemeral". 

> Does the 'cdid' count as a "special feature"?

Yes, removed the last line. 

> nit: "CPE" does not appear as "well known" at https://www.rfc-
> editor.org/materials/abbrev.expansion.txt and should be expanded on first
> use.

Fixed. 

> 
> Section 3.2.3
> 
> We could mention that the recursing gateway (e.g., Cn in Figure 12) must still
> be authorized to request mitigation for the resources (also) controlled by
> client Cc (though perhaps the closing discussion about there typically being a
> SLA among client, recursed, and recursing domain suffices).

Good point, updated text as follows:

Typically there is a contractual Service Level Agreement (SLA) negotiated among
the DOTS client domain, the recursed domain and the recursing domain 
to meet the privacy requirements of the DOTS client domain and authorization for the 
recursing domain to request mitigation for the resources controlled by the DOTS client domain.

> "which has operational challenges of its own", perhaps.

Sure, updated.

> I am not sure if we've mentioned configuring mitigation on loss of signal, yet.
> A forward reference to Section 3.3.3 might help.

Done. 

> probably we should say "that are applicable to" DOTS deployments.

Fixed. 

>    mappings.  This document does not prescribe the method by which

Okay.

> nit: I think this could be parsed as "links are congested by attack traffic and
> other traffic", whereas we intend to say that "attack traffic is not the only
> possible cause of link congestion".  Perhaps "Attack traffic congesting links is
> not the only reason why signal could be lost" is more clear.

Thanks, updated. 

> signal blocking is in general hard, but we could consider mentioning again that
> the automated mitigation on loss of signal discussed in Section 3.3.3 is an
> option, albeit one with risks of its own.

Added the following lines:

   DOTS agents MUST perform mutual authentication to ensure authenticity
   of each other and DOTS servers MUST verify that the requesting DOTS
   client is authorized to request mitigation for specific target
   resources (see Section 2.2.2).

   An MITM attacker can intercept and drop packets, preventing the DOTS
   peers from receiving some or all of the DOTS messages, automated
   mitigation on loss of signal can be used as a countermeasure but with
   risks discussed in Section 3.3.3.

> ("[RFC4033] must be used where [...]", "[RFC6887] may be used to [...]").

Moved. 

> 14 keyword allowing its deployment.

Done.

Cheers,
-Tiru

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Feb 2020 17:22:28 -0800

Hi Tiru,

Thanks for the updates; these all look good.

-Ben