Subject: [Iotops] Status update on MUD-IoT-DNS-Considerations

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Jul 2021 21:44:22 -0400

Hi, I have submitted draft-ietf-opsawg-mud-iot-dns-considerations.

I thought that I had previously reported on conversations/feedback that
occured from the dnsop WG, at which I presented for IETF110.
(I can't find the message in the archives that I wanted to link to,
perhaps it was just a dream)

The presentation to the DNSOP WG at IETF110 went well, and I think that the
group understood the problem.  The chairs seemed very happy to have people
come to them for advice.

The short of it is that many people in the WG felt that it wouldn't work.
Even if we did all the things that I've suggested
     - the MUD Controller and the IoT device doing the same queries to the
       same DNS server,
     - respecting TTLs in the MUD controller

Due to the unpredictability of cache evictions, one can never be sure that
that the DNS server won't have to make a new query, and get a new geofenced
answer.

I had done some research in preparing this document as to how exactly round
robin DNS worked, back when we started doing that ~25 years ago.
The people in the WG felt that
   a) there was never ever any guarantee that browsers would pick the
      first record to connect to.
   b) that the set of IPs returned in RR-DNS was never the complete set anyway.
      (despite what the spec says)
   c) that modern geo-fenced DNS wasn't going to be consistent... ever.

My takeaway from all of this was that essentially... if geofenced/CDNed DNS
is not gonna for for IoT devices with MUD files... then maybe the advice
about working around them is WRONG.  Maybe the right advice is... DON'T DO THAT.

