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

[<[e-mail]>]

Hi Ben, 

Please see one comment inline. 

Cheers,
Med

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

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

> 
> 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.
> 
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots