Subject: [Dots] draft-boucadair-dots-server-discovery: Roland's comment

From: <[email-masked]>
Date: Fri, 21 Jul 2017 06:29:44 +0000

Hi Roland,

You made the following comments during the DOTS session:

1. Break out explicit configuration into local/manual and dynamic configuration. I reconfirm my answer. The current draft already follows that approach (see the excerpt below):

==
   1.  Explicit configuration:

       *  Local/Manual Configuration: A DOTS client, by default, will
          learn the DOTS server(s) by means of local or manual DOTS
          configuration (i.e., DOTS servers configured at the system
          level).  Configuration discovered from a DOTS client
          application is considered as local configuration.  An
          implementation may give the user an opportunity (e.g., by
          means of configuration file options or menu items) to specify
          DOTS server(s) for each address family.

       *  DHCP: The DOTS client attempts to discover DOTS server(s)
          names from DHCP by including a DOTS option code in the Option
          Request for IPv6 and Parameter Request List Option for IPv4,
          respectively.

==

2. Shorten the list to focus on the above two means: I hear this comment. I would really appreciate if other WG participants share their thoughts on this before making changes to the draft (e.g., is there an interest to specify how DNS-SD/mDNS can be used for automatic DOTS discovery, whether the group sees a value in reserving a anycast address for DOTS usage).

Cheers,
Med

---

From: "Russ White" <[email-masked]>
Date: Fri, 21 Jul 2017 03:48:41 -0400

2. Shorten the list to focus on the above two means: I hear this comment. I
> would really appreciate if other WG participants share their thoughts on this
> before making changes to the draft (e.g., is there an interest to specify how
> DNS-SD/mDNS can be used for automatic DOTS discovery, whether the group
> sees a value in reserving a anycast address
> for DOTS usage).

DNS should be useable for discovery, as well as having anycast address. We cannot assume the DHCP case -- we also need to consider a box with a manually configured address that needs to find a DOTs server, and the entire SLAAC environment, among others.

😊

Russ

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 21 Jul 2017 07:54:46 +0000

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Russ White
> Sent: Friday, July 21, 2017 1:19 PM
> To: [email-masked]; 'Dobbins, Roland'
> <[email-masked]>; [email-masked]
> Subject: Re: [Dots] draft-boucadair-dots-server-discovery: Roland's comment
> 
> 
> > would really appreciate if other WG participants share their thoughts
> > on this before making changes to the draft (e.g., is there an interest
> > to specify how DNS-SD/mDNS can be used for automatic DOTS discovery,
> > whether the group sees a value in reserving a anycast address for DOTS
> > usage).
> 
> DNS should be useable for discovery, as well as having anycast address. 

Yup. Excluding windows, I don't think any POSIX standard nor any OS vendor has offered a generic facility to access information 
made available in DHCP packets.  DNS-SD/mDNS will be useful in scenarios where browser, application server act as DOTS client. 

-Tiru

> We
> cannot assume the DHCP case -- we also need to consider a box with a
> manually configured address that needs to find a DOTs server, and the entire
> SLAAC environment, among others.
> 
> 😊
> 
> Russ
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Dave Dolson <[email-masked]>
Date: Fri, 21 Jul 2017 08:03:19 +0000

I think it might make sense to split this from the dots spec. E.g., add a distinct doc for "Provisioning dots server with DHCP/RA"

In the dots spec, assume the dots server is known by the client.

David Dolson
Sandvine
  Original Message
From: Konda, Tirumaleswar Reddy
Sent: Friday, July 21, 2017 9:56 AM
To: Russ White; [email-masked]; 'Dobbins, Roland'; [email-masked]
Subject: Re: [Dots] draft-boucadair-dots-server-discovery: Roland's comment

-Tiru

---

From: <[email-masked]>
Date: Fri, 21 Jul 2017 09:51:28 +0000

Hi Russ,

Thank you for the feedback. 

