On 7/7/25 15:06, Ben Schwartz wrote:
Quick thoughts:
1. I don't know what this is for. Is it for firewall configuration?
Local firewalls or network firewalls? Configured by the client
application or by a middlebox? Is this for allowing unexpected
inbound traffic, or locking down outbound traffic to unrecognized
IPs? Or is this really about annotating traffic for post-hoc analysis?
Most all of these, yes. Locking down outbound traffic to unrecognized IP
addresses is a primary use case in my mind, though more generally
firewall configuration to avoid domain name hacks like SNI inspection is
desirable, and post-hoc analysis is always something that making data
richer is a good thing (reaction to security events is just as important
as trying to prevent them, since 100% prevention is impossible).
2. The mention of WebRTC is very puzzling. Most WebRTC services allow
direct connection between any pairs of peers in the world, so the
CIDRS record would be 0.0.0.0/0. Is that the intent?
Definitely not, as short prefixes are discouraged and /0 would be "right
out". The example refers to the real-world practice of such applications
to have fallback CIDRs that, if unblocked, will ensure the vendor's
service always works even if arbitrary destinations are blocked which
would otherwise result in more direct paths.
3. The draft mentions RFC 9000 server mobility as an example use
case. Is that a key motivation? Server-initiated QUIC connection
migration is basically impossible due to stateful firewalls (and
symmetric NATs), so this is not something that anyone does on the open
internet in practice, or could do in the foreseeable future.
No, it was just another example. It would be nice if implementations
*could* do that, but if you think it's a low-value example, we can
provide more practical examples (such as detail on the teleconferencing
case).
--Ben
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
