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]

Message-ID: <20160107114935.GJ32456@pox.localdomain>
Date:	Thu, 7 Jan 2016 12:49:35 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	Jesse Gross <jesse@...nel.org>
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 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.
--
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