I interpret your answer as being in favor of the current approach in the draft: https://tools.ietf.org/html/draft-boucadair-dots-server-discovery-02#section-5 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Russ White
> Envoyé : vendredi 21 juillet 2017 09:49
> À : BOUCADAIR Mohamed IMT/OLN; 'Dobbins, Roland'; [email-masked]
> Objet : Re: [Dots] draft-boucadair-dots-server-discovery: Roland's comment
> 
> 
> DNS should be useable for discovery, as well as having anycast address. We
> manually configured address that needs to find a DOTs server, and the
> entire SLAAC environment, among others.
> 
> 😊
> 
> Russ
>

---

From: <[email-masked]>
Date: Fri, 21 Jul 2017 09:53:56 +0000

Re-,

Agree with your comment about DHCP and its applicability for hosts. 

As you know, DHCP in this I-D is mainly targeting the CPE case. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : vendredi 21 juillet 2017 09:55
> À : Russ White; BOUCADAIR Mohamed IMT/OLN; 'Dobbins, Roland';
> [email-masked]
> Objet : RE: [Dots] draft-boucadair-dots-server-discovery: Roland's comment
> 
> Yup. Excluding windows, I don't think any POSIX standard nor any OS vendor
> has offered a generic facility to access information
> made available in DHCP packets.  DNS-SD/mDNS will be useful in scenarios
> where browser, application server act as DOTS client.
> 
> -Tiru
> 
> > We

---

From: <[email-masked]>
Date: Fri, 21 Jul 2017 09:57:39 +0000

Re-,

Agree. This is exactly why we have this draft.

One comment about RA, there is an objection from the IPv6 community to duplicate DHCP functionality in RA.

I suggest we don't go that way. 

Cheers,
Med

> De : Dave Dolson [mailto:[email-masked]]
> Envoyé : vendredi 21 juillet 2017 10:03
> À : Konda, Tirumaleswar Reddy; Russ White; BOUCADAIR Mohamed IMT/OLN;
> 'Dobbins, Roland'; [email-masked]
> I think it might make sense to split this from the dots spec. E.g., add a
> distinct doc for "Provisioning dots server with DHCP/RA"
>

---

From: "Russ White" <[email-masked]>
Date: Mon, 24 Jul 2017 07:58:26 -0400

> I interpret your answer as being in favor of the current approach in the draft:
> https://tools.ietf.org/html/draft-boucadair-dots-server-discovery-
> 02#section-5

Broadly, yes -- I think the wording might want to be "helped along" a bit, however, in a couple of specific areas. 

In bullet point 1, I'm not certain what you mean by "by default..." This seems to expect that every device will have a manual configuration, and the remainder are "just" fallback mechanisms... And yet, the text below says, in effect, a DOTS client can use, or not use, any of these. This doesn't sound like there is a "default" method... I think here I would just take the implication that manual configuration is the "default" out of the text, especially as I suspect most operators are going to prefer some automated form of configuration. 

The numbered list seems to imply an order, as does the text above the numbered list, but one of the paragraphs below clearly states no order is implied. I think this might be a nod at either giving a precedence to one method or another, but this is not called out in the text... I think I would re organize this to be somewhat different. Maybe something like this --

==
A key point in the deployment of DOTS is the ability of network operators to be able to configure DOTS clients with the correct server information consistently. To accomplish this, operators will need a consistent set of ways in which DOTS clients can discover this information, and a consistent priority among these options. If some devices prefer manual configuration over DNS discovery, while others prefer DNS discovery over manual configuration, the result will be a process of "whack-a-mole," where the operator must find devices that are using the wrong DOTS server, determine how to ensure the devices is configured properly, and then reconfigure the device through the preferred method.

All DOTS clients MUST at least one of the four mechanisms below to determine a DOTS server list. All DOTS clients SHOULD implement all four, or as many as are practical for any specific device, of these ways to discover DOTS servers, in order to facilitate the deployment of DOTS in large scale environments.

