netdev - Re: [PATCH 2/2] ipv6: Set flow label to skb

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]

Message-ID: <CA+mtBx-OzFHAhXaYimiS4vkB9K6MDjXYHtF5M6EdW3RV3FYQTA@mail.gmail.com>
Date:	Mon, 28 Apr 2014 14:13:12 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Florent Fourcot <florent.fourcot@...t-bretagne.fr>
Cc:	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] ipv6: Set flow label to skb_hash on transmit

On Mon, Apr 28, 2014 at 1:49 PM, Florent Fourcot
<florent.fourcot@...t-bretagne.fr> wrote:
>
>> If someone is implementing a strong policy for
>> flow labels (like dropping based on it), it would be incorrect.
>> RFC6437 is clear on this:
>>
>
> And correct for RFC 3697:
>
>>    A source node MUST ensure that it does not unintentionally reuse Flow
>>    Label values it is currently using or has recently used when creating
>>    new flows.
>
> The situation is very uncomfortable, but the choice is to break old
> implementations based on a rule valid between (at least) 2004 and 2011,
> or to follow the newer RFC. If we not set it by default, the
> distributions still have the choice to enable it.
>
Agreed, following robustness principle I will concede that the
conservative approach is to not enable auto_flowlabel by default. But
for RX purposes, the implementation needs to be consistent with 6437--
again we should not enforce that a received flow label corresponds to
a stateful connection (BSD would apparently break that). This might be
something that needs to be considered with flowlabel manager?

>
>>> As second point, the name of auto_flowlabel is in my opinion not a
>>> perfect choice if you set a label it only on tunnels. This is exactly
>>> the same name that a BSD sysctl, setting a random label on all sockets
>>> (TCP, UDP...). The flow label world is already hard enough to
>>> understand, thanks to various implementations.
>>>
>> This is not just for tunnels, but would apply to transports and
>> potentially obviates the need for a lot of UDP encapsulation (like
>> ESP/UDP). So it would appear that this is pretty much the same thing
>> as what the BSD implementation does and same sysctl name (a happy
>> coincidence). Looks like the default in BSD is on btw.
>>
>
> Oups sorry, I missed the line in the patch for the transports. If you
> follow the BSD implementation, what about the IPV6_AUTOFLOWLABEL socket
> option, to disable/enable it only on some sockets? (the enable is
> actually already available thanks to the manager).

I doubt a socket option would be very useful. The goal is to affect
aggregate behavior in the network which means we'd want it to be
generally used. As I mentioned, my primary use case would be to use
this with ESP (transport or tunnel mode) so we can avoid an extra UDP
encap with IPv6 for getting things like RPS and ECMP.

Thanks,
Tom
--
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