At Sun, 20 May 2007 08:09:21 +0000,
Pavel Cahyna <pavel@NetBSD.org> wrote:

> > > Also, I don't recall RH0 support being optional.
> > 
> > have you read the pdf referenced in a comment?
> 
> Yes.
> 
> > don't you agree that it shouldn't be enabled?
> 
> No, though I agree it should be disabled by default.

I personally don't necessarily object to removing sysctl at this
stage, but I don't think the risk of keeping it (with the default
being "disable") at the moment is that high in reality either.

Keeping the sysctl knob does real harm if all of the following
condition are met:

- the administrator explicitly turns it on again
- the attacker finds the address of the node that re-enables the
  feature (it's not always so easy)
- two such nodes are close enough (if there are many hops between
  them, the amplification factor is limited), and
- the entire path between the two nodes is broad enough (since the
  amplification effect is bound by the narrowest bandwidth in the path)

I understand the risk of underestimating the threat level, but I don't
think it's very easy for an attacker to ensure all of these conditions
hold.

Meanwhile, there should still be many "unpatched" implementations that
can be exploited.  Until the number of such implementations decreases
to some negligible point, just removing a sysctl knob which disables
the feature by default wouldn't contribute to reducing the whole risk
much.

Having said that, I agree there are not so many (if any) useful and
widely deployed applications of the type 0 routing header, so I'd not
necessarily oppose to removing the knob now.

My point however is that the decision does not seem so obvious to me
that we can just commit it by stating "it's too dangerous compared to
its benefit".  I hope the decision was actually made via more
intensive consideration about the tradeoff between the real threat and
the benefit rather than a knee-jerk response that the simply commit
log may indicate.

BTW, it now looks that the IETF is reaching a consensus of deprecating
the type 0 routing header.  If this actually happens, this change will
just conform to the new standard (and will be "officially" justified).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp