On 16-Jun-2007, at 02:23, Christopher Morrow wrote:
I'd actually be a fan of not deprecating the headers in question, but
permitting implementations to either ignore+forward, drop, use them.
So, in the case at hand an operator could decide that 'source routing
is ok' on their network and follow the wishes of the packet creator.
The approach that we seem to have consensus to follow is that RH0 has
practical risks which are too great and hence should be deprecated,
but that this does not preclude some form of "off-by-default" source
routing functionality to be defined in future. This new source-
routing feature presumably would lack some of the features that make
RH0 particularly potent/dangerous, and be implemented as some other-
numbered routing header so it can be distinguished from RH0 by
firewalls.
Some concern has been voiced that if we don't deprecate RH0, and just
require processing by hosts and routers to be disabled by default,
some malware or other will just turn it back on.
The following text at the end of section 5 of -01-c-01 refers to this
approach:
The severity of the threat is considered to be sufficient to warrant
deprecation of RH0 entirely. This has the unfortunate side-effect
that benign use cases for RH0 are eliminated along with the
potential
security hazards; such applications may be facilitated in the future
by new routing header specifications which do not suffer from RH0's
problems.
This lets the technology be used where appropriate and doesn't do undo
harm because folks can choose to, as adults, handle the traffic
properly for their network/systems.
The approach above does not preclude that entirely; it's just more
conservative.
Joe
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
