From owner-svn-src-head@freebsd.org Sat Aug 20 23:25:57 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7231CBC059B; Sat, 20 Aug 2016 23:25:57 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 430C31DAA; Sat, 20 Aug 2016 23:25:57 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2D95720597; Sat, 20 Aug 2016 19:25:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 20 Aug 2016 19:25:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=GhyA1fRNWhlqlLzVIAEtg6zuTFk=; b=ERoLN6 Otka4TQ0s7fi7aUC00ZBD4FT8ACKsVdKQEYYiRLutr5PRb65w+SNYvdlor4ckDaX Ofo0nyjKGQsu9ndjq1s8mHDNJ71Xmuywtc+48i4QPGnBnGzuQ69k6MTiUBoT3q4Q NbJZIUAlNQHqgjhY8+aVa/JPUViWQwWUx/20o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=GhyA1fRNWhlqlLz VIAEtg6zuTFk=; b=Y+F+S10mUNaA5Odut60dwlFJ9OCYhhtSbGiYphE/gCE0zSA iGzALGJlTOpHSYQXyL4h7FT4FbCJ8zqIQJVtp5vtbGQAH/uOJyTDeiAyHw4L2DG5 ZvkVl8gzGp1Wr7qTZxwjp7mMRLOxOM5KAtsxF3855Mx58rD39pBnBnA9fcP4= X-Sasl-enc: J12LT999O2YQnjP2/ci8YMhrCX0TtWQ5TNHG9/6kLkDr 1471735555 Received: from pion.local (cpc96954-walt26-2-0-cust843.13-2.cable.virginm.net [82.31.91.76]) by mail.messagingengine.com (Postfix) with ESMTPA id F2234CCE7E; Sat, 20 Aug 2016 19:25:54 -0400 (EDT) Subject: Re: svn commit: r304436 - in head: . sys/netinet To: Slawa Olhovchenkov References: <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> <20160820173050.GQ22212@zxy.spb.ru> <20160820184506.GV8192@zxy.spb.ru> <0f42c5fb-f930-c6e3-75d6-df97f67c201d@fastmail.net> <20160820204106.GW8192@zxy.spb.ru> <0acba141-4701-d9c2-0ddb-46d1f60ff55b@fastmail.net> <20160820220510.GX8192@zxy.spb.ru> Cc: Ryan Stone , "svn-src-head@freebsd.org" , Ryan Stone , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , Adrian Chadd From: Bruce Simpson Message-ID: <8ac23bd1-dcb3-7c64-f195-5039f9af0eaf@fastmail.net> Date: Sun, 21 Aug 2016 00:25:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160820220510.GX8192@zxy.spb.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 23:25:57 -0000 On 20/08/16 23:05, Slawa Olhovchenkov wrote: > I am think this substitution is very bad idea (by design). > Also, on transmit side this is must be irrelevant on received L2 > header (and this in many cases this is will be L2 unicast packet). For > other cases packet will be created on host and don't have any received > information. > Whilst I agree with your concerns about multipoint, I support the motivation behind Ryan's original change: optimize the common case. On the other hand, I'm suggesting a slight extension to it -- one which would probably require adoption across some L2-exposed subsystems, or anywhere which might reinterpret an M_BCAST from re-entrant encapsulation (i.e. I receive a UDP broadcast packet, but my VPN daemon then decides it needs to be NATted and forwarded somewhere else). Whilst I believe the scope for problems like this are limited (and perhaps to Netgraph permutations), I do believe they exist, and should be defensively coded for. And: If, the logic for this can be factored out into one additional bit, in a conditional branch (or small set of those) in terms of delta to the existing FreeBSD data plane path -- i.e. my suggestion; Then: we should be able to preserve correctness for multipoint configurations, without sacrificing performance. Or, a possible tie-breaker: ...we ensure that M_BCAST is cleared at all times before possible re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols decide themselves if re-entered about M_BCAST based on DMAC. > On received side for host relaing on L2 information for accepting > packet as host targeting sound like security hole. > > In router case receiving broadcast packet in any way need additional > check for dst IP address (host part is all zero or all one? what about > handling this broadcast type (RFC talk about conroling variation of > this)? what about sysctl control of receiving routed broadcast > packets? what about handling 255.255.255.255?) I believe most of this is already special-cased in ip_fastfwd.c (which gnn@ of course has merged, as it's full of sensible FIB-like operators which most router forwarding planes adopt on *their* IP input paths up to the forwarding decision), assuming the Ethernet input path colours packets with the right flags. Although, no direct distinction between IPv4 directed or undirected broadcast is made, until that code (or a full rtalloc()) is hit. In the past, I have tried to "hack around" the issue on the output (send) side, by introducing IP_ONESBCAST from BSD/OS. The fundamental problem there is that the IPv4 socket APIs were never designed to deal with 'with link' as well as 'with destination' particularly well -- i.e. to direct traffic to a particular host, with correct L2 resolution, but over a specific choice of link (or even, class of link). So, for correct behaviour when handling packets like this, the XORP FEA and libfeaclient frameworks would attempt to fully-bind control sockets requiring broadcast input where possible (OLSR being one candidate, but there are also other protocols requiring them). > In any way, this is irrelevant to L2 broadcast MAC and present L2 > broadcast flags. On the contrary, I believe in teasing as much explanation about the Layer 2 Soup 'out there' and how in FreeBSD it is treated, as this lends much background to the original problem posed by Ryan's change, to those who may not be from a primarily networking-oriented background.