Subject: [homenet] Security goals

From: Tim Chown <[email-masked]>
Date: Sun, 11 Mar 2012 01:04:33 +0000

It's good to see some traction in service discovery and naming.

We also have a fifth area, security.  The text as it stands says a few
things that apply to this area, e.g.

a) An assumption of "Simple Security" with default deny on the CER.  
    This implies PCP or uPnP to support punching holes.  The text 
     also talks about addressability vs reachability.

b) Mention of appropriate mechanisms for users to associate 
    devices, and that devices may need keys configured, e.g. WPA2.
    So we should be aiming for these tasks to be as simple as possible. 

c) The possibility to say that a ULA source indicates a connection
    within the home. Suggested by Chris Palmer in Quebec, but not
    discussed since.

d) Mention of "Advanced Security", which talks about the ability to
     install 3rd party policies.  Some have suggested removing this
     from the initial homenet spec.

e)  Discussion of (determination of) network borders; these are
     points at which policies may apply.  In the "self-configuring"
     section we talk more on that task.  Homenets may have internal
     policy borders, e.g. between private and guest areas.

There's certainly scope to put down more in the way of goals; any 
comments in this area are welcome.

Tim

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 10 Mar 2012 21:28:03 -0800

>     also talks about addressability vs reachability.

I still disagree with this premise that we must default deny and have a
mess of inadequate and complex  signalling to compensate . Can someone
articulate a threat model that requires this default deny and state
tracking ? Or must we put the cart before the horse without facts presented
(maybe I missed that detailed presentation of threats) ? Because win2k
required a network based firewall, we must always cripple e2e?

Or, can homenet simply say home devices must be independently secure, may
have host based firewalls, or they must be placed in a properly screened
subnet of fundamentally flawed devices that require network security
controls and multi device port coordination ?

Cb
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Tim Chown <[email-masked]>
Date: Sun, 11 Mar 2012 17:25:39 +0000

On 11 Mar 2012, at 05:28, Cameron Byrne wrote:
> I still disagree with this premise that we must default deny and have a mess of inadequate and complex  signalling to compensate . Can someone articulate a threat model that requires this default deny and state tracking ? Or must we put the cart before the horse without facts presented (maybe I missed that detailed presentation of threats) ? Because win2k required a network based firewall, we must always cripple e2e?
> 
> Or, can homenet simply say home devices must be independently secure, may have host based firewalls, or they must be placed in a properly screened subnet of fundamentally flawed devices that require network security controls and multi device port coordination ?
> 
> 

The -02 that is coming soon still has "simple security" as a default position, but also states a requirement for support of RFC 6092's transparent mode.  That should be something a residential user can enable simply, if they choose to do so.

Tim

---

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Mar 2012 13:36:24 -0400

>>>>> "Tim" == Tim Chown <[email-masked]> writes:
    Tim> It's good to see some traction in service discovery and naming.

    Tim> We also have a fifth area, security.  The text as it stands
    Tim> says a few things that apply to this area, e.g.

There are two categories: security services provided by homenet.
(Your a-d).  And security required by homenet. (Your (e)).

Let's keep those two sections seperate!

I think we need a 3.3.4. Security Considerations for security required by
homenet.   It is here that we need to put the limits on what a solution
can demand.

Parts (a-d), belongs in 3.4.  

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Mar 2012 13:40:52 -0400

>>>>> "Cameron" == Cameron Byrne <[email-masked]> writes:
    >> We also have a fifth area, security.  The text as it stands says
    >> a few things that apply to this area, e.g.
    >> 
    >> a) An assumption of "Simple Security" with default deny on the
    >> CER.  This implies PCP or uPnP to support punching holes.  The
    >> text also talks about addressability vs reachability.
    >> 

    Cameron> I still disagree with this premise that we must default
    Cameron> deny and have a mess of inadequate and complex signalling
    Cameron> to compensate . Can someone articulate a threat model that
    Cameron> requires this default deny and state tracking ? Or must we
    Cameron> put the cart before the horse without facts presented

+1

I think that the question as to whether or not "Simple Security"
defaults to on is a seperate question as to whether or not "Simple
Security" MUST be available to be turned on.

    Cameron> Or, can homenet simply say home devices must be
    Cameron> independently secure, may have host based firewalls, or
    Cameron> they must be placed in a properly screened subnet of
    Cameron> fundamentally flawed devices that require network security
    Cameron> controls and multi device port coordination ?

so, if such a subnet is to exist (and it could be virtual thanks to
things like NEA), then Simple Security still needs to be implemented.

In my mind, to get around the "NAT is security, e2e is bad" CROWD, which
is ALL OVER THE PLACE out there (not here at the IETF, where we are much
more clueful. I'm talking about people with phony letters after their titles
who have never heard of the IETF), we need to have an answer, and that
answer must be very clearly labelled, such that it can be turned off by
people who want it.

---

From: Dave Taht <[email-masked]>
Date: Sun, 11 Mar 2012 18:15:11 +0000

On Sun, Mar 11, 2012 at 5:40 PM, Michael Richardson <[email-masked]> wrote:
>    >> It's good to see some traction in service discovery and naming.
>    >>
>    >> We also have a fifth area, security.  The text as it stands says
>    >> a few things that apply to this area, e.g.
>    >>
>    >> a) An assumption of "Simple Security" with default deny on the
>    >> CER.  This implies PCP or uPnP to support punching holes.  The
>    >> text also talks about addressability vs reachability.
>    >>
>

I have a tendency to drag discussions down into implementation details,
and I apologize in advance here for not having a high level viewpoint,
on what could be, vs what is.

I recently sat down with jg to try and implement a useful amount of ipv6,
with a useful amount of security.

