Subject: RE: Is Device Control in the charter?

From: "Rose, William" <[email-masked]>
Date: Mon, 10 Apr 2000 11:07:41 -0400

>I don't want to be a pain, but almost all of the discussion on the "home
>network security" topic pertains to device control. And I don't think
>that topic is in scope for this working group. Instead, I think that we
>are chartered only to look at host configuration,
>name-to-address translation, service discovery, and multicast address
>allocation.
>
>I can see a reasonable argument that we must consider device control
>when designing (or identifying requirements for) our protocols.
>Otherwise, we may design something that's incompatible with (or very
>different from) the security used for device control protocols. If
>that's the concern, it would be very useful to have some information
>about *what kinds* of security is or will be included in popular device
>control protocols.
>
>* Could the working group chairs or area directors please comment on
>  whether discussions of device control are in scope? If so, are we
>  actually contemplating designing (or developing requirements for)
>  device control protocols? Or are we simply looking to align our
>  work with the work others are doing on device control protocols?
>
>My personal opinion is that it would be useful and interesting to get
>some real information about the security included in important device
>control protocols. But I'm reluctant to expand the scope of the working
>group to include the development of such protocols. We already have
>*plenty* of work to do.

The problem as I see it is the following:
-The "control" devices need to be able to be accessed from, and have access
to, outside the house to be truly useful to homeowners
-There will be several protocols used by controls (LonWorks, CEBus, X10,
Bluetooth, Home PnA, Home RF, HAVi, etc., they will use multiple media, they
will share access with applications such as PC networking, sharing of ISP
accounts, multimedia, VoIP, etc.
-They will use different security approaches within the home, especially on
shared media such as RF and PLC where security will be essentially mandatory
-It is difficult to differentiate between control and other applications. Is
it control if I use an LCD touch screen sitting on a "control" network for
multiple uses such as lighting, displaying Email, speaker phone VoIP, push
services (news, stock quotes, weather info)...

I am not at this group's technical level of understanding as to the
implications of these issues but I believe that configuring the connection
is the first step toward a secure environment. 
I also think that to get applications to interoperate there needs to be a
somewhat standard approach to security. Otherwise each application needs to
understand the security approach of every home network and device it might
have to communicate with. With the plethora of protocols that will find
their way into homes, this will be impossible without standards. What I
would want to see is the control and other home networks use a standard
approach for all signaling leaving/entering the home over an Internet
connection. If manufacturers choose to use additional security layers, they
do so with the understanding that it will limit the applications they can
connect with.

Bill Rose

---

From: Daniel Senie <[email-masked]>
Date: Mon, 10 Apr 2000 11:35:15 -0400

> "Rose, William" wrote:
> -The "control" devices need to be able to be accessed from, and have
> access to, outside the house to be truly useful to homeowners

How do these devices get addresses which are addressable from outside
the house? Zeroconf, by its nature, must automatically assign addresses.
This appears incompatible with assignment of publicly routable
addresses. Before we get into the questions of device control and
security, let's decide if we're even in Zeroconf land.

> 
> -There will be several protocols used by controls (LonWorks, CEBus,
> X10, Bluetooth, Home PnA, Home RF, HAVi, etc., they will use multiple
> media, they will share access with applications such as PC networking,
> sharing of ISP accounts, multimedia, VoIP, etc.
> 
> -They will use different security approaches within the home,
> especially on shared media such as RF and PLC where security will be
> essentially mandatory
> 
> -It is difficult to differentiate between control and other
> applications. Is it control if I use an LCD touch screen sitting on a
> "control" network for multiple uses such as lighting, displaying
> Email, speaker phone VoIP, push services (news, stock quotes, weather
> info)...
> 
> implications of these issues but I believe that configuring the
> connection is the first step toward a secure environment.
> 
> I also think that to get applications to interoperate there needs to
> be a somewhat standard approach to security. Otherwise each
> application needs to understand the security approach of every home
> network and device it might have to communicate with. With the
> plethora of protocols that will find their way into homes, this will
> be impossible without standards. What I would want to see is the
> control and other home networks use a standard approach for all
> signaling leaving/entering the home over an Internet connection. If
> manufacturers choose to use additional security layers, they do so
> with the understanding that it will limit the applications they can
> connect with.

I think your concerns are all valid, but I believe these issues are all
outside of this Working Group's realm. That said, they're also worthy of
consideration separately.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 10 Apr 2000 18:15:56 -0700

>security, let's decide if we're even in Zeroconf land.

The current state of affairs is worth reviewing. 

As implemented in Windows '98 and MacOS, auto-configuration 
was originally intended to support adhoc linklocal networks. 
As a result, auto-configuration behavior only manifested 
in the absence of a DHCP server. Since many home gateways 
include mini-DHCP servers, allocation within the 169.254/24 
linklocal prefix would not occur. In this "classic" model,
devices cannot necessarily be expected to use
linklocal addressing.  

Home gateways with mini-DHCP servers often allocated 
out of 192.168/16 in this case. The difference is 
significant; packets from source address prefix 
169.254/24 never leave the link, even due to NAT. 
Packets from source address prefix 192.168/16 MAY 
leave the link, provided they are translated
to a routable address. 

Thus the security issues hang to some extent on
what kind of addresses are used by the devices.

The "new, improved" linklocal addressing spec changes 
addressing behavior to allow both linklocal and routable 
addresses on the same interface. In the "new, improved" 
model, it is possible for a device to auto-configure even 
in the presence of a DHCP server. Thus, in the "new, improved"
model devices can be expected to use linklocal addresses.