1. Manual configuration. The DOTS client may be manually configured through an automation system (or a local CLI, though this is less preferred), with a list of DOTS servers to contact. These MAY be specified either as IP addresses or the DNS name of a DOTS server.

2. DHCP. The DOTS client attempts to discover DOTS server name(s) from DHCP, as described below.

3. DNS SD. The DOTS client attempts to discover DOTS server name(s) using DNS service discovery, as described below. 

4. Anycast. Send DOTS request to establish a DOTS session with the assigned DOTS server anycast address for each combination of interface and address family.

Some of these mechanisms imply the use of DNS to resolve the IP address of the DOTS server, while others imply the IP address of 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. Operators SHOULD, therefore, deploy at least two way for clients to discover an authoritative DOTS server in their domain, so devices of both types will operate properly.

Clients will prefer information received from the discovery methods in the order listed; i.e. manually configured servers will be preferred over servers learned through DHCP, etc.
==

There is some confusion here on the DNS bits of the discovery process that probably needs to be cleared up. IMHO, it's important to allow a DOTS client to discover servers without needing DNS configured locally. Not all clients may have DNS running or configured.

I also tend to think there needs to be a "happy eyeballs" section here someplace. Servers running v6 should be preferred over servers running v4, with a fallback timer, probably the same one used in the happy eyeballs drafts.

😊

Russ

---

From: <[email-masked]>
Date: Mon, 24 Jul 2017 13:07:36 +0000

Hi Russ, 

Please see inline. 

Cheers,
Med

> De : Russ White [mailto:[email-masked]]
> Envoyé : lundi 24 juillet 2017 13:58

[Med] OK. Let's see together how to tweak the text. 

> In bullet point 1, I'm not certain what you mean by "by default..." This
> seems to expect that every device will have a manual configuration, and
> the remainder are "just" fallback mechanisms... And yet, the text below
> says, in effect, a DOTS client can use, or not use, any of these. This
> doesn't sound like there is a "default" method... I think here I would
> just take the implication that manual configuration is the "default" out
> of the text, especially as I suspect most operators are going to prefer
> some automated form of configuration.

[Med] Good catch. 

> 
> The numbered list seems to imply an order, as does the text above the
> numbered list, but one of the paragraphs below clearly states no order is
> implied.

[Med] As stated in the text, no order is assumed. 

 I think this might be a nod at either giving a precedence to one
> method or another, but this is not called out in the text... I think I
> would re organize this to be somewhat different. Maybe something like this

[Med] Thank you for the proposal. 

> --
> 
> ==
> A key point in the deployment of DOTS is the ability of network operators
> to be able to configure DOTS clients with the correct server information
> consistently. To accomplish this, operators will need a consistent set of
> ways in which DOTS clients can discover this information, and a consistent
> priority among these options. If some devices prefer manual configuration
> over DNS discovery, while others prefer DNS discovery over manual

[Med] I guess you meant "dynamic" instead of "DNS discovery". 

> configuration, the result will be a process of "whack-a-mole," where the
> operator must find devices that are using the wrong DOTS server, determine
> how to ensure the devices is configured properly, and then reconfigure the
> device through the preferred method.
> 
> All DOTS clients MUST at least one of the four mechanisms below to
> determine a DOTS server list. All DOTS clients SHOULD implement all four,
> or as many as are practical for any specific device, of these ways to
> discover DOTS servers, in order to facilitate the deployment of DOTS in
> large scale environments.
> 
> 1. Manual configuration. The DOTS client may be manually configured
> through an automation system (or a local CLI, though this is less
> preferred), with a list of DOTS servers to contact. These MAY be specified
> either as IP addresses or the DNS name of a DOTS server.
> 

[Med] I would put the use of "an automation system" in the same level as DHCP. Both provide a dynamic provisioning means. In my mind, "Manual configuration" is more about static configuration.

> DHCP, as described below.

[Med] FWIW, we clarified in -01 of the draft why a name is required. I'm inserting that text here because it was removed from -02:

