On Thu, Oct 26, 2023 at 09:43:57AM -0400, Michael Richardson wrote:
>
> Toerless Eckert <t...@cs.fau.de> wrote:
> > Randomnly jumping into the discussion, probavbly too late for any
> > impact, but:
>
> > I am not quite sure that section 6.4 "geofenced names" exactly means, a
> > RFC reference would help. Also a reference for the described problems.
>
> I see that it's not in RFC8499.
> It's a way to provide different Views of the DNS depending upon where the
> requestor is.
Right. I knew this under split horizon DNS, but i don't follow trending
terminoloy.
> "Fast Flux DNS" is an interesting entry as well.
>
> > If this geofenced is what i think, then i don't believe it is a valid
> > argument:
>
> > The draft outlines how TLS proxying does not work with 1.3
> > anymore. However, TCP and UDP proxying would still work, as long as
> > servers do not try to deduce anything from the IP address of the
> > connecting clinet (or vice versa), but only worry about the
> > cryptographic authentication.
>
> > In result, a well working strategy for MUD enforcement points would be
> > to act as TCP/UDP proxies for all the domain names known from MUD
> > files. In return of course, they have to be the DNS servers inquired.
>
> So, the idea is to lie in DNS for all the names in the MUD file, point at
> some RFC1918/20 block (or trivially a single IPv6/64). Then each end point
> is then proxied at the circuit layer to the real destination.
>
> This will trivially break if a device turns on DNSSEC, but otherwise, it
> seems like a reasonable way to implement.
Sure, but that DNSSEC issue equally applies to TLS proxies, right ?
DNSSEC is not mentioned in the docs paragraphs discussing TLS.
And MUD devices with TA for their cloud services would arguably not just
believe wrong DNS information when their TLS peer don't provide the right
credentials, and hopefully those are not just WebPKI anyhow. Aka: not sure
if DNSSEC is relevant.
Of course, one could always extend MUD to explicitly allow clients
to look for local-domain domain names to explicitly support TCP/UDP or TLS
proxies in case such proxies are desired. TLS proxies of course still
being a highly desirable option to support (likely independent of this draft),
to allow the operator of the MUD devices to actually inspect the traffic
between te devices the operator owns and their cloud services.
>
> > That IMHO is not different from any type of CDN in the internet which
> > is overloading domain names of services which they cache.
>
> > Of course, this scheme would reasonably only work well for IPv6 because
> > that would give a firewall most easily enough address space to map from
> > the DNS names in MUD to separate IPv6 addresses thus that the IPv6
> > address identifies a proxied DNS name.
>
> Agreed.
> It's probably not that many IP addresses though.
>
> It scales by the number of types of devices, rather than the number of
> devices. So a building with three models of light bulb might burn only a few
> dozen addresses, while serving thousands of bulb's need to ask about software
> updates.
Right.
Cheers
toerless
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
>
>
>
--
---
t...@cs.fau.de
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
