Comments in-line. Meta note: it seems your concerns are all focused on
the way allow/block traffic enforcement consumes this information. Do
you have any concerns with the ability to discover associations for
logging and audit purposes?
On 7/7/25 15:58, Ben Schwartz wrote:
Thanks for the explanation.
I have serious concerns about proposals that would encourage
blocking/unblocking IP addresses based on previous DNS activity. If
your network's firewall behavior depends on the history of DNS
queries, this creates an extreme form of stateful protocol
ossification that prevents IP from working correctly. It's like NAT
but worse, because the stateful behaviors at the IP layer depend on
history from "outside" of IP.
The comparison with NAT seems like a weird apples-to-mangoes comparison.
Neither this draft nor the mentioned use cases that would depend on it
"prevent IP from working correctly" as they have no effect on routes or
IP headers whereas NAT actually rewrites headers and obfuscates the
"real" IP address of one or both peers. Anyway, how is this different
from enforcement of IP allow/block based on other dynamic, non-IP logic
such as which process it originated from or what the current time is,
both common practices today that are "history from 'outside' of IP"?
It also messes with DNS (which is a lookup protocol, /not/ a signaling
protocol). For example, it creates perverse interactions with DNS
stub caching, which one might have to /disable/ in order to generate
the DNS query activity that will cause a block to be lifted.
Implementations may end up doing this, sure, but it isn't inevitable. I
know my previous employer's implementation of DNS-based allowlisting has
a long-term approval time period that well exceeds most TTL values,
because in real life, everyone continues using resolutions for as long
as possible. Breaking connectivity just because a cache was cleared (for
any reason) was deemed unacceptable. In other words: this is up to the
implementation of the enforcement.
Network operators that want to limit network activity to allowed DNS
domains should use a domain-based transport proxy such as HTTP
CONNECT, so policies can be imposed /before/ DNS resolution, and each
data flow is explicitly tied to its domain.
Two things: (1) you are assuming the deployer is a *network* operator
and not a *device* operator. What about when there is no network "edge"
to manage? I don't buy that the only correct answer is to proxy
everything. (2) Whatever is doing enforcement of policy has to know
about what CIDRs are associated with what use cases, whether by using
this draft or by existing practices (scraping vendor websites, vendor
REST APIs, etc.). Now the proxy is in the same situation this draft
addresses as the endpoint was when it decided to offload this
enforcement problem to the proxy.
In the specific example of WebRTC relays, I'm not convinced that this
approach accomplishes the security goal either. Relay servers (like
TURN) are themselves opaque proxies for e2e-encrypted data. If the
client is untrusted, giving it access to a TURN server is equivalent
to giving it access to the whole internet. Regardless, this use case
would be resolved better by giving the relays DNS names that can be
approved by the network operator, rather than passing IP literals and
then trying to encode (ahead of time!) all potential IP literals that
might be used.
It is absolutely true that trust in an endpoint, defined by any
identifier, has risks. A firewall rule that blocks specific IP addresses
isn't perfect when an allowed IP address will proxy traffic to those
same IP addresses. I do not see how this draft introduces a new paradigm
in that regard. Some dependencies are riskier than others (allowlisting
a proxy or gateway by any means, this draft or not, always means you
either have to manage that service or you entirely trust them to filter
the entire Internet for you).
As for assigning DNS names to <whatever>... yes, I would very much like
that, but this requires the same operator to control the managed
endpoints *and* all services they connect to. That isn't reflective of
reality, where everyone has dependencies on many third parties who can
define their endpoints by domain name or IP addresses. As mentioned
above, the operator may or may not be a network operator, just an
endpoint operator.
Consider a VoIP operator that acquires relays (or whatever other
literal-addressed resource) dynamically from AWS. In this proposal,
they would have to list all of AWS's IP range in their CIDRS records
... substantially defeating the intended security goal.
Yes, that would be a bad use case for this, unless that dynamic
retrieval of relays is customer specific. For example, allowlisting by
any mechanism, this draft or not, could work in this scenario if
tommycorp[.]voip[.]cloudvendor[.]example CIDRS records aren't the same
as benbook[.]voip[.]cloudvendor[.]example CIDRS records. Any service
which shares "every CIDR owned by a cloud vendor" as a potential
endpoint can't be allowlisted anyway. This feedback overlaps with the
generic problem of allowlisting rather than being specific to this draft.
Even though there are services which operate this way, many do limit and
actively communicate their CIDR dependencies. If this draft was
supported by a percentage of the vendors an operator depended on, and
the remaining vendors were all in this "any AWS IP range could be used,
who knows" camp, that would still allow a percentage reduction in
traffic the operator has to pay for infra to proxy (falling back on your
suggestion above in lieu of having DNS-discovered CIDRs).
--Ben
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