{ME: Doctor! Doctor! It hurts when I use a geographic CDN!
 Doctor: Don't do that.}

The draft update I just posted tries to clear out a few TODO, but mostly I am
going towards that direction.  Section 6.4... it's pretty weak at this point.

Other than firmware updates, are IoT devices heavy users of geofenced things?
I don't think so, but I could be totally wrong here.

Where I think that maybe it would be relevant is if I were some OTP video
provider, and I sold a tablet designed to do only that.  (or if we get into
per-App MUD files!).
In that case, I might be forced to acceptlist all of my EC3 cloud, and maybe that's okay.

IPv6 could make this significantly easier, since such an entity could
trivially be assigned their own /56 per site, which would be plenty.
Or even their own /40, to announce /48s from each geographic location.

Name:		draft-ietf-opsawg-mud-iot-dns-considerations
Revision:	02
Title:		Operational Considerations for use of DNS in IoT devices
Document date:	2021-07-11
Html:           https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-02.html
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-iot-dns-considerations-02

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Jul 2021 07:39:55 +0200

The key issue is that the new query and resolution has to get picked up 
by the network management system.  So long as that happens, then life is 
good.  This means that the resolver needs to be integrated with the MUD 
manager, but also that the IoT device should also be careful to observe 
caching semantics, particularly in the case of a connection failure. 
Those failures will happen with or without MUD.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jul 2021 06:59:23 -0400

Eliot Lear <[email-masked]> wrote:
    > by the network management system.  So long as that happens, then life
    > is good.   This means that the resolver needs to be integrated with the
    > MUD manager, but also that the IoT device should also be careful to
    > observe caching semantics, particularly in the case of a connection
    > failure.

I agree that having a MUD-aware caching resolver can solve the problem.
It might be practical in some places for the MUD-aware network management
system to control DHCP, and be able to tell the IoT devices what DNS server
to use.
I don't have a problem writing this kind of advice, but it's no longer advice
to the IoT device creator, but the Enterprise operator of the MUD system.

    > Those failures will happen with or without MUD.

Please explain: how do we see inconsistent application of DNS based rules
without MUD?

    >> My takeaway from all of this was that essentially... if
    >> geofenced/CDNed DNS is not gonna for for IoT devices with MUD
    >> files... then maybe the advice about working around them is WRONG.
    >> Maybe the right advice is... DON'T DO THAT.
    >>
    >> {ME: Doctor! Doctor! It hurts when I use a geographic CDN!  Doctor:
    >> Don't do that.}

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Jul 2021 13:41:14 +0200

> Please explain: how do we see inconsistent application of DNS based rules

What I meant in context was that there could be NAT binding timeouts and 
the like, but there are systems out there that do keep context based on 
name resolution.

Eliot

---

From: Robert Kisteleki <[email-masked]>
Date: Thu, 15 Jul 2021 13:53:00 +0200

Hi,

> that the DNS server won't have to make a new query, and get a new geofenced

I believe it's not only about geofenced answers, but answers in general. 
Maybe because of geofencing, maybe for other reasons.

> about working around them is WRONG.  Maybe the right advice is... DON'T DO THAT.

"Do or do not. There is no try." :-)

> {ME: Doctor! Doctor! It hurts when I use a geographic CDN!

Yet people do use it, and in many cases for good reasons!

> I don't think so, but I could be totally wrong here.

It is probably not a major use case, but it's possible that the 
principle applies in other contexts too: RIPE Atlas (which is, according 
to some, can be considered IoT as well) in some cases uses DNS lookups 
to figure our measurement targets. The TTL on those is really low.

Robert

---

From: Robert Kisteleki <[email-masked]>
Date: Thu, 15 Jul 2021 13:53:30 +0200

> This means that the resolver needs to be integrated with the MUD 
> manager

I think you're right. However, we also know this kind of bundling is not 
always a good idea, or even favourable. Like an init system that has a 
built-in network manager, DNS resolver or MUD controller :-)

 > but also that the IoT device should also be careful to observe

Doesn't that prescribe that the IoT devices "should behave correctly"? 
Because we all know in reality they do not, at least not always -- but 
then what is a MUD controller supposed to do? Work around? Cover 
potential bad cases? Ignore this?

Robert

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Jul 2021 14:33:23 +0200

> {ME: Doctor! Doctor! It hurts when I use a geographic CDN!

We want MUD files to be data origin authenticated and integrity protected, possibly with a measure of freshness added.

Relying on TLS communications security (server hostname authentication) plus Web server integrity for that is possible as long as both the TLS communications security and the delivery behavior of the authenticated server are actually set up in a way that provides the above.

(For my taste, this adds too many variables, and I would never rely on TLS deployments to do this properly in the age of CDNs — object security is called for in cases where any real security is required.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Jul 2021 14:11:37 -0400

> Because we all know in reality they do not, at least not always -- but then
    > what is a MUD controller supposed to do? Work around? Cover potential bad
    > cases? Ignore this?

It's a BCP, and even if it was a STD, it would still be a voluntary standard.

When the vendor does something dumb, the RFC/BCP at least lets customers
and ISPs tell the vendor who has problems (or has caused problems), that they
have violated the BCP.  "Get a clue"

our advice had better:
1) actually do something useful
2) be implementable

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Jul 2021 14:16:56 -0400

> We want MUD files to be data origin authenticated and integrity
    > protected, possibly with a measure of freshness added.

Hi, we aren't talking about MUD controllers retrieving MUD files.
MUD files can be (and are) signed. (with CMS. Ick)
I'm not entirely sure if you have confused things here.

The connections this document deals with are those initiated by the IoT
devices, towards some Internet target, in order to effect their function.

As an example of a TCP connection that would be hard to describe,
the TCP chunks used in a video feed such as netflix uses, would be an
example.  They are to random EC2 hosts, at whichever IP addresses EC2 happen
to assign.
(I assume that Prime, Disney, Britbox, Crunchyroll also do this, but I
haven't read any analysis of that yet.  Smaller,  more specialized services,
might get away with a small set of permanent servers.  I know that youtube
does not do this, but rather connects to Google's nearest dark-fiber gateway)

A MUD definition for a SmartTV that had Netflix on it might have to
acceptlist the entire EC2 blocks, which are like /12s or something like that.
That's a lot of access, and leaves all of EC2 attackable by IoT devices.

(Again, IPv6 would make this problem mostly go away)

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Jul 2021 20:39:44 +0200

> As an example of a TCP connection that would be hard to describe,

Ah, right, we are using IP addresses as credentials (in the “ACLs” inside MUD).

> That's a lot of access, and leaves all of EC2 attackable by IoT devices.

And, more importantly, leaves IoT devices attackable by all of EC2.

This is just a symptom of the fact that we don’t have ways to properly model desirable communication, in a way that the desirability then is verifiable by justified parties.
So let’s work on those.

Grüße, Carsten

PS.: you can put in your paper submissions at https://dai-snac21.hotcrp.com/; deadline September 17

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Jul 2021 20:46:04 +0200

Reminds me of the concern about authentication of addressing i just
brought up on another mailing list to you ;-)

On Thu, Jul 15, 2021 at 08:39:44PM +0200, Carsten Bormann wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Jul 2021 15:41:25 -0400

> And, more importantly, leaves IoT devices attackable by all of EC2.

Maybe. Depends upon implementation and details.
For UDP, probably, assuming IoT device was addressable.
But, mostly TCP SYN flow is unidirectional in the ACLs.

    > This is just a symptom of the fact that we don’t have ways to properly
    > model desirable communication, in a way that the desirability then is
    > verifiable by justified parties.
    > So let’s work on those.

Well, in the EC2 case, the right solution would seem to be to assign IPv6
blocks to larger user.

But, in general you are right.
How, does an authoritative (or even authoritarian) firewall identify itself
such that traffic that needs to traverse it can self-identify?
APN has this problem.
I described this problem back in 1996:
  https://www.ietf.org/archive/id/draft-richardson-ipsec-aft-00.txt
  https://www.ietf.org/archive/id/draft-richardson-ipsec-traversal-01.txt

    > PS.: you can put in your paper submissions at
    > https://dai-snac21.hotcrp.com/; deadline September 17

Interesting.  I guess you are suggesting that the problem I've described is a
general problem, and is worth a paper.  I'll think about it.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Jul 2021 22:21:36 +0200

What is and is not a good idea is highly contextual in this case.  The 
network CAN provide a level of protection to limit attacks on devices, 
but it can only do so if it knows who that device wants to talk to.  
There is no magic here.  Either the bindings can be established or they 
can't.

Eliot

On 15.07.21 13:53, Robert Kisteleki wrote:
>
>> This means that the resolver needs to be integrated with the MUD manager
>
> I think you're right. However, we also know this kind of bundling is 
> not always a good idea, or even favourable. Like an init system that 
> has a built-in network manager, DNS resolver or MUD controller :-)
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Jul 2021 17:02:46 -0400

