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.
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.
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.
Cheers
Toerless
On Mon, Oct 23, 2023 at 05:36:28PM +0200, Eliot Lear wrote:
>
> On 23.10.2023 17:27, Michael Richardson wrote:
> > Maybe someone else can explain it back to me in a better way.
>
> The fundamental issue is this:
>
> * If you are permitting an IP address in an ACL based on a name in a
> MUD file, the mapping to that address is valid for the greater of
> the TTL on the name or the state of a connection, assuming you have
> that state. If the state isn't there and endpoints inappropriately
> cache the name beyond TTL, That Would Be Bad.
>
> Eliot
> _______________________________________________
> OPSAWG mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsawg
--
---
[email protected]
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
