Subject: Re: [Mud] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

From: "Panwei (William)" <[email-masked]>
Date: Wed, 23 Sep 2020 09:01:54 +0000

Hi Michael,

This is an very useful and essential draft, I think. The DNS resolving issue may be an important obstacle for deploying MUD solution successfully.

   The simplest successful strategy for translating names is for a MUD
   controller to take is to do a DNS lookup on the name (a forward
   lookup), and then use the resulting IP addresses to populate the
   physical ACLs.
This strategy is simple, but I doubt it can't be called 'successful' as it won't work all the time. You already listed some failure scenarios.

Beyond the considerations in the draft, another method I imagine is to deploy a DNS proxy (but I don't know whether it's practical).
In the residential scenario, the CPE device is usually the MUD controller and the policy enforcement point, and it can also act as a DNS proxy. When the IoT device sends a DNS query it will send to the CPE. And CPE can first filter the unexpected DNS query by comparing the DNS names with the ones defined in the MUD file, then CPE will query the actual DNS server. When the CPE gets the answers from the actual DNS server, it can respond to the IoT devices with the answers and generate the corresponding ACLs as it knows the IP addresses now.
In the enterprise scenario, the MUD controller, the policy enforcement point, and the DNS proxy may be three different devices. The MUD controller gets the MUD file of the IoT device and dispatch the file to the DNS proxy. When the IoT device sends the DNS query to the DNS proxy, the DNS proxy can filter the DNS query as well and then get the answers by querying the real DNS server. After that, the DNS proxy will tell the IP addresses of the DNS names to the MUD controller, and the MUD controller can generate the ACLs and configure the policy enforcement point.
I'm not an DNS expert, and this is a little thought, please don't mind if it's useless.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Wednesday, September 23, 2020 9:30 AM
> To: [email-masked]
> Subject: I-D Action:
> draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : Operational Considerations for use of DNS in IoT
> devices
>         Author          : Michael Richardson
> 	Filename        :
> draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
> 	Pages           : 13
> 	Date            : 2020-09-22
> 
> Abstract:
>    This document details concerns about how Internet of Things devices
>    use IP addresses and DNS names.  The issue becomes acute as network
>    operators begin deploying RFC8520 Manufacturer Usage Description
>    (MUD) definitions to control device access.
> 
>    This document explains the problem through a series of examples of
>    what can go wrong, and then provides some advice on how a device
>    manufacturer can best make deal with these issues.  The
>    recommendations have an impact upon device and network protocol
>    design.
> 
>    {RFC-EDITOR, please remove.  Markdown and issue tracker for this
>    document is at https://github.com/mcr/iot-mud-dns-considerations.git
>    }
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-richardson-opsawg-mud-iot-dns-con
> siderations/
> 
> There is also a HTML versions available at:
> https://www.ietf.org/id/draft-richardson-opsawg-mud-iot-dns-considerati
> ons-03.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-richardson-opsawg-mud-iot-dns-co
> nsiderations-03
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Sep 2020 14:27:41 -0400

Panwei (William) <[email-masked]> wrote:
    > This is an very useful and essential draft, I think. The DNS resolving
    > issue may be an important obstacle for deploying MUD solution
    > successfully.

Thank you.

    mcr> The simplest successful strategy for translating names is for a MUD
    mcr> controller to take is to do a DNS lookup on the name (a forward
    mcr> lookup), and then use the resulting IP addresses to populate the
    mcr> physical ACLs.

    > This strategy is simple, but I doubt it can't be called 'successful' as
    > it won't work all the time. You already listed some failure scenarios.

Okay, so maybe my words are not perfect.  Please suggest some better ones here.

The naive method of using the reverse map never works :-)
(Some people read RFC1034/35 and think that DNS inverse queries are still a thing)

This method is the simplest that can be made to work.
The rest of the document is really about making this method work.

    > Beyond the considerations in the draft, another method I imagine is to
    > deploy a DNS proxy (but I don't know whether it's practical).

I am not sure what you call a DNS proxy.
A recursive DNS server accessed by Do53 effectively proxies and caches all requests.

    > In the residential scenario, the CPE device is usually the MUD
    > controller and the policy enforcement point, and it can also act as a
    > DNS proxy.

    > When the IoT device sends a DNS query it will send to the
    > CPE. And CPE can first filter the unexpected DNS query by comparing the
    > DNS names with the ones defined in the MUD file, then CPE will query
    > the actual DNS server.

Yes, the CPE could look at the DNS queries the device is using, and then
cache them.   Or, when it loads the MUD file, it could do a DNS lookup on all
the names, and cache them.  Then, when the device asks, it is already cached,
and one can be sure that a known IP/name combination is returned.
If it does this DNS lookup on a regular basis (updating the MUD ACLs
implemented in the forwarding plane), then the cache stays warm, and the
rules are accurate.

This is how our implementation worked.

    > When the CPE gets the answers from the actual
    > DNS server, it can respond to the IoT devices with the answers and
    > generate the corresponding ACLs as it knows the IP addresses now.

If you can generate the ACL on demand fast enough, it can work.
Many IoT devices, if DNS seems slow, will switch to 8.8.8.8.
Google Chromecast for instance, always sends to both local and 8.8.8.8 from
what I've read, and uses which ever is faster.

    > In the enterprise scenario, the MUD controller, the policy enforcement
    > point, and the DNS proxy may be three different devices. The MUD
    > controller gets the MUD file of the IoT device and dispatch the file to
    > the DNS proxy. When the IoT device sends the DNS query to the DNS
    > proxy, the DNS proxy can filter the DNS query as well and then get the
    > answers by querying the real DNS server. After that, the DNS proxy will
    > tell the IP addresses of the DNS names to the MUD controller, and the
    > MUD controller can generate the ACLs and configure the policy
    > enforcement point.

