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

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Sep 2020 13:22:11 -0700

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

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 21 Sep 2020 11:37:50 +0100

Hi Ben,

[I did send this out previously but provided a bad email address - sorry]

> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of Benjamin Kaduk
> Sent: 18 September 2020 21:22
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Dots] AD review of draft-ietf-dots-server-discovery-10

Thanks for this,

I have implemented this (for both DOTS client r and Call Home DOTS server)
as IP-Address Domain DHCP S-NAPTR DNS-SD And one or more of these can be
defined, so providing a search order.

I will try to address the more technical comments that you raised as some of
these may have been triggered by doing the above work.  For the sake of
brevity, I am skipping over the nits which can be addressed by the authors.

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

Interesting question - DNS has a TTL - should we be enforcing a refresh here
as well?
- my implementation does not do this at present

> allocated port numbers such importance in selecting the peer address 
> to use.

We do need a method for differentiation between whether the address is for a
DOTS server or Call Home Dots client.

> this scheme ends up being safe, and am hoping that you have a head 
> start over me on doing the analysis :)

I don't immediately recall the rational for this, but if both are returned
there needs to be a preference for one of them and  think that
OPTION_V6_DOTS_ADDRESS is the priority.  It is conceivable that the
OPTION_V6_DOTS_RI, when resolved, may point to an address that is not in the
local domain (i.e. traffic needs to go via a DOTS gateway rather than direct
to a DOTS server).

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

5.1.1. implies that that there can only be a singular dots-agent-name, so I
would go for "ignore the whole thing as malformed" (but raise an alert that
there is a misconfiguration).

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

I think that this was down to NAT being more likely in V4, and so the IP
addresses take preference over the domain name returned.  That said, I guess
V6 could be a MUST as well.

I do recall that I had issues with the DHCP client (Centos) for V4 - where I
could not just ask for these options and get back a sensible response -
there was an inherent assumption that it would normally be used for getting
the DHCP IP/Name etc for the requesting interface, not for just requesting
the information of some remote object.  This was not an issue for V6.  It
maybe that I had to provide both options for it to work - I need to go back
and test this out at some point.

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

My understanding was that we need to start with a seed domain that needs to
be 'acquired' from somewhere.  The standard domain that is allocated to a
device may not be the same domain that handles the DOTS S-NAPTR - hence
OPTION_V(4|6)_DOTS_RI responses can be used to get the DOTS relevant domain.

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

I firmed up on the final version of this after many failing attempts to get
things right and working!

Regards

Jon

---

From: <[email-masked]>
Date: Mon, 21 Sep 2020 14:23:05 +0000

Hi Ben, 

Thank for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : vendredi 18 septembre 2020 22:22
> À : [email-masked]
> Cc : [email-masked]
> Objet : AD review of draft-ietf-dots-server-discovery-10
> 
> 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.

[Med] We used TBA1/TBA2 in the core text for the codes to be assigned for DHCPv6. Fixed the IANA section, though.  

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

[Med] Works for me. Thanks. 

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

[Med] Fixed.

> nit: (also, this sentence is fairly long, though not necessarily

[Med] Will consider splitting it. 

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

[Med] Indeed. 

> nit: comma here, rather than semicolon.

[Med] OK. 

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

[Med] Went for "one of".

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

[Med] That is normal. As the discovery does not require knowing about how the signals are working.  

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

[Med] Fixed. 

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

[Med] OK

>       provider provisioned to a DOTS client into IP address(es)

[Med] ACK.

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

[Med] Done. 

> nit: s/Leveraging on/Leveraging/

[Med] Ack.

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

[Med] Change to "Leveraging existing protocol behaviors that do not require specific feature on the node embedding the DOTS client may ease DOTS deployment."

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

[Med] Indeed.

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

[Med] Will split to ease the readability. 

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

[Med] I deleted "an automation system".

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

[Med] Yes. Changed to "proper DNS configuration".

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

[Med] ACK.

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

[Med] This is generic.  

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

[Med] I don't know how "few" ended there, but you are right.  

>    used to fed the DOTS server selection procedure or to provide

[Med] Ack.

> nit: "address selection procedure"

[Med] Ack. 

> allocated port numbers such importance in selecting the peer address

[Med] We need to demux call-home from the base signal channel. We have text in the call home draft to explain this. We can point the reviewers to that section. 

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

[Med] Because we don't have a section to cite. There is only a list discussed in 5.10 but we don't only need one name. 

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

[Med] Actually, we want to avoid the aliasing issues discussed in RFC7227#section-7 (the resolution may lead to different addresses if the logic for binding a client to server is not visible to "public" resolvers). 

When OPTION_V6_DOTS_ADDRESS is configured, then it takes precedence. The client must not try to resolve the OPTION_V6_DOTS_RI. 

  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 :)

