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

Hi Roman,

Thanks for the review. Please see inline

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of Roman Danyliw
> Sent: Friday, January 10, 2020 3:00 AM
> To: dots@ietf.org
> 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!
> 
> 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.

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. 

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

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

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.

> 
> ** 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)?

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.

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

Thanks, Fixed.

Cheers,
-Tiru

> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots