Subject: RE: home network security

From: "Rose, William" <[email-masked]>
Date: Thu, 6 Apr 2000 13:37:52 -0400

>> I would also note that most of the threats are
>> not specific to zeroconf. That is, they exist
>> as much or more in a non-zeroconf home environment (say, running
>> NAT on ADSL or cable modem) as they do in a network that is running
>> on prefix 169.254/16. So we are really talking about a security
>> analysis of home networking.
>

>I would have to agree with that sentiment.

>However, the zeroconf requirements document would seem like
>a good place to at least mention some of the risks associated
>with home networking given that it is such an obvious application
>domain.  Alternatively, it could be done as a seperate document
>and referenced.

>> Some thoughts on what kinds of threats might be worth addressing:
>
>> a. Threats of "external" parties bridging to the home network, either
>>    by design or without consent.
>>
>> b. Threats of external parties controlling internal devices or hosts.
>>
>> c. Threats of internal hosts being tricked into using bogus external
>>    services.
>>
>> The above issues seem to boil down to first, putting some kind of
firewall
>> capability in place and then making sure that an "external" party cannot
get
>> around it by bridging to the inside network.

As a starting point, the following list of threats came from a presentation
by Home Plug and Play (HPnP):
· Unauthorized access
· Eavesdropping
· Intercept/Alter (Info is intercepted and altered)
· Masquerade (spoofing or acting as a legitimate device
· Replay (Eavesdropped message is replayed at a later time)
· Denial of Service
· Resource exhaustion
· Service Spoofing
· Trojan Horse 
· Repudiation

>In a wireless home, keeping the "external" parties from bridging onto
>your network can be hard (if you live in a block of flats for example).

>It seems to me that wireless home networking results in a situation
>where an attacker can be listening to your network on the "internal"
>side of the firewall.  Link layer encryption is an obvious way to
>prevent this from happening, but it requires configuration and is
>by no means mandatory.  (I'm not at all convinced that many link
>layer encryption schemes are really that strong either).

>Given that we can't rely on layer two protection being there,
>I think I would like to see some kind of requirement statement
>to the effect that zeroconf protocols must be securable, but
>that security does not need to be turned on by default.

>This avoids complicating home networks over private wires,
>but gives (in my opinion) an insurance policy when using IP
>over wireless or powerline networks.

To my knowledge, all of the major RF (Home RF, Bluetooth, etc.) and
Powerline carrier (Ambient, Inari, Itran, Intellon, Adaptive Technologies,
Enikia, etc.) protocols use encryption as a default already. I don't know if
they use the same encryption methods.

Bill Rose
Leviton
CEA Home Network Committee

---

From: Steve Hanna <[email-masked]>
Date: Thu, 06 Apr 2000 15:33:43 -0400

I'm glad to see we're getting back to the threat analysis.

> As a starting point, the following list of threats came from a
> presentation by Home Plug and Play (HPnP):
> · Unauthorized access
> · Eavesdropping

I'm not sure that all of these threats make sense in the zeroconf
context. For instance, we're not dealing with executable content so the
trojan horse attack probably doesn't apply.

And I don't think that we need to worry about repudiation (someone
taking an action and later claiming they did not) in our domain (host
configuration, name-to-address translation, service discovery, and
multicast address allocation). That would be more relevant for
application layer protocols.

Resource exhaustion sounds like what our requirements document calls
hoarding.

Service spoofing sounds like an application of masquerading in the
service discovery domain. Still, it's a very nice phrase to describe the
problem.

I don't consider intercepting, alterating, and replaying packets to be
threats. They are a natural consequence of the assumption that the
network is not secure. Assume that the bad guys are out there and they
can send, receive, or block anything on the network. Now, what can they
do? Those things are the threats.

-Steve