[Med] Returning both the address and the RI in the DHCP prevents redirecting a client to a "fake" server if the DNS queries are intercepted. We don't have this issue if both the address and the RI are returned in DHCP. 

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

[Med] deleted "option". 

> whole thing as malformed?

[Med] If the message is ignored, the service won't be provided. 

> looks relevant here.  Was perhaps a different document intended?

[Med] It used to be "Section 8 of 3315", but since 3315 was obsoleted by 8415, it should read "Section 10 of 8415". Good catch. Thanks. 

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

[Med] OK.

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

[Med] I see your point but the figure uses the convention used in many other dhc wg document. I will leave it. Bernie (dhc co-chair)  reviewed the dhcp part of the document and he didn't raise a comment about this.  

> structure for the figure, instead of keeping with the "traditional"
> DHCP option diagrams.

[Med] At least, Bernie didn't complain when he reviewed the document. 

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

[Med] Because we start the v4 text with "To discover a peer DOTS agent,". We could align both, though. 

> section we say that this is a concatenation-requiring option.

[Med] Agree. 

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

[Med] The validation is basically check it follows Section 3.1 of [RFC1035] and compression is not used.  

> only in 5.1.3; it seems like it would also apply here.

[Med] Indeed. 

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

[Med] Sure. 

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

[Med] S-NAPTR lookups is covered by "... to a name resolution library". Nevertheless, some deployments may not require S-NAPTR lookups and A/AAAA resolution would be just fine.    

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

[Med] Fixed. 

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

[Med] Went for "the appropriate application service". 

> priority" mechanism's results with the same capabilities).

[Med] Good point. I added the folliwng: 

"An attacker may block some protocol messages (e.g., DHCP) to force the client to use a discovery mechanism with a lower priority. The security implications of such attack are those inherent to the fallback discovery mechanism discussed in the following subsections. "

> interface and address family, and that bad things can happen if you
> use a result from one interface for traffic from a different
> interface.

[Med] We can add the following: 

"The results of the discovery procedure are a function of the interface/address family. Contacting a discovered DOTS server via an interface to which it is not bind may exacerbate the delay required to establish a DOTS channel. Moreover, such behavior may reveal that a DOTS service is enabled by a DOTS client domain and exposes the identity of the DOTS service provider (that can be inferred from the name and the destination IP address) to external networks."

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

[Med] The NEW text above touched on "privacy". I'm not sure what we need to say more. 

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

[Med] Good point. Will update the text. 

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

[Med] Will let them as they are. Let's see if we will get comments on this. 

> -Ben

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 22 Sep 2020 13:16:21 +0000

Hi Ben, all, 

FWIW, a candidate version is available at: 
https://github.com/boucadair/draft-ietf-dots-discovery/blob/master/draft-ietf-dots-server-discovery.txt

The diff can be seen here: https://github.com/boucadair/draft-ietf-dots-discovery/commit/1fd6b52c9347ea8e59005533b175b62ea6928237 

Cheers,
Med

