netdev - Re: OVS VXLAN decap rule has full match on TTL for the outer headers?

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:	Wed, 2 Dec 2015 10:04:16 -0800
From:	Jesse Gross <jesse@...nel.org>
To:	Joe Stringer <joe@....org>
Cc:	Haggai Eran <haggaie@...lanox.com>,
	Or Gerlitz <gerlitz.or@...il.com>,
	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>,
	Pravin B Shelar <pshelar@...ira.com>
Subject: Re: OVS VXLAN decap rule has full match on TTL for the outer headers?

On Wed, Dec 2, 2015 at 9:52 AM, Joe Stringer <joe@....org> wrote:
> On 29 November 2015 at 05:06, Haggai Eran <haggaie@...lanox.com> wrote:
>> 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.
>
> I'm not the author or reviewer, but it seems like this is an attempt
> to prevent flows from matching TTL=0 then proceeding to forward the
> frame. You could still match a non-zero TTL with a wildcarded mask,
> but it wouldn't be possible for a single flow to match all (non-zero)
> TTL values.

You can match on TTL=0 as long as you do it explicitly. The assumption
though is that this isn't what most people want to do if they don't
specify any value so it would be bad default.

However, it looks like while this was primarily targeted at the key,
the check also bled over into the mask translation as well, preventing
it from being wildcarded through omission. It's still not clear to me
that this makes any difference in the real world though.
--
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