Date: 15-07-2021

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

____________________________=
___________________
OPSAWG mailing list
OPS=
AWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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 t=
he
group understood the problem.  The chairs seemed very happy to have peopl=
e
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 th=
e
       same DNS server,
     - respecting TTLs in the MUD controller

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

I had done some research in preparing this document as to how exactly rou=
nd
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 a=
nyway.
      (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 D=
NS
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 D=
O 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 po=
int.

Other than firmware updates, are IoT devices heavy users of geofenced thi=
ngs?
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 in=
to
per-App MUD files!).
In that case, I might be forced to acceptlist all of my EC3 cloud, and ma=
ybe 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:           h=
ttps://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-consideratio=
ns-02.html
Diff:           ht=
tps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-iot-dns-considera=
tions-02

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8=
T consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.

Date: 10-06-2021<= /h1>

Participants

Discussion

Date: 29-04-2021

Participants

Agenda

Discussion

Action Points

Date: 15-07-2021

Participants

Discussion

Action Points

Date: 24-06-2021<= /h1>

Participants

Discussion

= Action Points

Participants

Action Points