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: <565AF849.8030008@mellanox.com>
Date:	Sun, 29 Nov 2015 15:06:17 +0200
From:	Haggai Eran <haggaie@...lanox.com>
To:	Joe Stringer <joestringer@...ira.com>,
	Or Gerlitz <gerlitz.or@...il.com>
CC:	Jesse Gross <jesse@...nel.org>, Or Gerlitz <ogerlitz@...lanox.com>,
	"Jesse Gross" <jesse@...ira.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Ilya Lesokhin <ilyal@...lanox.com>,
	Rony Efraim <ronye@...lanox.com>,
	"Hadar Hen Zion" <hadarh@...lanox.com>,
	Jesse Gross <jesse@...ira.com>,
	"Pravin B Shelar" <pshelar@...ira.com>
Subject: Re: OVS VXLAN decap rule has full match on TTL for the outer headers?

On 14/11/2015 08:45, Joe Stringer wrote:
> On 13 November 2015 at 06:46, Or Gerlitz <gerlitz.or@...il.com> wrote:
>> > On Fri, Nov 13, 2015 at 10:14 AM, Joe Stringer <joestringer@...ira.com> wrote:
>> >
>>> >> I don't follow the logic. You observed one flow which matched on
>>> >> TTL=64, therefore all vxlan packets terminated at OVS have TTL=64?
>> >
>>> >> If OVS received packets with different TTLs, they would miss and
>>> >> ovs-vswitchd would generate flows to match that traffic too.
>> >
>> > ok, that makes things a bit better, but (see next)
>> >
>>> >> If that becomes an issue, presumably the wildcard generation can be improved.
>> >
>> > is there a deep reason for vlxan "learned flows" to actually match w
>> > or w.o wild cards on TTLs?? for non-tunneled flow I don't see  this
>> > happening.
> No deep reason I'm aware of.

Hi,

We looked into the OVS kernel module, and apparently there's a check
that rejects new tunnel flows if they don't have the TTL mask set [1].

I was able to trace it to this commit [2] on the OVS tree, but I don't
quite understand why the check was added. There was some discussion
about the patch on the mailing list [3] that hints this was about
catching zero TTL, but it has too little context for me to understand.

I'm adding the author and reviewer of the patch, perhaps they can help
explain this requirement.

Regards,
Haggai

[1]
http://lxr.free-electrons.com/source/net/openvswitch/flow_netlink.c?v=4.3#L660
[2] datapath: More flexible kernel/userspace tunneling attribute.
    9b405f1aa8d175dc63ad3ffe5d0fe05d5ee09162
[3] http://openvswitch.org/pipermail/dev/2013-January/024573.html
--
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