(catching up on the homenet ML...)

Comments inline, bracketed by <RCC></RCC>

Robert

On 14/03/2012 5:11 AM, Cameron Byrne wrote:
On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan<ash...@cisco.com>  wrote:
On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote:


That's reality, and much as I love the e2e principle I think the ordinary
citizen is better off behind default-deny.

I am not trying to be dense, but why?

What is the negative scenario of not having a homenet firewall on? Using
real examples from the last 5 years .... I would like to know how a cpe
firewall protects against real threats to modern software.

It seems hard to predict a priori what a "real threat" is going to be. And
it seems unlikely that "modern software" is all that will be found in
average homes. For example, will the Android version on the refrigerator
display be updated?

Agreed about a priori.  BUT! what else do we have to go on?  I am
asking for a baseline to justify why a CPE firewall is required.  In
fact, i have asked for it multiple times on this thread, and all i get
back is anecdotal hand waving, not technical reasons.

Putting the E back in IETF, let's see some data about why this
function  of the system must exist.

My cursory research says you are not going to be able to present a
convincing amount of data to support the fact that a stateful
inspection firewall should be applied in a contemporary home
environment.  I believe the spirit of Homenet is moving the internet
forward without being beholden to the Morris worm and X.25

You mention Android running on the refrigerator, as if i am supposed
to be concerned about that?  Can you cite an example of an Android
security flaw that a CPE firewall  would have ever prevented?  My
guess is no, android does not listen on any ports (default
non-root)... thus no inbound connections... thus... stateful firewall
does not have a technical justification for obstructing e2e flows.
<RCC>That may indeed be the way devices work now (client only, pulling information or setting up some arcane push mechanism) but in the future we are much more likely to see devices running server communicating P2P or asynchronously. Therefore these devices will be listening on ports, and these devices may well need to be reached from outside the CP zone.<RCC>

If you want to talk about rooted devices running BIND 4.0, well...
that person that is wise enough to manually do that i likely wise
enough to allow the relevant firewall rules or PCP interactions to
allow the bad guys in as well.

Personally I haven't run without an on-board firewall since I got my
first wireless card (late 1999?). But we can't assume that applies to
every home device.

Most PC software has shipped with a firewall on for the last ~10 years

And these have to be then managed, and the triggers for "should this flow be
allowed" will then transition to the PC as opposed to the CPE. Did the
system become any simpler, really?

I think there is some 3rd party off the shelf software that does these
pop-ups.... but the PCs i run with native firewalls have never popped
up to me like that.  But, i agree... pop ups are not helpful.

As an end user, i can proudly say i have a host based firewalls, but i
have not once ever administered one (except sometimes i turn off the
FW so i can ping my PC)

But the real issue to my mind is _non-PC_ software; the firmware on some
power-line bridge written for the cheapest dollar by pulling together some
version of Linux because the device had to sell for $25. Not only do all
these devices now need firewalls (unlikely), they now need an easy way to
manage these firewalls (next to impossible).

power-line bridge?

Once again, please paint for me a realistic scenario of how a CPE
firewall will protect this device?

My first statement is that this device should not have a globally
routable address, and therefore is not exposed to the internet, and
does not need the CPE to filter for it.  This is a good case for ULA
in IPv6.
<RCC>So by using ULAs, you have a clear demarcation point for the CP zone. I am not sure what the problem is in allowing policing at this demarcation point to make the attack surface lower (Fred's "threading two needles"). I also agree with Fred's statement that the primary purpose of a firewall is for defending the bandwidth in the defended domain. Sure, there is additional administration but it is much more feasible to administer at a CPE router than a device which may have no UI on it at all (e.g the pool pump controller)</RCC>

Second, crappy software should not be tolerated or compensated for in
Homenet.  Setting the president that flawed software is acceptable is
a slippery slope to somewhere bad.  If it takes making application and
host security requirements for endpoint, so be it.  Passing the buck
to the CPE/Firewall to give the illusion of security is not the right
path.  Tolerating broken software is also not the right path.
<RCC>I don't think anyone is proposing the use of a firewall as sticking plaster for crappy software but there has never been anything wrong with a belt 'n' braces approach.</RCC>

Homenet is a unique opportunity to restore end to end ... or as some
would say... the internet model.. Smart end points, dumb network.
<RCC>Some of these end points may not have the resources to be that smart. We can't preclude these from homenet.</RCC>

If we need a smart network, then lets make a real solid fact based
exploration of threats and then we can select the appropriate
compensating security controls.

CB

-Ashok

Cb
   Brian
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to