[Cerowrt-devel] preliminary codel and fq_codel support for cerowrt

[dpreed at reed.com]

So here's an interesting question .. can cerowrt's approach relate to FON?   FON is not so successful in US, but in Europe, it is doing well.   FON should also adopt codel and fq_codel.
 
It may not make sense quickly, but the 802.11p stuff that is going on in the world might be a big opportunity to enage with cerowrt capabilities....
 
-----Original Message-----
From: "Sebastian Moeller" <moeller0 at gmx.de>
Sent: Wednesday, May 16, 2012 3:51pm
To: "Dave Taht" <dave.taht at gmail.com>
Cc: "<cerowrt-devel at lists.bufferbloat.net>" <cerowrt-devel at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt



Hi Dave,

all of this sounds interesting, and a bit scary...

While I have a hunch that I am trying to flog a quite deceased horse here,I think that closed by default is the safest way to set up a secure router. If it is easy to open it up for incoming services easily than everything is golden. As long as I control the router control and restriction actually become great concepts :) (even DPI is decidedly non-scary if I perform it my own network packages versus someone else doing it on my packages :) )


On May 16, 2012, at 10:52 AM, Dave Taht wrote:

> The problem with most home router firewalls today is that they have a strict
> "us" vs "them" concept in them, and are closely tied to what can be
> NATed, or not, which limits our internet to tcp and udp.
> 
> Recently the concept of 'guest' has been added to many devices,
> which doesn't work particularly well.
> 
> A problem with "us vs them" and extending this sort of thinking
> to ipv6, is that interesting new protocols such as
> sctp, hip, rdp, dccp, rsvp esp, gre, ah, skip, ospf, vrrp, isis, manet, shim6,
> wesp, and rohc…

 Just to show my ignorance, but all are on top of IP packages, so why can these not be integrated into NAT default closed firewalls?

> 
> are all blocked by default in ipv6, too.

 Which I think is the right thing to do, as long as opening a service is a few mouse clicks away. 

 There is too much internet enabled gear around (say like my ipod) which is not really be trustworthy nor can be audited easily to go to open by default. Having the router be restrictive does not eradicate consequences from insecure devices but mitigates it some. It should be easier to keep a single router secure than a small armada of end user devices behind this thing (and so much easier to give TLC to one firewall instead of several all using slightly different configuration methods). Hey, I just realize I am a pessimist and a spassbremse...


> 
> It doesn't need to be this way.
> 
> I have hated living in a world of purely tcp on port 80 and 443.
> 
> Seeing udp begin to fail in multiple respects - such as dns,dhcp, voice, etc
> really bothers me.

 How is that related to restrictive handling of incoming data? I ask because I really do not know. I always assumed that blocking all incoming unless either related to an already initiated connection or explicitly allowed made sense and should allow most things to just work. (I am totally prepared to open the firewall for services I am interested in).

> 
> So cerowall attempted (I've never finished it) to use pattern matching
> in iptables, and device renaming, to make it possible to have a nearly
> default free zone (DFZ) for guests, and use a bare minimum of rules,
> to pass through…

 That sounds great (if the secure zone stays restrictive by default, having an easy way to go into the deep end sounds great). 

> 
> and the core idea was also be able to pass ALL protocols everywhere,
> under ipv6.

 That I can not understand, as IPv6 becomes more pervasive so will exploits and security issues. I see the whole issue a bit as the dichotomy between control and laissez faire; in theory cooperation easily beats strict control, but in reality cooperation only works well in special cases. And from that perspective I see allow all incoming IPv6 as a gamble that will fail once the population of users grows beyond the early-adopter tech crowd…

> 
> The current openwrt firewall solution scales O(n) where n = the number
> of interfaces
> the cerowall idea scales O(n) where n = the number of different zones.
> 
> Firewalling is responsible for a minimum of 11% of the current runtime,
> with the current firewall rules, with 6 interfaces in play.

 But is that not a good part of what a network edge router should do to "earn" its living :) 

> 
> CeroWall did a lot better, while opening up new vistas to play in.

 It seems I am a chicken incapable of appreciating these vistas without worrying about what else could happen :)

Anyway, I am truly interested in learning the gains of default open routing and what risk mitigation approaches exist for the t scenario.


Best
 Sebastian

> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20120516/522450b7/attachment.html>