> De : [email-masked]
> [mailto:[email-masked]]
> Envoyé : lundi 21 septembre 2020 16:23
> À : Benjamin Kaduk <[email-masked]>; draft-ietf-dots-server-
> [email-masked]
> Cc : [email-masked]
> Objet : RE: AD review of draft-ietf-dots-server-discovery-10
> 
> Hi Ben,
> 
> Thank for the review.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : vendredi 18
> > septembre 2020 22:22 À : draft-ietf-dots-server-
> [email-masked]
> > Cc : [email-masked]
> them
> > to refer to the port assignments from the signal channel and call
> home
> [Med] We used TBA1/TBA2 in the core text for the codes to be
> assigned for DHCPv6. Fixed the IANA section, though.
> 
> >
> > Abstract
> >
> really
> >    o  Many use cases discussed in [I-D.ietf-dots-use-cases] do
> involve
> > a
> >       providers may even be considered.  It is intuitive to
> leverage
> > on
> >
> it
> > a little hard to understand what's going on.  Are the initial
> > "features"
> [Med] Change to "Leveraging existing protocol behaviors that do not
> require specific feature on the node embedding the DOTS client may
> ease DOTS deployment."
> 
> >
> > Section 4
> >
> > nit: "ability" and "to be able to" are redundant (I suggest s/to
> be
> > able
> > to/to/)
> 
> [Med] Indeed.
> 
> >
> > 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
> >           The DOTS client attempts to discover DOTS server(s)
> names
> > and/
> >       "few certification authorities issue server certificates
> based
> > on
> >       at 2001:db8:122:300::2.  The DHCP server will then return
> one
> > DOTS
> >       client.  That list is passed to the DOTS client (or Call
> Home
> > DOTS
> >       2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS
> server
> > (or
> >       Call Home DOTS client).
> >
> [Med] We need to demux call-home from the base signal channel. We
> have text in the call home draft to explain this. We can point the
> reviewers to that section.
> 
> >
> > Section 5.1.2
> >
> [Med] Because we don't have a section to cite. There is only a list
> discussed in 5.10 but we don't only need one name.
> 
> >
> > Section 5.1.3
> >
> itself,
> > addresses in OPTION_V6_DOTS_ADDRESS?
> 
> [Med] Actually, we want to avoid the aliasing issues discussed in
> RFC7227#section-7 (the resolution may lead to different addresses if
> the logic for binding a client to server is not visible to "public"
> resolvers).
> 
> When OPTION_V6_DOTS_ADDRESS is configured, then it takes precedence.
> The client must not try to resolve the OPTION_V6_DOTS_RI.
> 
>   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 :)
> 
> [Med] Returning both the address and the RI in the DHCP prevents
> redirecting a client to a "fake" server if the DNS queries are
> intercepted. We don't have this issue if both the address and the RI
> are returned in DHCP.
> 
> >
> [Med] It used to be "Section 8 of 3315", but since 3315 was
> obsoleted by 8415, it should read "Section 10 of 8415". Good catch.
> Thanks.
> 
> >
> > Section 5.2.1
> >
> understanding
> >      The values s1, s2, s3, etc. represent the domain name labels
> in
> > the
> >      domain name encoding.
> >
> bytes
> > of the DHCP option, but this wording implies that we are naming
> > labels, which are multi-byte (except for the root).
> 
> [Med] I see your point but the figure uses the convention used in
> many other dhc wg document. I will leave it. Bernie (dhc co-chair)
> reviewed the dhcp part of the document and he didn't raise a comment
> about this.
> 
> >
> > Section 5.2.2
> >
> say
> > much explicitly about a "validation procedure".
> 
> >        and address family.  A DOTS agent has to determine the
> domain
> > in
> I'm
> "the
> [Med] S-NAPTR lookups is covered by "... to a name resolution
> library". Nevertheless, some deployments may not require S-NAPTR
> lookups and A/AAAA resolution would be just fine.
> 
> >
> >    peer DOTS agent name that needs to be resolved (e.g., Section
> 5),
> > an
> >
> "An attacker may block some protocol messages (e.g., DHCP) to force
> the client to use a discovery mechanism with a lower priority. The
> security implications of such attack are those inherent to the
> fallback discovery mechanism discussed in the following subsections.
> "
> 
> >
> "The results of the discovery procedure are a function of the
> interface/address family. Contacting a discovered DOTS server via an
> interface to which it is not bind may exacerbate the delay required
> to establish a DOTS channel. Moreover, such behavior may reveal that
> a DOTS service is enabled by a DOTS client domain and exposes the
> identity of the DOTS service provider (that can be inferred from the
> name and the destination IP address) to external networks."
> 
> >
> considerations
> >    The primary attack against the methods described in Section 6
> is
> > one
> the
> > 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.
> 
> 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.)
> >
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 27 Sep 2020 12:48:41 -0700

Hi Med,

Thanks for the responses (and the follow-up link to the staged changes).
Just covering the remaining topics inline; this generally looks good.

[...]
> [Med] Will split to ease the readability. 

Thanks, it looks a lot better.

[...]
> [Med] We need to demux call-home from the base signal channel. We have text in the call home draft to explain this. We can point the reviewers to that section. 

Okay, we can see if that is persuasive enough to convince the reviewers.

> When OPTION_V6_DOTS_ADDRESS is configured, then it takes precedence. The client must not try to resolve the OPTION_V6_DOTS_RI. 

Thanks for the reference+discussion.  (I might say that we still have the
aliasing, but we try to forestall the negative consequences by defining a
specific priority order of processing.)

> [Med] Returning both the address and the RI in the DHCP prevents redirecting a client to a "fake" server if the DNS queries are intercepted. We don't have this issue if both the address and the RI…

