Subject: Re: [homenet] Next steps

From: Ray Bellis <[email-masked]>
Date: Fri, 9 Dec 2011 10:26:15 +0000

On 17 Nov 2011, at 10:16, Mark Townsley wrote:

First, we'd like to formally move draft-chown-homenet-arch-01 to draft-ietf-homenet-arch-00. This of course does not mean that the document is finished, just that this will be the document the working group will recognize as its collective work in progress until it becomes an RFC. If anyone has substantive objections to this, please let us know within the next week (i.e, by Nov 25).

As there have been no objections, we have approved the submission of draft-chown-homenet-arch-01 as a WG item which should happen shortly.

Second, we'd like to reiterate our call for people who have a particular routing protocol that they believe would be a good candidate for application to the homenet problem space, please let the WG know via an Internet Draft submission. Reason being is that we have fewer homenet documents submitted thus far than we have heard chatter about in terms of possible solutions. Also, a routing solution was listed as one of our first deliverables when homenet was chartered.

Currently the only relevant draft is Acee and Jari's "draft-acee-ospf-ospfv3-autoconfig".

We'd therefore like to re-reiterate this call, as no alternate drafts have been forthcoming!

Minutes of the meeting will be coming soon.

They're available at <http://tools.ietf.org/wg/homenet/minutes>

Ray and Mark

---

From: james woodyatt <[email-masked]>
Date: Fri, 09 Dec 2011 15:36:53 -0800

On Nov 17, 2011, at 06:28 , Michael Richardson wrote:
> 
> I do not think that there is a consensus as yet as to how much security
> is enough.   I think that this is going to be a major sticking point.

Why is the question so rarely about how much security is too much?

--
j h woodyatt <[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Dec 2011 19:33:20 -0500

> Why is the question so rarely about how much security is too much?

And why, even more rarely, is the question about what needs to be secured, and how can it be effectively secured?

In this case I think the amount of security that we want is enough so that we don't get accidental network joins and we don't get malicious network joins without physical access.   A lot of security that doesn't accomplish this is useless.  Not enough security that doesn't accomplish this is also useless (unless we decide that we don't care about this, which I think would be a mistake).

---

From: Tim Chown <[email-masked]>
Date: Sat, 10 Dec 2011 16:02:52 +0000

> As there have been no objections, we have approved the submission of draft-chown-homenet-arch-01 as a WG item which should happen shortly.

I have just done this - it is the same text as the previous draft, no edits have been made post-meeting (yet).

Tim

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Dec 2011 13:15:39 -0500

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

    Ted> And why, even more rarely, is the question about what needs to
    Ted> be secured, and how can it be effectively secured?

    Ted> In this case I think the amount of security that we want is
    Ted> enough so that we don't get accidental network joins and we
    Ted> don't get malicious network joins without physical access.  A

And, it would all be easy if we could rely on physical access, but there
are wireless hops, and we haven't clearly said we want to delegate that
problem into 802.1x/WPA.  In particular, we've talked about the
opposite, that the "one network password" thing which is already
necessary for the WPA, could be leveraged for the wired as well.

I see a few ways out, mutually exclusive:
  1) all devices shall have an interface that can have a WPA-equivalent
     string entered into them before they can join the homenet.

  2) there shall be no security at layer-3: physical wire access is
     enough, and we shall rely on WPA/WEP to live up to its name and
     give us "Wired Equivalent Privacy"
        
  3) security at layer-3 shall be implemented in all devices that have
     a wireless interface.  Physical security will suffice for wired
     interfaces.   All wireless devices shall be capable of accepting a
     WPA-key, and will use this to build layer-3 security for wireless
     networks which do not include an WEP.

(#3 is for the case where you want to permit someone visiting your
 network, and using your Guest ESSID to also get a prefix delegated.  You
 have to tell the guest to your home some kind of WPA-like thing for
 layer3, but you aren't letting them on your "secure" wifi)

-- 
]       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: james woodyatt <[email-masked]>
Date: Mon, 12 Dec 2011 11:23:34 -0800

