From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp161.iad.emailsrvr.com (smtp161.iad.emailsrvr.com [207.97.245.161]) (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 3456B21F0CD for ; Wed, 16 May 2012 17:09:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp56.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 84E863D824C; Wed, 16 May 2012 20:09:47 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy26.wa-web.iad1a (legacy26.wa-web.iad1a.rsapps.net [192.168.4.179]) by smtp56.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 098FB3D81EC; Wed, 16 May 2012 20:09:46 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy26.wa-web.iad1a (Postfix) with ESMTP id A971E58FE3; Wed, 16 May 2012 20:09:46 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Wed, 16 May 2012 20:09:46 -0400 (EDT) Date: Wed, 16 May 2012 20:09:46 -0400 (EDT) From: dpreed@reed.com To: "Sebastian Moeller" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20120516200946000000_41165" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <6F884B65-4388-4655-8B03-4B7936ABCDE0@gmx.de> <4FB3DF2D.3070109@gmail.com> Message-ID: <1337213386.690219401@apps.rackspace.com> X-Mailer: webmail7.0 Cc: "=?utf-8?Q?=3Ccerowrt-devel=40lists.bufferbloat.net=3E?=" Subject: Re: [Cerowrt-devel] =?utf-8?q?preliminary_codel_and_fq=5Fcodel_suppor?= =?utf-8?q?t_for_cerowrt?= 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: Thu, 17 May 2012 00:09:49 -0000 ------=_20120516200946000000_41165 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ASo here's an interesting question .. can cerowrt's approach relate to FO= N? FON is not so successful in US, but in Europe, it is doing well. FON= should also adopt codel and fq_codel.=0A =0AIt may not make sense quickly,= but the 802.11p stuff that is going on in the world might be a big opportu= nity to enage with cerowrt capabilities....=0A =0A-----Original Message----= -=0AFrom: "Sebastian Moeller" =0ASent: Wednesday, May 16, = 2012 3:51pm=0ATo: "Dave Taht" =0ACc: "" =0ASubject: Re:= [Cerowrt-devel] preliminary codel and fq_codel support for cerowrt=0A=0A= =0A=0AHi Dave,=0A=0Aall of this sounds interesting, and a bit scary...=0A= =0AWhile I have a hunch that I am trying to flog a quite deceased horse her= e,I think that closed by default is the safest way to set up a secure route= r. 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 actuall= y 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 :) )= =0A=0A=0AOn May 16, 2012, at 10:52 AM, Dave Taht wrote:=0A=0A> The problem = with most home router firewalls today is that they have a strict=0A> "us" v= s "them" concept in them, and are closely tied to what can be=0A> NATed, or= not, which limits our internet to tcp and udp.=0A> =0A> Recently the conce= pt of 'guest' has been added to many devices,=0A> which doesn't work partic= ularly well.=0A> =0A> A problem with "us vs them" and extending this sort o= f thinking=0A> to ipv6, is that interesting new protocols such as=0A> sctp,= hip, rdp, dccp, rsvp esp, gre, ah, skip, ospf, vrrp, isis, manet, shim6,= =0A> wesp, and rohc=E2=80=A6=0A=0A Just to show my ignorance, but all are o= n top of IP packages, so why can these not be integrated into NAT default c= losed firewalls?=0A=0A> =0A> are all blocked by default in ipv6, too.=0A=0A= Which I think is the right thing to do, as long as opening a service is a = few mouse clicks away. =0A=0A There is too much internet enabled gear aroun= d (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 shou= ld 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...=0A=0A=0A> =0A> It do= esn't need to be this way.=0A> =0A> I have hated living in a world of purel= y tcp on port 80 and 443.=0A> =0A> Seeing udp begin to fail in multiple res= pects - such as dns,dhcp, voice, etc=0A> really bothers me.=0A=0A How is th= at related to restrictive handling of incoming data? I ask because I really= do not know. I always assumed that blocking all incoming unless either rel= ated to an already initiated connection or explicitly allowed made sense an= d should allow most things to just work. (I am totally prepared to open the= firewall for services I am interested in).=0A=0A> =0A> So cerowall attempt= ed (I've never finished it) to use pattern matching=0A> in iptables, and de= vice renaming, to make it possible to have a nearly=0A> default free zone (= DFZ) for guests, and use a bare minimum of rules,=0A> to pass through=E2=80= =A6=0A=0A That sounds great (if the secure zone stays restrictive by defaul= t, having an easy way to go into the deep end sounds great). =0A=0A> =0A> a= nd the core idea was also be able to pass ALL protocols everywhere,=0A> und= er ipv6.=0A=0A 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 dich= otomy between control and laissez faire; in theory cooperation easily beats= strict control, but in reality cooperation only works well in special case= s. 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=E2=80=A6=0A=0A> =0A> The current openwrt firewall solution scales O(= n) where n =3D the number=0A> of interfaces=0A> the cerowall idea scales O(= n) where n =3D the number of different zones.=0A> =0A> Firewalling is respo= nsible for a minimum of 11% of the current runtime,=0A> with the current fi= rewall rules, with 6 interfaces in play.=0A=0A But is that not a good part = of what a network edge router should do to "earn" its living :) =0A=0A> =0A= > CeroWall did a lot better, while opening up new vistas to play in.=0A=0A = It seems I am a chicken incapable of appreciating these vistas without worr= ying about what else could happen :)=0A=0AAnyway, I am truly interested in = learning the gains of default open routing and what risk mitigation approac= hes exist for the t scenario.=0A=0A=0ABest=0A Sebastian=0A=0A> =0A> -- =0A>= Dave T=C3=A4ht=0A> SKYPE: davetaht=0A> US Tel: 1-239-829-5608=0A> http://w= ww.bufferbloat.net=0A=0A_______________________________________________=0AC= erowrt-devel mailing list=0ACerowrt-devel@lists.bufferbloat.net=0Ahttps://l= ists.bufferbloat.net/listinfo/cerowrt-devel ------=_20120516200946000000_41165 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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. &nb= sp; FON should also adopt codel and fq_codel.

=0A

 

=0A

It may not make sen= se quickly, but the 802.11p stuff that is going on in the world might be a = big opportunity to enage with cerowrt capabilities....

=0A

 

=0A

-----Origi= nal Message-----
From: "Sebastian Moeller" <moeller0@gmx.de>
Sent: Wednesday, May 16, 2012 3:51pm
To: "Dave Taht" <dave.taht@g= mail.com>
Cc: "<cerowrt-devel@lists.bufferbloat.net>" <cer= owrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] prel= iminary codel and fq_codel support for cerowrt

