netdev - Re: [PATCH net-next] Revert "net/ipv6: add sysctl option accept_ra_min_hop

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>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 11 Sep 2015 13:09:26 +0200
From:	"D.S. Ljungmark" <ljungmark@...io.se>
To:	Florian Westphal <fw@...len.de>,
	YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com>
Cc:	Sabrina Dubroca <sd@...asysnail.net>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	liuhangbin@...il.com, hannes@...essinduktion.org
Subject: Re: [PATCH net-next] Revert "net/ipv6: add sysctl option
 accept_ra_min_hop_limit"

On 11/09/15 12:53, Florian Westphal wrote:
> YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com> wrote:
>> Sabrina Dubroca wrote:
>>> 2015-09-10, 14:52:45 +0900, YOSHIFUJI Hideaki wrote:
>>>> Sabrina Dubroca wrote:
>>>>> Would you agree with a default of 64, as Florian suggested?
>>>>
>>>> 1 was chosen to restore our behavior before introduction of current
>>>> hoplimit check.  I am not in favor of changing that value.
>>>
>>> But our old behavior had a security issue, which is why the >= current
>>> check was introduced.
>>
>> We have the knob to "protect" ourselves now but it has drawbacks no to
>> accept lower values than specified.  We can never have ultimate default
>> for everybody.  The knob might "mitigate" the issue but once we have
>> any rouge routers on our L2, we lose anyway.  So, I do want to keep it
>> as-is not to change our traditional behavior.
> 
> If that argument is brough forward (and it's a good point!), then the
> entire case for rejecting 'low' hoplimit values in first place becomes moot.
> 
> If this is an important security issue, then either the sysctl has to be
> removed or the default raised to some 'safe' value (32, for example).
> 
> If its not a security issue -- and it isn't if we think "1" is a good
> default choice -- then we should seriously consider reverting both
> the added sysctl and the 'original' commit (6fd99094de2b; "ipv6: Don't
> reduce hop limit for an interface").
> 


The most common use-case for this is public WiFi.  So far, a negible
amount of access points have even remote ability to filter "unwanted" L2
traffic.

The fact that a single, empty RA packet with a hop limit of 2 will take
down your entire ipv6, even if your infrastructure uses DHCPv6 for
addressing is problematic.

There are scenarios where an L2 agent can push a link-local or
Peer-to-peer routes with a low hoplimit. These routes would then lower
the interface-level hop limit to something that breaks your other routing.

Personally, I think the concept of hop-limit being per interface in IPv6
is disasterously stupid, but I'm not arguing against the RFC there.

//D.S.



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)