Subject: [homenet] Creating a security association via physical link + button

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Nov 2011 17:01:33 +0900

It would be cool if I could plug in a new router into my homenet, press a
special button on it and on the router I plug it into, and have the new
router download the homenet config (at least the routing protocol key, but
maybe other things like the wifi SSID) from the existing router.

The button would cause the existing router to make the information
available in the clear for, say, 30 seconds, and would cause the new router
to attempt to fetch it from a directly connected neighbour. The combination
of physically plugging something in and pressing the button might provide
enough security to defend against unintended pairings (e.g., because you
plugged something in to the wrong port; maybe to your neighbour's homenet).

I don't know how you would decide who is the "homenet" and who is the "new
router" though.

Comments?

---

From: Russ White <[email-masked]>
Date: Tue, 22 Nov 2011 07:42:36 -0500

> It would be cool if I could plug in a new router into my homenet, press
> a special button on it and on the router I plug it into, and have the
> new router download the homenet config (at least the routing protocol
> key, but maybe other things like the wifi SSID) from the existing router.

This is, generally speaking, how current home routers work... And, I
think, it might be the only way to make a homenet work. The primary key
beyond this is a device being able to figure out "I'm an edge to the
outside world."

If we can sort these two problems, the rest of the problems are mostly a
matter of just thinking through the best solution...

:-)

Russ

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 09:54:30 -0500

> beyond this is a device being able to figure out "I'm an edge to the

Yeah, I don't think either device decides that it is the homenet; rather, they are regularly dynamically discovering topology, and deciding what to do based on whether they are connected to an edge.   Possibly both devices are connected to an edge, and cooperate to do multihoming.

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 22 Nov 2011 17:19:09 -0500

A physical button, or a virtual button?
I don't want to do mechanical engineering here.  And buttons are expensive.

Lee

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, November 22, 2011 3:02 AM
To: [email-masked]
Subject: [homenet] Creating a security association via physical link + button

It would be cool if I could plug in a new router into my homenet, press a special button on it and on the router I plug it into, and have the new router download the homenet config (at least the routing protocol key, but maybe other things like the wifi SSID) from the existing router.