The biggest problem I ran into was that nearly every useful service
had an acl that required enabling before it could be used inside the
network in the first place. In a dynamically (PD assigned) world,
this would mean that  trigger scripts would have to be fired off
to alter these on every change, and daemons restarted, and
there are related problems....

the list:

polipo web proxy: acl needed to access it at all via ipv6,
                           needed to be blocked from the outside
bind9 - acl needed in order to distinguish between 'us' and 'them' queries,
           needed a distinct ipv6 address for 'external' queries
radvd - dnssl is not widely supported on clients
dhcp - helpful to have an autoconfiguration based naming scheme -
          (assign an ipv4 address, force an ra message, ping6 to see
if the device has it,
            if so, add the autoconfed ipv6 address  to dns)
mrd6 - specific addresses/interfaces assigned
pim - I haven't ever seen pim on ipv4 or ipv6, actually work
routing daemon (babel/ospf/whatever) - needs configuration from scratch, almost
web server - things like wpad.domain.wherever should work only on the inside
web server for router configuration - should only be available inside
dhcp-pd - big headache as yet
rsync - I LIKE rsync and don't mind it being entirely open
bidirectionally. That's me.
ssh - I trust ssh, LIKE leaving it open bidirectionally.

And the converse was also a problem:

Several other services (notably samba/cifs) were open to the world
via ipv6 by default.

I'm pretty sure these ports shouldn't be open to the world, and
the simplest way was to block them via the firewall, and not
use acls.

In addition to the above cases, the concept of having a 'guest' network
in the home complicates matters even further, as by what scheme
can you dynamically assign addresses, and retain security.
Certain devices (printers for example) should be available inside
in all cases, your accounting server or home security webcam system,
not so much....

In the polipo case, (I note that a ipv6/ipv4 capable translating web proxy
is darn useful) there is presently no way to distinguish between
an internal guest network and a normal internal network.

So I provide these cases as food for thought only. I too, would like
E2E connectivity restored, but there are some services that
should not be available out to the wild, woolly internet over ipv6.

Requiring that all ipv6 services use PCP or upnp to open an
incoming port is also a can of worms.

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Mar 2012 16:49:07 -0400

>>>>> "Dave" == Dave Taht <[email-masked]> writes:
    Dave> The biggest problem I ran into was that nearly every useful
    Dave> service had an acl that required enabling before it could be
    Dave> used inside the network in the first place. In a dynamically
    Dave> (PD assigned) world, this would mean that trigger scripts
    Dave> would have to be fired off to alter these on every change, and
    Dave> daemons restarted, and there are related problems....

(thus in the windows world, where you have to reboot all the time)

What I think is happening in the Linux-kernel-based desktop world 
(i.e. GNOME/KDE, which includes man *BSD systems too, of course), is
that dbus is being used to announce new addresses.    It's less obvious
that this should be used for routers/servers, but I think it will become
the thing.

So, what we actually need from your list of things to be tweaked is a
list of what inputs they need for the tweaking.  The mechanism for the
tweaking could evolve, so long as we can keep the naming of each
parameter consistent.

    Dave> In addition to the above cases, the concept of having a
    Dave> 'guest' network in the home complicates matters even further,
    Dave> as by what scheme can you dynamically assign addresses, and
    Dave> retain security.  Certain devices (printers for example)
    Dave> should be available inside in all cases, your accounting
    Dave> server or home security webcam system, not so much....

So, this is where the naming and categorization of services is
important.

The first slide here:
    http://www.ietf.org/proceedings/81/slides/homenet-5.pdf

was bemoaning the lack of anything between local link, and world.
And I think the take-home from your list is that there is nor only the
"Home", but also the "Trusted home" and "Guest home"

---

From: Fred Baker <[email-masked]>
Date: Sun, 11 Mar 2012 14:44:35 -0700

>     from the initial homenet spec.

One of these days I'll figure out what is "advanced" about "advanced security". I think the point of interest is that it can be expected to not be maintained (how many people maintain their norton-or-whatever-firewall contracts?) and will therefore allow a lot of stuff through.

I will be doing a talk in opsawg trying to make the firewall story a little less "I don't like this and I do like that", more about what a firewall does and doesn't do and what models one might consider - at least three of them. If there is interest in homenet, I could comment on that discussion.

http://tools.ietf.org/html/draft-baker-opsawg-firewalls
  "On Firewalls in Internet Security", Fred Baker, 20-Jan-12

---

From: Fred Baker <[email-masked]>
Date: Sun, 11 Mar 2012 14:55:00 -0700

Hmm. I just scheduled the agenda, and homenet and opsawg conflict. I may or may not be able to wander from one meeting to the other.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 12 Mar 2012 10:44:11 +0100

> Let's keep those two sections seperate!

I was about to commenting on the same, that we have two different
security settings here.

About security for end-users, why should it be deny by default? It
don't really rise the security level by much since  virus/trojans get
in through user initiated action, and out again just as easy in the
background.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 12 Mar 2012 22:27:02 -0400

>  "On Firewalls in Internet Security", Fred Baker, 20-Jan-12

Any chance of having such a conversation in the Security Area WG?  I mentioned the debate to Sean Turner (Security AD), and he thought it would be an excellent topic for security experts to discuss.  However, since there had been no discussion on list, I did not get around to writing a draft, so I have nothing to submit for the agenda.

Lee

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Mar 2012 23:04:35 -0700

> Any chance of having such a conversation in the Security Area WG?  I mentioned the debate to Sean Turner (Security AD), and he thought it would be an excellent topic for security experts to discuss…

I'm willing to enough to have the conversation there. I'd just like to have the conversation, as we seem to throw bats around regarding firewalls with ever really reaching a conclusion beyond "they are a market requirement regardless of what anyone thinks about them technically".

