From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 56C0121F1C6 for ; Sat, 22 Mar 2014 13:20:25 -0700 (PDT) Received: from hms-beagle.home.lan ([84.172.116.169]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MSv6D-1WYmga3eir-00Rmrs; Sat, 22 Mar 2014 21:20:22 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Sat, 22 Mar 2014 21:20:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <811DC061-22A5-43FF-A0D0-720AA9E8FA1F@gmx.de> References: <3F98D180-3AF8-4AFA-80B4-A13E55CAA03A@gmx.de> <87mwgjtb8z.fsf@alrua-x1.karlstad.toke.dk> <7F1EA8E6-0C2E-471D-A24F-8D08A10998FC@gmx.de> <87ior7t9ov.fsf@alrua-x1.karlstad.toke.dk> <608F3E46-3D81-48A3-B60C-E90661DD3AB2@gmx.de> <87eh1utrqu.fsf@alrua-x1.karlstad.toke.dk> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:TyjtTJbh3jXkv2TfA7BIOC1bfq503FdZlNMalXFXgdbKJ5NlDey +tlLIxFaM636aEA4mvE8x/Lff6RNLLde99tTIvYGekfWcQXEsx9r1e92tyyn4/HCaE4hfM1 DwPzpi9RhykFVUWs4M/0FHN4KKYIiM1HBX3y5fCE4fta/BtLg0u2n+xYT3sBqEi+WobfWI9 wzx/NtBs01rlk4ZeLqpyw== Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] cerowrt-3.10.32-12 released X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 20:20:25 -0000 Hi Dave, On Mar 22, 2014, at 18:09 , Dave Taht wrote: > On Sat, Mar 22, 2014 at 11:08 AM, Toke H=F8iland-J=F8rgensen = wrote: >> Sebastian Moeller writes: >>=20 >>> I have a question about the reasoning behind the whole thing though. = I >>> can see that not permitting source addresses that do not belong to >>> cerowrt's subnets makes a ton of sense. But what precisely is the >>> reasoning to not route the private addresses? >>=20 >> Well, for IPv6, not permitting valid source addresses is exactly how >> this is implemented -- by having source-based routing for the = assigned >> prefixes (I suppose you could do a similar private address blocking >> thing for IPv6, but I punted on that for now; and don't think it's as >> important). However, for IPv4 the question of "which addresses are >> valid" becomes harder to answer in anything but the simple case of = "one >> network behind the router". I.e. for mesh networks etc. >>=20 >> At the same time, in general, egress traffic from the home network = could >> conceivably go anywhere, so blocking on destination is not viable >> either. Except, basically, for the networks being blocked by the = current >> implementation; these are all defined by various RFCs (most = well-known >> probably RFC1918) to be invalid on the internet, and so can be safely >> dropped. And since all sorts of equipment probe the default addresses >> (think users on a new net trying to find their home gateway at >> 192.168.1.1, devices that think they are on a VPN but are really not, >> etc), so packets leaking onto the internet can be quite common, and = they >> can go a surprisingly long way before being dropped, I'm told. >=20 > 0) I've seen 5 hops or more before they die. >=20 > I have observed 3 use cases in the last couple years personally. >=20 > 1) In the campground I have a primary dns server that frequently drops > off the (routed) network. 2 minutes later, all queries directed at = that dns > server start going out the default gateway, with no reply. with this = code > in place, they get stopped at the edge, with an appropriate reply, and = when > the server comes back online they are responded to normally. win. This makes a lot of sense, thanks. >=20 > 2) I have seen many worms banging away at everything in every subnet > they can find, and several that just arbitrarily bang away at = 192.168.x.y. > in cero's case these not only eat external bandwidth but interact = badly with the > "fast queue" concept - as being sparse, they are optimized to go out = the > router first, and never return=85. "Automatic worm deprioritization", we should pass this onto the = marketing department ;) Kidding aside, again makes a ton of sense. >=20 > 3) In a data center I have seen multiple attempts by sources with > invalid return addresses to leverage dns reflection attacks. Dropping > totally invalid addresses is a win=85 And even more sense. I guess I am glad I posed the question, = since I learned a lot... >=20 > That said, the primary purpose of this code is to supply a tool and = clue > to places that could do this sort of filtering better inside their = network. > small corporate campuses, isps, etc. >=20 >>> Or, asked differently what harm does it to route those except = wasting >>> a bit of bandwidth; but since the src is correct it will be = relatively >>> easy to pinpoint malicious sources that way? >>=20 >> Well, a DDOS is just a lot of people "wasting a bit of bandwidth"... = ;) >=20 > Lack of universal BCP38 has cost a lot of dns managers a lot of hair, > and more recently the ntp ddos was pretty bad. >=20 >> Really, though, BCP38 (which, btw, is a Best Current Practice = document >> =46rom the IETF: http://tools.ietf.org/html/bcp38) should be = implemented >> by ISPs to be really effective in DOS mitigation. I think = implementing >> it in cerowrt (apart from the "be secure by default" goal) is to >> demonstrate that it's possible to do a workable solution (trough = ipsets) >> that doesn't involve traversing a bunch of slow firewall rules, and = so >> doesn't impact performance noticeably. You know, the old clue-bat ;) >=20 > Perhaps this is a new logo idea for cero: A giant clue-bat. Is that bat as in micro/macrochiroptera ( = http://en.wikipedia.org/wiki/Bat ) or as in = http://en.wikipedia.org/wiki/Baseball_bat, I assume the latter but the = former would allow more leeway for the potential logo ;) >=20 >>=20 >>> The point I wanted to make is that following >>> http://wiki.openwrt.org/doc/howto/access.modem.through.nat is a bit >>> more involved than what should be required from the typical home = user. >>=20 >> Yeah, I can see that. It would probably be possible to do some >> autodetection (perhaps by crowdsourcing a database of likely modem >> addresses), but I fear the implementation would be annoyingly = complex. >> In the perfect world, you could just arping each of the addresses and >> see if they reply, but I have this nagging feeling that the kind of >> equipment we want to talk to will do things like refuse to reply to = ARP >> unless the request comes from within its own (probably hard-coded) >> subnet. In which case we would have to assign a bunch of addresses on >> the upstream interface to do the probing, then remove them again, >> leaving to all sorts of annoying potential failure modes... :( >=20 > Well, a brute force way would be to insert all these addresses with > say a one hour timeout to expire on a cold boot. I think requiring the user to add the specific address in the = white-list is not a bad way, as long as it is prominently documented. I = assume most users will not care anyway and those that are should not = mind following simple easy instructions. Best Regards Sebastian >=20 >>> Your implementation is so straight forward I could talk my siblings >>> though over the phone, so it passes my ad-hoc tests for viability in >>> the real world ;) >>=20 >> Haha, great! Sometimes I think someone should write up a formal = document >> on the "non-technical family member" test... >=20 > +1 >=20 >>> So on several other pages (like >>> = https://gw.home.lan:81/cgi-bin/luci/;stok=3De2041363b170e62aa756a4ee3e525f= 72/admin/network/hosts) >>> the GUI is used slightly different, there is one fixed add button = and >>> each entry always comes with its own delete button. I have not = looked >>> at the luci code for that though. >>=20 >> Well I didn't do a lot of research on luci primitives for this, but = did >> come across that one. That widget is a different one that mirrors a >> different configuration primitive (adding config *sections* rather = than >> a list of config *entries*). I don't *think* there's a better widget = for >> the lists, but would be happy to be proved wrong :) >=20 > In terms of featureitus it might be nice to have a comment field shown > in the gui and in the config file. >>=20 >> -Toke >>=20 >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html