Subject: [Dots] AD Review of draft-ietf-dots-architecture-14

From: Roman Danyliw <[email-masked]>
Date: Thu, 9 Jan 2020 21:30:09 +0000

Hello!

The following is my AD review of draft-ietf-dots-architecture-14:

** Section 1.2.  Per "In this architecture, DOTS clients and servers communicate using DOTS signaling ...", is this definition too narrow?  Per the guidance in Section 1.1.2 to use RFC8612 definitions, which says that "DOTS signal:  [is a] A status/control message transmitted over the authenticated signal channel ..." the text seems to ignoring the data channel.

** Section 1.2.  Along the same line, the next sentence, "As a result of signals from the DOTS client ...", seems to also present a very narrow example of what the signal channel might do (let alone the data channel).  I'm not sure how much this sentence adds to clarifying the scope as suggested by the section title.

** Section.  1.3 Per "The signal and data channels are loosely coupled, and may not terminate on the same DOTS server", it seems help to clarify the obvious that how these signals would be synchronized is out of scope.

** Section 2.  Figure 3.  Is this figure (i.e., the JSON example) normative?  This seems like a detail best left to the data channel spec (and omitted from this document).

** Section 2.  Per:
Note that while it is possible to exchange the above information
   before, during or after a DDoS attack, DOTS requires reliable
   delivery of this information and does not provide any special means
   for ensuring timely delivery of it during an attack.  In practice,
   this means that DOTS deployments should not rely on such information
   being exchanged during a DDoS attack.

It seems to me that there is guidance missing here.  If the first sentence says that this information can be exchanged before, during or after an attack, but don't count on it during the attack.  The second sentence reiterates the point that during an attack it will be unreliable, is a statement to the effect that necessary configuration must be made prior to the attack also needed?

** Section 2.1  Per "It is not until this point that the mitigation service is available for use.", this closing point about a mitigation service follows from the previous description.  However, I wanted to point out, the notion of a "mitigation service" being available after a fully configured DOTS client is not a construct previously used in the document or the terminology.  It's likely worth relating it to the previously defined terms like mitigator.

** Section 2.1.  To avoid confusion on terms (i.e., from HTTP), perhaps replace s/basic authorization/authorization/.

** Section 2.2.2.  Per "For a given DOTS client (administrative) domain, the DOTS server needs to be able to determine whether a given target  resource is in that domain.", what is a "target resource" isn't clear.  I think it is meant to be the resource that is the target of the attack (that the DOTS client is signaling about).  Also, the idea that DOTS clients have "domains" is a new concept here that needs clarification.

** Section 2.2.2. Per "The DOTS server enforces authorization of DOTS clients' signals for mitigation.", no objection.  Is there a complementary statement to make the data channel?

** Section 5.  Per "Any attacker with the ability to impersonate ...", this paragraph clearly describes in the impact of impersonation.  However, the suggested mitigations read like requirements.  Instead of trying to list them again, I would recommend explicitly citing the relevant requirements from Section 2.4 of the RFC8612 and noting that need for conformance to these security mechanisms.

** Section 5.  Per "Similarly, received data at rest SHOULD be stored with a satisfactory degree of security.", I would recommend explaining why the data should be secured. Perhaps:
OLD: 
Similarly, received data at rest SHOULD be
   stored with a satisfactory degree of security.

NEW (or something like it):
Similarly, as the received data may contain network topology, telemetry, threat, or preconfigured mitigation information which could be considered sensitive in certain environment, it SHOULD be protected at rest per required local policy.

** Section 5.  Per "As many mitigation systems employ diversion to scrub attack traffic, operators of DOTS agents SHOULD ensure DOTS sessions are resistant to Man-in-the-Middle (MitM) attacks.", I'm not following the link between the mitigation systems re-routing traffic with DOTS agents resisting MitM attack.  What actions should be agents be taking?

** Section 5.  Per:
   Any attack targeting the availability of DOTS servers may disrupt the
   ability of the system to receive and process DOTS signals resulting
   in failure to fulfill a mitigation request.  DOTS agents SHOULD be
   given adequate protections, again in accordance with best current
   practices for network and host security.

-- The first sentence talks about "DOTS servers".  The second talk about protecting "DOTS agents".  What's the role in the DOTS clients in this guidance?
-- Shouldn't the protections afforded to the DOTS agents be a mandatory (MUST)?

** Editorial Nits:
-- Section 1.  Editorial. s/for help defending/for help to defend/
-- Section 3.2.5.  Typo. s/deployements/deployments/

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 10 Jan 2020 09:04:54 +0000

Hi Roman,