opsawg chairs, the issue is that homenet and opsawg conflict and I don't do a very good imitation of myself in a separate working group.

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Mar 2012 15:25:34 -0700

On Mar 12, 2012, at 2:44 AM, Roger Jørgensen wrote:
> About security for end-users, why should it be deny by default? It don't really rise the security level by much since  virus/trojans get in through user initiated action, and out again just as easy in the background.

From my perspective, there is a question of what is being defended and of defense in depth, and a question of market requirement.

I agree that a firewall of any kind doesn't defend the host, since the vast majority of attacks come from behind the firewall. What a firewall defends is primarily the bandwidth within the defended domain - which would be best done if the firewall was at the ISP (before the typical bottleneck link).

However, it does prevent certain kinds of messages from getting to a host that don't have a reason to get there. The net effect is to make the attack surface of the host smaller from the perspective of attacks from the outside - the attack has to thread two needles, not just one.

The general argument against "default deny" is that it prevents legitimate traffic from reaching the host. I'll argue that this is exactly the right model for traffic that the host has no application to process - traffic that look legitimate but isn't because of the set of applications running on the host. Take, for example, a host that is prepared to operate as an http client but not a server; a packet directed to an http server on it is going to be refused by the host, and could be refused anywhere in the path. The problem with something that is literally "default deny" is that it needs a way to identify and apply rules like "sending smtp to smtp.example.com is reasonable". I'll argue that protocols like PCP are reasonable ways to do that; "default deny" plus PCP does *not* prevent legitimate traffic from getting to the host, but it does prevent unwanted traffic from arriving at the host.

You'll ask why I care. I care for two reasons.

First is a personal experience. At my home, I have a standing load of about 25 (plus or minus) packets per second that are discarded by the firewall. I don't know what they are, and I don't honestly care. They don't have my permission to be in my network, and I have to assume that if they were to get into it, the hosts in my network would have to deal with them.

Second and more importantly, this came up with James Woodyat was building the Airport Express IPv6 capability for Apple, and is the reason that he wrote what is now RFC 6092. He released a product that provided an IPv6 CPE router, and his marketing department came back and told him that a firewall capability was a market requirement for such a product - "if you don't build it, we can't sell it." Now, you can argue that it *shouldn't* be a market requirement; I'll let you tilt at that windmill if you like. Cisco is building IPv6 firewalls as well, and various other folks are. The reason is not that we want to run out and sell folks on the idea. It's that people tell us that they won't buy our networks without them.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Mar 2012 13:38:13 +1300

On 2012-03-14 11:25, Fred Baker wrote:
...

>From time to time I look at TCPView to see what's going on. At this
instant, to my knowledge, I'm doing nothing on my machine except typing
this email. TCPView tells me I have 63 endpoints (sockets) open, with
18 established TCP connections, and 14 sockets listening. Admittedly
some of these sockets are connected to the loopback address, but even
so, it's scary. What are all those .exe files listening on a socket
all day?

Windows Firewall is dropping about 3 UDP packets per second, and that's
behind our campus firewall.

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

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.

   Brian

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 13 Mar 2012 18:16:04 -0700

On Mar 13, 2012 5:38 PM, "Brian E Carpenter" <[email-masked]>
wrote:
> > First is a personal experience. At my home, I have a standing load of
about 25 (plus or minus) packets per second that are discarded by the
firewall. I don't know what they are, and I don't honestly care. They don't
have my permission to be in my network, and I have to assume that if they
were to get into it, the hosts in my network would have to deal with them.
> 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.

> first wireless card (late 1999?). But we can't assume that applies to

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

Cb

---

From: Thomas Herbst <[email-masked]>
Date: Tue, 13 Mar 2012 18:21:49 -0700

The Apple marketing department had some external input -

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-1338

On 3/13/12 3:25 PM, "Fred Baker" <[email-masked]> wrote:

>>don't really rise the security level by much since  virus/trojans get in
>>through user initiated action, and out again just as easy in the
>>background.
>
>From my perspective, there is a question of what is being defended and of
>defense in depth, and a question of market requirement.
>
>I agree that a firewall of any kind doesn't defend the host, since the
>vast majority of attacks come from behind the firewall. What a firewall
>defends is primarily the bandwidth within the defended domain - which
>would be best done if the firewall was at the ISP (before the typical
>bottleneck link).
>
>However, it does prevent certain kinds of messages from getting to a host
>that don't have a reason to get there. The net effect is to make the
>attack surface of the host smaller from the perspective of attacks from
>the outside - the attack has to thread two needles, not just one.
>
>The general argument against "default deny" is that it prevents
>legitimate traffic from reaching the host. I'll argue that this is
>exactly the right model for traffic that the host has no application to
>process - traffic that look legitimate but isn't because of the set of
>applications running on the host. Take, for example, a host that is
>prepared to operate as an http client but not a server; a packet directed
>to an http server on it is going to be refused by the host, and could be
>refused anywhere in the path. The problem with something that is
>literally "default deny" is that it needs a way to identify and apply
>rules like "sending smtp to smtp.example.com is reasonable". I'll argue
>that protocols like PCP are reasonable ways to do that; "default deny"
>plus PCP does *not* prevent legitimate traffic from getting to the host,
>but it does prevent unwanted traffic from arriving at the host.
>
>firewall. I don't know what they are, and I don't honestly care. They
>don't have my permission to be in my network, and I have to assume that
>if they were to get into it, the hosts in my network would have to deal
>with them.
>
>Second and more importantly, this came up with James Woodyat was building
>the Airport Express IPv6 capability for Apple, and is the reason that he
>wrote what is now RFC 6092. He released a product that provided an IPv6
>CPE router, and his marketing department came back and told him that a
>firewall capability was a market requirement for such a product - "if you
>don't build it, we can't sell it." Now, you can argue that it *shouldn't*
>be a market requirement; I'll let you tilt at that windmill if you like.
>Cisco is building IPv6 firewalls as well, and various other folks are.
>The reason is not that we want to run out and sell folks on the idea.
>It's that people tell us that they won't buy our networks without them.

