If we want to take the view that sites trying to protect themselves from
injection of limited domain protocol should block all extension headers,
then sure, that can be done and will work. I believe it is rather
stricter than most people would like.
If the set of limited domain protocols is itself small, then we can use
Ethertypes to identify them. And filter easily.
If the set is large, it seems to be difficult unless we put some
structuring in place, or go overboard (as I presume I am
misinterpretting you as suggesting.)
Yours,
Joel
On 10/19/2024 6:56 PM, Tom Herbert wrote:
On Sat, Oct 19, 2024 at 2:29 PM Joel Halpern <j...@joelhalpern.com> wrote:
I agree that we need to be careful about scaling. Conversely, if the
set of things needing to be filtered at the domain edge is large, we
can't expect ACLS to work well for it either. Even if the ACL can look
at whatever new thing is being define. And it is very hard to define
these things at L3 so they fail closed.
Joel,
I'm not sure the set of things that need to be filtered is really all
that big. If a site wants to protect its networking infrastructure
from potentially harmful L3 features then it should only need to
filter on Hop-by-Hop options and routing headers at the edge. Anything
else in the packet is E2E which shouldn't impact network
infrastructure .
Which suggests something the folks looking to leverage "limtied domains"
probably won't like. Either we use a common marker for a set of limited
domain technologies to get it to scale, or we heavily restrict the set
of limited domain things we standardize.
It's not clear to me how to standardize anything in regards to limited
domains. For instance, today there is one one set of standards for
IPv6, and it's fully expected that those standards ensure
interoperability in any possible domain-- open Internet, datacenters,
5G networks, home networks, etc. But if we started standardizing
protocols that only can run in limited domains then where could that
go? Do we really want to have one variant of IPv6 that might only work
in limited domains and is not interoperable with RFC8200? While I
think RFC8799 is a good description and is useful for thinking in
terms of using protocols in a limited domain, I'm leary of efforts to
formally standardize "limited domain protocols".
I believe we agree that pretending stuff won't leak in or out without
reliable enforcement is a technical mistake.
Maybe, but it's not clear to me if using a different Ethertype is
really reliable enforcement or is more "enforcement through obscurity"
:-).
Tom
Yours,
Joel
On 10/19/2024 5:23 PM, Eliot Lear wrote:
Hi Joel
On 19.10.2024 22:58, Joel Halpern wrote:
I am not sure Iunderstand Eliot's disagreement. Or Brian's. While
the cases you were envisioning when the term was first coined may
have been pure L3, the practical requirements operators have
articulated is explicitly to be able to fail closed, to avoid
accidentally allowing limited domain protocols into their operating
domain. Whether you call that L2.5 (MPLS) or L3 (SRv6) the need
doesn't change.
My point is not that I object to "fail closed' in principle, but (a)
it would be better to have a more detailed threat model so that it is
clear what is being defended against, and (b) that the proposed means
to do so may not scale to other innovations in L3. Now maybe we can
balance that with the idea that there should not be too many
innovations at L3, I suppose, but we think should happen and what
actually happens may diverge.
I also worry that we are trying to legislate a defense against "evil
bits". Regardless of whether a protocol feature makes use of a new
ethertype, providers still have to defend against garbage being thrown
at them by neighbors.
Finally were we to apply this logic above L3 to IANA port allocations,
and someone wanted to request a new port for a new protocol feature,
we'd tell them to jump in a lake. Especially with a 16 bit field.
Eliot
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