Eliot Lear <[email-masked]> wrote:
    > network CAN provide a level of protection to limit attacks on devices, but it
    > can only do so if it knows who that device wants to talk to.  There is no
    > magic here.  Either the bindings can be established or they can't.

Right.
So the advice boils down to:

  Dear IoT device Manufacturer,
  if you want your device protected,
  then avoid playing DNS games that can not be described easily MUD.

----

Maybe the document would go better as a song?
        https://www.youtube.com/watch?v=0NnzChrd0S4

my new lyrics:

A lonely MUD controller gazing out of the window
Staring at a IoT device that she just can't touch
If at any time, he's in a IoT attack, she'll be by his side
But he doesn't realize he hurts the Internet so much
But all the DNS-filtering just ain't helping at all
'Cause he can't seem to keep hisself out of 8.8.8.8
So he goes out and he connects to the cloud the best way he knows how
Another TLS connection laying cold in the IDS
Listen to me

[Chorus: TLC]
Don't go chasing DNS flows
Please stick to the servers and the stub resolvers that you're used to
I know that you're gonna have it your way or nothing at all
But I think you're moving too fast

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Jul 2021 19:18:30 -0400

I think the deployments also have to be somewhat forgiving in terms of 
maintaining an ACL some period beyond TTL.  It would make a good paper 
to understand just how much.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 Jul 2021 12:16:25 -0400

Eliot Lear <[email-masked]> wrote:
    > maintaining an ACL some period beyond TTL.  It would make a good paper to
    > understand just how much.

Yes, I agree.  When one does a DNS lookup, the TTL one gets back is the
amount of time that it's valid in that cache.
At the point where it expires, one should do another lookup of that QNAME.

If an A or AAAA is now gone, I think that that maintaining a positive ACL
for another TTL worth makes sense.
If it was a negative ACL (traffic forbidden), then I'd remove it immediately.
(MUD doesn't really do negative ACLs)

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 16 Jul 2021 18:45:00 +0200

>  https://www.ietf.org/archive/id/draft-richardson-ipsec-traversal-01.txt

I think one trap that many of these efforts fell into was that they tried to be small attachments to existing technology.

There is nothing wrong with describing a little hack that has some useful applications, but that won’t cover the gamut of use cases that we really have.
Looking at these uses cases we need to derive an understanding of the parties involved and what security (and “trust”) relationships they have, and what granularity of authorization of “desirable” traffic is required, desired, and achievable.
Note also the term “justifiable” in my problem statement!
Only then can we check whether a proposed solution actually solves a large enough problem.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 Jul 2021 16:42:14 -0400

> I think one trap that many of these efforts fell into was that they
    > tried to be small attachments to existing technology.

In 1996, I'm not sure I'd say that IPsec was "existing" :-)
The pushback that I got was that it seemed complex.
NAT44 was not established, but it was visible in the form of actual security gateways.

    > Looking at these uses cases we need to derive an understanding of the
    > parties involved and what security (and “trust”) relationships they
    > have, and what granularity of authorization of “desirable” traffic is
    > required, desired, and achievable.

Some things have progressed in 25 years.

RPKI exists, although it is not well deployed.  (My understanding is that one
reason it is slow in ARIN region is that ARIN won't let you have their public
key until you assure them you won't sue...)
RPKI would allow a node to say, "I am authoritative for 2001:db8:1234/48"

This could be very powerful if used correctly.