I think my main concern here is that we get back a name to use for
authenticating the resulting connection, but then are told to not use our
normal procedure for establishing a secure connection to a named entity.
In theory the PKI structure should protect the communication no matter how
we decide to establish the connection (we trust the CA and the name is
certified by the trusted CA chain), but this kind of short-circuiting can
make some classes of attack easier -- if an attacker can get a fraudulently
issued cert, this mechanism lets them send the victim directly to the
attacker's machine without needing to also adjust the DNS/resolution path
on the victim.  Your example of a split-DNS case seems apt, but we should
probably mention the loss of "defense in depth" against mis-issued
certificates in the security considerations.

Which risk is more concerning (DNS spoofing vs. mis-issued cert) will
probably depend on the deployment specifics, including DNSSEC (non)usage,
so we will probably just have to document the tradeoff.

> [Med] I see your point but the figure uses the convention used in many other dhc wg document. I will leave it. Bernie (dhc co-chair)  reviewed the dhcp part of the document and he didn't raise a co…

Okay, thanks.  I only took a narrow view into previous DHCP documents, so
he would have a better sense for what is current.

> "An attacker may block some protocol messages (e.g., DHCP) to force the client to use a discovery mechanism with a lower priority. The security implications of such attack are those inherent to the…

Thanks for adding the mention of forcing a lower priority; I think I'll
need to reread the whole thing in context to see if I want to have anything
else mentioned here.

> [Med] The NEW text above touched on "privacy". I'm not sure what we need to say more. 

The one I had in mind when writing the above was "if you put the
name/address of your DOTS server/call-home-client in DHCP or DNS, people
with access to that DNS/DHCP can find out the name/address of your DOTS
server/call-home-client", which is both (1) hopefully obvious and (2)
may not be particularly sensitive information, though I guess the DOTS
server might be an interesting DDOS target itself...

Thanks.

> [Med] Will let them as they are. Let's see if we will get comments on this. 

Sounds good.

If you could try to add a mention of the "attacker-supplied IP addresses
makes it easier to use a mis-issued certificate" case to the security
considerations and publish the new version, it sounds like this will be
ready for IETF LC.

Thanks again,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 27 Sep 2020 12:53:32 -0700

Hi Jon,

Thanks for ths implementation insight (I reply to the original message that
has the complete list of mechanisms you implemented, presumably in priority
order).

A few notes inline.

On Mon, Sep 21, 2020 at 10:51:27AM +0100, Jon Shallow wrote:
> as
> IP-Address
> Domain
> DHCP
> S-NAPTR
> DNS-SD
> And one or more of these can be defined, so providing a search order.
> 

I see Med added mention of TTL in the staged changes, which helps clue in
the reader.  I don't know whether we specifically need to mandate a
refresh, since that is probably covered by the core DNS specs (not that
they are an easy read to digest...)

> DOTS server or Call Home Dots client.

Definitely.  They tend to try to push people to use a dynamic
port-discovery mechanism and avoid assuming that a registered port is used
for the registered use, but I don't have great insight into the specific
considerations there, so we may have to wait and see.

> there is a misconfiguration).

Med noted that rejecting it would prevent receiving the requested service.
This is hopefully an exceptional case, so presumably would not matter too
much, and is just a tradeoff on strict compliance vs runtime resiliance
(roughly speaking, the Postel principle).

Thanks again,

Ben

---

From: <[email-masked]>
Date: Mon, 28 Sep 2020 06:48:18 +0000

Hi Ben, 

Thank you for checking.

This is now fixed in the updated version. A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-11

Cheers,
Med

> Envoyé : dimanche 27 septembre 2020 21:49
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]; [email-masked]
> Objet : Re: AD review of draft-ietf-dots-server-discovery-10
> 
> Hi Med,
> 
> have
> authenticating the resulting connection, but then are told to not
> use our normal procedure for establishing a secure connection to a
> named entity.
> In theory the PKI structure should protect the communication no
> matter how we decide to establish the connection (we trust the CA
> and the name is certified by the trusted CA chain), but this kind of
> short-circuiting can make some classes of attack easier -- if an
> attacker can get a fraudulently issued cert, this mechanism lets
> them send the victim directly to the attacker's machine without
> needing to also adjust the DNS/resolution path on the victim.  Your
> example of a split-DNS case seems apt, but we should probably
> mention the loss of "defense in depth" against mis-issued
> Which risk is more concerning (DNS spoofing vs. mis-issued cert)
> will probably depend on the deployment specifics, including DNSSEC
> (non)usage, so we will probably just have to document the tradeoff.
>