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

["D.S. Ljungmark" <ljungmark@modio.se>]

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

On 11/09/15 12:53, Florian Westphal wrote:
> YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]