======
   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 certificates are a very
   small percentage (less than 1%) of issued certificates".  In order to
   allow for PKIX-based authentication between a DOTS client and server,
   this document specifies the DHCP option as a name.  One or multiple
   IP addresses may be returned as a result of name resolution.

   Defining the option to include a list of IP addresses would avoid a
   dependency on an underlying name resolution, but that design requires
   to also supply a name for PKIX-based authentication purposes.

   Because aliasing is to be avoided (Section 7 of [RFC7227]), this
   document specifies one single option that conveys a DOTS server's
   name.
=====

> 
> 3. DNS SD. The DOTS client attempts to discover DOTS server name(s) using
> DNS service discovery, as described below.
> 
> 4. Anycast. Send DOTS request to establish a DOTS session with the
> assigned DOTS server anycast address for each combination of interface and
> address family.
> 
> Some of these mechanisms imply the use of DNS to resolve the IP address of
> the DOTS server, while others imply the IP address of 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. Operators SHOULD, therefore, deploy at least two way for
> clients to discover an authoritative DOTS server in their domain, so
> devices of both types will operate properly.

[Med] I like this. 

> 
> Clients will prefer information received from the discovery methods in the
> order listed; i.e. manually configured servers will be preferred over
> servers learned through DHCP, etc.

[Med]  Preferring local/static configuration over a dynamic one may lead to never using the dynamic configuration in case a new server is deployed or a change occurred. I do agree that explicit configuration should be preferred over the other means (DNS-SD and anycast), but the information that is dynamically retrieved should be preferred over static or manual one. No?      

> ==
> 
> There is some confusion here on the DNS bits of the discovery process that
> probably needs to be cleared up. IMHO, it's important to allow a DOTS
> client to discover servers without needing DNS configured locally. Not all
> clients may have DNS running or configured.

[Med] Agree. But... see above for the implications on DHCP for example.

==
   Defining the option to include a list of IP addresses would avoid a
   dependency on an underlying name resolution, but that design requires
   to also supply a name for PKIX-based authentication purposes.
==

> 
> I also tend to think there needs to be a "happy eyeballs" section here
> someplace. Servers running v6 should be preferred over servers running v4,
> with a fallback timer, probably the same one used in the happy eyeballs
> drafts.
> 

[Med] We already have this discussed as part of the DOTS signal channel: 
https://tools.ietf.org/html/draft-ietf-dots-signal-channel-02#section-4

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 26 Jul 2017 13:41:22 +0900

I agree.

Kaname

---

From: "Russ White" <[email-masked]>
Date: Wed, 26 Jul 2017 17:41:38 -0400

> > A key point in the deployment of DOTS is the ability of network
> > operators to be able to configure DOTS clients with the correct server
> > information consistently. To accomplish this, operators will need a
> > consistent set of ways in which DOTS clients can discover this
> > information, and a consistent priority among these options. If some
> > devices prefer manual configuration over DNS discovery, while others
> > prefer DNS discovery over manual
> 

Yes, this is right.

> [Med] I would put the use of "an automation system" in the same level as
> DHCP. Both provide a dynamic provisioning means. In my mind, "Manual
> configuration" is more about static configuration.

Well, it depends... 😊 For some folks, "manual configuration" is automated. This is a very cloudy area.... I'm fine with putting them on the same level, however.

> [Med] FWIW, we clarified in -01 of the draft why a name is required. I'm
> inserting that text here because it was removed from -02:

Hmmm... So this means that DOTS _cannot_ work without DNS -- I don't know that this is a "good" dependency to put in place, especially if it is implicit, rather than explicit. For one thing, it means that if the attacker can take DNS access out of play, then DOTS is no longer useable. For another, there are many situations where DOTS is going to be useful where DNS cannot be deployed. So -- this needs to be clarified, to me --

Is it possible to run DOTS without DNS? OR must every client have an operational DNS stack, and be able to reach a DNS server?

More just below --

>    document specifies one single option that conveys a DOTS server's

