[Dots] AD review of draft-ietf-dots-server-discovery-10

[Benjamin Kaduk <[e-mail]>]

Hi all,

Despite the first half of the review basically being entirely nits, there
are some substantive comments in there later on.  (Would it be helpful if I
tried harder to split the nits out into a separate section in the future?)

Overall it's pretty straightforward, so no major issues left to address;
sorry for taking so long to get through it.


One thing that we should definitely fix before getting more eyes on this
document is that both TBD1 and TBD2 are overloaded -- we use them to
refer to the port assignments from the signal channel and call home
protocol assignments, but also for the DHCPv6 option codes.

Abstract

The first paragraph seems to be generic about all of DOTS, not really
very specific to discovery.  I wonder if we want to just remove the
first paragraph or perhaps swap the order, the latter of which might
look like:

% This document specifies mechanisms to configure Districuted Denial of
% Service Open Threat Signaling (DOTS) clients with their DOTS servers.
% The discovery procedure also covers the DOTS Signal Channel Call Home.
%
% Knowing the appropriate DOTS server for a given location can be useful
% to engage mitigation actions even in cases where the DOTS client
% cannot localize the attack, but only knows that some resources are
% under attack and that help is needed.

Section 1

   appropriate mitigation actions are required.  Indeed, because the
   lack of a common method to coordinate a real-time response among
   involved actors and network domains inhibits the effectiveness of
   DDoS attack mitigation, DOTS signal channel protocol
   [I-D.ietf-dots-signal-channel] is meant to carry requests for DDoS

nit: missing "the" before "DOTS signal channel protocol".

   attack mitigation, thereby reducing the impact of an attack and
   leading to more efficient defensive actions in various deployment
   scenarios such as those discussed in [I-D.ietf-dots-use-cases].

nit: (also, this sentence is fairly long, though not necessarily
problematic.)

   Moreover, DOTS clients can instruct a DOTS server to install
   filtering rules by means of the DOTS data channel protocol
   [I-D.ietf-dots-data-channel].

nit: maybe "named filtering rules", since that is an important aspect of
how we interact with them.

   [I-D.ietf-dots-architecture] specifies that the DOTS client may be
   provided with a list of DOTS servers; each associated with one or

nit: comma here, rather than semicolon.

   This document assumes that security credentials to authenticate DOTS
   server(s) are provisioned to a DOTS client using a variety of means
   such as (but not limited to) those discussed in [RFC8572] or

nit: "using a variety of means" implies that all are used concurrently;
do we really mean "any of" or "one of"?

Section 2

   The reader should be familiar with the terms defined in
   [I-D.ietf-dots-architecture], [RFC3958], and
   [I-D.ietf-dots-signal-call-home].

A bit surprising to not see RFCx 8782/8783 in there, too :)

Section 3

   o  Many use cases discussed in [I-D.ietf-dots-use-cases] do involve a
      CPE device.  Multiple CPEs, connected to distinct network

nit(?): I think "Many of the use cases" reads better.

      providers may even be considered.  It is intuitive to leverage on

nits: comma after "providers"; s/on$//

   o  Resolving a DOTS server domain name offered by an upstream transit
      provider provisioned to a DOTS client into IP address(es) require

nit: s/require/requires/

   o  Some of the use cases may allow DOTS clients to have direct
      communications with upstream DOTS servers; that is no DOTS gateway

nit: comma/semicolon usage; let's go for "DOTS servers, that is, no DOTS
gateway"

      is involved.  Leveraging on existing features that do not require

nit: s/Leveraging on/Leveraging/

      specific feature on the node embedding the DOTS client may ease

nit: we use "features" and "feature" in this sentence, which makes it a
little hard to understand what's going on.  Are the initial "features"
more of "protocol behaviors"?

Section 4

   A key point in the deployment of DOTS is the ability of network
   operators to be able to configure DOTS clients with the correct DOTS

nit: "ability" and "to be able to" are redundant (I suggest s/to be able
to/to/)

   All DOTS clients MUST support at least one of the three mechanisms
   below to determine a DOTS server list.  All DOTS clients SHOULD
   implement all three, or as many as are practical for any specific
   device (e.g., a CPE will support the first two mechanisms, a host
   within a LAN will support the last two mechanisms, or an application
   server will support a local configuration.  More samples are
   discussed in Section 3), of these ways to discover DOTS servers, in
   order to facilitate the deployment of DOTS in large scale
   environments:

