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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