---

From: Ashok Narayanan <[email-masked]>
Date: Tue, 13 Mar 2012 23:29:48 -0400

On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote:

> 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? 

> 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?

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).

-Ashok

---

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Mar 2012 15:39:30 +1100

In message <[email-masked]>, Ashok Narayanan wr
ites:
> >=20
> > > That's reality, and much as I love the e2e principle I think the =
> ordinary
> >=20
> >=20
> > 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.
> >=20
> 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?=20
> 
> 
> > > first wireless card (late 1999?). But we can't assume that applies =
> to
> > > every home device.
> > >
> >=20
> >=20
> 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?
> 
> 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).

And for most of them "drop !RA-ANNOUNCED(source)" would be sufficient
and achieves what a default drop at the CPE does.  What would be
really good would be to add a site prefix length to the RA prefix
option.  There is room in the option to do this.  Knowing this would
be useful for source/destination address selection.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 13 Mar 2012 22:11:19 -0700

On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan <[email-masked]> wrote:
> 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.

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.

> 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.

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.

Homenet is a unique opportunity to restore end to end ... or as some
would say... the internet model.. Smart end points, dumb network.

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

---

From: Randy Turner <[email-masked]>
Date: Tue, 13 Mar 2012 22:20:48 -0700

You can have real e2e even with a middlebox performing some type of security, so e2e and CPE-firewall are not mutually exclusive.

