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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Ben,

Please see inline

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Thursday, February 6, 2020 11:16 AM
> To: The IESG <[e-mail]>
> Cc: Roman Danyliw <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: [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.
> 
> 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.

Good catch, removed "ephemeral". 

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

Yes, removed the last line. 

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

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.

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

Sure, updated.

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

Done. 

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

Fixed. 

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

Okay.

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

Thanks, updated. 

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

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.

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

Moved. 

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

Done.

Cheers,
-Tiru

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