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:	Thu, 16 Jan 2014 14:07:53 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Florent Fourcot <florent.fourcot@...t-bretagne.fr>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH V2 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET

On Thu, Jan 16, 2014 at 01:45:18PM +0100, Florent Fourcot wrote:
> 
> >> Was there a specific reason you did not use np->flow_label here and just
> >> mirroring the flowlabel from the first packet of the connection for the
> >> whole connection?
> >>
> >> I don't know if it makes a difference, but maybe it was done on purpose?
> > 
> > I thought about it and am actually in favor of reusing the flowid from the syn
> > packet so userspace does report correct outgoing flowlabel even in case of
> > strange tcp peer changing it mid-stream.
> > 
> 
> Actually, the idea was that the remote could changed the flow label
> during the lifetime of a connection.
> I do not have a strong opinion on that, but in a "reflect" mode, I
> except that the last received value will be in used.

Would it make sense to sync the flowlabel if it changes with the socket, so
user space can query the label really used? Otherwise I wouldn't even report
it.

> Second, in case of SYN cookie, is the SYN flow label stored somewhere?

Should then be synced as soon as the cookie is validated. You can test it by
setting tcp_syncookies to 2. It uses syncookies unconditionally then.

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