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.
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.
I believe we agree that pretending stuff won't leak in or out without
reliable enforcement is a technical mistake.
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