The point of this text seems to be that if you cannot validate the server with a certificate, then you cannot use the server. But I don't understand why the client should not be similarly situations towards the server... So this means the client must also have a DNS name entry, and that entry must map to the correct IP address, because the client cannot be authenticated otherwise. 

The second point here is -- just because certificates are not offered for IP addresses today does not mean they cannot be. In fact, if I wanted to deploy a lot of devices that could not run DNS, or I didn't want the DNS dependency involved, I could simply build such certificates... So this text disallows a perfectly useable deployment option because "it's not done that way today." This does not seem like a strong line of argument to me.

> > Some of these mechanisms imply the use of DNS to resolve the IP
> > address of the DOTS server, while others imply the IP address of 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. Operators SHOULD, therefore,
> > deploy at least two way for clients to discover an authoritative DOTS
> > server in their domain, so devices of both types will operate properly.
> 
> [Med] I like this.

See above, however -- if a DNS name is _required_, then DOTS is very limited in its usefulness, and this paragraph isn't needed.

> > Clients will prefer information received from the discovery methods in
> > the order listed; i.e. manually configured servers will be preferred
> > over servers learned through DHCP, etc.
> 
> [Med]  Preferring local/static configuration over a dynamic one may lead to
> never using the dynamic configuration in case a new server is deployed or a
> change occurred. I do agree that explicit configuration should be preferred
> over the other means (DNS-SD and anycast), but the information that is
> dynamically retrieved should be preferred over static or manual one. No?

This is actually a catch22 -- if the automatic configuration always overrides any manual configuration, then there is no way to perform manual local troubleshooting. I'm not certain how to resolve this...

> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-02#section-4

Okay.

😊

Russ

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 27 Jul 2017 03:30:02 +0000

Hi Russ,

DNS resolution can be performed during peace time, to avoid the problem of DNS server not being available during a volumetric DDoS attack. I don't think DOTS should recommend server certificates based on IP addresses, see https://tools.ietf.org/html/rfc6125.  In case of manual configuration, DOTS client can be configured with the DOTS server IP addresses and SPKI fingerprint (hash of the DOTS server public key) and there is still no need to generate DOTS server certificate based on IP address (For example, we have used SPKI fingerprint in https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-10 to validate the DNS server certificate).

The DOTS client may or may not have a DNS name entry, DOTS client can use EST for certificate enrollment (EST server will be provided by the DDoS mitigation provider). 

-Tiru

