From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4A84A21F20C for ; Sat, 22 Mar 2014 10:10:00 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so2375841wgg.6 for ; Sat, 22 Mar 2014 10:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MfP9Fork50LX8QwNoHlFAEIgJ3pHFKh1a/0Yd35QGvA=; b=zycS8VTGnylZ1HKuqZd1+BhGIkXcYHeuPyIMSWdR2Waajl4mx/AffAWqXa0LOicxvu orusbs8h+tan3WtkF76aKSPXRxVH0v+NzQ2zNfUNiV6DRraIb0ezAw5MHXF9Li5s7VcZ CBIPI69l553n1Fw3nLlTztF4dDfvkzez55WkFreR7cecnlX/KHMOjwkaO0d6nNuovP9U MRo+Dkv5KIVd8QzGkIiKACqLDvzwLf/9RkUTgvxrZWl8GCrT7KK2jkmMELxjzzDcs7No Zqxl6DORwjpf9/sYxJA/9onS7MRHR0cLMMwX0lcg4nBT7f7/GQaSkqeLuNYKHjMVA52y gXcw== MIME-Version: 1.0 X-Received: by 10.180.189.139 with SMTP id gi11mr4630203wic.53.1395508178383; Sat, 22 Mar 2014 10:09:38 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Sat, 22 Mar 2014 10:09:38 -0700 (PDT) In-Reply-To: <87eh1utrqu.fsf@alrua-x1.karlstad.toke.dk> 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> Date: Sat, 22 Mar 2014 17:09:38 +0000 Message-ID: From: Dave Taht To: =?ISO-8859-1?Q?Toke_H=F8iland=2DJ=F8rgensen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 17:10:00 -0000 On Sat, Mar 22, 2014 at 11:08 AM, Toke H=F8iland-J=F8rgensen = wrote: > Sebastian Moeller writes: > >> 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? > > 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. > > 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. 0) I've seen 5 hops or more before they die. I have observed 3 use cases in the last couple years personally. 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. 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 wit= h the "fast queue" concept - as being sparse, they are optimized to go out the router first, and never return.... 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... 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. >> 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? > > Well, a DDOS is just a lot of people "wasting a bit of bandwidth"... ;) Lack of universal BCP38 has cost a lot of dns managers a lot of hair, and more recently the ntp ddos was pretty bad. > Really, though, BCP38 (which, btw, is a Best Current Practice document > From 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 ;) Perhaps this is a new logo idea for cero: A giant clue-bat. > >> 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. > > 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... :( Well, a brute force way would be to insert all these addresses with say a one hour timeout to expire on a cold boot. >> 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 ;) > > Haha, great! Sometimes I think someone should write up a formal document > on the "non-technical family member" test... +1 >> So on several other pages (like >> https://gw.home.lan:81/cgi-bin/luci/;stok=3De2041363b170e62aa756a4ee3e52= 5f72/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. > > 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 :) In terms of featureitus it might be nice to have a comment field shown in the gui and in the config file. > > -Toke > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html