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.
"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.
> 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.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
