As someone who works for a host software vendor, I'd like to add couple of points. I agree with Mark that in general the security topic is wider than only filtering on the borders of the realms of the traffic destined to hosts, and I support the efforts to figure out the right set of knobs for the former. That said, for the latter, I'd like to see something along the below lines in the requirements (some of which may already be in the text in some form, putting it here just for fluency of this piece of the story).
1. Homenet hosts MUST implement their own security policies in accordance to their computing capabilities. 2. Homenet routers MUST preserve the integrity of the security boundary - for example, not allow into the realm an ingress traffic sourced from addresses of the destination realm. 3. Homenet routers MAY apply additional filtering to the traffic destined to hosts and crossing security boundaries. 4. If a router applies such filtering (3), it MUST provide: 4.a. a way for participating hosts to enable per-host exemption from such additional filtering; 4.b. an information to hosts, based on which the router would apply such additional filtering if there was no exemption. An example of a signalling protocol for (4.a) could be PCP (extended if needed). An example of information 4.b is definition of the security boundaries and a the way to provide it could be prefix information option in RA, with additional marking allowing to distinguish guest routes from "core" home routes. The motivation for these: while it is a fact of life that there may be some devices on the network, having less built-in protections than others due to many reasons, it seems logical to provide for those devices, which are capable to implement rich security functionality, a way to be in full control of their behavior. -Dmitry ________________________________________ From: [email protected] [[email protected]] on behalf of Mark Townsley [[email protected]] Sent: Tuesday, March 20, 2012 4:19 PM To: [email protected] Group Subject: Re: [homenet] Security goals Let me try and up-level a bit architecturally, because this is more than just about whether we turn on or off a firewall on a particular border. Consider two routers fully within a homenet Now, list all the types of traffic and information that might be exchanged between those routers, e.g., - Datalink establishment - IP addressing for the link - IP Prefixes reachable by the router (what a "routing protocol" would do) - Services present on the router itself - Services on connected links propagated via the router - User traffic - etc... Our job is to determine what kind of link exists between two routers and start crossing out items, in whole or in part, based on how promiscuous we wish the routers to be on that link. In effect, we are deciding where to break the network and where not to, but it is by doing this that we carve out the separate "home", "guest" and "Internet" realms that we are targeting to create. I think that what is most important at this moment is to nail down what knobs we want to try and have available, what their "out of the box" defaults are for the above 3 combinations of border types, and allow for super-users, ISP-managed devices, etc. monkey around with them as they wish according to what vendors and providers can dream up. If we can agree on these, and still remain blocked on what kind of firewall to recommend to be enabled by default, we will still have accomplished quite a bit. So I'd like to encourage us to step out of the firewall rathole for a moment, and look at this from a w ider angle. Further, if we *really* want to talk about goals for security of our homenet routers, we should consider mandating the ability to download bug fixes and security updates. Far and away, this has been what has made hosts more secure in the past decade, why a home router would be exempt from this baffles me. - Mark On Mar 14, 2012, at 8:41 PM, Brian E Carpenter wrote: > On 2012-03-14 18:11, Cameron Byrne wrote: >> On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan <[email protected]> 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 > > Fred and I provided factual but local evidence of background radiation > of unwanted UDP packets. Actually there is a lot more systematic evidence > of this too. For example, this week at the PAM conference in Vienna > there's a paper "One-way traffic monitoring with iatmon" by Nevil Brownlee > that gives a detailed analysis of observed unwanted traffic, both UDP and TCP > SYN. > See http://www.caida.org/publications/papers/2012/one_way_traffic_iatmon/ > > Can you assert that all low-end homenet devices will be internally > protected against such traffic? > > Bian > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
