Jason,
I haven't been following the RH0 deprecation discussion quite as closely
as you have, but it seems to me that your concerns would best be
addressed by creation of a new RH option to support a safer form of
source routing. My understanding is that RH0 is a lot like directed
broadcast (smurf amp), in that if you can find two networks that support
RH0, and ISP(s) in the middle that allow it, that opens up a DoS
vector. As a result, I think everyone needs to discard RH0 packets, and
that the ability to ignore (pass-through) source-routed packets would
best be implemented with a new RH option with tighter security.
I guess that makes me #17 in favor of option #1.
-Scott
Jason Schiller wrote:
On Tue, 28 Aug 2007, Jun-ichiro itojun Hagino wrote:
ok, i assume you have not seen this. http://www.natisbad.org/.
the key topic being discussed here with the draft is URGENT need to
publish the deprecation/restriction of RH0.
please refrain from generalizing the problem, until RH0 RFC goes
out of the door. we can handle your generic opinions about the
source routing in general some other time.
again, it is about rather serious security problem, which risked
the DNS root name servers. it's quite serious and really urgent.
the RFC publication should have finished way earlier.
itojun
Itojun-san,
Thank you for the URL http://www.natisbad.org/.
I have been closely following the RH0 discussion as it relates to ISP
network security and the implications on the specific routing gear in my
network. I have closely examined the security bulletins from my vendors,
and have specified the required testing of their current functionality and
possible work around configurations.
I am also quite aware of the security implications including:
1. The possibility of end-sites making traffic engineering decisions about
how traffic is forwarded across my network.
2. The possibility of a DoS attack on a link by looping traffic between a
pair of routers or hosts
3. The possibility of circumventing firewall filters by specifying a good
destination, and then source routing the packet behind the firewall to a
filtered destination.
I have only loosely followed the discussion with regard to Unix / Linux
implementation of RH0, and believe the problem to be the same as for some
router vendors who have not provided a configuration statement to discard
source routed IPv6 packets. I do appreciate the additional links
discussing the RH0 problem wrt particular host operating systems.
I do appreciate the importance of this issue.
We can all agree that at the very least all vendors should offer the
ability to easily discard source routed packets.
I am agreeable to making that the default behavior, although I suspect
there will be some push back as people tend to be uncomfortable whenever
defaults change. Generally people get upset when they depend on a
default, and then the upgrade their version of Cisco IOS and the default
changes and something breaks.
I understand that this work is holding up getting vendors to modify their
code.
I personally would like to see my vendors offer BOTH the ability to
discard source routed packets, as well as the ability to ignore source
routed packets. However, if IPv6 source routing is deprecated, then it is
unlikely that they will provide this functionality as it will violate an
RFC. This is why I prefer option 2.
With regard to generalization I think it is important that we consider
feature parity with IPv4 and IPv6 and understand the implications of
deprecating IPv6 RH0 on IPv4 source routing.
Thanks,
__Jason
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