The CPE firewall (we really need to decide the functionality of what we're calling a firewall here) would be a way to centralize some amount
of security policy for the home network.  Having every device on the home network support a complete security solution is not realistic.  Seems like
the CPE will be involved for some aspects of security that are common to the home network, and then there would be devices on the home network that
are also "secured", possibly depending upon the application or functionality of the device.

Consumers are not going to want to manage security policy in 20 different ways on the home network for 20 different devices.  I think at a minimum, the ISP (or NSP) may want to offer a "managed security" service for the CPE to take over the burden of the average consumer having to know what the details of security policy.

Randy

---

From: "Mr.R.A.Hunter" <[email-masked]>
Date: Wed, 14 Mar 2012 12:04:37 +0100

My personal take on the situation is that security threats and tolerance 
levels vary per organization and per individual. There's no point in the 
IETF trying to perform a Business Impact Analysis and then attempting to 
generate the appropriate Security Norms as defined in the ISO27000 
series on behalf of all Internet users. It simply can't be done.

Suggested Homenet Security Goal: Provide feature equivalence to today's 
IPv4 solutions that are already widely deployed in the home.

Simple, clear, and addresses the concerns expressed in the NIST advisory 
CVE-2007-1338 and the marketing department.

Or would you like to swim against the tide of operational expectations 
and huge installed base of devices inherited from IPv4? That would seem 
to me like a very bad idea to deploy as default behavior in a dual stack 
World where IPv4 and IPv6 run in parallel over the same devices and links.

Equally, choosing for a security model based on equivalence with 
existing IPv4-functionality would at first glance seem to place 
draft-vyncke-advanced-ipv6-security-03 out of reach until the devices 
were IPv6 only. But to me that draft just seems like too radical a step 
towards an IDP type approach to be able to gain traction quickly in the 
home, at least as default behavior. Who's going to want to pay for 
maintaining attack signatures?

One useful compromise would be for Homenet to explicitly add the option 
for a user to be able to completely disable the default stateful packet 
filtering firewall of RFC6092 (ask a grown up before selecting this 
option), so that the user could deploy the model described in 
draft-vyncke-advanced-ipv6-security-03 using their favorite open-source 
IDP with attack signatures, or other security  model, should they really 
want to.

Intentionally disabling /bypassing NAT and the built in firewall in IPv4 
devices was really hard. IMHO We should at least make that easy in 
Homenet devices for those who really want non-default behavior (via PCP 
and manual configuration options).

regards,
RayH

Cameron Byrne wrote:
>
>
> On Mar 13, 2012 5:38 PM, "Brian E Carpenter" 
> <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > > First is a personal experience. At my home, I have a standing load 
> of about 25 (plus or minus) packets per second that are discarded by 
> the firewall. I don't know what they are, and I don't honestly care. 
> They don't have my permission to be in my network, and I have to 
> assume that if they were to get into it, the hosts in my network would 
> have to deal with them.
> >
> 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.
>
> > [email-masked] <mailto:[email-masked]>

---

From: Ashok Narayanan <[email-masked]>
Date: Wed, 14 Mar 2012 10:04:31 -0400

> forward without being beholden to the Morris worm and X.25

So as a thought experiment, does your hypothesis hold for any sort of {firewall|NAT|blocking-device}? In other words, are you unconvinced that any sort of centralized connection-management/protection device at the home edge is not required? Or are you specifically unhappy about a SPI firewall?

> does not have a technical justification for obstructing e2e flows.

Doesn't that translate to "I haven't seen any security flaws in Software X so far, so it is inconceivable that it would ever occur". This is proof by example.

> allow the bad guys in as well.

No, I don't agree. The customer may well not even know that a device in his home is running old/compromised software.

This is a classic separation-of-costs problem. The product developer has to weigh off security of his firmware (audits, continuous updates, etc) against development cost. The thing that is most visible to the consumer is cost, with security being a nebulous "nice-to-have". Hence, the product developer is incentivized to cut costs by not doing the things he needs. This is not universal, but common enough.

> have not once ever administered one (except sometimes i turn off the

Again, proof by example. Can you make the same statement about not-as-clueful family members? I for one get phone calls from my mom (in Washington DC) every time her Norton firewall pops up a window. 

But that's not the point, really, since the issue of permissions exists for firewalls anywhere. The protection role of a NAT/firewall is not so much to protect home computers (since they are capable of protecting themselves). It's to protect non-computer networked devices. 

> firewall will protect this device?

By blocking connections to a management port left open by a careless coder that might allow a remote exploit to install DDoS software on it?

It doesn't solve all problems, but removes at least one attack surface.

> does not need the CPE to filter for it.  This is a good case for ULA

Sure, and that would be a nice solution to this problem at least in my mind - simple and mostly effective. But there are other discussions on these lists that specifically talk about _not_ doing this, as a way to get around issues seen with NAT today.

> path.  Tolerating broken software is also not the right path.

A worthy goal, but kinda like saying "airbags give an illusion of security. Speeding should not be tolerated". IOW, not gonna happen.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Mar 2012 11:16:54 -0400

>>>>> "Mark" == Mark Baugher <[email-masked]> writes:
    Mark> IETF Homenet will have a default policy for security and
    Mark> protocol operation, etc.  Future vendors who ship Homenet may
    Mark> choose to change the default policy, and users who use Homenet
    Mark> may want to change the policy that the vendors ship.  So I
    Mark> would expect that there may be policies that are required for
    Mark> compliance and many others that are recommended.  Why can't

Assuming that we get over the hurdle of having vendors and ISP implement
and deploy homenet, and homenet security, whatever we set as the
recommended default will be what is there for 99% of users, and
therefore what anyone writing an application that has to live in the
home is going to have to deal with.
(That you and I can change our policies is great, but doesn't help 
someone selling a new application to grandma)

So, if we recommend something which does not facilitate e2e, including
incoming connections, then we have killed e2e.  While I'm not happy
about Simple Security + PCP, I prefer that to killing e2e.

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Mar 2012 09:07:34 -0700

On Mar 14, 2012, at 4:04 AM, Mr.R.A.Hunter wrote:

> One useful compromise would be for Homenet to explicitly add the option for a user to be able to completely disable the default stateful packet filtering firewall of RFC6092 

I suspect that they have it in any product, but it may be useful to say that it is a requirement.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Mar 2012 08:41:12 +1300

> 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

---

From: james woodyatt <[email-masked]>
Date: Wed, 14 Mar 2012 12:56:46 -0700

On Mar 14, 2012, at 08:16 , Michael Richardson <[email-masked]> wrote:

> whatever we set as the recommended default will be what is there for 99% of users, and therefore what anyone writing an application that has to live in the home is going to have to deal with.

A point I have been trying to make for several years now is that we have already set a recommended default in many places for "block all incoming connections" at unmanaged Internet gateways.  We probably had a chance to reverse course on this for IPv6 in the middle of the last decade, but not anymore.  We now have a strategic direction we have been following for quite some time now, and we have too much invested in it to turn back.

I think the credit for preserving the continuity of the IPv4/NAT experience with the transition to IPv6 should go to the IAB and the IESG.  The HOMENET architecture should throw in the towel on E2E and go with RFC 6092 on by default at the border gateway.  It should be silent about PCP until something can be done about its lack of explicit support for nested security domains.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 14 Mar 2012 12:57:14 -0700

> protected against such traffic?

"If a tree falls in a forest and no one is around to hear it, does it
make a sound?"

I can assert that if the low-end homenet device is not listening on
TCP port 80, the TCP SYN to port 80 will cause no new harm, firewall
or not.

Now, if there is 80mb/s of TCP SYN coming in, maybe it is a DOS ....
and the link is saturated, firewall or not.

Alternatively, if there is 1 mb/s of TCP SYN coming in, and the
firewall is doing SPI, the firewall will likely choke on session per
second creation.... Thus the DOS is cheaper and easier to achieve.

In my operational experience, session overloading and misconfiguration
of firewalls has created more problems than hacks prevented by
firewalls.  If you are running a a 10 year old version of IIS, and you
are hosting an internet web page, and you have port 80 open,  that CPE
firewall is not going to help at all.

If the low level device should not be communicating with the internet,
then a link-local or ULA address can be one layer of segmentation.

Fred made a good assesment that the firewall is just protecting the
LAN bandwidth from junk.  I can buy that. But assuming LAN > WAN in
capacity, and usually by an order of magnitude, it is still not
justified IMHO.

My main concerns is stateful inspection of every session, it is a
terrible waste to import this legacy thinking into homenet. And, it
effectively makes IPv6 the same experience as NAT44... everything over
port 80.

CB

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 14 Mar 2012 13:07:21 -0700

> I think the credit for preserving the continuity of the IPv4/NAT experience with the transition to IPv6 should go to the IAB and the IESG.  The HOMENET architecture should throw in the towel on E2E…

I disagree with your pessimism, but not with your summary of reality.

If that really is the case, then i am not sure why HOMENET exist.

So far, all i have gleaned from this group is debates about problems i
consider pretty far fetched and irrelevant.  Turing routing protocols
on cheap routers is not interesting to me.... in fact, i am so boring,
and admin a network all day long, that i cant imagine why anyone in
their right mind would want more than one subnet in their home.... but
that is just me (and 99% of all home users).  I have the same apathy
towards multihoming.

Making IPv6 restore e2e, or the internet model, is a worthy goal and i
am glad to help... But, if HOMENET is throwing in the towel, i can
lurk somewhere else and you folks can keep debating about OSPF vs RIP
and thinking that SPI makes something secure.

CB

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Mar 2012 13:12:34 -0700

On Mar 13, 2012, at 10:11 PM, Cameron Byrne wrote:
> 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 don't recall anyone saying that a "stateful inspection" firewall was specifically called for. I think we argued that there is a market expectation that a firewall is at least available, and that however the firewall is implemented, it should prevent simple attacks from "outside" the network (I will argue "network layer attacks" as opposed to combing through bits in layers above). As we get into the specifics of kinds of firewalls, I think we're treading even more heavily on people's religion.

As to "kinds of firewalls", I have a posted draft (which I think I mentioned), which might be discussed in opsawg and might be discussed in the Security Area meeting. I haven't heard a decision on that. I would suggest we defer to that discussion. However, as far as *this* draft goes, I think that it is fair to say that

 - a CPE Router MAY include a firewall function.

 - IF such a function is implemented, it MUST be possible to disable
   it, reducing the CPE to a simple router.

   (my rule on the use of "MUST": I use the term when failing to
   do so breaks something, and I try to say what breaks. In this
   case, a CPE Router that has a firewall that can't be turned off 
   cannot be used as an interior router in the home network)

 - IF it is a "deny all" firewall, it SHOULD have a means of providing
   access rules for services inside the home, such as allowing SMTP
   to an SMTP server or ISP access to a set-top box. PCP or other
   protocols like it MAY be used to achieve that.

 - IF it is a role-based firewall, it SHOULD have a means of
   configuring and using roles.

 - IF it is a stateful inspection, reputation-based, or anomaly 
   detection firewall, it SHOULD have a way to maintain the indicated
   tables such as periodic download of signed files from a trusted
   site.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 15 Mar 2012 09:56:39 +0100

Whilst I don't disagree significantly with Fred's list (which seems to 
match the functionality of the installed IPv4 base), I think the 
challenge for Homenet is going to be to make this requirements list work 
in a multi-vendor environment out of the shrink wrap (Homenet 
architecture by definition assumes more than one CPE device). To me, 
ensuring interoperability is the main added value of the Homenet WG.

I therefore humbly submit that language based on "MAY" is generally not 
going to cut it for Homenet.

Here are my suggested modifications of Fred's list, for further improvement.

1) s/a CPE Router MAY include a firewall function/a Customer Edge Router 
(CER) SHOULD implement a mechanism to facilitate egress and ingress 
access control of traffic crossing the external border of the Homenet. 
This MAY be implemented either as a firewall or as simple IPv6 Access 
Control List (ACL)./

ACL being debatable, but it's functionality that exists today in IPv4 
and which works. Who am I to say that isn't "good enough" for some 
folks' security needs? As an end-user, I'm all for functional 
equivalence with IPv4.

2) For me it's debatable whether the Homenet WG needs to further define 
how this egress or ingress control functionality actually processes 
traffic. That's something IMHO where vendors can differentiate their 
products, and which can evolve over time.