> Sent: Thursday, July 27, 2017 3:12 AM
> > > operators to be able to configure DOTS clients with the correct
> > > server information consistently. To accomplish this, operators will
> > > need a consistent set of ways in which DOTS clients can discover
> > > this information, and a consistent priority among these options. If
> > > some devices prefer manual configuration over DNS discovery, while
> > > others prefer DNS discovery over manual
> >
> > [Med] I would put the use of "an automation system" in the same level
> > as DHCP. Both provide a dynamic provisioning means. In my mind,
> > "Manual configuration" is more about static configuration.
> 
> Well, it depends... 😊 For some folks, "manual configuration" is automated.
> This is a very cloudy area.... I'm fine with putting them on the same level,
> however.
> 
> > [Med] FWIW, we clarified in -01 of the draft why a name is required.
> > I'm inserting that text here because it was removed from -02:
> 
> Hmmm... So this means that DOTS _cannot_ work without DNS -- I don't
> know that this is a "good" dependency to put in place, especially if it is implicit,
> rather than explicit. For one thing, it means that if the attacker can take DNS
> access out of play, then DOTS is no longer useable. For another, there are
> many situations where DOTS is going to be useful where DNS cannot be
> deployed. So -- this needs to be clarified, to me --
> 
> Is it possible to run DOTS without DNS? OR must every client have an
> operational DNS stack, and be able to reach a DNS server?
> 
> More just below --
> 
> > ======
> The point of this text seems to be that if you cannot validate the server with
> a certificate, then you cannot use the server. But I don't understand why the
> client should not be similarly situations towards the server... So this means
> the client must also have a DNS name entry, and that entry must map to the
> correct IP address, because the client cannot be authenticated otherwise.
> 
> The second point here is -- just because certificates are not offered for IP
> addresses today does not mean they cannot be. In fact, if I wanted to deploy
> a lot of devices that could not run DNS, or I didn't want the DNS dependency
> involved, I could simply build such certificates... So this text disallows a
> perfectly useable deployment option because "it's not done that way today."
> This does not seem like a strong line of argument to me.
> 
> > > 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. Operators SHOULD,
> > > therefore, deploy at least two way for clients to discover an
> > > authoritative DOTS server in their domain, so devices of both types will
> operate properly.
> >
> > [Med] I like this.
> 
> See above, however -- if a DNS name is _required_, then DOTS is very limited
> in its usefulness, and this paragraph isn't needed.
> 
> > > Clients will prefer information received from the discovery methods
> > > in the order listed; i.e. manually configured servers will be
> > > preferred over servers learned through DHCP, etc.
> >
> > [Med]  Preferring local/static configuration over a dynamic one may
> > lead to never using the dynamic configuration in case a new server is
> > deployed or a change occurred. I do agree that explicit configuration
> > should be preferred over the other means (DNS-SD and anycast), but the
> > information that is dynamically retrieved should be preferred over static or
> manual one. No?
> 
> This is actually a catch22 -- if the automatic configuration always overrides any
> manual configuration, then there is no way to perform manual local
> troubleshooting. I'm not certain how to resolve this...
>

---

From: <[email-masked]>
Date: Thu, 27 Jul 2017 06:06:17 +0000

Hi Russ, 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 26 juillet 2017 23:42
> This is a very cloudy area.... I'm fine with putting them on the same
> level, however.

[Med] Deal.

> Hmmm... So this means that DOTS _cannot_ work without DNS

[Med] No, that's more subtle. What it means is that a name is needed for the reason mentioned in that text. Supplying a list of IP addresses together with a name would avoid requiring a resolution library (DNS, for example). In such case, the dependency on the resolution library is not a problem. 

 -- I don't know
> that this is a "good" dependency to put in place, especially if it is
> implicit, rather than explicit. For one thing, it means that if the
> attacker can take DNS access out of play, then DOTS is no longer useable.
> For another, there are many situations where DOTS is going to be useful
> where DNS cannot be deployed. So -- this needs to be clarified, to me --

[Med] See above. For the particular case of DHCP, we could define the option to return both a name and a list of IP addresses, but this is not recommended by dhc wg (referred to as aliasing). We don't have such constraints for in-house automated systems or local configuration. 

> 
> Is it possible to run DOTS without DNS?

[Med] Yes, this is possible. 

 OR must every client have an
> operational DNS stack, and be able to reach a DNS server?

[Med] This is deployment-specific. We need to cover both client with or without resolution libraries.   

> The point of this text seems to be that if you cannot validate the server
> with a certificate, then you cannot use the server. But I don't understand
> why the client should not be similarly situations towards the server... So
> this means the client must also have a DNS name entry, and that entry must
> map to the correct IP address, because the client cannot be authenticated
> otherwise.
> 
> The second point here is -- just because certificates are not offered for
> IP addresses today does not mean they cannot be. In fact, if I wanted to
> deploy a lot of devices that could not run DNS, or I didn't want the DNS
> dependency involved, I could simply build such certificates... So this
> text disallows a perfectly useable deployment option because "it's not
> done that way today." This does not seem like a strong line of argument to
> me.
> 
> See above, however -- if a DNS name is _required_, then DOTS is very
> limited in its usefulness, and this paragraph isn't needed.
> 
> This is actually a catch22 -- if the automatic configuration always
> overrides any manual configuration, then there is no way to perform manual
> local troubleshooting. I'm not certain how to resolve this...