=0A
=0A

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

While I h= ave a hunch that I am trying to flog a quite deceased horse here,I think th= at 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 gre= at concepts :) (even DPI is decidedly non-scary if I perform it my own netw= ork packages versus someone else doing it on my packages :) )

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

> The prob= lem with most home router firewalls today is that they have a strict
&= gt; "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.
> <= br />> Recently the concept of 'guest' has been added to many devices,> which doesn't work particularly well.
>
> A probl= em 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, an= d rohc=E2=80=A6

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

>
> are all blocked by default in ipv6, to= o.

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 interne= t 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 r= estrictive does not eradicate consequences from insecure devices but mitiga= tes it some. It should be easier to keep a single router secure than a smal= l 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 configu= ration methods). Hey, I just realize I am a pessimist and a spassbremse...<= br />

>
> 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 tha= t related to restrictive handling of incoming data? I ask because I really = do not know. I always assumed that blocking all incoming unless either rela= ted 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 ce= rowall 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=E2=80=A6

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

>
> and the core idea was a= lso be able to pass ALL protocols everywhere,
> under ipv6.
That I can not understand, as IPv6 becomes more pervasive so will expl= oits and security issues. I see the whole issue a bit as the dichotomy betw= een control and laissez faire; in theory cooperation easily beats strict co= ntrol, but in reality cooperation only works well in special cases. And fro= m 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=E2= =80=A6

>
> The current openwrt firewall solution sca= les O(n) where n =3D the number
> of interfaces
> the cerow= all idea scales O(n) where n =3D the number of different zones.
> <= br />> Firewalling is responsible for a minimum of 11% of the current ru= ntime,
> with the current firewall rules, with 6 interfaces in play= .

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

>
> CeroWall did a l= ot better, while opening up new vistas to play in.

It seems I a= m a chicken incapable of appreciating these vistas without worrying about w= hat else could happen :)

Anyway, I am truly interested in learni= ng the gains of default open routing and what risk mitigation approaches ex= ist for the t scenario.


Best
Sebastian

&g= t;
> --
> Dave T=C3=A4ht
> SKYPE: davetaht
&= gt; US Tel: 1-239-829-5608
> http://www.bufferbloat.net

= _______________________________________________
Cerowrt-devel mailing = list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloa= t.net/listinfo/cerowrt-devel

=0A
 ------=_20120516200946000000_41165--