Perhaps:
/The firewall MAY be functionally defined by 
draft-ietf-v6ops-cpe-simple-security or 
draft-vyncke-advanced-ipv6-security-03. Other functional definitions of 
the ingress and egress access control mechanism may be introduced to 
Homenet later. As a general principle, equivalent security controls 
SHOULD be applied to both IPv4 and IPv6 traffic when running in dual 
stack mode at the external boundary./

3) s/IF such a function is implemented, it MUST be possible to disable 
it, reducing the CPE to a simple router./
It MUST be possible to disable the ingress and egress access control 
function to reduce the CER to a simple router, and the mechanism to 
achieve this SHOULD ...../

In this case, "be manual" or do you want the device to "auto-detect that 
the device is acting as a CER"?
I think this is pretty essential for ensuring that Homenet works as a 
system when users plug and play kit from various vendors.
Perhaps the detail is best left for another day.

4) s/IF it is a "deny all" firewall, it SHOULD have a means of providing 
access rules for services inside the home/
IF it is a "deny all" ingress mechanism, it SHOULD have a means of 
providing access rules for services located inside the home, and the 
mechanism to achieve this SHOULD be ...../

"PCP"?

If PCP isn't considered by the WG to be "good enough" for the task of 
acting as the Homenet control protocol for the ingress and egress 
security function, then I submit that the challenge is either going to 
be to make PCP "good enough", or come up with an alternative. I am 
neutral on what the control protocol should be. But there's no doubt in 
my mind that we really should define an open and standard control 
protocol to configure the ingress and egress access control mechanism 
(to ensure interoperability,  to preserve e2e, and to ensure the sanity 
of developers and end users).

regards,
RayH

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 15 Mar 2012 14:13:40 +0100

On Wed, Mar 14, 2012 at 9:07 PM, Cameron Byrne <[email-masked]> wrote:
<snip>
> and thinking that SPI makes something secure.

I don't think we should throw in the towel just yet.... as I see it,
homenet should by default _not_ care about traffic into homenet. That
is the CPE's job. A seperate feature and function.

However, homenet should _support_ the creation of several security
"zones" internaly
* One that is isolated toward The Big Bad World (Internet), no
communication toward the CPE functionality
* One that _ask_ the CPE to block all traffic into it
* One that allow every packet that flow.....
* whatever else we might figure out etc...

The only default one should be allow all (leave the job to CPE)

-- 

Roger Jorgensen           |

---

From: Jim Gettys <[email-masked]>
Date: Thu, 15 Mar 2012 11:26:29 -0400

I'd like to get away from the worshipping of end-to-end (which I
genuflect at that altar as much as anyone), and bring it back to reality
slightly, amplifying a bit on some bits I've seen in parts of this long
thread.  I think Stuart Chesire pointed out remotely in the Philadelphia
ftf meeting that attack surface is a real issue, and I think it is a
rapidly growing issue.

Here's reality:

