From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 86C9021F240 for ; Sat, 22 Mar 2014 04:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id BD4891BD4F; Sat, 22 Mar 2014 12:08:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1395486540; bh=evefxrxYJ+KWp2vW6RQt2EfYE5OQCcDed9+g7dh7iUs=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=ka/lnE3gwD1wQYNcT3O2Wi9r4RKsxpYEiPjvgLBG3fAVABQczWdHS1DFS/UcF3OqX HwLNOnCFW43oA/zS/POFGrxXSd5y6xl+yUBIjepxNLeMQ/2PXwD1Ws8EO+0oivkPom oP6TFWiC0Aojvvwm0Gel8qIkXNzPDPkFBKhXRxtM= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller 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> Date: Sat, 22 Mar 2014 12:08:57 +0100 In-Reply-To: <608F3E46-3D81-48A3-B60C-E90661DD3AB2@gmx.de> (Sebastian Moeller's message of "Sat, 22 Mar 2014 11:26:39 +0100") Message-ID: <87eh1utrqu.fsf@alrua-x1.karlstad.toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" 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 11:09:09 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. > 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"... ;) Really, though, BCP38 (which, btw, is a Best Current Practice document From=20the 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 ;) > 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... :( > 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... > So on several other pages (like > https://gw.home.lan:81/cgi-bin/luci/;stok=3De2041363b170e62aa756a4ee3e525= f72/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 :) =2DToke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTLW9JAAoJEENeEGz1+utPtQIH/3GZcKuMmtaWFdEkC4P+goYm Yc5eRtdrxiogVTYDq25OpOe90ptx7xSjMO9g/VvxtF3x5xBGyiW+b/L59fdSj7SA CpD3kVD/EKeGzlJ1LhE+Nt4WbMjWPM1Hvc9osgXly8eKiQctSGwQqo666hRBfj/j PSimAIefTJCG63iFKY+mfWCwU9OCbvnh4cIvwBvj5JFYpQlV9UMJ0aHan2ZIulD/ yWHz/cyIwlUCq2eMyPdYqdSgtQBJF2mO2TlbUO5GZRX3/W148FlPxKa0FwzfPu6S XEpaEi+CjN/XP4hPZgmkDFWulAf5j/hANIoo8cHsc/3Lf92PpKSetXbCkjBSzQE= =skgW -----END PGP SIGNATURE----- --=-=-=--