On Dec 9, 2011, at 16:33 , Ted Lemon wrote:
> 
>  enough so that we don't get accidental network joins

>From where I stand, it seems like it should completely obvious to everyone in this discussion that the distinction between an accidental network join and an intentional one is undecidable by any kind of automatic system within our power to define.

I think our documents should be VERY CLEAR on this point.  I'm absolutely serious.  We are dealing with an environment where the average person inserting tab A into slot B (either physically or virtually) is usually proceeding in a trial and error fashion.

They don't say, "I want to join these two networks together."  They have a more nebulous idea in mind, like, "I want this group of devices (e.g. the phones my house guests bring with them, the home theater system, the home office workstations) to be able to get that kind of service (the public Internet, the house printer/scanner)," and they start inserting plugs into jacks until it works.  In an environment like that, every network join event is an accidental one, until it seems to be working acceptably, at which point it becomes the intentional one.

This is where the cognitive load of our designs will either make or break our chances of establishing a useful standard.  If security considerations make the construction of IETF standard home networks by trial and error impractical, because the cognitive load required to keep track of which authentication credentials are required for authorization to access which services in what domains with whose privileges, then the IETF standard will lose.

We must not preclude the assembly of standard home networks by trial and error.

---

From: Randy Turner <[email-masked]>
Date: Mon, 12 Dec 2011 11:34:05 -0800

I basically agree with what James is stating here, but we're talking about the "error" part of the "trial and error" -- we can allow "plug this in to see if it works…" but we need a consumer friendly way to tell him it doesn't work (The "error" part)

Randy

On Dec 12, 2011, at 11:23 AM, james woodyatt wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2011 14:47:55 -0500

> From where I stand, it seems like it should completely obvious to everyone in this discussion that the distinction between an accidental network join and an intentional one is undecidable by any ki…

I'm not sure whether or not to be offended by how little faith you have in our intelligence, James.  Of course the system can't *decide* what is an accidental join and what is intentional.   That's the point of trying to come up with a design that will make it so that some kind of deliberate action has to be taken to cause the networks to join, and that they don't just spontaneously join.

Clearly this system has to be something that people can get working in a fairly trial-and-error fashion, as you propose, without some deep (or even particularly shallow) understanding of how networks work.   But particularly wireless devices can't be *completely* promiscuous, or you will get automatic accidental network joins.

Apple actually sells wireless devices that join, and has a UI that is used to get them to join.   It doesn't work very well—it seems to require someone like me to get it to work, because my father can't do it, and he's no dummy.   So I understand your inclination to throw up your hands and say it can't be done.   Maybe you're right.   But I think it's worth discussing.

---

From: Russ White <[email-masked]>
Date: Sat, 24 Dec 2011 09:53:32 -0500

>      string entered into them before they can join the homenet.

It would be interesting to consider a layer 2 connection between all the
devices in the homenet simply to share information between the devices
themselves --I.e., every device, on connecting, must join a virtual
layer 2 domain where every device can reach every other device in one
hop (layer 3). This would give us a handy way to share information and
learn capabilities, etc.

We could specify such a thing by asking every homenet device to act as a
bridge and a router, and using the bridged side only for control plane
(not for user traffic).

:-)

Russ

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Dec 2011 09:24:40 -0500

>>>>> "Russ" == Russ White <[email-masked]> writes:
    >> 1) all devices shall have an interface that can have a
    >> WPA-equivalent string entered into them before they can join the
    >> homenet.

    Russ> It would be interesting to consider a layer 2 connection
    Russ> between all the devices in the homenet simply to share
    Russ> information between the devices themselves --I.e., every
    Russ> device, on connecting, must join a virtual layer 2 domain
    Russ> where every device can reach every other device in one hop
    Russ> (layer 3). This would give us a handy way to share information
    Russ> and learn capabilities, etc.

What's the advantage of having this layer-2 area which must communicate
with STP (to avoid loops), vs using OSPF at layer-3?  STP doesn't work
for multiple 1q tags, so you'd have to use MSTP...

Given that layer-2 can be tunnelled trivially, I see no advantage.