[Med] Manual local troubleshooting can be done, e.g.,
- deactivate the dynamic means to supply configuration data 
- use the latest supplied data
- enable a local configuration parameter so that static configuration overrides dynamic one.

---

From: "Russ White" <[email-masked]>
Date: Thu, 27 Jul 2017 06:52:13 -0400

> DNS resolution can be performed during peace time, to avoid the problem of
> DNS server not being available during a volumetric DDoS attack. I don't think
> DOTS should recommend server certificates based on IP addresses, see
> https://tools.ietf.org/html/rfc6125.  In case of manual configuration, DOTS

So -- to get this straight -- the idea is that either the certificate must be configured along with the IP address, or DNS must be used to resolve the IP address of the server. There is no alternative to provide a client without a DNS stack running a list of IP addresses, and work from this point.

Which makes no sense to me at all. 

This restricts DOTS to a broad, rather incomplete, set of use cases -- and assumes that DNS "at least works once," will not change once it does not work, etc. 

Further, ponder on what this is saying. What is the worst result if the client attaches to a server that cannot be authenticated? The client sends requests for mitigation to a non-server. What is the worst result if a bad actor acts as a client? The client can use the DOTS channel as a new attack surface. And yet... There are much stronger authentication requirements on which server a client attaches to versus which client attaches to a server. This makes no sense to me at all.

AFAICT, DOTS has limited its own usefulness with this move, for no apparent gain. 

If you want to make DOTS useful, and these are really the requirements, then either -

- there MUST be a way to automatically carry certificates in DHCP/etc., not just a name 

- you MUST rule DHCP sorts of configuration out entirely, as there is no way for the DHCP server to know whether or not its client is DNS enabled, DNS settings have been overridden in a way that will cause DOTS not to function, etc.

What is specified right now is a half measure that is going to cause a lot of networks to break, and many hours of troubleshooting and frustration.

😊

Russ

---

From: "Russ White" <[email-masked]>
Date: Thu, 27 Jul 2017 06:53:12 -0400

> - enable a local configuration parameter so that static configuration overrides

You are assuming every implementation will have such a capability -- if this is what is required to make things deployable, then it should be in the requirements that clients MUST have this ability.

😊

Russ

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 27 Jul 2017 11:24:27 +0000

> From: Russ White [mailto:[email-masked]]
> Sent: Thursday, July 27, 2017 4:22 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>;
> [email-masked]; 'Dobbins, Roland' <[email-masked]>;
> [email-masked]
> Subject: RE: [Dots] draft-boucadair-dots-server-discovery: Roland's comment
> 
> 
> > DNS resolution can be performed during peace time, to avoid the
> > problem of DNS server not being available during a volumetric DDoS
> > attack. I don't think DOTS should recommend server certificates based
> > on IP addresses, see https://tools.ietf.org/html/rfc6125.  In case of
> > manual configuration, DOTS
> 
> So -- to get this straight -- the idea is that either the certificate must be
> configured along with the IP address, or DNS must be used to resolve the IP
> address of the server. 

