Folks,
Thanks for writing this draft. The following are a few comments:
1.
This document should include the following statement:
*
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.
3.
Other solutions are available. For example, the IETF could:
*
Assign an identifier to each limited domain protocol
*
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
