netdev - Re: [ovs-dev] [PATCH net 0/2] vxlan: Set a large MTU on ovs-created vxlan devices

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, 7 Jan 2016 08:35:35 -0800
From:	Jesse Gross <jesse@...nel.org>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	David Wragg <david@...ve.works>,
	David Miller <davem@...emloft.net>, dev@...nvswitch.org,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [ovs-dev] [PATCH net 0/2] vxlan: Set a large MTU on ovs-created
 vxlan devices

On Thu, Jan 7, 2016 at 3:49 AM, Thomas Graf <tgraf@...g.ch> wrote:
> On 01/06/16 at 04:46pm, Jesse Gross wrote:
>> On Wed, Jan 6, 2016 at 4:14 PM, Hannes Frederic Sowa
>> > I don't see any other way as to make MTUs part of the flow if we want to
>> > have correct ip_local_error notifications. And those must also work across
>> > VMs, so openvswitch in quasi brouting mode would need to emit ICMP PtBs
>> > (hopefully with a correct source address, otherwise uRPF kills them before
>> > reaching the applications) or do error signaling via virtio_net.
>>
>> I actually implemented this a long time ago and then there was some
>> additional discussion on this about a year ago. I agree it's the right
>> solution overall but it's not entirely clearly to me how to get the
>> details correct.
>
> When I looked into this last, the wildcard flow model of OVS  made this
> difficult to get 100% right. That said, I don't think we have to do
> the actual dropping in OVS itself but the signaling has to back to OVS
> and ultimately the source. We don't want to replicate the entire flow
> cache model in OVS.
>
> A simple start could be to add a new return code for > MTU drops in
> the dev_queue_xmit() path and check for NET_XMIT_DROP_MTU in
> ovs_vport_send() and emit proper ICMPs.

That could be interesting. The problem in the past was making sure
that ICMPs that are generated fit in the virtual network appropriately
- right addresses, etc. This requires either spoofing addresses or
some additional knowledge about the topology that we don't currently
have in the kernel.
--
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