o the number of devices has been growing exponentially in people's
houses: first it was one machine, then one/person, and now it's the
TV(s), BluRay player(s) phones, NAS boxes, TiVO, Roku Box, Apple TV, and
often more than one computer/person, IP camera(s), thermostat(s) (I just
ordered a Nest to play with), printers, etc. This is the concrete
example of my house, but even the grandparent's house I visit isn't that
far behind, with around 3 laptops and a TiVO and a printer.

More and more of these devices are "legacy" devices already that sit and
rot without software updates (concrete example: the NAS box I have which
hasn't seen a software update now in about 3 years).  This is a huge
problem, but not one this working group can undertake.  Certainly the
consumer electronics Linux efforts are trying to help this problem via
the Linux foundation efforts.

But I don't think this problem is going to go away, and certainly not in
my lifetime.  Even if rotting hardware didn't exist, and it all had the
right UI's to let you control its access, you're asking the poor home
manager to learn the management UI on all devices just to ensure the
right policies are in case: this means there is essentially *zero*
chance of succeeding.

o there are certain policies I really want to enforce: the one that Dave
Taht and I ran into last week installing the latest CeroWrt was the
following: to ensure that Microsoft file services were *not* accessible
by default to the outside; we had a bug that it was accessible via IPv6.

My reasoning is the following:  the RIAA would like me to legally liable
for accidental sharing of my CD collection that I've digitised.  So I
really want to prevent this accidental sharing of a misconfigured laptop
or NAS box; I really, really want to make sure it fails, so that my door
is not left "unlocked" by accident.  And there is lots of other personal
data I'd also not like to share.  So despite the fact that this is at
best a half-measure, when we detected that via IPv6 the default firewall
rules allowed such access on CeroWrt, Dave set it to deny, and I expect
that that is what most people will want/need.  In fact, for my NAS
device, I really want to ensure that *all* ports are blocked from
outside, since it's OS has been rotting and its attack surface grows
with almost every passing day.

So I'm not interested in default-deny in general; but I sure want to be
able to easily do deny-all or deny a particular service to particular
devices, or particularly insecure protocols to everyone (e.g. microsoft
file sharing).  For our general laptops, which are kept decently up to
date, I probably *do* want almost all ports open (with the exception
again of things like file sharing services, for the reason given above).

This is yet another example of the *primary* utility of firewalls;
reduce the attack surface, particularly to vulnerable systems, and  to
try to prevent things getting *out*, rather then coming in.  In my
example, I just want to be able to appear in court and say to the judge:
"my door was locked".  As a way of keeping things out: we know that
doesn't work in general; at most firewalls can reduce the attack surface
from the outside.

Ok, what have I been thinking about doing for CeroWrt, that is more nuanced?
==============================================

I've been thinking about this problem a lot this week, as I need to put
time based controls to help my son control his game playing, have been
thinking about visibility of internal names to the global internet, and
how to ensure diffserv is handled properly (if the home gateway has no
controls over diffserv for users, then it will be gamed to uselessness
by applications/devices).  I'm writing this lengthy message in part as
it's helping me to make my thinking concrete.

I'm really not worried about someone using my printer from outside: I
suppose that they can waste some paper and toner, and if that becomes a
problem, I'll put other (per person) access control on it.  But for
printer devices, I'll want a policy that opens my IPv6 capable printer
to the world on some protocol, so I can easily print from anywhere. 
Since it's firmware is not frequently updated by HP, I probably want all
other ports "closed", just to reduce it's attack surface.  I don't know
if the printer has an internal firewall or not...

For actively maintained laptops/phones, I'll want a policy that allows
pretty much full access, with the exception of file sharing, where I'll
want my kids and wife to have to come see me to do anything out of the
ordinary (until we have file sharing protocols  that enforce strong
authentication).

On top of this basic policy, I may want to add the time based control
for my son.

My NAS box(es) I want default deny all, until/unless someone can sell me
one (or I set one up myself) that does both strong authentication and is
auto-updating its system.

Similarly, depending on the update rate of the firmware and how general
the device is, I may have other nuanced policies I'd like to have the
firewall enforce.

OK, where does this leave me?

o having a firewall at all is necessary, if only to try to protect
myself from the RIAA and rotting devices in my home.  My primary systems
are mostly kept up to date and wander all over the Internet, between
work and school.

o knowing what class of device it is may help a lot in setting the
firewall rules.  It might be useful to define a protocol that devices
can inform the environment what they are to automate this, but something
like that isn't going to happen any time soon and then presents yet
another way to attack the system.

So I need a way to associate a device (IP address or mac address) with a
particular default rule (e.g. file server, printer, thermostat, camera
and so on).  On top of that I may have other access rules (e.g. no
public internet access at all for my son after he should be in bed, so I
can stop losing sleep every night).  So it may be a device belongs to
more than one class of device.  You can think of a laptop as something
which can be any class of device...  But the user of that laptop may
need other policies ;-).

o end users can't have to know about port numbers or firewall rule
languages; gotta do something pretty simple.

o firewall rules that are global to all devices aren't what I want: I
need to set the rules on a per-device basis.

o because of attack surface issues, saying "just put devices into a DMZ"
is an insufficient answer as those devices may not have actively
maintained firmware and I want to reduce the attack surface against
those devices.  It isn't clear to me what a DMZ buys other than more
complication.  So on the KISS principle, I want to avoid DMZ's.

o keeping track of all devices in my home has become a real problem: I
want my home router to keep track of all MAC addresses it sees; from
that (the physical device), I can associate a policy.

So we'll see where I get to on all this.  But it's a lot easier to think
about these problems if you are actually trying to solve them
yourself... (Hint... Hint...  Hint.... Help very welcome!).
                        - Jim

---