nit: the way the parenthetical is structured is a bit unusual, with a
sentence break occurring within the parentheses (and leaving quite a gap
for processing in the middle of the thought "implement all three of
these ways").  It's probably okay to just make the "SHOULD implement all
three" a single standalone sentence, and leave the clarification of when
implementing all three is infeasible/unnecessary to a follow-up
sentence.

          server.  When only DOTS server's IP addresses are configured,
          a reference identifier must also be configured for
          authentication purposes.

Forestalling my common questions; good work!

       *  Automatic configuration (e.g., DHCP, an automation system):
          The DOTS client attempts to discover DOTS server(s) names and/
          or addresses from DHCP, as described in Section 5.

We may get questions about this one, since it is apparently equating
DHCP with a (generic) "automation system".  Perhaps we want to say that
the DHCP mechanism is used in the absence of manual or automated
explicit configuration?

   the relevant DOTS server is obtained directly.  Implementation
   options may vary on a per device basis, as some devices may not have
   DNS capabilities and/or proper configuration.

nit: maybe "proper DNS configuration" or "proper resolver
configuration"?

   combination of interface and address family.  A DOTS client may
   choose to perform the discovery procedure only for a desired
   interface/address combination if the client does not wish to discover

nit: I think "interface/address-family combination".

   o  Expiry of a lease associated with a discovered DOTS agent.

Is this specifically a DHCP lease, or a more generic concept?

Section 5

   As reported in Section 1.7.2 of [RFC6125]:

      "few certification authorities issue server certificates based on
      IP addresses, but preliminary evidence indicates that such

I think the quote is actually "[s]ome", not "few" -- please check!

   The list of the IP addresses returned by DHCP servers is typically
   used to fed the DOTS server selection procedure or to provide DOTS

nit: s/fed/feed/

   for the DOTS Call Home.  The DOTS client (or Call Home DOTS server)
   will then use the address selection specified in Section 4.3 of

nit: "address selection procedure"

      Let's consider that the DOTS server is reachable at
      2001:db8:122:300::1 while the Call Home DOTS client is reachable
      at 2001:db8:122:300::2.  The DHCP server will then return one DOTS
      reference identifier and a list that includes both
      2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP
      client.  That list is passed to the DOTS client (or Call Home DOTS
      server) which will try to establish connections to the addresses
      of that list and destination port number TBD1 (or TBD2).  As a
      result, the DOTS client (or Call Home DOTS server) will select
      2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or
      Call Home DOTS client).

I mostly expect pushback from TSV-area reviewers about giving the
allocated port numbers such importance in selecting the peer address to
use.

Section 5.1.2

   format of this option is shown in Figure 5.  As a reminder, this
   format follows the guidelines for creating new DHCPv6 options
   (Section 5.1 of [RFC7227]).

We need the reminder for the second option but not the first one? ;)

Section 5.1.3

   are used to reach the peer DOTS agent.  In other words, the name
   conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying
   resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a
   response.

I'm not sure how much of this needs to end up in the document itself,
but can we walk through the scenarios here, especially when the
DNS-resolution addresses for the name in question differ from the
addresses in OPTION_V6_DOTS_ADDRESS?  I don't understand yet why/how
this scheme ends up being safe, and am hoping that you have a head start
over me on doing the analysis :)

   If the DHCP client receives OPTION_V6_DOTS_RI only, but
   OPTION_V6_DOTS_RI option contains more than one name, as

nit: insert "the" at the start of the second line.

   If the DHCP client receives OPTION_V6_DOTS_RI only, but
   OPTION_V6_DOTS_RI option contains more than one name, as
   distinguished by the presence of multiple root labels, the DHCP
   client MUST use only the first name.  Once the name is validated

Is there a reason to make this "use the first one" vs. "ignore the whole
thing as malformed?

   (Section 8 of [RFC8415]), the name is passed to a name resolution
   library.  Moreover, that name is also used as a reference identifier
   for authentication purposes.

Hmm, I'm not seeing much in Section 8 specifically of RFC 8415 that
looks relevant here.  Was perhaps a different document intended?

Section 5.2.1

A reference to 2132 here would be timely, not least for understanding
the figure.

     The values s1, s2, s3, etc. represent the domain name labels in the
     domain name encoding.

super-nitty-nit: maybe "the octets of the domain name labels"?  IIUC the
RFC 2132 convention is to give such names to the individual bytes of the
DHCP option, but this wording implies that we are naming labels, which
are multi-byte (except for the root).

Section 5.2.2

I wonder if anyone will complain that we are using a more "modern"
structure for the figure, instead of keeping with the "traditional" DHCP
option diagrams.

Section 5.2.3

   To discover a peer DOTS agent, the DHCPv4 client MUST include both
   OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request
   List Option [RFC2132].