Sure, that's essentially correct.
The DNS proxy is just the local recursive resolver.
What counts is that the MUD controller and the IoT device use the same
recursive resolver, and see the same cache.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Panwei (William)" <[email-masked]>
Date: Thu, 24 Sep 2020 02:40:07 +0000

Hi Michael,

> > Beyond the considerations in the draft, another method I imagine is
> > to deploy a DNS proxy (but I don't know whether it's practical).
> 

The DNS proxy I call more likes a middle-box, I think. I mean when the IoT device onboarding, the CPE/Access Point can provision the IoT device with the IP address of the DNS proxy rather than the real DNS server.
 
> > CPE. And CPE can first filter the unexpected DNS query by comparing
> > the DNS names with the ones defined in the MUD file, then CPE will
> > query the actual DNS server.
> 
> cache them.   Or, when it loads the MUD file, it could do a DNS lookup on
> all the names, and cache them.  Then, when the device asks, it is already
> cached, and one can be sure that a known IP/name combination is
> returned.

I think the 'cache' here means a pre-query. But the cached IP/name may be incorrect if the real DNS server changes the answer.
What I suggest is no pre-queries. The IoT device sends a DNS query to the DNS proxy, and the DNS proxy queries the real DNS server. So the DNS proxy can 1) filter the illegal DNS queries which are not defined in the MUD file, and 2) know the DNS answer exactly with the IoT device.

> what I've read, and uses which ever is faster.

The CPE can block the DNS query to 8.8.8.8 and force the IoT device to wait.

> > proxy, the DNS proxy can filter the DNS query as well and then get
> > the answers by querying the real DNS server. After that, the DNS proxy
> > will tell the IP addresses of the DNS names to the MUD controller, and
> > the MUD controller can generate the ACLs and configure the policy
> > enforcement point.
> 

Yes.
Also, I assume the IoT device won't do DNS lookup frequently, so updating the cache each time when the IoT device sends the DNS query can be acceptable.

Regards & Thanks!
Wei Pan

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Sep 2020 10:37:49 +0200

Hi,

> On 23 Sep 2020, at 20:27, Michael Richardson <[email-masked]> wrote:
> 

Either this, or there should be a relationship between the resolver and the AP/switch/firewall/CPE in which appropriate query responses are shared. That might be the better long term approach.  What is key- in order for protection to work, the infrastructure needs to know (1) what names are authorized and (b) their associated addresses.  As important, its understanding must be the same as that of the device that makes the query.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Sep 2020 10:43:22 -0400

> I think the 'cache' here means a pre-query. But the cached IP/name may
    > be incorrect if the real DNS server changes the answer.

That's why an extra layer of proxy is not helpful: it's already present.
No additional middle boxes are needed.

A recursive DNS server caches answers and, in a sense proxies, the question.
It pays attention to the provided TTL, and expires the data when it happens.

The MUD controller needs to know the TTL of all things it looks up, so that
it can look them up again before the TTL expires.
The operator of the service can't update their servers faster than the TTL
anyway (because clients can cache the result), so there won't be any
inconsistency.

A DNS TTL of 0 is permitted however, and either this document needs to recommend
against doing that, or provide some guidance.  I'm not sure what the right
answer yet.

    > What I suggest is no pre-queries. The IoT device sends a DNS query to
    > the DNS proxy, and the DNS proxy queries the real DNS server. So the
    > DNS proxy can 1) filter the illegal DNS queries which are not defined
    > in the MUD file, and 2) know the DNS answer exactly with the IoT
    > device.

I see.
This depends upon the IoT query always travelling via the same path to the
same recursive DNS server.  That's why you've put this proxy in place.
I think that this just introduces an additional single point of failure, when
DNS has already provided redundancy.  That is, it makes DNS less reliable.

Doing the queries when installing the ACLs leverages the resilience rather
than reduces it.

Perhaps, however, the MUD controller should perform the query to all
recursive DNS servers and should merge the results if they are not
identical.

    > The CPE can block the DNS query to 8.8.8.8 and force the IoT device to wait.

It could do that.

    > Yes.
    > Also, I assume the IoT device won't do DNS lookup frequently, so
    > updating the cache each time when the IoT device sends the DNS query
    > can be acceptable.

I agree that this would reduce the DNS lookup frequency.

In the end, either strategy can work, as long as the IoT device can be
convinced to always do DNS queries to a place that the MUD controller knows
about.

Updating the ACLs based upon DNS queries means that there has to be some new
active entity in the DNS lookup path, and this may be much harder to deploy.
For home gateways, it's all degenerate, so both methods are probably
equivalent.  For enteprises, it is not.
DNS recursive services are something which enterprise operators tend to be
reluctant to mess with, as it often have profound effects on the desktop user
experience.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Sep 2020 10:46:36 -0400

> Either this, or there should be a relationship between the resolver and
    > the AP/switch/firewall/CPE in which appropriate query responses are
    > shared. That might be the better long term approach.

So you are imagining some channel from the recursive DNS resolver(s) which
basically just stream all name->IP pairs being cached.
An MQTT channel or encrypted multicast or CoAP Observe.

The policy enforcement point(s) would then be in charge of updating the ACLs
that were installed with names.
One could even hash the names into some number of channels if the update rate
was otherwise too busy.

    > What is key- in
    > order for protection to work, the infrastructure needs to know (1) what
    > names are authorized and (b) their associated addresses.  As important,
    > its understanding must be the same as that of the device that makes the
    > query.

Yes.  The common understanding of the mapping is key.