Thanks for the review. Please see inline

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Roman Danyliw
> Sent: Friday, January 10, 2020 3:00 AM
> To: [email-masked]
> Subject: [Dots] AD Review of draft-ietf-dots-architecture-14
> 
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> Hello!
> 
> ** Section 1.2.  Per "In this architecture, DOTS clients and servers
> communicate using DOTS signaling ...", is this definition too narrow?  Per the
> guidance in Section 1.1.2 to use RFC8612 definitions, which says that "DOTS
> signal:  [is a] A status/control message transmitted over the authenticated
> signal channel ..." the text seems to ignoring the data channel.

Updated line as follows:
In this architecture, DOTS clients and servers communicate using DOTS signal channel and data channel protocols.

> 
> ** Section 1.2.  Along the same line, the next sentence, "As a result of signals
> from the DOTS client ...", seems to also present a very narrow example of
> what the signal channel might do (let alone the data channel).  I'm not sure
> how much this sentence adds to clarifying the scope as suggested by the
> section title.

Agreed, I don't see a need for this sentence in the "Scope" section. Removed it. 

> 
> ** Section.  1.3 Per "The signal and data channels are loosely coupled, and
> may not terminate on the same DOTS server", it seems help to clarify the
> obvious that how these signals would be synchronized is out of scope.

Okay, added the following line:
How the DOTS servers synchronize the DOTS configuration is out of scope of this specification.

> 
> ** Section 2.  Figure 3.  Is this figure (i.e., the JSON example) normative?

No.

 This
> seems like a detail best left to the data channel spec (and omitted from this
> document).

Yes, we have an example in the data channel spec. Removed Figure 3. 

> It seems to me that there is guidance missing here.  If the first sentence says
> that this information can be exchanged before, during or after an attack, but
> don't count on it during the attack.  The second sentence reiterates the point
> that during an attack it will be unreliable, is a statement to the effect that
> necessary configuration must be made prior to the attack also needed?

Yes, updated last line as follows:
In practice, this means that DOTS deployments should rely on such information 
being exchanged only under normal traffic conditions.

> 
> ** Section 2.1  Per "It is not until this point that the mitigation service is
> available for use.", this closing point about a mitigation service follows from
> the previous description.  However, I wanted to point out, the notion of a
> "mitigation service" being available after a fully configured DOTS client is not
> a construct previously used in the document or the terminology.  It's likely
> worth relating it to the previously defined terms like mitigator.

"mitigation service" is already used in Sections 2 and 1.2

> 
> ** Section 2.1.  To avoid confusion on terms (i.e., from HTTP), perhaps
> replace s/basic authorization/authorization/.

Okay, replaced.

> 
> ** Section 2.2.2.  Per "For a given DOTS client (administrative) domain, the
> DOTS server needs to be able to determine whether a given target  resource
> is in that domain.", what is a "target resource" isn't clear.  I think it is meant to
> be the resource that is the target of the attack (that the DOTS client is
> signaling about). 

Yes.

> Also, the idea that DOTS clients have "domains" is a new
> concept here that needs clarification.

I have simplified the text as follows:
For a given DOTS client (administrative) domain, the DOTS server needs to be
able to determine whether a given resource is in that domain. For
example, this could take the form of associating a set of IP addresses and/or
prefixes per DOTS client domain.

> 
> ** Section 2.2.2. Per "The DOTS server enforces authorization of DOTS
> clients' signals for mitigation.", no objection.  Is there a complementary
> statement to make the data channel?

Good point, updated text as follows:
The DOTS server enforces authorization of signals for mitigation, filtering rules and aliases for resources from DOTS clients.  
The mechanism of enforcement is not in scope for this document, but is expected to restrict mitigation requests, filtering rules and aliases
scope to addresses, prefixes, and/or services owned by the DOTS client domain, such that a DOTS
client from one domain is not able to influence the network path to another
domain. A DOTS server MUST reject requests for mitigation of resources, filtering rules and aliases for
resources not owned by the requesting DOTS client's administrative domain.

> 
> ** Section 5.  Per "Any attacker with the ability to impersonate ...", this
> paragraph clearly describes in the impact of impersonation.  However, the
> suggested mitigations read like requirements.  Instead of trying to list them
> again, I would recommend explicitly citing the relevant requirements from
> Section 2.4 of the RFC8612 and noting that need for conformance to these
> security mechanisms.

Good point, updated paragraph as follows:

Any attacker with the ability to impersonate a legitimate DOTS client or server
or, indeed, inject false messages into the stream may potentially
trigger/withdraw traffic redirection, trigger/cancel mitigation activities or
subvert drop-/accept-lists.  From an architectural standpoint, operators MUST
ensure conformance to the security requirements defined in Section 2.4 of 
RFC8612 to secure data in transit. 

> 
> ** Section 5.  Per "Similarly, received data at rest SHOULD be stored with a
> satisfactory degree of security.", I would recommend explaining why the
> data should be secured. Perhaps:
> OLD:
> Similarly, as the received data may contain network topology, telemetry,
> threat, or preconfigured mitigation information which could be considered
> sensitive in certain environment, it SHOULD be protected at rest per required
> local policy.

