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