From: Colin Dixon <[email-masked]>
Date: Thu, 15 Mar 2012 16:18:32 -0500

[email-masked] wrote on 03/14/2012 02:57:14 PM:
> From: Cameron Byrne <[email-masked]>
> To: Brian E Carpenter <[email-masked]>,
> Cc: Ashok Narayanan <[email-masked]>, Roger Jørgensen
> <[email-masked]>, Fred Baker <[email-masked]>, "[email-masked]
> Group" <[email-masked]>, Michael Richardson <[email-masked]>
> Date: 03/14/2012 02:58 PM
> Subject: Re: [homenet] Security goals
> Sent by: [email-masked]
>

If the LAN is wireless (as it almost certainly will be), then there
is no clean way to assert that LAN > WAN and, even more so, any
extra traffic on the WLAN can cause problems w.r.t. power
consumption for devices with batteries.

--Colin

---

From: Mark Townsley <[email-masked]>
Date: Wed, 21 Mar 2012 00:19:59 +0100

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 wider 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

---

From: Robert Cragie <[email-masked]>
Date: Mon, 26 Mar 2012 11:24:37 +0100

(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<[email-masked]>  wrote:
<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>
> does not need the CPE to filter for it.  This is a good case for ULA
<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>
> 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>
> 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>

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 27 Mar 2012 22:58:01 +0000

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-masked] [[email-masked]] on behalf of Mark Townsley [[email-masked]]
Sent: Tuesday, March 20, 2012 4:19 PM
To: [email-masked] Group
Subject: Re: [homenet] Security goals

- Datalink establishment

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.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2012 14:53:02 +1300

> 1. Homenet hosts MUST implement their own security policies in accordance to their computing capabilities.

I think we know from some famous cases that SCADA systems are highly
insecure, mainly due to following this principle (translated as
"security is too hard and this device will always be on a private
network anyway"). I'm a bit nervous that this policy will encourage
low-end device designers to classify their devices as not having
enough resource to deal with security.

    Brian

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 27 Mar 2012 20:29:39 -0700

On Mar 27, 2012 6:53 PM, "Brian E Carpenter" <[email-masked]>
wrote:
> > 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.
> enough resource to deal with security.

This category should / will be eliminated by market forces, too much
liability associated with being willfully insecure.  There are famous cases
for this too.

If internet segmentation is all that is required, there are address types
that facilitate local only access.

Cb

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 28 Mar 2012 05:47:44 +0000

Brian,

I personally would definitely want to see a stronger statement that hosts should be implementing means sufficient to perform end 2 end communication securely on any network, without requiring additional protections from outside. But I guess a few people would then argue that some hosts can't implement the same degree of security protection as  the degree e.g. tablets and PC can - and that guess led to the current lanuage.

If you think it should be changed to some stronger statement, do you have something specific in mind?

-Dmitry

________________________________

From: Cameron Byrne [[email-masked]]
Sent: Tuesday, March 27, 2012 8:29 PM
To: Brian E Carpenter
Cc: Mark Townsley; Dmitry Anipko; [email-masked] Group
Subject: Re: [homenet] Security goals

> enough resource to deal with security.

This category should / will be eliminated by market forces, too much liability associated with being willfully insecure.  There are famous cases for this too.

If internet segmentation is all that is required, there are address types that facilitate local only access.

Cb
> [email-masked]<mailto:[email-masked]>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 28 Mar 2012 12:20:51 +0100

I think there are two orthogonal aspects here. There is one regarding 
the ability for host to perform end to end communication securely (i.e 
with integrity and/or confidentiality). This goes without saying and I 
agree there needs to be a strong statement regarding this. However this 
is orthogonal to a host's ability to handle all manner of traffic which 
could be directed to it, especially malicious traffic. Ideally hosts 
would be able to handle this and the recommendation would still be to 
require hosts to firewall their own data. When a host is implemented on 
a platform with plenty of storage and processing power, this is not 
really an issue. However, in the LLN case, hosts may be running on 
platforms which have very little storage and processing power by 
comparison with limited ability to firewall. I do not think we should be 
precluding these type of devices.

Robert

On 28/03/2012 6:47 AM, Dmitry Anipko wrote:
>
> Brian,
>
> I personally would definitely want to see a stronger statement that 
> hosts should be implementing means sufficient to perform end 2 end 
> communication securely on any network, without requiring additional 
> protections from outside. But I guess a few people would then argue 
> that some hosts can't implement the same degree of security protection 
> as  the degree e.g. tablets and PC can - and that guess led to the 
> current lanuage.
>
> ------------------------------------------------------------------------
> *From:* Cameron Byrne [[email-masked]]
> *Sent:* Tuesday, March 27, 2012 8:29 PM
> *To:* Brian E Carpenter
> *Cc:* Mark Townsley; Dmitry Anipko; [email-masked] Group
> *Subject:* Re: [homenet] Security goals
>
>
> On Mar 27, 2012 6:53 PM, "Brian E Carpenter" 
> > > 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).
> > >
> liability associated with being willfully insecure.  There are famous 
> cases for this too.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Mar 2012 08:42:25 +1300

Maybe we should add a statement that device designers must assume
that DDoS and other forms of malicious traffic are present on
the homenet, as well as a statement that all traffic may be visible
to unknown third parties. A sort of generic threat model for homenets.

Regards
   Brian

---

From: Robert Cragie <[email-masked]>
Date: Fri, 30 Mar 2012 23:02:11 +0100

I like the idea of developing a generic threat model for homenets. This 
should frame what we are up against and make it clearer what the 
appropriate countermeasures should be and where they are best placed.

Robert

On 28/03/2012 8:42 PM, Brian E Carpenter wrote:
>>> <[email-masked]<mailto:[email-masked]>>  wrote: