On Sun, May 20, 2007 at 11:13:07PM -0700, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> 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)

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