Works for me, minor update to proposed text:

Similarly, as the received data may contain network topology, telemetry,
threat and mitigation information which could be considered
sensitive in certain environment, it SHOULD be protected at rest per required
local policy.
 
> 
> ** Section 5.  Per "As many mitigation systems employ diversion to scrub
> attack traffic, operators of DOTS agents SHOULD ensure DOTS sessions are
> resistant to Man-in-the-Middle (MitM) attacks.", I'm not following the link
> between the mitigation systems re-routing traffic with DOTS agents resisting
> MitM attack.  What actions should be agents be taking?

Good point, modified paragraph as follows (and removed line discussing re-routing traffic):

An attacker with control of a DOTS client may negatively
influence network traffic by requesting and withdrawing requests for mitigation
for particular prefixes, leading to route or DNS flapping. DOTS operators should carefully
monitor and audit DOTS clients to detect misbehavior and deter misuse.

> -- The first sentence talks about "DOTS servers".  The second talk about
> protecting "DOTS agents".  What's the role in the DOTS clients in this
> guidance?

Good point, the guidance is only meant for DOTS servers and is mandatory. Modified text as follows:
DOTS servers MUST be given adequate protections,  in accordance with best current practices for network and host security.

> -- Section 3.2.5.  Typo. s/deployements/deployments/

Thanks, Fixed.

Cheers,
-Tiru

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

---

From: <[email-masked]>
Date: Fri, 10 Jan 2020 09:49:07 +0000

Hi Tiru, all, 

Two minor comments inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Konda,
> Tirumaleswar Reddy
> Envoyé : vendredi 10 janvier 2020 10:05
> À : Roman Danyliw; [email-masked]
> Objet : Re: [Dots] AD Review of draft-ietf-dots-architecture-14
> 
> Hi Roman,
> 
...
> "mitigation service" is already used in Sections 2 and 1.2

[Med] Given that only "mitigation" and "mitigator" are defined in the terminology inherited from RFC8612, I suggest to make this simple change:

OLD: 
   A simple example instantiation of the DOTS architecture could be an
   enterprise as the attack target for a volumetric DDoS attack, and an
   upstream DDoS mitigation service as the mitigator.

NEW:
   A simple example instantiation of the DOTS architecture could be an
   enterprise as the attack target for a volumetric DDoS attack, and an
   upstream DDoS mitigator. The service provided by the mitigator is called: DDoS mitigation service.

> prefixes per DOTS client domain.

[Med] Please make sure that the same wording is consistently used in the document. Typically, please make these changes in many places of the document:

s/DOTS client's domain/DOTS client domain 
s/DOTS server's domain/DOTS server domain

This is also to be aligned with the signal channel document. Thanks.

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 10 Jan 2020 10:36:27 +0000

Hi Tiru!

Everything proposed below works for me and addresses my concerns. Med’s subsequent consistency edits make sense to me too.

Thanks for the quick turn around. I’ll start the IETF LC with the -15 that has these changes.

Roman

> On Jan 10, 2020, at 4:05 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Roman,
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 11 Jan 2020 06:21:09 +0000

Thanks Med, will update text.

Cheers,
-Tiru

> From: [email-masked]
> <[email-masked]>
> Sent: Friday, January 10, 2020 3:19 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; Roman Danyliw
> <[email-masked]>; [email-masked]
> Subject: RE: AD Review of draft-ietf-dots-architecture-14
> 
> > Tirumaleswar Reddy Envoyé : vendredi 10 janvier 2020 10:05 À : Roman
> > Danyliw; [email-masked] Objet : Re: [Dots] AD Review of
> > draft-ietf-dots-architecture-14
> >
> > Hi Roman,
> >
> > > CAUTION: External email. Do not click links or open attachments
> > > unless
> > you
> > > the previous description.  However, I wanted to point out, the
> > > notion
> > of a
> > > a construct previously used in the document or the terminology.
> > > It's
> > likely
> [Med] Given that only "mitigation" and "mitigator" are defined in the
> terminology inherited from RFC8612, I suggest to make this simple change:
> 
> OLD:
> > > is in that domain.", what is a "target resource" isn't clear.  I
> > > think
> > it is meant to
> > > be the resource that is the target of the attack (that the DOTS
> > > client
> > is
> > > signaling about).
> >
> > Yes.
> >
> > > Also, the idea that DOTS clients have "domains" is a new concept
> > > here that needs clarification.
> >
> > For a given DOTS client (administrative) domain, the DOTS server needs
> > to be able to determine whether a given resource is in that domain.
> > For example, this could take the form of associating a set of IP
> > addresses and/or prefixes per DOTS client domain.
> 
> [Med] Please make sure that the same wording is consistently used in the
> document. Typically, please make these changes in many places of the
> document:
> 
> s/DOTS client's domain/DOTS client domain s/DOTS server's domain/DOTS
> server domain
>