netdev - Re: [PATCH RFC 1/2] ipv6: add the IPV6_FL_F_REPLY flag to IPV6_FL_A

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

Message-ID: <20131214095650.GD23563@order.stressinduktion.org>
Date:	Sat, 14 Dec 2013 10:56:50 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Florent Fourcot <florent.fourcot@...t-bretagne.fr>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH RFC 1/2] ipv6: add the IPV6_FL_F_REPLY flag to IPV6_FL_A_GET

On Thu, Dec 12, 2013 at 11:39:30AM +0100, Florent Fourcot wrote:
> There two patches extend the flow API. It adds three new actions with
> IPV6_FLOWLABEL_MGR:
> 
>  * setsockopt with IPV6_FL_A_GET and IPV6_FL_F_REPLY set:
>       enable the reply of flow label, packet are sent with the
>       last low label read in packet sent by remote device
>  * setsockopt with IPV6_FL_A_PUT and IPV6_FL_F_REPLY set:
>       disable the flow label reply
>  * getsockopt with IPV6_FL_A_GET and IPV6_FL_F_REPLY set:
>       get the flow label send by the remote device

Sorry, I am not up to date with flowlabel RFCs and applications. Couldn't
such a feature get in the way of RSVP flow control if a remote side
can dictate the label to use for the outgoing connection (I know, your
implementation is opt-in, but I don't want to give application developers
something at hand which could make their software difficult to operate
in future).

> I'm not sure of the best way to do that. First, should we allocate a
> real flow label in the global flow label? I don't think so, and it could
> add hard issues with the system of permission/sharing.

I wouldn't do that either. OTOH we are emitting frames with a flowlabel the
flowmgr does not know about. :/

> Second, I was not sure of the best way for the coverage for all TCP states.

And why would you only support TCP? Wouldn't this work for connected UDP
sockets, too?

Greetings,

  Hannes

--
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