Why is the v4 case a MUST but the v6 case was only MAY?

   If the DHCP client receives more than one instance of
   OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use
   only the first instance of that option.

I think the parenthetical needs to be dropped, since in the previous
section we say that this is a concatenation-requiring option.

   If the DHCP client receives OPTION_V4_DOTS_RI only, but
   OPTION_V4_DOTS_RI option contains more than one name, as
   distinguished by the presence of multiple root labels, the DHCP
   client MUST use only the first name.  Once the name is validated
   (Section 10 of [RFC8415]), the name is passed to a name resolution
   library.  Moreover, that name is also used as a reference identifier
   for authentication purposes.

[same comments about "use first" as for v4]
I see that here we reference §10, rather than 8, of RFC 8415, though it
still doesn't say much explicitly about a "validation procedure".

The diff between §5.1.3 and 5.2.3 includes "(e.g., PKIX [RFRC6125])"
only in 5.1.3; it seems like it would also apply here.

   The DHCP client MUST silently discard multicast and host loopback
   addresses conveyed in OPTION_V4_DOTS_ADDRESS.

Can we put a reference for "multicast and host loopback" addresses as we
did for the v6 case?

Section 6

   1.  A DNS domain name is retrieved for each combination of interface
       and address family.  A DOTS agent has to determine the domain in
       which it is located relying on dynamic means such as DHCP
       (Section 5) . [...]

Hmm, this may be worth a closer look.  If I understand correctly, if the
procedures in Section 5 only give you a name, you're supposed to use DNS
to get IP addresses to talk to, from that name.  So is this procedure
only applicable when the A/AAAA lookup fails?  Otherwise I'm not sure
how you would get only a name but not full contact information, from the
section 5 procedure.  Or, if the intent of "the name is passed to a name
resolution library" in Section 5 is to induce the S-NAPTR lookups
defined here, Section 5 should be more clear about that.

   Once the DOTS agent has retrieved its DNS domain or discovered the
   peer DOTS agent name that needs to be resolved (e.g., Section 5), an

(The parenthetical seems redundant with step (1).)

   S-NAPTR lookup with 'DOTS' application service and the desired
   [...]
   This specification defines "DOTS" and "DOTS-CALL-HOME" as application
   service tags (Sections 9.4.1 and 9.4.2).  It also defines

We should probably mention "DOTS-CALL-HOME" in both places, or just say
something generic like "the appropriate application service" in the
first instance, instead of only saying 'DOTS' the first time.

   a.example.net.
   IN AAAA  2001:db8::1

I'm sure my INT-area colleagues will appreciate the IPv6 examples :)

Section 8

Having a clearly defined priority order for using the different
discovery mechanisms covers most of the potential security
considerations inherently, but I think some text is in order about
whether an attacker can block/modify traffic to force a "lower priority"
mechanism to be used (but would not be able to modify the "higher
priority" mechanism's results with the same capabilities).

We may also want to reiterate that discovery results are scoped by
interface and address family, and that bad things can happen if you use
a result from one interface for traffic from a different interface.

There are probably not particularly interesting privacy considerations
of advertising/exposing DOTS server names in these various discovery
mechanisms, but a brief section on privacy considerations is likely in
order regardless.

Section 8.2

   The primary attack against the methods described in Section 6 is one
   that would lead to impersonation of a peer DOTS agent.  An attacker
   could attempt to compromise the S-NAPTR resolution.  The use of
   mutual authentication makes it difficult to redirect a DOTS client
   (or a Call Home DOTS server) to an illegitimate DOTS server (or a
   Call Home DOTS client).

IIUC this property only holds if the domain name used for authenticating
the peer (i.e., the input to the RFC 6125 procedures) is the one used as
input to the procedure in Section 6, not the intermediate names produced
during that procedure (e.g., "example.net" as input and "a.example.net"
as intermediate, from Figure 10).  I don't think we specify anywhere
that this must be the case, so on the face of it it seems that in the
absence of DNSSEC, an attacker spoofing DNS responses can redirect the
client to an arbitrary name controlled by the attacker, for which the
attacker has valid PKIX credentials.  (We also allow SRV-IDs for
validation, so the SRV names are also affected.)
I also note that the analogous question for mail servers (whether they
authenticate as example.net or a.example.net) is a recurring source of
trouble, so our hand may be forced by deployment realities.

Section 8.3

I was going to say that we should reference the RFC 6763 security
considerations, too, but they are just saying the same things we already
say.

Section 12.2

I expect at least one AD to suggest that the architecture draft should
be normative since we require it for terminology, but I don't insist on
changing its classification at this time.  (Likewise for Call Home.)

-Ben