Chairs: I think that the question of minimal security is a difficult
one, and I think that have made no progress on this.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Dec 2011 19:12:11 +0200

I think that discovering how far you can extend your bridged network is an interesting topic. (Do we have any IEEE or other solutions for that? I'd like to know...)

I'm not sure what the value of bridging and then separating the payload traffic to a routed network is.

And yes, security is difficult. I'd approach the security question from three angles. First, "do no harm". Whatever we do, should not create more opportunities for attacks than existed before the automatically managed homenet technology came around. I think this should be relatively easy, but of course it is also not a big win either. The second angle is easy user interfaces. If you want true enterprise-class security, someone is going to have to configure something somewhere. However, it might be possible to re-employ one secret for multiple purposes (with some key derivations in between, of course) such as enter one key and that becomes ýour WPA key _and_ your OSPF router key. The third angle is better-than-nothing security. It may be possible to design something that allows you to insert devices into the network and provide leap-of-faith security, but once the leap-of-faith phase is over, the system is secure for outsiders trying to get in. Some examples of this include 
ssh-like authentication of routers ("do you really want to add fe80::bad as a new router?") and some resource ownership ideas (a new router cannot take over existing router's resources). But the devil is in the details. I'm just saying there are opportunities.

Jari

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Dec 2011 12:54:29 -0500

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:
    Jari> better-than-nothing security. It may be possible to design
    Jari> something that allows you to insert devices into the network
    Jari> and provide leap-of-faith security, but once the leap-of-faith
    Jari> phase is over, the system is secure for outsiders trying to
    Jari> get in. Some examples of this include ssh-like authentication
    Jari> of routers ("do you really want to add fe80::bad as a new
    Jari> router?") and some resource ownership ideas (a new router

It is really easy to do this, if you have a UI you know the user is
going to visit.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Dec 2011 19:09:09 +0100

Hello Jari:

In the Manemo world we discussed those properties under yet another CIA acronym.

This time it meant Capability (can that router get my packets where I want them to go), Innocuousness (can my relationship with that router be harmless for both parties) and Anonymity (because we were dealing with inside and outside). With those properties ascertained, we'd allow mobile routers to attach to one another in a TIT for TAT fashion.

There are interesting ways by which those CIA properties could be achieved, but that requires a lot more text... The core thing was: no PKI. 

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: mercredi 28 décembre 2011 18:12
To: Michael Richardson
Cc: Russ White; [email-masked]
Subject: Re: [homenet] Next steps

And yes, security is difficult. I'd approach the security question from three angles. First, "do no harm". Whatever we do, should not create more opportunities for attacks than existed before the automatically managed homenet technology came around. I think this should be relatively easy, but of course it is also not a big win either. The second angle is easy user interfaces. If you want true enterprise-class security, someone is going to have to configure something somewhere. However, it might be possible to re-employ one secret for multiple purposes (with some key derivations in between, of course) such as enter one key and that becomes ýour WPA key _and_ your OSPF router key. The third angle is better-than-nothing security. It may be possible to design something that allows you to insert devices into the network and provide leap-of-faith security, but once the leap-of-faith phase is over, the system is secure for outsiders trying to get in. Some examples of this include ssh-like authentication of routers ("do you really want to add fe80::bad as a new router?") and some resource ownership ideas (a new router cannot take over existing router's resources). But the devil is in the details. I'm just saying there are opportunities.

Jari

---

From: Russ White <[email-masked]>
Date: Thu, 29 Dec 2011 11:36:03 -0500

> Given that layer-2 can be tunnelled trivially, I see no advantage.

Actually, I was thinking of a tunneled layer 2 subnet across all "edge
devices." The point would be that if all the edge devices can
communicate in a straightforward manner, it makes solving a lot of other
problems much simpler (including security).

In other words, every edge device connected to the network must somehow
join a virtual layer 2 domain that hops over all layer 3 hops to provide
single hope reachability between all of the connected devices with
access to some form of "the outside world."

:-)

Russ

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Dec 2011 09:23:06 -0500

>>>>> "Russ" == Russ White <[email-masked]> writes:
    Russ> Actually, I was thinking of a tunneled layer 2 subnet across
    Russ> all "edge devices." The point would be that if all the edge
    Russ> devices can communicate in a straightforward manner, it makes
    Russ> solving a lot of other problems much simpler (including
    Russ> security).

It's not simpler.  It just looks that way because layer-2 bridging seems
ubiquitous and trivial to layer-3 people.  The recent TRILL work at the
IETF demonstrates the limitations of layer-2.   The idea is to make
things simpler, and layer-2+MSTP doesn't seem at all simpler to me.
(and I've both designed such networks and written the code)

But, you have simply replaced one routing table (layer-3, that includes
source routing and loop detection) with another routing table (layer-2,
that is flood with pruning, and no loop detection).

---

From: Jim Gettys <[email-masked]>
Date: Fri, 30 Dec 2011 12:10:33 -0500

On 12/30/2011 09:23 AM, Michael Richardson wrote:
> It's not simpler. It just looks that way because layer-2 bridging
> seems ubiquitous and trivial to layer-3 people. The recent TRILL work
> at the IETF demonstrates the limitations of layer-2. The idea is to
> make things simpler, and layer-2+MSTP doesn't seem at all simpler to
> me. (and I've both designed such networks and written the code) But,
> you have simply replaced one routing table (layer-3, that includes
> source routing and loop detection) with another routing table
> (layer-2, that is flood with pruning, and no loop detection). 

And you really don't want random multicast traffic to pollute a wireless
network for which it is not intended (given the way 802.11 works, this
is a real headache).  A little multicast can ruin your whole day on
802.11; as the bandwidths have gone up, this problem has become
increasingly acute (since the transmission rate at which broadcast is
constrained hasn't).

Better to route than bridge; though the remaining question (which much
be answered) is if there are unintended dependencies on multicast that
cause grief.  The simple cases (e.g. mdns) aren't a problem; we have the
mdns forwarder code available.
                - Jim

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Dec 2011 12:52:45 -0500

>>>>> "Jim" == Jim Gettys <[email-masked]> writes:
    >> seems ubiquitous and trivial to layer-3 people. The recent TRILL
    >> work at the IETF demonstrates the limitations of layer-2. The
    >> idea is to make things simpler, and layer-2+MSTP doesn't seem at
    >> all simpler to me. (and I've both designed such networks and
    >> written the code) But, you have simply replaced one routing table
    >> (layer-3, that includes source routing and loop detection) with
    >> another routing table (layer-2, that is flood with pruning, and
    >> no loop detection).

    Jim> And you really don't want random multicast traffic to pollute a
    Jim> wireless network for which it is not intended (given the way
    Jim> 802.11 works, this is a real headache).  A little multicast can
    Jim> ruin your whole day on 802.11; as the bandwidths have gone up,
    Jim> this problem has become increasingly acute (since the
    Jim> transmission rate at which broadcast is constrained hasn't).

So, Russ' suggestion is to have this single layer-2 VLAN among exit
routers only, and it would be used by exit routers so that they can get
a packet straight to another exit router.   This layer-2 VLAN would not
be bridged onto any other LAN, so the multicast vs wireless issue does
not arise.

However!
It does require that all routers (not just edge routers) implement
layer-2 VLANs with (M)STP.  Up to the "MSTP" part (which we really
need), it's true that it's already present in a Linux stack.
What concerns me, more than just that we are invoking a more complicated
code path is:
  a) if this can really work, then some people will ask, again and
     again, why not bridge everything, period.  (Your answer is one
     answer)

  b) this really limits everything in the future to being ethernet-like,
     while a layer-3 solution liberates us from that.

---

From: Russ White <[email-masked]>
Date: Fri, 30 Dec 2011 17:17:41 -0500

> be bridged onto any other LAN, so the multicast vs wireless issue does

Actually, I wasn't thinking about pushing user traffic onto this virtual
overlay layer 2 network at all --I was just thinking that it could be
used for all edge devices to find one another in a simple way and have a
channel across which they can coordinate their actions in terms of
forwarding and security.

:-)

Russ