From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B3A9C21F1D6 for ; Sat, 22 Mar 2014 12:24:03 -0700 (PDT) Received: from hms-beagle.home.lan ([84.172.116.169]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LzoSt-1XDt9H3o9L-0150Qa; Sat, 22 Mar 2014 20:24:01 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: <87eh1utrqu.fsf@alrua-x1.karlstad.toke.dk> Date: Sat, 22 Mar 2014 20:23:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D237658-E6E9-4985-AAFD-8A87256E1D77@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: =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:RS2jsx/eoLLADVra0HUzTyU2JEhajP9v05t/EwrWA5SAyXAI0W3 /v5TnmTVKN3XkILRcgjuvJONDKtFpshsap82PUeYGxDtyN+aO4Wxn81ZIYagnadYhCUfnmn sFwd/mFe8HLY6DUvYrUfKEjCc5PF4tYRWsPITqp3qi9+ChPbValDSmcauylx2uSjQ3M3bk4 hNh7D7u7IYudVLpMZfHiA== 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 19:24:04 -0000 Hi Toke, On Mar 22, 2014, at 12:08 , 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. Ah, thanks for the information. >=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"... = ;) I had not looked at it from that perspective, makes a lot of = sense... >=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 >=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 >> 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 >> 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 :) I thought a bit about this, and I think there might be a way to = use the available widgets in a way that emulates consistency ;) (well at = least in theory) If the first entry would not hog the singleton entry field with the add = button, but would spawn a new empty field with an add button, while the = just entered (and saved & applied) entry would be followed by the delete = button, he whole thing would be consistent enough to not confuse the = user. I will see whether I can implement that in the luci code. Best Regards Sebastian >=20 > -Toke