Re: rht0 sysctl (Re: CVS commit: src/sys/netinet6)

At Sun, 20 May 2007 08:09:21 +0000,
Pavel Cahyna <pavelNetBSD.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.
					jinmeiisl.rdc.toshiba.co.jp

On Sun, May 20, 2007 at 11:13:07PM -0700, JINMEI Tatuya /
?$B?LC#:H?(B wrote:
> At Sun, 20 May 2007 08:09:21 +0000,
> Pavel Cahyna <pavelNetBSD.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)

One should add that RH0 must not be filtered on the path
between the
attacker and the node which re-enables the feature to make
attacks
feasible.

The application I have in mind is to enable the feature on
routers in
some administrative area and filter it at the border of this
area, to
have a backup solution if dynamic routing breaks.

(I have suffered from broken dynamic routing often in
community wireless
networks.)

Pavel