Subject: [OPSAWG] DNS Name resolution in https://tools.ietf.org/html/draft-ietf-opsawg-mud-06

From: "Ranganathan, Mudumbai (Fed)" <[email-masked]>
Date: Wed, 5 Jul 2017 18:56:30 +0000

Hello,

I am reading the MUD profile draft

https://tools.ietf.org/html/draft-ietf-opsawg-mud-06#page-18

I have a few questions regarding DNS name resolution:

Clearly the resolution of the DNS name depends on the DNS server which can return a different address every time it is queried (for example for load balancing). Is it required that the MUD controller be aware of the name resolution as seen by the device? (i.e. does it have to be aware of DNS lookups done by the device?)

If the IP address used by the device can be reverse resolved to the DNS name in the mud profile without the device doing an explicit DNS lookup, whereas the MUD profile specifies a name that could have been resolved to the IP address that the device looked up, is that a allowable behavior?

The DNS names specified in the document are FQDN host name and port.

Is there a use case for an IOT device looking up a service record (e.g. email server address or voip server address for a domain) ?

I hope I have not missed anything. Thank you in advance for any clarifications.

Ranga.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Jul 2017 22:50:06 +0200

Hi!

Thanks for your comments.

On 7/5/17 8:56 PM, Ranganathan, Mudumbai (Fed) wrote:
> Clearly the resolution of the DNS name depends on the DNS server which
> can return a different address every time it is queried (for example
> for load balancing). Is it required that the MUD controller be aware
> of the name resolution as seen by the device? (i.e. does it have to be
> aware of DNS lookups done by the device?)

In the architecture it will depend on where policy enforcement is
performed, but wherever that is, a current mapping is best.  There are
numerous ways to do that, one of which is just to snoop DNS, another of
which is to provide the name server, a third would be to provide a
communication path between the name server and the enforcement point.
>
> If the IP address used by the device can be reverse resolved to the
> DNS name in the mud profile without the device doing an explicit DNS
> lookup, whereas the MUD profile specifies a name that could have been
> resolved to the IP address that the device looked up, is that a
> allowable behavior?

I wouldn't use that approach personally because I would find it
unreliable.  Reverse lookups are unreliable, especially in the cloud use
case.
> The DNS names specified in the document are FQDN host name and port.
That shouldn't be the case- a dns name should be just an FQDN.  Not a port.

>
> Is there a use case for an IOT device looking up a service record
> (e.g. email server address or voip server address for a domain) ?

This depends on the mechanism, but certainly the same approach as above
can be used.  Note- MX records lead to an A/AAAA record query.  Same
with SRV records.

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 5 Jul 2017 20:09:53 -0400

Thank you for your reply. More  questions below.

On Jul 5, 2017 4:50 PM, "Eliot Lear" <[email-masked]> wrote:

Hi!

Hello,

Clearly the resolution of the DNS name depends on the DNS server which can
return a different address every time it is queried (for example for load
balancing). Is it required that the MUD controller be aware of the name
resolution as seen by the device? (i.e. does it have to be aware of DNS
lookups done by the device?)

If the IP address used by the device can be reverse resolved to the DNS
name in the mud profile without the device doing an explicit DNS lookup,
whereas the MUD profile specifies a name that could have been resolved to
the IP address that the device looked up, is that a allowable behavior?

Thus, for the proposed scheme to work, IF the device does  DNS lookup the
ACE must specify DNS names. Or put another way, if the device directly use
addresses, then the mud profile for the device should also specify
addresses in the ACE.

Sorry - I meant the enhanced ACE specifies a FQDN and port.

Is there a use case for an IOT device looking up a service record (e.g.
email server address or voip server address for a domain) ?

This depends on the mechanism, but certainly the same approach as above can
be used.  Note- MX records lead to an A/AAAA record query.  Same with SRV
records.

Correct and therefore the ACE  can presumably just specify a service such
as voip.company.com  (no port) which would recursively resolve to some host
name and port. Is that allowed In your enhanced ACL?

How do you propose to handle dynamic port assignments (for example in voip
call setups ) or is that out of scope  ?

Eliot

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Eliot Lear <[email-masked]>
Date: Thu, 6 Jul 2017 06:38:41 +0200

Hi again!

Trimming:

On 7/6/17 2:09 AM, M. Ranganathan wrote:

> Thus, for the proposed scheme to work, IF the device does  DNS lookup
> the ACE must specify DNS names. Or put another way, if the device
> directly use addresses, then the mud profile for the device should
> also specify addresses in the ACE.

Yes.  The key point is that the MUD file should be appropriate for the
operation of a given device.  Remember, the envisaged usage case is a
device connecting to the cloud, and that the means by which scale is
achieved is through the usual DNS-based load balancing, at least at
first blush.  That doesn't eliminate the possibility of using
addresses.  However, I would generally DISCOURAGE addresses in MUD
files, to the extent possible, because it is rare that a single or small
number of addresses will scale.  I have already seen some cases where a
block of IP addresses is used, and thus in the default free zone.  That
has routing implications, and costs more money (you need an address
block, and in the context of IPv4 that could really run a bill).

>     unreliable.  Reverse lookups are unreliable, especially in the
>     cloud use case.
>>

Sure.  This is all based on the ACL model.
>     This depends on the mechanism, but certainly the same approach as
>     above can be used.  Note- MX records lead to an A/AAAA record
>     query.  Same with SRV records.
>
>
> Correct and therefore the ACE  can presumably just specify a service
> such as voip.company.com <http://voip.company.com>  (no port) which
> would recursively resolve to some host name and port. Is that allowed
> In your enhanced ACL?
The host, yes.  The port, no.  The DNS name approach is primarily
focused on A/AAAA records.  For a MUD file in such circumstances I would
likely leave out the port.  It's slightly broader exposure, but if the
host at the other end is compromised, adding the port probably isn't
going to save you.

>
> How do you propose to handle dynamic port assignments (for example in
> voip call setups ) or is that out of scope  ?
>

For the moment it's out of scope, but I have some ideas which I will
share in due course.

Eliot