The button would cause the existing router to make the information available in the clear for, say, 30 seconds, and would cause the new router to attempt to fetch it from a directly connected neighbour. The combination of physically plugging something in and pressing the button might provide enough security to defend against unintended pairings (e.g., because you plugged something in to the wrong port; maybe to your neighbour's homenet).

I don't know how you would decide who is the "homenet" and who is the "new router" though.

Comments?

________________________________
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: Hans Liu <[email-masked]>
Date: Wed, 23 Nov 2011 00:03:48 +0000

There is a physical button for WPS PBC and it is widely adopted in the Wi-Fi CPE devices. We can use it by defining an extension.

Hans

Sent from Hans' iPad2

On Nov 23, 2011, at 6:19 AM, "Howard, Lee" <[email-masked]<mailto:[email-masked]>> wrote:

A physical button, or a virtual button?
I don’t want to do mechanical engineering here.  And buttons are expensive.

Lee

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, November 22, 2011 3:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [homenet] Creating a security association via physical link + button

Comments?

________________________________
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.
_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 20:37:39 -0500

> I don’t want to do mechanical engineering here.  And buttons are expensive.

Great, let's just do a USB port then!   :)

Seriously, if you make a device cheap enough, it simply won't be able to do homenet.   The question is, how cheap is that?

---

From: Mark Townsley <[email-masked]>
Date: Wed, 23 Nov 2011 12:17:56 +0100

I think I have said this before verbally, but I wanted to put some text around it. If folks agree on this framework, the target would be the homenet arch document for fleshing out. 

First, I think we should keep "host to router" links out of scope. Of course we need hosts, but they are not our main concern in homenet. Hosts that become routers are, and all they have to do is turn on "Internet Connection Sharing" to do so. I'd expect these hosts to look exactly like a router on the wire. 

So, scoped to "router-to-router links", let's define 3 different pairings we are concerned about:

1. "Local" router to router links within the homenet
2. "Internet" router to Internet Service Provider links
3. "Other Network" links to another network (guest, grid, neighbor, etc...)

Note that a router to router "link" may exist virtually *inside* a single router. A good example is the case of a home:guest connection on two separate SSIDs from the same home router. 

In terms of what we define in Homenet, let's focus on #1, #2, and provide one solid example for #3 (guest) for others to replicate as needed. For example, SmartGrid could use our "guest" definition as a guideline, either reusing it entirely or providing their own "homenet to grid" profile if necessary. 

Now, the border discovery problem begins to look like this: 

When a device is connected, we have to discover whether it is a router or a host first. If it is a router, we need to discover whether it is "in the homenet" or "outside the homenet". If it is "outside the homenet" we have to discover whether it is an "ISP" link for the homenet, or "other network". For "other networks" we now need to know what kind of "other network" which suggests a registry (and that's why we have IANA) and a protocol extension (which is why we have a WG).  This is a pretty simple cascading flowchart, with each exit point  resulting in a default policy for our 5 (6 if we include troubleshooting) functional areas. 

For the 3 base cases listed above (Local, Internet, Guest) If we can solidly answer the 5 (6) questions below, we've accomplished well what is within our scope:

1. Do we share or accept assigned prefixes over this link?
2. Do we share or accept routing information over this link?
3. Do we share or accept services information over this link?
4. Do we share or accept naming information over this link?
5. Do we allow application traffic to flow over this link? If so, do we apply a firewall function?
(6.) Do we allow troubleshooting protocols over this link (ping, traceroute - could be part of the FW question in #5)?

We might realize that for all 3 cases and any other case we could dream of, the answer for a given default profile question is the same. That's goodness. The reason the 5 questions are here is that they correspond to the 5 areas of scope we have some control over in homenet, and I think helps us to understand what it is we are defining when tackling a given area. 

Comments?

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Nov 2011 09:39:25 +1300

Mark,

> 3. "Other Network" links to another network (guest, grid, neighbor, etc...)

I find this category troubling. Either the other network is part of the Internet,
except that it isn't an ISP network (i.e. it is a peer that does not offer
transit), or it is part of the homenet (i.e. it is a stub within the homenet).
Thus a guest network (your friend who's living in your garage) is not in
the same category as your neighbour's peer network.

The considerations are totally different for the two cases. For example: in some
jurisdictions, the homenet operator might be legally liable for any activity
performed within a stub of the homenet, but not for activity performed within a
non-transit peer. So the approach to security would be completely different
in the two cases. In some sense the non-transit peers would be reached
by an EGP (even if we actually used a trditional IGP protocol).

Regards
   Brian

On 2011-11-24 00:17, Mark Townsley wrote:
> [email-masked]

---

From: Mark Townsley <[email-masked]>
Date: Thu, 24 Nov 2011 00:27:42 +0100

On Nov 23, 2011, at 9:39 PM, Brian E Carpenter wrote:

> I find this category troubling.

OK, let's see what we can do about that. 

> Either the other network is part of the Internet,

I think this is mostly semantics. I'm describing this from the perspective of the homenet, and what I am trying to outline is that the "pairing" between any two routers leads to a default policy. That policy is either "these routers are part of the same homenet" and thus "share everything", or not. If not, it's either an Internet Service Provider link with an associated default policy, or a link to some "other network" for which we're only going to define what Guest means and leave the rest to others. The policy questions were worded in both  directions on purpose (sharing with others, accepting from others), so even if you describe the border associations from another point of view, you'll end up with the same policy questions to answer, just from a different relative perspective. Does this help?

> the same category as your neighbour's peer network.

I agree. That's why the "neighbor peer" would have to define what kind of default policy it would conform too. Same for your 6lowpan, etc. We'll tackle one, just to prove if it can be done or not. I'm suggesting it be "guest". 

> by an EGP (even if we actually used a trditional IGP protocol).

Yes, those are the devilish details. My email was just a framework. 

I'd hope that we could at least define the default policy for a retail homenet router. If that needed to be modified for sale in a certain country, or as equipment supplied by a certain ISP, so be it, but at least it would still hopefully be within the framework.

- Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Nov 2011 18:44:10 +0900

On Tue, Nov 22, 2011 at 23:54, Ted Lemon <[email-masked]> wrote:

> Yeah, I don't think either device decides that it is the homenet; rather,
> they are regularly dynamically discovering topology, and deciding what to
> do based on whether they are connected to an edge.   Possibly both devices
> are connected to an edge, and cooperate to do multihoming.
>

Let me rephrase my original question. You connect two routers and press the
button on both. What happens, and who gets the config from whom?

If one is a member of a homenet and an ISP connection already, and one has
a blank config, then you might assume that  the one with the blank config
should join the existing homenet. What if they both have a config on them?
What if you're actually merging two separate networks?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Nov 2011 11:27:16 -0500

On Nov 24, 2011, at 4:44 AM, Lorenzo Colitti wrote:
> If one is a member of a homenet and an ISP connection already, and one has a blank config, then you might assume that  the one with the blank config should join the existing homenet. What if they both have a config on them? What if you're actually merging two separate networks?

I think that's the idea.   The user is saying "merge the two networks" in this case.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 25 Nov 2011 09:46:56 +0900

> I think that's the idea.   The user is saying "merge the two networks" in

Ok, so it would seem to me that to support that case then we need to either
a) support multiple simultaneous keys in the IGP or b) provide a mechanism
to tell a number of homenet routers that "the key to the IGP is changing".
Both are non-trivial. Any other ideas?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Nov 2011 21:42:41 -0500

On Nov 24, 2011, at 7:46 PM, Lorenzo Colitti wrote:
> Ok, so it would seem to me that to support that case then we need to either a) support multiple simultaneous keys in the IGP or b) provide a mechanism to tell a number of homenet routers that "the key to the IGP is changing". Both are non-trivial. Any other ideas?

