lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Thu, 21 Jun 2012 01:07:55 +0200
From:	Jiri Bohac <jbohac@...e.cz>
To:	yoshfuji@...ux-ipv6.org
Cc:	Teran McKinney <sega01@...il.com>,
	Pekka Savola <pekkas@...core.fi>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: accept_ra_rt_info_max_plen default value

Hi,

I have been looking for the reason behind the default of
accept_ra_rt_info_max_plen being 0. No luck.

The feature has been introduced by 930d6ff2 ([IPV6]: ROUTE: Add
accept_ra_rt_info_max_plen sysctl).

The only relevant discussion I found was
http://markmail.org/message/5m34bfzhox6y5lcf
with no explanation.

I imagine that the motivation for setting
accept_ra_rt_info_max_plen to 0 would be security concerns (?).

However, RFC 4191, section "6. Security Consideration", concludes
that the new features don't increase the risks already present:

	A malicious node could send Router Advertisement messages, specifying
	a High Default Router Preference or carrying specific routes, with
	the effect of pulling traffic away from legitimate routers.  However,
	a malicious node could easily achieve this same effect in other ways.

	For example, it could fabricate Router Advertisement messages with a
	zero Router Lifetime from the other routers, causing hosts to stop
	using the other routes.  By advertising a specific prefix, this
	attack could be carried out in a less noticeable way.  However, this
	attack has no significant incremental impact on Internet
	infrastructure security.


RFC 6434 has been published since, and under 5.3. it says:

	Small Office/Home Office (SOHO) deployments supported by routers
	adhering to [RFC6204] use RFC 4191 to advertise routes to certain
	local destinations.  Consequently, nodes that will be deployed in
	SOHO environments SHOULD implement RFC 4191.


Shouldn't the default value of accept_ra_rt_info_max_plen be
re-considered to comply with RFC 6434 by default? Any reason not
to make it 128?

Thanks,

-- 
Jiri Bohac <jbohac@...e.cz>
SUSE Labs, SUSE CZ

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists