Ron,
On 20-Oct-24 12:21, Ron Bonica wrote:
Folks,
Thanks for writing this draft. The following are a few comments:
1.
This document should include the following statement:
1.
In the future, the IETF MUST NOT standardize any fail-open protocols
that are designed for deployment in limited domains
2.
While the ethertype and extended ethertype solutions work, they may not be
very popular with IEEE. The IETF is producing limited domain protocols by the
dozen. IEEE may not want to provide that many ethertypes.
I think it's worse than that. If you think in terms of domains that are purely
nested inside one another, you would presumably need one new Ethertype per
level of nesting. But if you think of domains that are both nested and
overlapped, you would need a more complex solution.
Operators might not see a Venn diagram of domains as necessary, but some
application designers might. And I'm pretty sure they wouldn't consider a
multitude of Ethertypes as a solution.
Again, it isn't relevant to operators, but I'm impressed with way the DFINITY
people are handling their version of large numbers of secure domains:
https://medium.com/dfinity/secure-scalability-the-internet-computers-peer-to-peer-layer-6662d451f2cc
https://youtu.be/HOQb0lKIy9I
Brian
3.
Other solutions are available. For example, the IETF could:
1.
Assign an identifier to each limited domain protocol
2.
Define a new IPv6 hop-by-hop option. The opt bits of the new option are
01, so the packet will be dropped if the option is not recognized. The new
option contains the identifier of each limited domain protocol in which the
packet participates
The ingress router will drop an incoming packet if the new option is
present and it has not been explicitly configured to pass every limited
protocol identifier in the option. Routers participating in the limited domain
protocol will drop the packet if the option is absent of if it does not contain
the relevant limited protocol identifier.
4.
Section 3 could be modified as follows:
Protocols can be broadly classified as either "fail-open" or "fail- closed".
Fail-closed protocols are those that require explicit interface or device-wide configuration to
enable them to be accepted or processed when received on an interface. A classic example of a
fail-closed protocol is MPLS ([RFC3031]): In order to allow MPLS to transit an interface, the
operator must enable the MPLS protocol on that interface and on the device itself. This ensures
that outside MPLS traffic does not leak in.
Fail-open protocols are those that do not require explicit interface or
device-wide configuration to enable them to be accepted or processed when
received on an interface. Therefore, fail-open protocols
require explicit configuration in order to ensure that they do not leak out
of a domain, for example, through the application of filters.
An example of a fail-open protocol is SRv6 - in order to ensure that SRv6 traffic does not leak out of a network, the operator must explicitly filter this traffic, and, in order to ensure that SRv6 traffic does not leak in, the operator must explicitly filter SRv6 traffic. Fail-open protocols are inherently riskier than fail-closed protocols, as they rely on perfect configuration of filters on all interfaces at the boundary of a domain, and, if the filters are removed for any reason (for example, during troubleshooting), there is a risk of inbound or outbound leaks. In addition, some devices or interfaces may have limitations in the size and complexity of filters that can be applied, and so adding new filter entries to limit leaks of a new protocol may not be possible. Fail-closed protocols, on the other hand, do not require any explicit filtering. In order for the protocol to be accepted and processed when received on an interface, the
operator must explicitly enable the protocol on that interface and on the device itself. In addition, there is less risk of operational mistakes, as it does not rely on filters that may be limited in number and complexity. Finally, fail-closed protocols do not require that operators of networks outside of the limited domain implement filters to protect their networks from the limited domain traffic.
Ron
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Juniper Business Use Only
_______________________________________________
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
