Re: [Cerowrt-devel] cerowrt-3.10.32-12 released

["Toke Høiland-Jørgensen" <toke@toke.dk>]

[-- Attachment #1: Type: text/plain, Size: 4114 bytes --]

Sebastian Moeller <moeller0@gmx.de> 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 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 ;)


> 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=e2041363b170e62aa756a4ee3e525f72/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 :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]