No, IP and reference identifier can be configured (reference identifier is present in PKIX certificate's subjectAltName extension) to match the server certificate.

> There is no alternative to provide a client without a
> DNS stack running a list of IP addresses, and work from this point.
> 
> This restricts DOTS to a broad, rather incomplete, set of use cases -- and
> assumes that DNS "at least works once," will not change once it does not
> work, etc.
> 
> Further, ponder on what this is saying. What is the worst result if the client
> attaches to a server that cannot be authenticated? The client sends requests
> for mitigation to a non-server. What is the worst result if a bad actor acts as a
> client? The client can use the DOTS channel as a new attack surface. And yet...
> There are much stronger authentication requirements on which server a
> client attaches to versus which client attaches to a server. This makes no
> sense to me at all.

No, mutual authentication is mandatory to deal with bad DOTS server and DOTS client.

-Tiru

> - you MUST rule DHCP sorts of configuration out entirely, as there is no way
> for the DHCP server to know whether or not its client is DNS enabled, DNS
> settings have been overridden in a way that will cause DOTS not to function,
> etc.
> 
> What is specified right now is a half measure that is going to cause a lot of
> networks to break, and many hours of troubleshooting and frustration.
> 
> 😊
> 
> Russ

---

From: "Russ White" <[email-masked]>
Date: Thu, 27 Jul 2017 07:36:24 -0400

> No, IP and reference identifier can be configured (reference identifier is
> present in PKIX certificate's subjectAltName extension) to match the server
> certificate.

So there are really only two choices for configuration -

1. Configure the IP address and reference identifier manually on each client
2. Send ONLY a DNS name to the client, and expect the client to have properly function DNS to resolve the rest

There is no way to automatically configure a DOTS client in the absence of correctly operational DNS on the client -- something the server cannot know is true or not. Is there a specific operational or security reason for this limitation?

"Because we don't want to extend DHCP to supply the necessary information" doesn't seem like a good answer to me.

😊

Russ

---

From: <[email-masked]>
Date: Thu, 27 Jul 2017 12:04:01 +0000

Russ, 

* Issues related to DNS dependency are well documented: https://tools.ietf.org/html/rfc7227#section-8 

* In order to avoid such dependency, the first version of the DHCP DOTS option was designed to carry a list of IP address. A name can be configured to a DHCP server which can invoke a resolution library and then return back a list of IP addresses to requesting clients (see for example, https://tools.ietf.org/html/rfc7969#section-7)

* The main target of DHCP is DOTS client embedded in a CPE; those devices support DNS and are provided with DNS server. There is no issue out there. 

* We could design two options for DOTS: one for returning a list of IP addresses and another one to return a name. A client that does not support DNS will ask for a list of IP addresses, while a client with DNS capabilities may include both and let the server decide. Such practice is not recommended by DHC WG:

   Options are said to be aliases of each other if they provide input to
   the same configuration parameter.  A commonly proposed example is to
   configure the location of some new service ("my foo server") using a
   binary IP address, a domain name field, and a URL.  This kind of
   aliasing is undesirable and is not recommended.

Cheers,
Med

> Envoyé : jeudi 27 juillet 2017 13:36
> À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; 'Dobbins,
> Roland'; [email-masked]
> 2. Send ONLY a DNS name to the client, and expect the client to have
> properly function DNS to resolve the rest
> 
> There is no way to automatically configure a DOTS client in the absence of
> correctly operational DNS on the client -- something the server cannot
> know is true or not. Is there a specific operational or security reason
> for this limitation?
>

---

From: "Russ White" <[email-masked]>
Date: Thu, 27 Jul 2017 09:30:20 -0400

> * The main target of DHCP is DOTS client embedded in a CPE; those devices
> support DNS and are provided with DNS server. There is no issue out there.

However -- not everyone uses the provider CPE, and even when they do, they modify the DNS settings. I do, for instance, and have for years. 

> * We could design two options for DOTS: one for returning a list of IP
> addresses and another one to return a name. A client that does not support
> DNS will ask for a list of IP addresses, while a client with DNS capabilities may
> include both and let the server decide. Such practice is not recommended by
> DHC WG:

What the DHC drafts are talking about here is providing the same information in two different forms. With DOTS, this isn't _necessarily_ the same information. First, the IP address list would need to contain the matching reference identifiers, so the information is different in what it contains. Second, it would be perfectly rational for the DNS option and the IP address option to reveal a different list of servers for various reasons. In the normal DHC case, this would be a bug -- in this case, it could well be a feature.

But, ultimately -- if the point is there must be no way to autoconfigure a list of IP addresses with their corresponding reference identifiers, then this needs to be clearly documented in the _discovery_ documentation, rather than being hinted at in a round-a-bout way such that readers need to dig through a set of 4 drafts just to get an idea of how the various pieces interlock. Don't leave open the possibility of something in one draft that is foreclosed in another -- this just leads to confusion down the road, including non-interoperable implementations. 

😊

Russ