I think a security model that doesn't have each router generating its own keys, and using public key cryptography, is doomed.   If you use a shared secret, it's too easy to pwn your network because it has to be exchanged in the clear.   If the IGP protocol we want doesn't support this, then it pretty much has to be fixed, or we just can't do this.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 25 Nov 2011 09:43:57 +0100

Before we decide that we must have an IGP, that it must be cryptographically secured, and that we have to tackle key distribution for it, I'd like to take a step or two back from the routing protocol part of the equation.

First things first, we have to detect that there is a device present, whether it is a router or not, and if so what kind of router to router border we have on that link so that we can apply a policy. If that policy allows sending and receiving of addressing and routing information, from the perspective of the routing protocol it has every thing it needs to start sending IGP packets in the clear on that link. In terms of usability, the homenet cannot afford crypto security or key exchange at every layer. I think we must inherently trust security from layer 2 or physical, just like we do today between routers and hosts (or nat-routers and nat-routers for IPv4) in the home. 

In practical terms, I think this means that if two routers are connected with a physical link, that link should be trusted enough to send packets, in the clear, which can at least identify what kind of router to router link this is (e.g., local, ISP, etc.). The same applies if two routers are connected over a secured wireless L2 link.  Similarly, a wired broadband or 3G/LTE wireless connection to an ISP router in the neighborhood has its own authentication and policy enforcement happening at L2. 

In terms of UI, if one of those two routers is actually a PC or phone, we shouldn't worry about the "pairing" issues much as there is enough user interaction to sort that out (I do think that the state of the art could be improved here, but that's for the UI wizards make better, not protocol hacks like us). The most problematic real-world case today that comes to mind would be in how to establish homenet routers that are connected via a wireless link should be considered part of the same network. A link+button might be the best way to make this happen for some routers, but others might prefer a UI from a PC (e.g., the "airport utility") with passwords. I think the furthest we can go here is to say that such a link must exist, and what the minimum level of packet exchange should be allowed before discovering what type of router-to-router link is present. 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 25 Nov 2011 09:50:31 +0100

> I think a security model that doesn't have each router generating its own keys, and using public key cryptography, is doomed.   If you use a shared secret, it's too easy to pwn your network because…

In the email I just sent, I'm making an argument for why this is not the case. An IGP in a homenet setting needs crypto security no more than DHCP, ND or mDNS would. It's just another configuration protocol within the home. 

Yes, this means that we need to trust L2 or physical security. But that's already very much the case today. If we add keys and crypto at every layer we are doomed before we start on usability alone. 

- Mark

---

From: Acee Lindem <[email-masked]>
Date: Fri, 25 Nov 2011 08:33:49 -0500

I agree. Given that the routing protocols under considerations use IPv6 link-local addresses and are confined to a packet exchanges between routers on the same link, this model seems appropriate. 
Thanks,
Acee

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Nov 2011 12:22:40 -0500

> In the email I just sent, I'm making an argument for why this is not the case. An IGP in a homenet setting needs crypto security no more than DHCP, ND or mDNS would. It's just another configuration…

I liked the email you just sent, and agree with most of it.   However...

> Yes, this means that we need to trust L2 or physical security. But that's already very much the case today. If we add keys and crypto at every layer we are doomed before we start on usability alone…

As mcr pointed out, we have to make sure the thing we are talking on is actually an L2 link, and not an L3 link, so the key handshake you're talking about has to be done with some kind of 802.1x-ey protocol.   But you admitted that we need to be able to do this for wireless devices as well as wired.   If that's the case, there *has* to be a public/private key pair, or you might as well not bother with a crypto key at all.

But the notion that having to have a public/private key pair is onerous doesn't make sense anyway.  Public keys are just as easy as shared secrets, as long as you have space to store them. Why are we even debating this?

---

From: Randy Turner <[email-masked]>
Date: Fri, 25 Nov 2011 12:15:16 -0800

> "Similarly, a wired broadband or 3G/LTE wireless connection to an ISP router in the neighborhood has its own authentication and policy enforcement happening at L2. "

I'm curious if we want to "assume" a particular type of broadband connection is in use, or do we want the Homenet solution to be "broadband-agnostic", and supply a robust solution without any knowledge of ISP/NSP connectivity method?  If we make no assumptions, then our work is harder - if we "assume" certain types of links in place, then we may or may not fail in certain Homenet connectivity scenarios where our assumptions are incorrect, but the scope of our work will be less.

Randy

---

From: Mark Townsley <[email-masked]>
Date: Sat, 26 Nov 2011 02:15:47 +0100

On Nov 25, 2011, at 6:22 PM, Ted Lemon wrote:

> As mcr pointed out, we have to make sure the thing we are talking on is actually an L2 link, and not an L3 link, so the key handshake you're talking about has to be done with some kind of 802.1x-ey protocol.   But you admitted that we need to be able to do this for wireless devices as well as wired.  

Actually, I suggested that wired wouldn't need any key handshake. Wireless would, and such handshakes require UI. The UI is the problem if there are two devices that are not used to having any serious UI. I'm not sure I know how to solve that, but I'm not sure it's our problem to solve either. 

> If that's the case, there *has* to be a public/private key pair, or you might as well not bother with a crypto key at all.

What's the common case at L2 in homes today?

> But the notion that having to have a public/private key pair is onerous doesn't make sense anyway.  Public keys are just as easy as shared secrets, as long as you have space to store them. Why are…

You are debating the kind of keys to use, I'm not. I'm saying that once you need any more keys that we already have at L2, we've made the problem harder than it needs to be. 

- Mark

---

From: Hans Liu <[email-masked]>
Date: Sat, 26 Nov 2011 09:53:09 +0800

Mark,

> Actually, I suggested that wired wouldn't need any key handshake. Wireless
> would, and such handshakes require UI. The UI is the problem if there are
> two devices that are not used to having any serious UI. I'm not sure I know
> how to solve that, but I'm not sure it's our problem to solve either.
>

Take Wi-Fi for example, WPS PBC requires no UI. WPS PIN.

Hans

---

From: Hans Liu <[email-masked]>
Date: Sat, 26 Nov 2011 10:02:50 +0800

> Take Wi-Fi for example, WPS PBC requires no UI. WPS PIN.
WPS PIN does.

-- 
Instead of following the fashion, we lead it through.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Nov 2011 21:07:36 -0500

> What's the common case at L2 in homes today?

Stuff that needs to be secure uses SSL.   Gateways are trivially pwned by whatever malware is running on your PC.   I don't think we should feel complacent about this.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Nov 2011 17:49:56 +0900

On Fri, Nov 25, 2011 at 17:43, Mark Townsley <[email-masked]> wrote:

> Before we decide that we must have an IGP, that it must be
> cryptographically secured, and that we have to tackle key distribution for
> it, I'd like to take a step or two back from the routing protocol part of
> the equation.
>

I'm not saying we need to secure the IGP. I'm saying that we need homenet
devices to know if they're "part of the same homenet" or not. This is
important for border detection, among other things.

One easy way to do this, if you have an IGP anyway, is to say that all the
devices that are part of the same IGP domain, (and thus share the same
key), are on the same homenet. It might - just - be possible for users to
understand that to "join the network" you need "the password for the
network". Then all you need to do is find a way to share a key.

This simple solution falls over if a device needs to be part of two
homenets at the same time, or if you want to merge two homenets.

Is that clearer now?

---

From: Acee Lindem <[email-masked]>
Date: Mon, 28 Nov 2011 08:21:26 -0500

On Nov 28, 2011, at 3:49 AM, Lorenzo Colitti wrote:

> I'm not saying we need to secure the IGP. I'm saying that we need homenet devices to know if they're "part of the same homenet" or not. This is important for border detection, among other things.
> 
> One easy way to do this, if you have an IGP anyway, is to say that all the devices that are part of the same IGP domain, (and thus share the same key), are on the same homenet. It might - just - be possible for users to understand that to "join the network" you need "the password for the network". Then all you need to do is find a way to share a key.
> 
> This simple solution falls over if a device needs to be part of two homenets at the same time, or if you want to merge two homenets.
> 
> Is that clearer now?

I think the confusion stems from the fact that people have different views on both the HOMENET security requirements and the associated security operations model. 

Acee

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 29 Nov 2011 13:03:43 -0500

+1

And if the goal is just to identify the boundaries, I don't think that
passphrases and encryption are the right way to go about that. But to be
honest, I'm sort of fuzzy as to what the goals really are.

Barbara

An IGP in a homenet setting needs crypto security no more than DHCP, ND
or mDNS would. It's just another configuration protocol within the home.

Yes, this means that we need to trust L2 or physical security. But
that's already very much the case today. If we add keys and crypto at
every layer we are doomed before we start on usability alone. 

- Mark