RE: home network security

From owner-zeroconf@merit.edu Mon Apr 3 15:07:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22284 for ; Mon, 3 Apr 2000 15:07:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF21E5DD94; Mon, 3 Apr 2000 15:07:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BF45D5DD95; Mon, 3 Apr 2000 15:07:00 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id CD5CD5DD94 for ; Mon, 3 Apr 2000 15:06:48 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id LAA27505 for ; Mon, 3 Apr 2000 11:54:07 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: RE: home network security Date: Mon, 3 Apr 2000 12:09:09 -0700 Message-ID: <010701bf9da0$179da9c0$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38DB7941.688D4146@sun.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit It's hard to tell if we're "punting" until the threats are clearly identified. Then at least we'll be able to say what threats we are and are not addressing. So it seems like a security analysis is needed here. I liked Jeff Schiller's take on the threats: in a home environment, one should assume that the threats are mostly "external"; we do not necessarily need to go to a great deal of effort to protect parents against denial of service attacks by their children. However, it is not as easy to define "external" as it might seem. Defining this purely as someone outside the home makes it difficult to support scenarios such as connecting to the home network from the office. For example, is it completely unreasonable that someone might want to check on the status of their water heater while at work? 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. 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. From owner-zeroconf@merit.edu Mon Apr 3 15:57:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23415 for ; Mon, 3 Apr 2000 15:57:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D07575DD95; Mon, 3 Apr 2000 15:56:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BE4B35DD99; Mon, 3 Apr 2000 15:56:53 -0400 (EDT) Received: from apollo.leviton.com (apollo.leviton.com [209.177.59.130]) by segue.merit.edu (Postfix) with ESMTP id 89F875DD95 for ; Mon, 3 Apr 2000 15:56:52 -0400 (EDT) Received: by APOLLO with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Apr 2000 15:53:07 -0400 Message-ID: From: "Rose, William" To: zeroconf@merit.edu Subject: RE: home network security Date: Mon, 3 Apr 2000 15:53:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9DA6.3AA39316" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9DA6.3AA39316 Content-Type: text/plain; charset="iso-8859-1" I agree the internal threats are best left alone. However, everyone in the home automation and home networking industry is expecting external access to their products for monitoring, control, service information (as in the advertisement for the refrigerator that calls for service automatically), etc. Without a secure connection, these applications will be forced to use their own security solutions. And if each use their own solutions, it will be very unfriendly to the customer (multiple passwords/keys) and very difficult to get interoperable applications such as a personal WEB page with unified access to all enabled devices as well as push services for news, finance, entertainment, etc. I understand (I think) that a zeroconfig network might become configured when connected externally but an unconnected home network is not very useful for the products being planned by the product manufacturers. I think that ignoring the security issue is a mistake. Make it an option if necessary but define a minimal solution at least by reference. Regardless of what happens in the future (years from now), the first home products (other than PCs and PC like products) will not be sitting directly on an IP network. They will be on a cluster network and link to an IP network through a proxy or other "black box" (I am trying not to use the wrong term for the interface device). I hear that the necessary code etc. will only require a small increase in memory and processor cycles but the fact is the cost to connect devices is still a major issue. Even 10baseT is expensive for these devices and it requires new wires. The reality is power line carrier or low speed wireless (kbps)for retrofit homes and RS485 over CAT 5 for new homes. A proxy for the cluster will connect them to the external world. It is that connection to external world that needs some level of security defined so every cluster network interface can depend on a consistent minimal security approach. Producers can add more if they want. Let the system come up with security on by default and let the customer turn it off if that is their choice but don't "punt". Bill Rose -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Monday, April 03, 2000 3:09 PM To: zeroconf@merit.edu Subject: RE: home network security It's hard to tell if we're "punting" until the threats are clearly identified. Then at least we'll be able to say what threats we are and are not addressing. So it seems like a security analysis is needed here. I liked Jeff Schiller's take on the threats: in a home environment, one should assume that the threats are mostly "external"; we do not necessarily need to go to a great deal of effort to protect parents against denial of service attacks by their children. However, it is not as easy to define "external" as it might seem. Defining this purely as someone outside the home makes it difficult to support scenarios such as connecting to the home network from the office. For example, is it completely unreasonable that someone might want to check on the status of their water heater while at work? 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. 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. ------_=_NextPart_001_01BF9DA6.3AA39316 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: home network security

I agree the internal threats are best left alone. = However, everyone in the home automation and home networking industry = is expecting external access to their products for monitoring, control, = service information (as in the advertisement for the refrigerator that = calls for service automatically), etc. Without a secure connection, = these applications will be forced to use their own security solutions. = And if each use their own solutions, it will be very unfriendly to the = customer (multiple passwords/keys) and very difficult to get = interoperable applications such as a personal WEB page with unified = access to all enabled devices as well as push services for news, = finance, entertainment, etc. I understand (I think) that a zeroconfig = network might become configured when connected externally but an = unconnected home network is not very useful for the products being = planned by the product manufacturers.

I think that ignoring the security issue is a = mistake. Make it an option if necessary but define a minimal solution = at least by reference. Regardless of what happens in the future (years = from now), the first home products (other than PCs and PC like = products) will not be sitting directly on an IP network. They will be = on a cluster network and link to an IP network through a proxy or other = "black box" (I am trying not to use the wrong term for the = interface device). I hear that the necessary code etc. will only = require a small increase in memory and processor cycles but the fact is = the cost to connect devices is still a major issue. Even 10baseT is = expensive for these devices and it requires new wires. The reality is = power line carrier or low speed wireless (kbps)for retrofit homes and = RS485 over CAT 5 for new homes. A proxy for the cluster will connect = them to the external world. It is that connection to external world = that needs some level of security defined so every cluster network = interface can depend on a consistent minimal security approach. = Producers can add more if they want. Let the system come up with = security on by default and let the customer turn it off if that is = their choice but don't "punt".

Bill Rose
-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Monday, April 03, 2000 3:09 PM
To: zeroconf@merit.edu
Subject: RE: home network security

It's hard to tell if we're "punting" until = the threats are
clearly identified. Then at least we'll be able to = say
what threats we are and are not addressing. So it = seems
like a security analysis is needed here.

I liked Jeff Schiller's take on the threats: in a = home
environment, one should assume that the threats are = mostly
"external"; we do not necessarily need to = go to a great deal
of effort to protect parents against denial of = service
attacks by their children.

However, it is not as easy to define = "external" as it might
seem. Defining this purely as someone outside the = home
makes it difficult to support scenarios such as
connecting to the home network from the = office.
For example, is it completely unreasonable = that
someone might want to check on the status of their = water heater
while at work?

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.

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.

------_=_NextPart_001_01BF9DA6.3AA39316-- From owner-zeroconf@merit.edu Mon Apr 3 16:25:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24238 for ; Mon, 3 Apr 2000 16:25:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F20105DDCE; Mon, 3 Apr 2000 16:25:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E04695DDBC; Mon, 3 Apr 2000 16:25:41 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id AF1175DD99 for ; Mon, 3 Apr 2000 16:25:40 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA02117 for ; Mon, 3 Apr 2000 13:25:40 -0700 (MST)] Received: [from il33exm01.wes.mot.com (il33exm01.wes.mot.com [154.56.3.118]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA18103 for ; Mon, 3 Apr 2000 13:25:39 -0700 (MST)] Received: by il33exm01.wes.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Apr 2000 15:25:37 -0500 Message-ID: <7195C03599D9D311BE580008C75697EB07216C@il33exm01.wes.mot.com> From: Barr John-ARES35X To: "'Rose, William'" , zeroconf@merit.edu Subject: RE: home network security Date: Mon, 3 Apr 2000 15:25:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9DAA.C54E1870" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9DAA.C54E1870 Content-Type: text/plain; charset="iso-8859-1" I agree that security in the home is extremely important with the coming proliferation of always on connections (cable and DSL) and the use of residential gateways, cable modems supporting multiple connections via HomePNA, and service gateways (see http://www.osgi.org ). One of the current solutions is to create an open network in the home with an appropriate firewall similar to those found in major corporations protecting the easy to use home environment from the open Internet. Access from the external Internet will be necessary and must be secure. Regards, John -----Original Message----- From: Rose, William [mailto:Wrose@leviton.com] Sent: Monday, April 03, 2000 2:53 PM To: zeroconf@merit.edu Subject: RE: home network security I agree the internal threats are best left alone. However, everyone in the home automation and home networking industry is expecting external access to their products for monitoring, control, service information (as in the advertisement for the refrigerator that calls for service automatically), etc. Without a secure connection, these applications will be forced to use their own security solutions. And if each use their own solutions, it will be very unfriendly to the customer (multiple passwords/keys) and very difficult to get interoperable applications such as a personal WEB page with unified access to all enabled devices as well as push services for news, finance, entertainment, etc. I understand (I think) that a zeroconfig network might become configured when connected externally but an unconnected home network is not very useful for the products being planned by the product manufacturers. I think that ignoring the security issue is a mistake. Make it an option if necessary but define a minimal solution at least by reference. Regardless of what happens in the future (years from now), the first home products (other than PCs and PC like products) will not be sitting directly on an IP network. They will be on a cluster network and link to an IP network through a proxy or other "black box" (I am trying not to use the wrong term for the interface device). I hear that the necessary code etc. will only require a small increase in memory and processor cycles but the fact is the cost to connect devices is still a major issue. Even 10baseT is expensive for these devices and it requires new wires. The reality is power line carrier or low speed wireless (kbps)for retrofit homes and RS485 over CAT 5 for new homes. A proxy for the cluster will connect them to the external world. It is that connection to external world that needs some level of security defined so every cluster network interface can depend on a consistent minimal security approach. Producers can add more if they want. Let the system come up with security on by default and let the customer turn it off if that is their choice but don't "punt". Bill Rose -----Original Message----- From: Bernard Aboba [ mailto:aboba@internaut.com ] Sent: Monday, April 03, 2000 3:09 PM To: zeroconf@merit.edu Subject: RE: home network security It's hard to tell if we're "punting" until the threats are clearly identified. Then at least we'll be able to say what threats we are and are not addressing. So it seems like a security analysis is needed here. I liked Jeff Schiller's take on the threats: in a home environment, one should assume that the threats are mostly "external"; we do not necessarily need to go to a great deal of effort to protect parents against denial of service attacks by their children. However, it is not as easy to define "external" as it might seem. Defining this purely as someone outside the home makes it difficult to support scenarios such as connecting to the home network from the office. For example, is it completely unreasonable that someone might want to check on the status of their water heater while at work? 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. 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. ------_=_NextPart_001_01BF9DAA.C54E1870 Content-Type: text/html; charset="iso-8859-1" RE: home network security

I agree that security in the home is extremely important with the coming proliferation of always on connections (cable and DSL) and the use of residential gateways, cable modems supporting multiple connections via HomePNA, and service gateways (see http://www.osgi.org). One of the current solutions is to create an open network in the home with an appropriate firewall similar to those found in major corporations protecting the easy to use home environment from the open Internet. Access from the external Internet will be necessary and must be secure.

Regards, John

-----Original Message-----
From: Rose, William [mailto:Wrose@leviton.com]
Sent: Monday, April 03, 2000 2:53 PM
To: zeroconf@merit.edu
Subject: RE: home network security

I agree the internal threats are best left alone. However, everyone in the home automation and home networking industry is expecting external access to their products for monitoring, control, service information (as in the advertisement for the refrigerator that calls for service automatically), etc. Without a secure connection, these applications will be forced to use their own security solutions. And if each use their own solutions, it will be very unfriendly to the customer (multiple passwords/keys) and very difficult to get interoperable applications such as a personal WEB page with unified access to all enabled devices as well as push services for news, finance, entertainment, etc. I understand (I think) that a zeroconfig network might become configured when connected externally but an unconnected home network is not very useful for the products being planned by the product manufacturers.

I think that ignoring the security issue is a mistake. Make it an option if necessary but define a minimal solution at least by reference. Regardless of what happens in the future (years from now), the first home products (other than PCs and PC like products) will not be sitting directly on an IP network. They will be on a cluster network and link to an IP network through a proxy or other "black box" (I am trying not to use the wrong term for the interface device). I hear that the necessary code etc. will only require a small increase in memory and processor cycles but the fact is the cost to connect devices is still a major issue. Even 10baseT is expensive for these devices and it requires new wires. The reality is power line carrier or low speed wireless (kbps)for retrofit homes and RS485 over CAT 5 for new homes. A proxy for the cluster will connect them to the external world. It is that connection to external world that needs some level of security defined so every cluster network interface can depend on a consistent minimal security approach. Producers can add more if they want. Let the system come up with security on by default and let the customer turn it off if that is their choice but don't "punt".

Bill Rose
-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Monday, April 03, 2000 3:09 PM
To: zeroconf@merit.edu
Subject: RE: home network security

It's hard to tell if we're "punting" until the threats are
clearly identified. Then at least we'll be able to say
what threats we are and are not addressing. So it seems
like a security analysis is needed here.

I liked Jeff Schiller's take on the threats: in a home
environment, one should assume that the threats are mostly
"external"; we do not necessarily need to go to a great deal
of effort to protect parents against denial of service
attacks by their children.

However, it is not as easy to define "external" as it might
seem. Defining this purely as someone outside the home
makes it difficult to support scenarios such as
connecting to the home network from the office.
For example, is it completely unreasonable that
someone might want to check on the status of their water heater
while at work?

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.

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.

------_=_NextPart_001_01BF9DAA.C54E1870-- From owner-zeroconf@merit.edu Tue Apr 4 00:53:47 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07705 for ; Tue, 4 Apr 2000 00:53:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF2B65DE5B; Tue, 4 Apr 2000 00:53:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ABE155DE5A; Tue, 4 Apr 2000 00:53:11 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id D36275DE4D for ; Tue, 4 Apr 2000 00:52:59 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id VAA27973; Mon, 3 Apr 2000 21:39:52 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Rose, William'" , Subject: RE: home network security Date: Mon, 3 Apr 2000 21:54:58 -0700 Message-ID: <010e01bf9df1$ee772c90$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010F_01BF9DB7.42185490" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_010F_01BF9DB7.42185490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: home network securityI agree that foreclosing external access to the home network is too drastic. As you state, the home automation industry is looking forward to enabling Internet access to network-enabled appliances. This is critical for allowing maintenance to be done inexpensively. For example, if an engineer can monitor the performance of dozens of building or home security and energy conservation systems without visiting the sites that is going to save a lot of time and money. The question is how to enable this key scenario without compromising security. One approach that I've seen is to have some sort of applications layer gateway. For example, a web page that authenticates access and then allows the authenticated user to control and monitor the appliances on the other side of the gateway. The question is whether such a gateway solution is too limiting. Might there be situations in which the engineer might want direct access to the device? I think there are probably such scenarios. -----Original Message----- From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On Behalf Of Rose, William Sent: Monday, April 03, 2000 12:53 PM To: zeroconf@merit.edu Subject: RE: home network security I agree the internal threats are best left alone. However, everyone in the home automation and home networking industry is expecting external access to their products for monitoring, control, service information (as in the advertisement for the refrigerator that calls for service automatically), etc. Without a secure connection, these applications will be forced to use their own security solutions. And if each use their own solutions, it will be very unfriendly to the customer (multiple passwords/keys) and very difficult to get interoperable applications such as a personal WEB page with unified access to all enabled devices as well as push services for news, finance, entertainment, etc. I understand (I think) that a zeroconfig network might become configured when connected externally but an unconnected home network is not very useful for the products being planned by the product manufacturers. I think that ignoring the security issue is a mistake. Make it an option if necessary but define a minimal solution at least by reference. Regardless of what happens in the future (years from now), the first home products (other than PCs and PC like products) will not be sitting directly on an IP network. They will be on a cluster network and link to an IP network through a proxy or other "black box" (I am trying not to use the wrong term for the interface device). I hear that the necessary code etc. will only require a small increase in memory and processor cycles but the fact is the cost to connect devices is still a major issue. Even 10baseT is expensive for these devices and it requires new wires. The reality is power line carrier or low speed wireless (kbps)for retrofit homes and RS485 over CAT 5 for new homes. A proxy for the cluster will connect them to the external world. It is that connection to external world that needs some level of security defined so every cluster network interface can depend on a consistent minimal security approach. Producers can add more if they want. Let the system come up with security on by default and let the customer turn it off if that is their choice but don't "punt". Bill Rose -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Monday, April 03, 2000 3:09 PM To: zeroconf@merit.edu Subject: RE: home network security It's hard to tell if we're "punting" until the threats are clearly identified. Then at least we'll be able to say what threats we are and are not addressing. So it seems like a security analysis is needed here. I liked Jeff Schiller's take on the threats: in a home environment, one should assume that the threats are mostly "external"; we do not necessarily need to go to a great deal of effort to protect parents against denial of service attacks by their children. However, it is not as easy to define "external" as it might seem. Defining this purely as someone outside the home makes it difficult to support scenarios such as connecting to the home network from the office. For example, is it completely unreasonable that someone might want to check on the status of their water heater while at work? 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. 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. ------=_NextPart_000_010F_01BF9DB7.42185490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: home network security

I=20 agree that foreclosing external access to the home network is too = drastic. As=20 you state, the home automation

industry is looking forward to enabling = Internet access=20 to network-enabled appliances. This is critical for = allowing

maintenance to be done inexpensively. For = example, if=20 an engineer can monitor the performance of dozens of

building or home security and energy = conservation=20 systems without visiting the sites that is going to save a=20 lot

of=20 time and money.

The=20 question is how to enable this key scenario without compromising = security. One=20 approach that I've seen

is to=20 have some sort of applications layer gateway. For example, a web page = that=20 authenticates access and

then=20 allows the authenticated user to control and monitor the appliances on = the other=20 side of the gateway. The

question is whether such a gateway solution = is too=20 limiting. Might there be situations in which the = engineer

might=20 want direct access to the device? I think there are probably such = scenarios.=20

-----Original Message-----
From: = owner-zeroconf@merit.edu=20 [mailto:owner-zeroconf@merit.edu]On Behalf Of Rose,=20 William
Sent: Monday, April 03, 2000 12:53 PM
To:=20 zeroconf@merit.edu
Subject: RE: home network=20 security

I agree the internal threats are best left alone. = However,=20 everyone in the home automation and home networking industry is = expecting=20 external access to their products for monitoring, control, service = information=20 (as in the advertisement for the refrigerator that calls for service=20 automatically), etc. Without a secure connection, these applications = will be=20 forced to use their own security solutions. And if each use their own=20 solutions, it will be very unfriendly to the customer (multiple=20 passwords/keys) and very difficult to get interoperable applications = such as a=20 personal WEB page with unified access to all enabled devices as well = as push=20 services for news, finance, entertainment, etc. I understand (I think) = that a=20 zeroconfig network might become configured when connected externally = but an=20 unconnected home network is not very useful for the products being = planned by=20 the product manufacturers.

I think that ignoring the security issue is a = mistake. Make it=20 an option if necessary but define a minimal solution at least by = reference.=20 Regardless of what happens in the future (years from now), the first = home=20 products (other than PCs and PC like products) will not be sitting = directly on=20 an IP network. They will be on a cluster network and link to an IP = network=20 through a proxy or other "black box" (I am trying not to use the wrong = term=20 for the interface device). I hear that the necessary code etc. will = only=20 require a small increase in memory and processor cycles but the fact = is the=20 cost to connect devices is still a major issue. Even 10baseT is = expensive for=20 these devices and it requires new wires. The reality is power line = carrier or=20 low speed wireless (kbps)for retrofit homes and RS485 over CAT 5 for = new=20 homes. A proxy for the cluster will connect them to the external = world. It is=20 that connection to external world that needs some level of security = defined so=20 every cluster network interface can depend on a consistent minimal = security=20 approach. Producers can add more if they want. Let the system come up = with=20 security on by default and let the customer turn it off if that is = their=20 choice but don't "punt".

Bill Rose
-----Original=20 Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]=20
Sent: Monday, April 03, 2000 3:09 PM =
To: zeroconf@merit.edu
Subject: RE: = home=20 network security

It's hard to tell if we're "punting" until the = threats=20 are
clearly identified. Then at least we'll = be able to=20 say
what threats we are and are not = addressing. So it=20 seems
like a security analysis is needed = here.=20

I liked Jeff Schiller's take on the threats: in a = home=20
environment, one should assume that the threats are = mostly
"external"; we do not necessarily = need to go to=20 a great deal
of effort to protect parents = against=20 denial of service
attacks by their = children.=20

However, it is not as easy to define "external" as = it=20 might
seem. Defining this purely as someone = outside=20 the home
makes it difficult to support = scenarios such=20 as
connecting to the home network from the=20 office.
For example, is it completely = unreasonable=20 that
someone might want to check on the = status of=20 their water heater
while at work? =

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

Some thoughts on what kinds of threats might be = worth=20 addressing:

a. Threats of "external" parties bridging to the = home network,=20 either
by design or without=20 consent.

b. Threats of external parties controlling internal = devices or=20 hosts.

c. Threats of internal hosts being tricked into = using bogus=20 external
services.

The above issues seem to boil down to first, putting = some kind=20 of firewall
capability in place and then = making sure=20 that an "external" party cannot get
around = it by=20 bridging to the inside network.

------=_NextPart_000_010F_01BF9DB7.42185490-- From owner-zeroconf@merit.edu Tue Apr 4 06:25:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27264 for ; Tue, 4 Apr 2000 06:25:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DDC95DDB6; Tue, 4 Apr 2000 06:24:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 05FBC5DDCE; Tue, 4 Apr 2000 06:24:53 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id B11AB5DDB6 for ; Tue, 4 Apr 2000 06:24:52 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e34AOWn11667; Tue, 4 Apr 2000 06:24:32 -0400 Message-ID: <38E9C2DF.4A0D0CB4@senie.com> Date: Tue, 04 Apr 2000 06:24:31 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com Cc: "'Rose, William'" , zeroconf@merit.edu Subject: Re: home network security References: <010e01bf9df1$ee772c90$268939cc@ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard wrote: >I agree that foreclosing external access to the home network is too drastic. I'd add to this: "But should be easily and explicitly configurable in some fashion by the home user." >As you state, the home automation industry is looking forward to enabling >Internet access to network-enabled appliances. This is critical for allowing >maintenance to be done inexpensively. For example, if an engineer can monitor >the performance of dozens of building or home security and energy >conservation systems without visiting the sites that is going to save a lot >of time and money. That may well be, but I want to be VERY clear, that the homeowner or building owner MUST have the ability to regulate this. There will be those who do NOT wish this type of access to their homes or other structures. Applicances which need to send alerts can send OUTBOUND messages through a tight firewall without allowing someone outside to poll the device. It's up to the appliance manufacturer to decide which way they'd like to implement their code, of course, but it's also up to the individual how they'd like to implement their firewalls. >The question is how to enable this key scenario without compromising >security. Agree. And a question of whether there's a trust relationship with the manufacturer or servicer of an appliance. >One approach that I've seen is to have some sort of applications layer >gateway. For example, a web page that authenticates access and then allows >the authenticated user to control and monitor the appliances on the other >side of the gateway. The question is whether such a gateway solution is too >limiting. Even in a gateway scenario, there are concerns. A general lack of trust in large corporations to refrain from pushing the limits of the trust relationship is a concern. How long before the marketing department finds a way to use the data extracted from your refrigerator to market additional services? First time that happens, there'll be users pulling plugs. >Might there be situations in which the engineer might want direct access to >the device? I think there are probably such scenarios. I think the privacy folks will continue to make this an issue. I'd like to see Zeroconf make headway, and am not sure getting into defining the trust relationships with General Electric, Whirlpool, Sears and other such companies is a good use of that time. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Tue Apr 4 09:13:18 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02240 for ; Tue, 4 Apr 2000 09:13:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96E5D5DD94; Tue, 4 Apr 2000 09:12:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F3C65DDBC; Tue, 4 Apr 2000 09:12:58 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 7C4585DD94 for ; Tue, 4 Apr 2000 09:12:54 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id GAA28544; Tue, 4 Apr 2000 06:00:00 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Daniel Senie'" Cc: "'Rose, William'" , Subject: RE: home network security Date: Tue, 4 Apr 2000 06:15:08 -0700 Message-ID: <012d01bf9e37$cddcc210$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38E9C2DF.4A0D0CB4@senie.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I'd add to this: "But should be easily and explicitly configurable in >some fashion by the home user." If we are allowed to do configuration then a lot of things become easier :) >That may well be, but I want to be VERY clear, that the homeowner or >building owner MUST have the ability to regulate this. There will be >those who do NOT wish this type of access to their homes or other >structures. Sure. The question is how to enable granting of such access. In general, packet filtering firewalls aren't very good at enabling secure inbound access. For example, you'd need to know the IP address of the maintenance person, and even if this could be known and updated (unlikely) it would be vulnerable to spoofing. VPN technologies (such as IPSEC) are typically more secure for this kind of problem as well as more flexible. For example, you wouldn't need to know or care about what IP address the IPSEC packet is coming from, only the identity as expressed in the cert. This means that IPSEC may actually be EASIER to configure than a packet filtering firewall, assuming that the PKI obstacles can be overcome. Of course, there is then the question of how the certs are obtained and set up. However, I'm not convinced this is really so hard. See Steve Bellovin's proposal, draft-bellovin-ipsra-getcert-00.txt. From owner-zeroconf@merit.edu Tue Apr 4 10:48:48 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05188 for ; Tue, 4 Apr 2000 10:48:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2BE125DE02; Tue, 4 Apr 2000 10:48:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 182AE5DE03; Tue, 4 Apr 2000 10:48:01 -0400 (EDT) Received: from apollo.leviton.com (apollo.leviton.com [209.177.59.130]) by segue.merit.edu (Postfix) with ESMTP id DD57E5DE02 for ; Tue, 4 Apr 2000 10:47:59 -0400 (EDT) Received: by APOLLO with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Apr 2000 10:44:13 -0400 Message-ID: From: "Rose, William" To: "'Daniel Senie'" , aboba@internaut.com Cc: zeroconf@merit.edu Subject: RE: home network security Date: Tue, 4 Apr 2000 10:44:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9E44.3E0C5AA8" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9E44.3E0C5AA8 Content-Type: text/plain; charset="iso-8859-1" >I'd like to see Zeroconf make headway, and am not sure getting into defining the trust relationships with General Electric, Whirlpool, Sears and other such companies is a good use of that time. Agreed, trust in companies is not a productive discussion. Trust in a secure connection for access and control for a homeowner is. Discussions in HN meetings include levels of access. A service/repair person might have access to a refrigerator's health but not the ability to turn it off. Manufacturers can provide application level security that block access to potentially harmful functions unless the homeowner grants it. I don't think zeroconfig needs to define that type of security. The issue is providing a level of security that will give the homeowner access to all functions he/she wants without anyone else having that access unless given it. The question is how to standardize the security so manufacturers can add it to their products without having to support multiple approaches or the homeowner having different configurations for different products. Security can be an option that a homeowner can choose to use or not but if the option is chosen, then we need it to be standardized. Perhaps zeroconfig is the wrong venue for this discussion. If so, does anyone know the right one? Bill Rose ------_=_NextPart_001_01BF9E44.3E0C5AA8 Content-Type: text/html; charset="iso-8859-1" RE: home network security

>I'd like to see Zeroconf make headway, and am not sure getting into
defining the trust relationships with General Electric, Whirlpool, Sears
and other such companies is a good use of that time.

Agreed, trust in companies is not a productive discussion. Trust in a
secure connection for access and control for a homeowner is. Discussions in HN meetings
include levels of access. A service/repair person might have access to a refrigerator's
health but not the ability to turn it off. Manufacturers can provide application
level security that block access to potentially harmful functions
unless the homeowner grants it. I don't think zeroconfig needs to define that type
of security. The issue is providing a level of security that will give the homeowner
access to all functions he/she wants without anyone else having that access unless
given it. The question is how to standardize the security so manufacturers can add
it to their products without having to support multiple approaches or the homeowner
having different configurations for different products. Security can be an option
that a homeowner can choose to use or not but if the option is chosen, then we need
it to be standardized. Perhaps zeroconfig is the wrong venue for this discussion.
If so, does anyone know the right one?

Bill Rose

------_=_NextPart_001_01BF9E44.3E0C5AA8-- From owner-zeroconf@merit.edu Tue Apr 4 13:37:27 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10065 for ; Tue, 4 Apr 2000 13:37:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9D095DD94; Tue, 4 Apr 2000 13:36:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A70625DDB5; Tue, 4 Apr 2000 13:36:56 -0400 (EDT) Received: from imo20.mx.aol.com (imo20.mx.aol.com [152.163.225.10]) by segue.merit.edu (Postfix) with ESMTP id 582EC5DD94 for ; Tue, 4 Apr 2000 13:36:53 -0400 (EDT) Received: from PJohansson@aol.com by imo20.mx.aol.com (mail_out_v25.3.) id m.d.3334b82 (3996) for ; Tue, 4 Apr 2000 13:36:51 -0400 (EDT) From: PJohansson@aol.com Message-ID: Date: Tue, 4 Apr 2000 13:36:51 EDT Subject: Re: home network security To: ZeroConf@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 76 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In a message dated 00-04-04 06:25:22 EDT, dts@senie.com writes: <<... I want to be VERY clear, that the homeowner or building owner MUST have the ability to regulate this. There will be those who do NOT wish this type of access to their homes or other structures.>> I would take it a step further. Given what is at stake in access to your own home, I think the default policy should be to disallow access. No home or building owners should be faced with a situation where they purchase new hardware and are uncertain whether or not a new point of ingress to the home has been created. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX pjohansson@aol.com From owner-zeroconf@merit.edu Tue Apr 4 14:20:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11287 for ; Tue, 4 Apr 2000 14:20:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CAE475DDE5; Tue, 4 Apr 2000 14:15:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2FD275DDF2; Tue, 4 Apr 2000 14:15:02 -0400 (EDT) Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by segue.merit.edu (Postfix) with ESMTP id 585DA5DDE5 for ; Tue, 4 Apr 2000 14:14:56 -0400 (EDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by slafw.enet.sharplabs.com (8.9.1/8.9.2) with ESMTP id LAA11788; Tue, 4 Apr 2000 11:12:18 -0700 (PDT) Received: by admsrvnt02 with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Apr 2000 11:14:45 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA53731001E@MAILSRVNT02> From: "McDonald, Ira" To: "'PJohansson@aol.com'" , ZeroConf@merit.edu Subject: RE: home network security Date: Tue, 4 Apr 2000 11:14:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-zeroconf@merit.edu Precedence: bulk Hi Peter and Daniel, I agree with your points entirely. Any eventual language in ZC-based protocol specs about security needs to very tight and unambiguous, such as: "Conforming implmentations MUST disable all external access. External access MUST only be permitted after explicit configuration by the owner of the equipment." Automatically punching holes in a homeowner's or small business person's network will be the kiss of death for the products. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: PJohansson@aol.com [mailto:PJohansson@aol.com] Sent: Tuesday, April 04, 2000 10:37 AM To: ZeroConf@merit.edu Subject: Re: home network security In a message dated 00-04-04 06:25:22 EDT, dts@senie.com writes: <<... I want to be VERY clear, that the homeowner or building owner MUST have the ability to regulate this. There will be those who do NOT wish this type of access to their homes or other structures.>> I would take it a step further. Given what is at stake in access to your own home, I think the default policy should be to disallow access. No home or building owners should be faced with a situation where they purchase new hardware and are uncertain whether or not a new point of ingress to the home has been created. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX pjohansson@aol.com From owner-zeroconf@merit.edu Wed Apr 5 05:16:20 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07491 for ; Wed, 5 Apr 2000 05:16:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C0605E0EA; Wed, 5 Apr 2000 04:29:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ED35F5E0F7; Wed, 5 Apr 2000 04:29:34 -0400 (EDT) Received: from imo13.mx.aol.com (imo13.mx.aol.com [152.163.225.3]) by segue.merit.edu (Postfix) with ESMTP id EC4135E0EA for ; Wed, 5 Apr 2000 04:29:13 -0400 (EDT) Received: from PJohansson@aol.com by imo13.mx.aol.com (mail_out_v25.3.) id m.1a.1c2638e (3996) for ; Wed, 5 Apr 2000 02:48:55 -0400 (EDT) From: PJohansson@aol.com Message-ID: <1a.1c2638e.261c3bd6@aol.com> Date: Wed, 5 Apr 2000 02:48:54 EDT Subject: Re: home network security To: ZeroConf@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 76 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In a message dated 00-04-04 10:49:54 EDT, Wrose@leviton.com writes: <<... Manufacturers can provide application level security that block access to potentially harmful functions unless the homeowner grants it.>> I'd have to disagree that "trust" is not an issue. Manufacturers are fallible and I may well prefer to grant NO access and have this readily under my control---as a distinctly different option from enabling potentially harmful functions. Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX pjohansson@aol.com From owner-zeroconf@merit.edu Wed Apr 5 05:52:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07771 for ; Wed, 5 Apr 2000 05:52:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DBDF55E06D; Wed, 5 Apr 2000 05:50:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 76F575E6B4; Wed, 5 Apr 2000 05:49:47 -0400 (EDT) Received: from kitab.cisco.com (sj-dial-4-109.cisco.com [171.68.181.238]) by segue.merit.edu (Postfix) with ESMTP id DB07A5F6BE for ; Wed, 5 Apr 2000 05:37:12 -0400 (EDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.2/8.9.2) id CAA00668; Wed, 5 Apr 2000 02:37:02 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14571.2365.853794.900264@kitab.cisco.com> Date: Wed, 5 Apr 2000 02:37:01 -0700 (PDT) To: PJohansson@aol.com Cc: ZeroConf@merit.edu Subject: Re: home network security In-Reply-To: <1a.1c2638e.261c3bd6@aol.com> References: <1a.1c2638e.261c3bd6@aol.com> X-Mailer: VM 6.74 under 20.4 "Emerald" XEmacs Lucid Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit PJohansson@aol.com writes: > In a message dated 00-04-04 10:49:54 EDT, Wrose@leviton.com writes: > > <<... Manufacturers can provide application level security that block access > to potentially harmful functions unless the homeowner grants it.>> > > I'd have to disagree that "trust" is not an issue. Manufacturers are fallible > and I may well prefer to grant NO access and have this readily under my > control---as a distinctly different option from enabling potentially harmful > functions. I have to complete agree. I have no problem with making the default to grant such access as long the customer *can* *easily* configure security in a way that such access is *not* granted (and as long configuring things in this way retains all functionality of the customer's devices in the same way as they would function had such access been granted; i.e., don't cripple my equipment just because the manufacturer can't access it). Furthermore, access should be grantable on a per-device basis. /raj From owner-zeroconf@merit.edu Wed Apr 5 12:40:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12637 for ; Wed, 5 Apr 2000 12:40:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3CC25DE58; Wed, 5 Apr 2000 12:40:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D95A95DEE3; Wed, 5 Apr 2000 12:40:02 -0400 (EDT) Received: from apollo.leviton.com (apollo.leviton.com [209.177.59.130]) by segue.merit.edu (Postfix) with ESMTP id 1A9905DEBA for ; Wed, 5 Apr 2000 12:34:12 -0400 (EDT) Received: by APOLLO with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Apr 2000 12:30:23 -0400 Message-ID: From: "Rose, William" To: "'Richard Johnson'" , PJohansson@aol.com Cc: ZeroConf@merit.edu Subject: RE: home network security Date: Wed, 5 Apr 2000 12:30:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9F1C.3D90E08E" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9F1C.3D90E08E Content-Type: text/plain; charset="iso-8859-1" > > <<... Manufacturers can provide application level security that block access > to potentially harmful functions unless the homeowner grants it.>> > > I'd have to disagree that "trust" is not an issue. Manufacturers are fallible > and I may well prefer to grant NO access and have this readily under my > control---as a distinctly different option from enabling potentially harmful > functions. >I have to complete agree. I have no problem with making the default >to grant such access as long the customer *can* *easily* configure >security in a way that such access is *not* granted (and as long >configuring things in this way retains all functionality of the >customer's devices in the same way as they would function had such >access been granted; i.e., don't cripple my equipment just because the >manufacturer can't access it). Furthermore, access should be >grantable on a per-device basis. I agree also. My point was that manufacturers can provide limits on access to certain functions e.g. for repairs. Repairman can only access trouble log unless granted access to control functions by customer. That is what I meant by application level security. However, there is still a need for end-to-end security that gives the customer control over who if anyone gets any access at all to the device. Bill Rose Leviton ------_=_NextPart_001_01BF9F1C.3D90E08E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: home network security

>
> <<... Manufacturers can provide = application level security that block access
> to potentially harmful functions unless = the homeowner grants it.>>
>
> I'd have to disagree that = "trust" is not an issue. Manufacturers are fallible
> and I may well prefer to grant NO access = and have this readily under my
> control---as a distinctly different = option from enabling potentially harmful
> functions.

>I have to complete agree. I have no problem = with making the default
>to grant such access as long the customer *can* = *easily* configure
>security in a way that such access is *not* = granted (and as long
>configuring things in this way retains all = functionality of the
>customer's devices in the same way as they would = function had such
>access been granted; i.e., don't cripple my = equipment just because the
>manufacturer can't access it). = Furthermore, access should be
>grantable on a per-device basis.

I agree also. My point was that manufacturers can = provide limits on access to certain functions e.g. for repairs. = Repairman can only access trouble log unless granted access to control = functions by customer. That is what I meant by application level = security. However, there is still a need for end-to-end security that = gives the customer control over who if anyone gets any access at all to = the device.

Bill Rose
Leviton

------_=_NextPart_001_01BF9F1C.3D90E08E-- From owner-zeroconf@merit.edu Wed Apr 5 18:00:10 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16954 for ; Wed, 5 Apr 2000 18:00:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 596025DE02; Wed, 5 Apr 2000 17:59:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3B0EA5DE09; Wed, 5 Apr 2000 17:59:06 -0400 (EDT) Received: from imo16.mx.aol.com (imo16.mx.aol.com [152.163.225.6]) by segue.merit.edu (Postfix) with ESMTP id 1AAB35DE02 for ; Wed, 5 Apr 2000 17:59:00 -0400 (EDT) Received: from PJohansson@aol.com by imo16.mx.aol.com (mail_out_v25.3.) id u.48.3ad6270 (3996); Wed, 5 Apr 2000 17:58:53 -0400 (EDT) From: PJohansson@aol.com Message-ID: <48.3ad6270.261d111d@aol.com> Date: Wed, 5 Apr 2000 17:58:53 EDT Subject: Re: home network security To: Wrose@leviton.com, raj@cisco.com Cc: ZeroConf@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 76 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In a message dated 00-04-05 12:34:42 EDT, Wrose@leviton.com writes: <> Yes---it was to clarify whether or not this was a point of agreement. Peter Johansson From owner-zeroconf@merit.edu Wed Apr 5 20:34:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18205 for ; Wed, 5 Apr 2000 20:34:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E75425DDE0; Wed, 5 Apr 2000 20:34:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D096C5DDD2; Wed, 5 Apr 2000 20:34:06 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id 586BE5DD9E for ; Wed, 5 Apr 2000 20:34:05 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA06081 for ; Wed, 5 Apr 2000 17:34:05 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA18066 for ; Wed, 5 Apr 2000 17:34:03 -0700 (MST)] Received: from motorola.com (swerve.arc.corp.mot.com [217.1.10.63]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id KAA27462 for ; Thu, 6 Apr 2000 10:34:01 +1000 (EST) Message-ID: <38EBDB79.E8C8DA0D@motorola.com> Date: Thu, 06 Apr 2000 10:34:01 +1000 From: Aidan Williams X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Re: home network security References: <010701bf9da0$179da9c0$268939cc@ntdev.microsoft.com> <38E99B92.2FE1F494@motorola.com> Content-Type: multipart/mixed; boundary="------------87EA376C50111873382FA2B2" Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------87EA376C50111873382FA2B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > 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. 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. regards aidan ____ :wq! --------------87EA376C50111873382FA2B2 Content-Type: text/x-vcard; charset=us-ascii; name="Aidan.Williams.vcf" Content-Description: Card for Aidan Williams Content-Disposition: attachment; filename="Aidan.Williams.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Williams;Aidan tel;fax:+61 2 9666 0501 tel;work:+61 2 9666 0649 x-mozilla-html:FALSE url:http://www.arc.corp.mot.com/ org:Motorola Australian Research Centre;Scalable Commodity Internet Laboratory version:2.1 email;internet:Aidan.Williams@motorola.com title:Senior Research Engineer adr;quoted-printable:;;(Not mailing address)=0D=0ALevel 3, 12 Lord Street;Botany;NSW;2019;Australia note;quoted-printable:Mailing address is:=0D=0A=0D=0AAidan Williams=0D=0ALocked Bag 5028=0D=0ABotany NSW 1455=0D=0A fn:Aidan Williams end:vcard --------------87EA376C50111873382FA2B2-- From owner-zeroconf@merit.edu Thu Apr 6 06:18:49 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06460 for ; Thu, 6 Apr 2000 06:18:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B8895DDEE; Thu, 6 Apr 2000 06:16:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 49E505DDE2; Thu, 6 Apr 2000 06:16:39 -0400 (EDT) Received: from imo23.mx.aol.com (imo23.mx.aol.com [152.163.225.67]) by segue.merit.edu (Postfix) with ESMTP id D95315DD98 for ; Thu, 6 Apr 2000 06:16:37 -0400 (EDT) Received: from PJohansson@aol.com by imo23.mx.aol.com (mail_out_v25.3.) id m.6a.1a3ee9e (3858) for ; Thu, 6 Apr 2000 06:16:31 -0400 (EDT) From: PJohansson@aol.com Message-ID: <6a.1a3ee9e.261dbdfe@aol.com> Date: Thu, 6 Apr 2000 06:16:30 EDT Subject: Re: home network security To: ZeroConf@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 76 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In a message dated 00-04-05 20:34:51 EDT, Aidan.Williams@motorola.com writes: <> I've entered this discussion with the assumption that "zero configuration" implies that we are working in an environment with *very* naive users, that we can expect little or no responsibility on their part to administer the network. Based on my observations, many (if not most) of these naive users have little or NO concept of security, not even the concept that they need security. Based on recent experience with a DSL installation, ISPs are doing little or nothin to educate customers with respect to security. My cynical belief (which could well be erroneous) is that their legal counsel has advised them that they will be less liable if they say absolutely nothing about the topic. My own conclusion is that it would be unconscionable to offer "zero configuration" products that do not have security enabled by DEFAULT. I think this is important enough that the eventual RFC state "security MUST be enabled by default." Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX pjohansson@aol.com From owner-zeroconf@merit.edu Thu Apr 6 08:33:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07549 for ; Thu, 6 Apr 2000 08:33:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94D0D5DE23; Thu, 6 Apr 2000 08:33:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 839265DE1C; Thu, 6 Apr 2000 08:33:21 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 3FE4D5DDB5 for ; Thu, 6 Apr 2000 08:33:20 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e36CXEe28695; Thu, 6 Apr 2000 08:33:14 -0400 Message-ID: <38EC8408.AA794403@senie.com> Date: Thu, 06 Apr 2000 08:33:12 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PJohansson@aol.com Cc: ZeroConf@merit.edu Subject: Re: home network security References: <6a.1a3ee9e.261dbdfe@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit PJohansson@aol.com wrote: > > In a message dated 00-04-05 20:34:51 EDT, Aidan.Williams@motorola.com writes: > > < 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.>> > > I've entered this discussion with the assumption that "zero configuration" > implies that we are working in an environment with *very* naive users, that > we can expect little or no responsibility on their part to administer the > network. > > Based on my observations, many (if not most) of these naive users have little > or NO concept of security, not even the concept that they need security. > Based on recent experience with a DSL installation, ISPs are doing little or > nothin to educate customers with respect to security. My cynical belief > (which could well be erroneous) is that their legal counsel has advised them > that they will be less liable if they say absolutely nothing about the topic. > > My own conclusion is that it would be unconscionable to offer "zero > configuration" products that do not have security enabled by DEFAULT. I think > this is important enough that the eventual RFC state "security MUST be > enabled by default." So, your argument is: Because wireless layer 2 media has security issues that require configuration, we should abandon zeroconf in its entirely? Security for layer 2 wireless devices may well require configuration of devices at layer 2. In this case, such devices are not "zeroconf" devices. Please explain how you propose to reconcile zero configuration with security. We've gone around on this several times. Perhaps we should abandon much of zeroconf. We could REQUIRE a central "house controller" which allows the homeowner to type in the serial number (really the MAC address) of each device, including appliances, computers, and the blender, and then provide configuration and security via DHCP, as well as defining the trust relationship for outside access. The DHCP server obviously becomes a single point of failure, and a single point of security attack, but it does provide a place to deal with all of this various issues of security. In the end, if we want security, we have to have configuration. If we are going to have to have configuration, then zeroconf fails, and it's time to abandon this WG and start a new one on home networking. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Thu Apr 6 09:34:02 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08118 for ; Thu, 6 Apr 2000 09:34:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9C1D35DDBB; Thu, 6 Apr 2000 09:33:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7D8B15DDB5; Thu, 6 Apr 2000 09:33:42 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 92CB95DDBB for ; Thu, 6 Apr 2000 09:33:40 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA05064; Thu, 6 Apr 2000 06:33:32 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunlabs-74.East.Sun.COM [129.148.74.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA23615; Thu, 6 Apr 2000 09:33:31 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id JAA06249; Thu, 6 Apr 2000 09:33:26 -0400 (EDT) Message-ID: <38EC9176.E64F5436@sun.com> Date: Thu, 06 Apr 2000 09:30:30 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com Cc: zeroconf@merit.edu Subject: Re: home network security References: <010e01bf9df1$ee772c90$268939cc@ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm pleased to see so much discussion of zeroconf security. This is an important issue and I'm glad we're discussing it. I think Bernard Aboba hit the nail on the head when he said that we need a threat analysis. This is the most basic first step. Until we agree on a threat analysis, any discussion of security measures is pointless. Bernard said: > I liked Jeff Schiller's take on the threats: in a home > environment, one should assume that the threats are mostly > "external"; we do not necessarily need to go to a great deal > of effort to protect parents against denial of service > attacks by their children. But as Bernard pointed out, "external" is a vague word here. Using a firewall to define who's trusted and who's not causes problems when a trusted user wants to access devices from outside the firewall. The firewall model also breaks down when the "internal" network is not secure. Many home networks are based on wireless or powerline technology, which are usually not secure at all. So I think we need to toss out the firewall model and go back to the threat analysis. First, let's agree what we're trying to secure. Our charter restricts our focus to four basic network functions: host configuration, name-to-address translation, service discovery, and multicast address allocation. Application layer protocols are not in scope here, I believe. Next, let's look at what we're trying to secure against. Our requirements document lays out three types of threats: Hoarding: Hosts claim all available resources, whether they plan to use them or not. This is a form of denial of service attack. Masquerading: Hosts can respond to requests that they should not so they can masquerade as another host. Antagonistic Server: A server could offer support for a critical service but intentionally misconfigure hosts on the network. This seems like a reasonable set of threats to start with. The hoarding attack pertains to host configuration, name-to-address resolution, and multicast address allocation. The masquerading attack pertains to name-to-address resolution and service discovery. The antagonistic server attack probably pertains to all four functions (host configuration, name-to-address translation, service discovery, and multicast address allocation), since all zeroconf protocols are designed to transition to non-zeroconf protocols when a server is detected. Are there other threats that we should be considering? Do we need to preserve the confidentiality of these basic network messages? Maybe you don't want your neighbors to know what services you use and when. Bernard proposed the following list of threats: > 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. I would argue that we should take threat a as a fact of life. A home network is not secure. Assume that malicious parties can send and receive on the home network at will. Any other assumption is doomed to failure. Threat b is out of scope, since we are not considering device control protocols. Threat c is very appropriate. That is the Antagonistic Server threat cited in our requirements. -Steve From owner-zeroconf@merit.edu Thu Apr 6 10:08:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08644 for ; Thu, 6 Apr 2000 10:08:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFB1F5DE09; Thu, 6 Apr 2000 10:08:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9A8305DDFF; Thu, 6 Apr 2000 10:08:44 -0400 (EDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by segue.merit.edu (Postfix) with ESMTP id 78CDD5DDB5 for ; Thu, 6 Apr 2000 10:08:43 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA18406; Thu, 6 Apr 2000 10:08:32 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA20938; Thu, 6 Apr 2000 10:08:31 -0400 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA31927; Thu, 6 Apr 2000 10:05:26 -0400 Message-Id: <200004061405.KAA31927@rotala.raleigh.ibm.com> To: Daniel Senie Cc: PJohansson@aol.com, ZeroConf@merit.edu Subject: Re: home network security In-Reply-To: Message from Daniel Senie of "Thu, 06 Apr 2000 08:33:12 EDT." <38EC8408.AA794403@senie.com> Date: Thu, 06 Apr 2000 10:05:26 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > In the end, if we want security, we have to have configuration. If we > are going to have to have configuration, then zeroconf fails, and it's > time to abandon this WG and start a new one on home networking. I think pretty much everyone agrees that there is no such thing as real security with absolutely no configuration. However, it does not immediately follow that we should therefore punt on security because it invalidates the primary goal of zeroconf. If we define a secure mode that requires configuration, that doesn't mean that security will need to be enabled by default in all environments. However, deploying a zeroconf system that has absolutely no security and no way to enable it would be equally irresponsible. The goals of this group should be to come up with a resonably secure mode that can be enabled with a minimal amount of configuration, and with configuration that can be dealt with by the typical home user. In my mind that could mean something like: 1) point and click enablement, not typing in secrets. (there are plenty of ways to generate initial secrets as a starting point) 2) doing enablement once and having other services bootstrap from that initial configuration. It may well be that additional "manual configuration" is needed for a new service, but that service might be as simple as a window popping up saying "a new device just came online, it claims to be a toaster. Do you want to add it to your set of trusted machines?" The user can then respond, presumably it just plugged the toaster in and so can verify that it is not a bad guy device. Keep in mind also, that we're not necessarily looking for iron-clad security. Rather, we're looking for a reasonable tradeoff in terms of configuration/ease of enablement, protection against the most serious threats, etc. Thus, while 2) above might leave a site vulnerable to some attacks (i.e., bad guy chimes in right as new toaster comes online), it protects against more serious ones (i.e., bad guy comes up at random and is given immediate and wide-open access). Thomas From owner-zeroconf@merit.edu Thu Apr 6 12:39:19 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10937 for ; Thu, 6 Apr 2000 12:39:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7E625DE69; Thu, 6 Apr 2000 12:37:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 54F0F5DE1C; Thu, 6 Apr 2000 12:37:30 -0400 (EDT) Received: from ids2.idsonline.com (ids2.idsonline.com [205.177.236.32]) by segue.merit.edu (Postfix) with ESMTP id A5B255DE69 for ; Thu, 6 Apr 2000 12:37:02 -0400 (EDT) Received: from 21rst-century.com (dc-csesp159.idsonline.com [207.176.21.159]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id MAA04807; Thu, 6 Apr 2000 12:51:41 -0400 Message-ID: <38ECBD1E.1A5EEA9@21rst-century.com> Date: Thu, 06 Apr 2000 12:36:46 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Senie Cc: PJohansson@aol.com, ZeroConf@merit.edu Subject: Re: home network security References: <6a.1a3ee9e.261dbdfe@aol.com> <38EC8408.AA794403@senie.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Senie wrote: > PJohansson@aol.com wrote: > > > > In a message dated 00-04-05 20:34:51 EDT, Aidan.Williams@motorola.com writes: > > > > < > 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.>> > > > > I've entered this discussion with the assumption that "zero configuration" > > implies that we are working in an environment with *very* naive users, that > > we can expect little or no responsibility on their part to administer the > > network. > > > > Based on my observations, many (if not most) of these naive users have little > > or NO concept of security, not even the concept that they need security. > > Based on recent experience with a DSL installation, ISPs are doing little or > > nothin to educate customers with respect to security. My cynical belief > > (which could well be erroneous) is that their legal counsel has advised them > > that they will be less liable if they say absolutely nothing about the topic. > > > > My own conclusion is that it would be unconscionable to offer "zero > > configuration" products that do not have security enabled by DEFAULT. I think > > this is important enough that the eventual RFC state "security MUST be > > enabled by default." > > So, your argument is: Because wireless layer 2 media has security issues > that require configuration, we should abandon zeroconf in its entirely? > > Security for layer 2 wireless devices may well require configuration of > devices at layer 2. In this case, such devices are not "zeroconf" > devices. Please explain how you propose to reconcile zero configuration > with security. We've gone around on this several times. > > Perhaps we should abandon much of zeroconf. We could REQUIRE a central > "house controller" which allows the homeowner to type in the serial > number (really the MAC address) of each device, including appliances, > computers, and the blender, and then provide configuration and security > via DHCP, as well as defining the trust relationship for outside access. > The DHCP server obviously becomes a single point of failure, and a > single point of security attack, but it does provide a place to deal > with all of this various issues of security. Hello; I think that a reasonable goal for zeroconfig should be : to provide Internet connected devices that even your COULD and WOULD use. Pigs will fly before my Mother starts typing in all of of these serial numbers. You could probably get her to enter her phone number and / or her address. If you ask her for a password, she will probably use her phone number and / or her address. If she ever hears of someone's home being broken into because someone (say) hacked in and figured that no-one was at home because the refrigerator hadn't been opened for 4 days, she will NEVER buy the system. This suggests two levels of quasi-zeroconfig devices : Benign devices, such as a stand alone Internet radio or a printer, which can be truly zeroconfig BECAUSE THERE IS NO DANGER IF THEY ARE COMPROMISED. Non-benign devices, such as a home security system, which will require some configuration, such as the entry of a ID such as a phone number, It would probably be a good idea if such a non-benign device 1.) Only accepted commands from packets with TTL = 1 and confirmation of the ID from a central device. 2.) Required a manual override to be controlled from outside the zeroconfig network. (I.e., "you have to push the to allow us to upgrade your fire alarm"). This manual override should be of limited duration (say, 30 minutes). To be a benign device : The device cannot act in such a way as to cause any physical danger based on commands from outside, even from the zeroconfig net, (such as instructing a stove to turn on and stay on over the net) AND The device cannot convey any information about the state of the users (such as the last time the refrigerator door was opened). Zeroconfig should therefore work to provide a specification for what makes a device benign, and therefore subject to zeroconfig. Maybe there should be a separate WG for security and minimum configuration for non-benign devices. Regards Marshall Eubanks > > In the end, if we want security, we have to have configuration. If we > are going to have to have configuration, then zeroconf fails, and it's > time to abandon this WG and start a new one on home networking. > > -- > ----------------------------------------------------------------- > Daniel Senie dts@senie.com > Amaranth Networks Inc. http://www.amaranth.com T.M. Eubanks Multicast Technologies, Inc P.O. Box 99 Clifton, Virginia 20124 Phone : 703-803-8141 Fax : 703-222-3250 e-mail : tme@21rst-century.com From owner-zeroconf@merit.edu Thu Apr 6 13:42:06 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11872 for ; Thu, 6 Apr 2000 13:42:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C4425DDFD; Thu, 6 Apr 2000 13:41:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7AEB55DDF6; Thu, 6 Apr 2000 13:41:55 -0400 (EDT) Received: from apollo.leviton.com (apollo.leviton.com [209.177.59.130]) by segue.merit.edu (Postfix) with ESMTP id E45055DDBB for ; Thu, 6 Apr 2000 13:41:51 -0400 (EDT) Received: by APOLLO with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Apr 2000 13:37:53 -0400 Message-ID: From: "Rose, William" To: "'Aidan Williams'" , zeroconf@merit.edu Subject: RE: home network security Date: Thu, 6 Apr 2000 13:37:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9FEE.D5ADACA8" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9FEE.D5ADACA8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> 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): =B7 Unauthorized access =B7 Eavesdropping =B7 Intercept/Alter (Info is intercepted and altered) =B7 Masquerade (spoofing or acting as a legitimate device =B7 Replay (Eavesdropped message is replayed at a later time) =B7 Denial of Service =B7 Resource exhaustion =B7 Service Spoofing =B7 Trojan Horse=20 =B7 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 ------_=_NextPart_001_01BF9FEE.D5ADACA8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: home network security

>> 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):
=B7 Unauthorized access
=B7 Eavesdropping
=B7 Intercept/Alter (Info is intercepted and = altered)
=B7 Masquerade (spoofing or acting as a legitimate = device
=B7 Replay (Eavesdropped message is replayed at a = later time)
=B7 Denial of Service
=B7 Resource exhaustion
=B7 Service Spoofing
=B7 Trojan Horse
=B7 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

------_=_NextPart_001_01BF9FEE.D5ADACA8-- From owner-zeroconf@merit.edu Thu Apr 6 14:03:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12161 for ; Thu, 6 Apr 2000 14:03:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E903E5DE27; Thu, 6 Apr 2000 14:01:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AC9CE5DE2A; Thu, 6 Apr 2000 14:01:55 -0400 (EDT) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by segue.merit.edu (Postfix) with ESMTP id 793B05DE27 for ; Thu, 6 Apr 2000 14:01:53 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id NAA05816; Thu, 6 Apr 2000 13:59:55 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568B9.0062DB5D ; Thu, 6 Apr 2000 13:59:46 -0400 X-Lotus-FromDomain: TELCORDIA From: "Steven G. Ungar" To: tme@21rst-century.com Cc: Daniel Senie , PJohansson@aol.com, ZeroConf@merit.edu Message-ID: <852568B9.0062D970.00@notes949.cc.telcordia.com> Date: Thu, 6 Apr 2000 13:58:45 -0400 Subject: Re: home network security Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-zeroconf@merit.edu Precedence: bulk Marshall, Daniel, Peter, Bill, et al: I have been following this discussion with great interest, and have learned a lot. Marshall: I fully agree with your analysis, but I would be interested in knowing how would you classify, say, a digital television: Is it benign or non-benign? It contains a rather powerful processor which could be used to harbor a Trojan Horse that would operate throughout the home network, poking into data bases, collecting interesting information about the home (such as when the burglar alarm tends to be turned off, and where the safe is located), and sending that information out to the world. Yet, you can't expect a homeowner to tolerate a security lock on her television; she's not going to log in every time she wants to watch. In other words, I think you are on to something with the classification, but I think that there will be many everyday, commonly used appliances, that will not be "benign." Is it practical, for these devices, to distinguish between access that originates within the home, and thus can be considered friendly, and access that originates beyond the firewall, and must be authenticated? Steven Ungar, Telcordia Technologies Thomas Marshall Eubanks on 04/06/2000 12:36:46 PM Please respond to tme@21rst-century.com To: Daniel Senie cc: PJohansson@aol.com, ZeroConf@merit.edu (bcc: Steven G. Ungar/Telcordia) Subject: Re: home network security Daniel Senie wrote: > PJohansson@aol.com wrote: > > > > In a message dated 00-04-05 20:34:51 EDT, Aidan.Williams@motorola.com writes: > > > > < > 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.>> > > > > I've entered this discussion with the assumption that "zero configuration" > > implies that we are working in an environment with *very* naive users, that > > we can expect little or no responsibility on their part to administer the > > network. > > > > Based on my observations, many (if not most) of these naive users have little > > or NO concept of security, not even the concept that they need security. > > Based on recent experience with a DSL installation, ISPs are doing little or > > nothin to educate customers with respect to security. My cynical belief > > (which could well be erroneous) is that their legal counsel has advised them > > that they will be less liable if they say absolutely nothing about the topic. > > > > My own conclusion is that it would be unconscionable to offer "zero > > configuration" products that do not have security enabled by DEFAULT. I think > > this is important enough that the eventual RFC state "security MUST be > > enabled by default." > > So, your argument is: Because wireless layer 2 media has security issues > that require configuration, we should abandon zeroconf in its entirely? > > Security for layer 2 wireless devices may well require configuration of > devices at layer 2. In this case, such devices are not "zeroconf" > devices. Please explain how you propose to reconcile zero configuration > with security. We've gone around on this several times. > > Perhaps we should abandon much of zeroconf. We could REQUIRE a central > "house controller" which allows the homeowner to type in the serial > number (really the MAC address) of each device, including appliances, > computers, and the blender, and then provide configuration and security > via DHCP, as well as defining the trust relationship for outside access. > The DHCP server obviously becomes a single point of failure, and a > single point of security attack, but it does provide a place to deal > with all of this various issues of security. Hello; I think that a reasonable goal for zeroconfig should be : to provide Internet connected devices that even your COULD and WOULD use. Pigs will fly before my Mother starts typing in all of of these serial numbers. You could probably get her to enter her phone number and / or her address. If you ask her for a password, she will probably use her phone number and / or her address. If she ever hears of someone's home being broken into because someone (say) hacked in and figured that no-one was at home because the refrigerator hadn't been opened for 4 days, she will NEVER buy the system. This suggests two levels of quasi-zeroconfig devices : Benign devices, such as a stand alone Internet radio or a printer, which can be truly zeroconfig BECAUSE THERE IS NO DANGER IF THEY ARE COMPROMISED. Non-benign devices, such as a home security system, which will require some configuration, such as the entry of a ID such as a phone number, It would probably be a good idea if such a non-benign device 1.) Only accepted commands from packets with TTL = 1 and confirmation of the ID from a central device. 2.) Required a manual override to be controlled from outside the zeroconfig network. (I.e., "you have to push the to allow us to upgrade your fire alarm"). This manual override should be of limited duration (say, 30 minutes). To be a benign device : The device cannot act in such a way as to cause any physical danger based on commands from outside, even from the zeroconfig net, (such as instructing a stove to turn on and stay on over the net) AND The device cannot convey any information about the state of the users (such as the last time the refrigerator door was opened). Zeroconfig should therefore work to provide a specification for what makes a device benign, and therefore subject to zeroconfig. Maybe there should be a separate WG for security and minimum configuration for non-benign devices. Regards Marshall Eubanks > > In the end, if we want security, we have to have configuration. If we > are going to have to have configuration, then zeroconf fails, and it's > time to abandon this WG and start a new one on home networking. > > -- > ----------------------------------------------------------------- > Daniel Senie dts@senie.com > Amaranth Networks Inc. http://www.amaranth.com T.M. Eubanks Multicast Technologies, Inc P.O. Box 99 Clifton, Virginia 20124 Phone : 703-803-8141 Fax : 703-222-3250 e-mail : tme@21rst-century.com From owner-zeroconf@merit.edu Thu Apr 6 14:48:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12779 for ; Thu, 6 Apr 2000 14:48:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1866D5DDF6; Thu, 6 Apr 2000 14:46:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F0AA25DDFB; Thu, 6 Apr 2000 14:46:44 -0400 (EDT) Received: from ids2.idsonline.com (ids2.idsonline.com [205.177.236.32]) by segue.merit.edu (Postfix) with ESMTP id 9DA375DDF6 for ; Thu, 6 Apr 2000 14:46:43 -0400 (EDT) Received: from 21rst-century.com (dc-csesp159.idsonline.com [207.176.21.159]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id PAA14254; Thu, 6 Apr 2000 15:01:25 -0400 Message-ID: <38ECDB87.9D6427CB@21rst-century.com> Date: Thu, 06 Apr 2000 14:46:31 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Steven G. Ungar" Cc: Daniel Senie , PJohansson@aol.com, ZeroConf@merit.edu Subject: Re: home network security References: <852568B9.0062D970.00@notes949.cc.telcordia.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Steven G. Ungar" wrote: > Marshall, Daniel, Peter, Bill, et al: > > I have been following this discussion with great interest, and have learned a > lot. > > Marshall: > > I fully agree with your analysis, but I would be interested in knowing how would > you classify, say, a digital television: Is it benign or non-benign? It > contains a rather powerful processor which could be used to harbor a Trojan > Horse that would operate throughout the home network, poking into data bases, > collecting interesting information about the home (such as when the burglar > alarm tends to be turned off, and where the safe is located), and sending that > information out to the world. Yet, you can't expect a homeowner to tolerate a > security lock on her television; she's not going to log in every time she wants > to watch. In other words, I think you are on to something with the > classification, but I think that there will be many everyday, commonly used > appliances, that will not be "benign." Is it practical, for these devices, to > distinguish between access that originates within the home, and thus can be > considered friendly, and access that originates beyond the firewall, and must be > authenticated? > > Steven Ungar, > Telcordia Technologies > > Thomas Marshall Eubanks on 04/06/2000 12:36:46 PM Dear Steven; That has to be part of what the WG DOES. My personal feeling is that if you buy a box off the shelf, you should be able to trust it not to contain a trojan horse. If it does, the resulting lawsuits will probably drive the manufacturer out of business. However, your point is a good one that zeroconfig cannot ASSUME the absence of trojan horses, even inside the home. (Your computer will likely be on this net, and may certainly be compromised.) Maybe a benign device cannot transmit out at all ! For a benign device, deciding what comes from within the home and what does not is not so important. Even if you spoof it, you cannot really do anything seriously wrong. If my radio starts spewing out garbage, I can turn it off. It cannot kill me. I agree that there will be many everyday, commonly used appliances, that will not be "benign." A stove may be a good example - ever forgotten about a tea kettle ? I think it is reasonable to expect a learning curve here - things that seem benign now, may not after someone figures out a way to do something non-benign with them. I would again suggest that the working group, as a start, derive a description of a benign device : 1.) Incapable of causing physical harm, no matter what, either by its nature, or because of. e.g., physical interlocks. 2.) Cannot transmit information about the specific activities of the specific user, except maybe to the vendor using strong encryption. Consider a stand-alone Internet radio. Presumably it cannot be made to blow up, so # 1 is a given. Number 2 could be satisfied if there was no way it could reveal its state. Note that it could still receive a "turn on at 6:30- AM" message, and could even acknowledge it. It should NOT be able to report, even within the home, if it was turned on manually at a specific time. Note that at some level you have to trust the vendor. If that trust is violated, the vendor will not stay in business. Also note that there has to be a limit. Did you know that most devices do particular things to the line voltage in your house as they are turned on and off ? A trojan horse could simply monitor line voltage at its power input, and get a pretty good idea of activity patterns, and maybe even identify particular actions, such as the TV turning on. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc P.O. Box 99 Clifton, Virginia 20124 Phone : 703-803-8141 Fax : 703-222-3250 e-mail : tme@21rst-century.com From owner-zeroconf@merit.edu Thu Apr 6 14:54:42 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12913 for ; Thu, 6 Apr 2000 14:54:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAE425DDBF; Thu, 6 Apr 2000 14:54:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AA0615DDBB; Thu, 6 Apr 2000 14:54:33 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by segue.merit.edu (Postfix) with ESMTP id EF14B5DDA7 for ; Thu, 6 Apr 2000 14:54:31 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id OAA19983; Thu, 6 Apr 2000 14:53:35 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568B9.0067C2CF ; Thu, 6 Apr 2000 14:53:20 -0400 X-Lotus-FromDomain: TELCORDIA From: "Steven G. Ungar" To: tme@21rst-century.com Cc: "Steven G. Ungar" , Daniel Senie , PJohansson@aol.com, ZeroConf@merit.edu Message-ID: <852568B9.0067C152.00@notes949.cc.telcordia.com> Date: Thu, 6 Apr 2000 14:52:20 -0400 Subject: Re: home network security Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-zeroconf@merit.edu Precedence: bulk Marshall: Thanks for your response, but I think you missed my point: I am not so worried about buying an infected DTV from Circuit City: I am worried about an intruder penetrating my firewall, gaining access to my home network, finding an unprotected processor, for instance in my nice, clean DTV, and loading a Trojan Horse into it. It can then do nasty things, in the background, that I would not know about until it was way too late. Given that clarification, how do we classify my television, benign or not? And if not, how can we make it real hard for the above scenario to happen, without making it so expensive or inconvenient for the homeowner that she is inclined to either, a) take the risk or b) do without outside access to the home network. Thanks, Steven U. Thomas Marshall Eubanks on 04/06/2000 02:46:31 PM Please respond to tme@21rst-century.com To: "Steven G. Ungar" cc: Daniel Senie , PJohansson@aol.com, ZeroConf@merit.edu (bcc: Steven G. Ungar/Telcordia) Subject: Re: home network security "Steven G. Ungar" wrote: > Marshall, Daniel, Peter, Bill, et al: > > I have been following this discussion with great interest, and have learned a > lot. > > Marshall: > > I fully agree with your analysis, but I would be interested in knowing how would > you classify, say, a digital television: Is it benign or non-benign? It > contains a rather powerful processor which could be used to harbor a Trojan > Horse that would operate throughout the home network, poking into data bases, > collecting interesting information about the home (such as when the burglar > alarm tends to be turned off, and where the safe is located), and sending that > information out to the world. Yet, you can't expect a homeowner to tolerate a > security lock on her television; she's not going to log in every time she wants > to watch. In other words, I think you are on to something with the > classification, but I think that there will be many everyday, commonly used > appliances, that will not be "benign." Is it practical, for these devices, to > distinguish between access that originates within the home, and thus can be > considered friendly, and access that originates beyond the firewall, and must be > authenticated? > > Steven Ungar, > Telcordia Technologies > > Thomas Marshall Eubanks on 04/06/2000 12:36:46 PM Dear Steven; That has to be part of what the WG DOES. My personal feeling is that if you buy a box off the shelf, you should be able to trust it not to contain a trojan horse. If it does, the resulting lawsuits will probably drive the manufacturer out of business. However, your point is a good one that zeroconfig cannot ASSUME the absence of trojan horses, even inside the home. (Your computer will likely be on this net, and may certainly be compromised.) Maybe a benign device cannot transmit out at all ! For a benign device, deciding what comes from within the home and what does not is not so important. Even if you spoof it, you cannot really do anything seriously wrong. If my radio starts spewing out garbage, I can turn it off. It cannot kill me. I agree that there will be many everyday, commonly used appliances, that will not be "benign." A stove may be a good example - ever forgotten about a tea kettle ? I think it is reasonable to expect a learning curve here - things that seem benign now, may not after someone figures out a way to do something non-benign with them. I would again suggest that the working group, as a start, derive a description of a benign device : 1.) Incapable of causing physical harm, no matter what, either by its nature, or because of. e.g., physical interlocks. 2.) Cannot transmit information about the specific activities of the specific user, except maybe to the vendor using strong encryption. Consider a stand-alone Internet radio. Presumably it cannot be made to blow up, so # 1 is a given. Number 2 could be satisfied if there was no way it could reveal its state. Note that it could still receive a "turn on at 6:30- AM" message, and could even acknowledge it. It should NOT be able to report, even within the home, if it was turned on manually at a specific time. Note that at some level you have to trust the vendor. If that trust is violated, the vendor will not stay in business. Also note that there has to be a limit. Did you know that most devices do particular things to the line voltage in your house as they are turned on and off ? A trojan horse could simply monitor line voltage at its power input, and get a pretty good idea of activity patterns, and maybe even identify particular actions, such as the TV turning on. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc P.O. Box 99 Clifton, Virginia 20124 Phone : 703-803-8141 Fax : 703-222-3250 e-mail : tme@21rst-century.com From owner-zeroconf@merit.edu Thu Apr 6 15:33:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13691 for ; Thu, 6 Apr 2000 15:33:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 515EB5DE23; Thu, 6 Apr 2000 15:31:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 403705DE22; Thu, 6 Apr 2000 15:31:26 -0400 (EDT) Received: from rkrishnan.bbn.com (RKRISHNAN.BBN.COM [128.89.35.252]) by segue.merit.edu (Postfix) with ESMTP id DF0455DE1D for ; Thu, 6 Apr 2000 15:31:24 -0400 (EDT) Received: (from krash@localhost) by rkrishnan.bbn.com (8.9.3/8.9.3) id PAA25942; Thu, 6 Apr 2000 15:31:36 -0400 From: Rajesh Krishnan Message-Id: <200004061931.PAA25942@rkrishnan.bbn.com> Subject: Re: home network security To: sungar@telcordia.com (Steven G. Ungar) Date: Thu, 6 Apr 2000 15:31:36 -0400 (EDT) Cc: tme@21rst-century.com, sungar@telcordia.com (Steven G. Ungar), dts@senie.com (Daniel Senie), PJohansson@aol.com, ZeroConf@merit.edu In-Reply-To: <852568B9.0067C152.00@notes949.cc.telcordia.com> from "Steven G. Ungar" at Apr 06, 2000 02:52:20 PM Reply-To: krash@bbn.com X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Classifying Internet radios or controls for window blinds as "benign" and therefore not requiring access security is troublesome. If they have open control, and if firewalling is not an adequate answer (wireless bridging etc.,), then such devices could be turned off/on by unauthorized people. In a sense, this means any device which is network controllable or observable (if potentially carrying sensitive information) can not be safely classified as benign. The Internet Radio is benign as long as I cannot turn it on or off or change the volume or station over the net. Such network control could be a useful feature -- auto-mute-radio when getting a telephone call. If the device can be controlled over the net, then security requirements come right back in. The useful question I suppose is how many networked devices in the home would require security and what is the "cost" of providing such security. If the number is sufficiently large (which I believe to be true), and the cost is sufficiently low (which I do not know) then classifying some devices as benign may not be particularly helpful. If we are going to specify security as a requirement for at least some inexpensive zeroconf devices, then single chip network stack solutions which include zeroconf and security support will likely become available and benign could be simply a pin tied to the ground. -Rajesh > Marshall: > > Thanks for your response, but I think you missed my point: > > I am not so worried about buying an infected DTV from Circuit City: I am > worried about an intruder penetrating my firewall, gaining access to my home > network, finding an unprotected processor, for instance in my nice, clean DTV, > and loading a Trojan Horse into it. It can then do nasty things, in the > background, that I would not know about until it was way too late. > > Given that clarification, how do we classify my television, benign or not? And > if not, how can we make it real hard for the above scenario to happen, without > making it so expensive or inconvenient for the homeowner that she is inclined to > either, a) take the risk or b) do without outside access to the home network. > > Thanks, > > Steven U. > > > > > > > Thomas Marshall Eubanks on 04/06/2000 02:46:31 PM > > Please respond to tme@21rst-century.com > > To: "Steven G. Ungar" > cc: Daniel Senie , PJohansson@aol.com, ZeroConf@merit.edu (bcc: > Steven G. Ungar/Telcordia) > Subject: Re: home network security > > > > > "Steven G. Ungar" wrote: > > > Marshall, Daniel, Peter, Bill, et al: > > > > I have been following this discussion with great interest, and have learned a > > lot. > > > > Marshall: > > > > I fully agree with your analysis, but I would be interested in knowing how > would > > you classify, say, a digital television: Is it benign or non-benign? It > > contains a rather powerful processor which could be used to harbor a Trojan > > Horse that would operate throughout the home network, poking into data bases, > > collecting interesting information about the home (such as when the burglar > > alarm tends to be turned off, and where the safe is located), and sending that > > information out to the world. Yet, you can't expect a homeowner to tolerate a > > security lock on her television; she's not going to log in every time she > wants > > to watch. In other words, I think you are on to something with the > > classification, but I think that there will be many everyday, commonly used > > appliances, that will not be "benign." Is it practical, for these devices, to > > distinguish between access that originates within the home, and thus can be > > considered friendly, and access that originates beyond the firewall, and must > be > > authenticated? > > > > Steven Ungar, > > Telcordia Technologies > > > > Thomas Marshall Eubanks on 04/06/2000 12:36:46 PM > > Dear Steven; > > That has to be part of what the WG DOES. My personal feeling is that > if you buy a box off the shelf, you should be able to trust it not > to contain a trojan horse. If it does, the resulting lawsuits will probably > drive the manufacturer out of business. However, your point is a good > one that zeroconfig cannot ASSUME the absence of trojan horses, even > inside the home. (Your computer will likely be on this net, and may > certainly be compromised.) Maybe a benign > device cannot transmit out at all ! > > For a benign device, deciding what comes from within the home and what does > not > is not so important. Even if you spoof it, you cannot really do anything > seriously wrong. > If my radio starts spewing out garbage, I can turn it off. It cannot kill me. > > I agree that there will be many everyday, commonly used > appliances, that will not be "benign." A stove may be a good example - > ever forgotten about a tea kettle ? > > I think it is reasonable to expect a learning curve here - things that > seem benign now, may not after someone figures out a way to do something > non-benign > with them. I would again suggest that the working group, as a start, derive > a description of a > benign device : > > 1.) Incapable of causing physical harm, no matter what, either by its nature, or > because of. e.g., > physical interlocks. > 2.) Cannot transmit information about the specific activities of the specific > user, except > maybe to the vendor using strong encryption. > > Consider a stand-alone Internet radio. Presumably it cannot be made to blow up, > so # 1 is > a given. Number 2 could be satisfied if there was no way it could reveal its > state. > Note that it could still receive a "turn on at 6:30- AM" message, and could even > acknowledge it. > It should NOT be able to report, even within the home, if it was turned on > manually at a specific time. > > Note that at some level you have to trust the vendor. If that trust is violated, > the vendor will not > stay in business. > > Also note that there has to be a limit. Did you know that most devices do > particular things to > the line voltage in your house as they are turned on and off ? A trojan horse > could simply monitor > line voltage at its power input, and get a pretty good idea of activity > patterns, and maybe > even identify particular actions, such as the TV turning on. > > Regards > Marshall Eubanks > > > T.M. Eubanks > Multicast Technologies, Inc > P.O. Box 99 > Clifton, Virginia 20124 > Phone : 703-803-8141 > Fax : 703-222-3250 > e-mail : tme@21rst-century.com > > > > > > > > > From owner-zeroconf@merit.edu Thu Apr 6 15:38:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13744 for ; Thu, 6 Apr 2000 15:38:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 69D285DE12; Thu, 6 Apr 2000 15:37:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4B9F35DE1B; Thu, 6 Apr 2000 15:37:05 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 09B3F5DE12 for ; Thu, 6 Apr 2000 15:37:00 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25951; Thu, 6 Apr 2000 12:36:45 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA08134; Thu, 6 Apr 2000 15:36:44 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id PAA21026; Thu, 6 Apr 2000 15:36:39 -0400 (EDT) Message-ID: <38ECE697.BEB8BE2D@sun.com> Date: Thu, 06 Apr 2000 15:33:43 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rose, William" Cc: "'Aidan Williams'" , zeroconf@merit.edu Subject: Re: home network security References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit 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 > � 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 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 From owner-zeroconf@merit.edu Thu Apr 6 16:23:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14210 for ; Thu, 6 Apr 2000 16:23:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C7F65DDBB; Thu, 6 Apr 2000 16:23:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 597255DDBF; Thu, 6 Apr 2000 16:23:07 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id 4D24E5DDBB for ; Thu, 6 Apr 2000 16:23:06 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA06214 for ; Thu, 6 Apr 2000 13:23:05 -0700 (MST)] Received: [from az33exi02.corp.mot.com ([199.2.84.11]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA14192 for ; Thu, 6 Apr 2000 13:23:04 -0700 (MST)] Received: by AZ33EXI02 with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Apr 2000 13:23:02 -0700 Message-ID: From: Austin Bill-P23393 To: ZeroConf@merit.edu Subject: RE: home network security Date: Thu, 6 Apr 2000 13:22:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk This discussion topic has been pursued in our company for quite a while. I will clean up some of the more valuable points of our discussion and post them without attribution to the several authors. The post below tries to place "real-world" perspectives on the security implications of a variety of rapidly approaching networking technologies. The authors were very unhappy with the lack of a front-end, top-down, systems approach to security in the zero-conf environment. If you are new to the list, please read "nits" as "Zero-Conf" For what it's worth: " It appears the "nits" group (and likely soon [?] Bluetooth/other Personal Networks groups) may be focusing exclusively on performance without concern for security implications. The adverse potential business impact of that position should be obvious to anyone. " " If you and I pass anonymously, but I am able to capture your "address", whether IP or not, not only for your personal device, but also for your home freezer or alarm system or automobile, it is a relatively small step to attack you and/or your e-property. " " Ignoring for a moment the "classic military electronic warfare tools" which are now available in COTS devices, the ability for a Service Discovery Protocol, or equivalent, to walk my personal directory tree has terrible implications for information attack. Unfortunately, if we are not entirely successful in impacting internal company developments with "silly" top-down considerations such as security systems engineering, how will we be able to fixes/overlays/retrofits for already fielded systems? The fact that it is physically difficult to go somewhere and then break into a house is a fairly effective deterrent to burglars who would otherwise attack one's house door, etc., (whether with a master key, a prybar, sledgehammer or a heavy boot). However, the ability to look inside one's house and into the owner's private inventory files from any remote location --thereby determining the value and salability of one's property prior to a burglary -- would be a big help to the burglar. That possibility lies at the "Application" layer today. However, the ability to peruse someone else's e-property lies much lower in the stack. It appears that nits (etc.??) are trying to build that very capability into system MAC, Networking and/or Transport layers. Of course, whether or not I or a burglar would then try or even succeed with information attacks on YOUR e-property is then removed from your control, just as is your ability to stop me from trying to break into your house, whether I succeed or not, is outside your control. However, e-attack is less physically demanding. And vastly more profitable, as it would increase attacker opportunity, motive, and cycle time -- yielding an increased probability of success as a function of time and effort. " " The first gas crisis in the early 1970's spurred the ubiquity of gas tank locks, springs in the fill pipe and other countermeasures. Likewise, poorly designed and weakly implemented Service Discovery Protocols could spur vast new empires of e-protection -- all unnecessary with appropriate forethought. By ignoring the well known vulnerabilities designed into these systems we risk knowingly subjecting our customers to a wide variety of preventable criminal actions. So might we foresee multiple diverse after-market e-security overlays onto each e-nabled personal e-device? Might these effectively e-parallel the multiple overlays of physical security some paranoid (NO, that's "Rational") automobile owners now employ (e.g., OEM door/trunk locks, OEM/optional built-in alarm system, aftermarket CLUB, aftermarket add-on alarm system, aftermarket LoJack, etc.)?? " " After outfitting e-security overlays into my PDA or other personal device, the prospect of any "passing stranger" becoming acquainted with my entire e-directory (don't forget the need to also protect all shared ones such as for other family members) could even make me want to buy hardened cable and lockboxes for my freezer and dishwasher just for consistency. Where should we draw the line? A hardened cable for the e-pencil sharpener? An internal home atrium (screened overhead and alarmed of course) for my UPS battery bank and emergency generator? " " A bit of responsible top-down systems engineering from the Standards and Specification groups seems in order. Otherwise, after-the-fact, criticism and litigation will be much more expensive. Pinto gas tanks, Corvair road handling, and Space Shuttle O-rings come to mind. " -- Bill Austin http://home.att.net/~wbaustin/ Motorola Bluetooth http://www.mot.com/bluetooth/ The Digital Experience http://experience.motorola.com/ AzTeC Free-Net http://aztec.asu.edu/ > -----Original Message----- > From: Rajesh Krishnan [mailto:krash@bbn.com] > Sent: Thursday, April 06, 2000 12:32 PM > To: sungar@telcordia.com > Cc: tme@21rst-century.com; sungar@telcordia.com; dts@senie.com; > PJohansson@aol.com; ZeroConf@merit.edu > Subject: Re: home network security > > > Classifying Internet radios or controls for window blinds as "benign" > and therefore not requiring access security is troublesome. If they > have open control, and if firewalling is not an adequate answer > (wireless bridging etc.,), then such devices could be turned off/on > by unauthorized people. > > In a sense, this means any device which is network controllable > or observable (if potentially carrying sensitive information) can > not be safely classified as benign. The Internet Radio is benign > as long as I cannot turn it on or off or change the volume or > station over the net. Such network control could be a useful > feature -- auto-mute-radio when getting a telephone call. If the > device can be controlled over the net, then security requirements > come right back in. > > The useful question I suppose is how many networked devices in the > home would require security and what is the "cost" of providing > such security. If the number is sufficiently large (which I believe > to be true), and the cost is sufficiently low (which I do not know) > then classifying some devices as benign may not be > particularly helpful. > > If we are going to specify security as a requirement for at > least some > inexpensive zeroconf devices, then single chip network stack > solutions > which include zeroconf and security support will likely > become available > and benign could be simply a pin tied to the ground. > > -Rajesh > > > Marshall: > > > > Thanks for your response, but I think you missed my point: > > > > I am not so worried about buying an infected DTV from > Circuit City: I am > > worried about an intruder penetrating my firewall, gaining > access to my home > > network, finding an unprotected processor, for instance in > my nice, clean DTV, > > and loading a Trojan Horse into it. It can then do nasty > things, in the > > background, that I would not know about until it was way too late. > > > > Given that clarification, how do we classify my television, > benign or not? And > > if not, how can we make it real hard for the above scenario > to happen, without > > making it so expensive or inconvenient for the homeowner > that she is inclined to > > either, a) take the risk or b) do without outside access to > the home network. > > > > Thanks, > > > > Steven U. > > > > > > > > > > > > > > Thomas Marshall Eubanks on > 04/06/2000 02:46:31 PM > > > > Please respond to tme@21rst-century.com > > > > To: "Steven G. Ungar" > > cc: Daniel Senie , PJohansson@aol.com, > ZeroConf@merit.edu (bcc: > > Steven G. Ungar/Telcordia) > > Subject: Re: home network security > > > > > > > > > > "Steven G. Ungar" wrote: > > > > > Marshall, Daniel, Peter, Bill, et al: > > > > > > I have been following this discussion with great > interest, and have learned a > > > lot. > > > > > > Marshall: > > > > > > I fully agree with your analysis, but I would be > interested in knowing how > > would > > > you classify, say, a digital television: Is it benign or > non-benign? It > > > contains a rather powerful processor which could be used > to harbor a Trojan > > > Horse that would operate throughout the home network, > poking into data bases, > > > collecting interesting information about the home (such > as when the burglar > > > alarm tends to be turned off, and where the safe is > located), and sending that > > > information out to the world. Yet, you can't expect a > homeowner to tolerate a > > > security lock on her television; she's not going to log > in every time she > > wants > > > to watch. In other words, I think you are on to > something with the > > > classification, but I think that there will be many > everyday, commonly used > > > appliances, that will not be "benign." Is it practical, > for these devices, to > > > distinguish between access that originates within the > home, and thus can be > > > considered friendly, and access that originates beyond > the firewall, and must > > be > > > authenticated? > > > > > > Steven Ungar, > > > Telcordia Technologies > > > > > > Thomas Marshall Eubanks on > 04/06/2000 12:36:46 PM > > > > Dear Steven; > > > > That has to be part of what the WG DOES. My personal > feeling is that > > if you buy a box off the shelf, you should be able to trust it not > > to contain a trojan horse. If it does, the resulting > lawsuits will probably > > drive the manufacturer out of business. However, your point > is a good > > one that zeroconfig cannot ASSUME the absence of trojan horses, even > > inside the home. (Your computer will likely be on this net, and may > > certainly be compromised.) Maybe a benign > > device cannot transmit out at all ! > > > > For a benign device, deciding what comes from within the > home and what does > > not > > is not so important. Even if you spoof it, you cannot > really do anything > > seriously wrong. > > If my radio starts spewing out garbage, I can turn it off. > It cannot kill me. > > > > I agree that there will be many everyday, commonly used > > appliances, that will not be "benign." A stove may be a > good example - > > ever forgotten about a tea kettle ? > > > > I think it is reasonable to expect a learning curve here > - things that > > seem benign now, may not after someone figures out a way to > do something > > non-benign > > with them. I would again suggest that the working group, > as a start, derive > > a description of a > > benign device : > > > > 1.) Incapable of causing physical harm, no matter what, > either by its nature, or > > because of. e.g., > > physical interlocks. > > 2.) Cannot transmit information about the specific > activities of the specific > > user, except > > maybe to the vendor using strong encryption. > > > > Consider a stand-alone Internet radio. Presumably it cannot > be made to blow up, > > so # 1 is > > a given. Number 2 could be satisfied if there was no way it > could reveal its > > state. > > Note that it could still receive a "turn on at 6:30- AM" > message, and could even > > acknowledge it. > > It should NOT be able to report, even within the home, if > it was turned on > > manually at a specific time. > > > > Note that at some level you have to trust the vendor. If > that trust is violated, > > the vendor will not > > stay in business. > > > > Also note that there has to be a limit. Did you know that > most devices do > > particular things to > > the line voltage in your house as they are turned on and > off ? A trojan horse > > could simply monitor > > line voltage at its power input, and get a pretty good idea > of activity > > patterns, and maybe > > even identify particular actions, such as the TV turning on. > > > > Regards > > Marshall Eubanks > > > > > > T.M. Eubanks > > Multicast Technologies, Inc > > P.O. Box 99 > > Clifton, Virginia 20124 > > Phone : 703-803-8141 > > Fax : 703-222-3250 > > e-mail : tme@21rst-century.com > > > > > > > > > > > > > > > > > > > > From owner-zeroconf@merit.edu Thu Apr 6 17:34:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15325 for ; Thu, 6 Apr 2000 17:34:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D46CE5DDA7; Thu, 6 Apr 2000 17:34:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AFDAD5DD92; Thu, 6 Apr 2000 17:34:42 -0400 (EDT) Received: from apollo.leviton.com (apollo.leviton.com [209.177.59.130]) by segue.merit.edu (Postfix) with ESMTP id 4925C5DE65 for ; Thu, 6 Apr 2000 17:34:09 -0400 (EDT) Received: by APOLLO with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Apr 2000 17:30:19 -0400 Message-ID: From: "Rose, William" To: "'Steve Hanna'" Cc: zeroconf@merit.edu Subject: RE: home network security Date: Thu, 6 Apr 2000 17:30:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA00F.4D92F636" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFA00F.4D92F636 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >I'm glad to see we're getting back to the threat analysis. I am certain not all are zeroconfig threats but the thinking was as = follows: >> =B7 Unauthorized access No explanation needed. Obvious threat. >> =B7 Eavesdropping Allows outsider to determine lifestyle, do home/away analysis for = break-in, access in-home cameras, etc.=20 >> =B7 Intercept/Alter (Info is intercepted and altered) Intercepting a message such as "arm security system" and resend later = as "disarm security system" >> =B7 Masquerade (spoofing or acting as a legitimate device Numerous issues if the sender cannot be authenticated. Unlocking doors, opening garage doors, etc. >> =B7 Replay (Eavesdropped message is replayed at a later time) With in-the-clear messages, any command can be replayed such as "disarm security system", "open garage door" etc. >> =B7 Denial of Service More of a nuisance than a threat unless it keeps a critical message = from being sent or received. >> =B7 Resource exhaustion Overloading a device with minimal resources >> =B7 Service Spoofing >> =B7 Trojan Horse Particularly dangerous in Java type systems which will transfer = executable code to a JVM. >> =B7 Repudiation There is another potential issue. Just knowing what services are = available lets someone know what devices are in the house and therefore how = profitable a break-in might be. A DTV might have a list of storage (VCR, = TIVO/Replay, PC), playback (DVD, PC, TIVO/Replay), audio (surround sound, MP3 = player), etc. services listed. In the world of home systems, these are the types = of services that are part of the discovery process and can be accessed by = other devices to see what is available for use at a given time. Bill Rose ------_=_NextPart_001_01BFA00F.4D92F636 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: home network security

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

I am certain not all are zeroconfig threats but the = thinking was as follows:

>> =B7 Unauthorized access
No explanation needed. Obvious threat.

>> =B7 Eavesdropping
Allows outsider to determine lifestyle, do home/away = analysis for break-in, access in-home cameras, etc.

>> =B7 Intercept/Alter (Info is intercepted and = altered)
Intercepting a message such as "arm security = system" and resend later as "disarm security = system"

>> =B7 Masquerade (spoofing or acting as a = legitimate device
Numerous issues if the sender cannot be = authenticated. Unlocking doors, opening garage doors, etc.

>> =B7 Replay (Eavesdropped message is replayed = at a later time)
With in-the-clear messages, any command can be = replayed such as "disarm security system", "open garage = door" etc.

>> =B7 Denial of Service
More of a nuisance than a threat unless it keeps a = critical message from being sent or received.

>> =B7 Resource exhaustion
Overloading a device with minimal resources

>> =B7 Service Spoofing
>> =B7 Trojan Horse
Particularly dangerous in Java type systems which = will transfer executable code to a JVM.

>> =B7 Repudiation

There is another potential issue. Just knowing what = services are available lets someone know what devices are in the house = and therefore how profitable a break-in might be. A DTV might have a = list of storage (VCR, TIVO/Replay, PC), playback (DVD, PC, = TIVO/Replay), audio (surround sound, MP3 player), etc. services listed. = In the world of home systems, these are the types of services that are = part of the discovery process and can be accessed by other devices to = see what is available for use at a given time.

Bill Rose

------_=_NextPart_001_01BFA00F.4D92F636-- From owner-zeroconf@merit.edu Thu Apr 6 17:42:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15423 for ; Thu, 6 Apr 2000 17:42:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E54D95DDBF; Thu, 6 Apr 2000 17:42:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D51DD5DDBB; Thu, 6 Apr 2000 17:42:07 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id AEBA15DD92 for ; Thu, 6 Apr 2000 17:42:06 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA28826 for ; Thu, 6 Apr 2000 14:42:06 -0700 (MST)] Received: [from az33exi02.corp.mot.com ([199.2.84.11]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA29517 for ; Thu, 6 Apr 2000 14:42:04 -0700 (MST)] Received: by AZ33EXI02 with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Apr 2000 14:42:03 -0700 Message-ID: From: Austin Bill-P23393 To: ZeroConf@merit.edu Subject: RE: home network security Date: Thu, 6 Apr 2000 14:41:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk > -----Original Message----- > From: Austin Bill-P23393 [mailto:Bill_Austin-P23393@email.mot.com] > Sent: Thursday, April 06, 2000 1:23 PM > This discussion topic has been pursued in our company for > quite a while. I > will clean up some of the more valuable points of our > discussion and post > them without attribution to the several authors. > > The post below tries to place "real-world" perspectives on > the security > implications of a variety of rapidly approaching networking > technologies. > The authors were very unhappy with the lack of a front-end, top-down, > systems approach to security in the zero-conf environment. > > If you are new to the list, please read "nits" as "Zero-Conf" And for yet another perspective: " It's more fun than that : you look at the malicious-for-profit, what about the teen out for fun (or revenge)? Scenario : I'm a techno-teen (or have connections to one); we set a remote around your house (why waste my time there, and a remote is less visible). You come home and unlock your e-house with your wireless e-key. You again make the mistake of sneering at me for the third (and final straw) time as you go oh so smugly into your e-castle. Little do you suspect that at 02:03 your e-alarm systems panic button will signal your security company to respond to a silent alarm - won't you be surprised when they e-unlock your front door and wake you to inquire what the silent emergency response is. Then there's tomorrow morning, just after you left for work, when I reprogram your oven (it lists that it is holding a dinner to start cooking at 16:00) - now your oven just went into continuous clean mode - will there even be a cinder of the pan left (let alone that dinner)? By the way, your refrigerator temperature will be freezing by noon, and your freezer is defrosting, your lights are all on (as are all major appliances), and I'm resetting all clocks in your house to random (each one different) times. Your VCR is recording over whatever tape your kid left in the VCR, and you don't want to know what I'm doing to your home computer through it's link. And thanks to this blue-tooth technology, I didn't even have to enter your house - It's questionable if I've violated any laws at all (technically). My broadcast was within FCC limitations (short ranged, etc), I just had to pass close to your house - or is that illegal now. My thanks to all those bluetooth convenience makers who greatly simplified my righteous vengeance (you sneered at me). By the way, I also gave an inventory of your household contents (including your safe combination that I hacked) to some "associates" I know. I don't know when they'll visit, but that's ok, I gave them your e-home door, security combination, and the vacation itinerary you left on your computer, so they can let themselves in - they'll be the ones driving the moving van. " -- Bill Austin http://home.att.net/~wbaustin/ AzTeC Free-Net http://aztec.asu.edu/ Motorola Bluetooth http://www.mot.com/bluetooth/ Bluetooth Mailing List http://bluetooth.listbot.com/ From owner-zeroconf@merit.edu Thu Apr 6 20:04:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17352 for ; Thu, 6 Apr 2000 20:04:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F0A395DDA7; Thu, 6 Apr 2000 20:02:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DE0955DDBF; Thu, 6 Apr 2000 20:02:51 -0400 (EDT) Received: from rkrishnan.bbn.com (RKRISHNAN.BBN.COM [128.89.35.252]) by segue.merit.edu (Postfix) with ESMTP id 8C5905DDA7 for ; Thu, 6 Apr 2000 20:02:50 -0400 (EDT) Received: (from krash@localhost) by rkrishnan.bbn.com (8.9.3/8.9.3) id UAA27397 for zeroconf@merit.edu; Thu, 6 Apr 2000 20:03:19 -0400 From: Rajesh Krishnan Message-Id: <200004070003.UAA27397@rkrishnan.bbn.com> Subject: encryption on all hosts AND session migration on renumbering To: zeroconf@merit.edu Date: Thu, 6 Apr 2000 20:03:19 -0400 (EDT) In-Reply-To: from "Rose, William" at Apr 06, 2000 05:30:16 PM Reply-To: krash@bbn.com X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1. Need for crypto on every zeroconf host Fundamentally zeroconf deals with Layer 3 aspects of host configuration such as the acquistion of address/netmask/defaultroutes by a host. (Sure, there are some Layer 4+ overlays such as service discovery.) To be consistent, it is a good idea to require that all zeroconf hosts should support host-level security capabilities applicable to Layer 3, such as basic cryptographic functionality for providing information security. This is almost as fundamental as the ability to create and forward IP packets. I would recommend adding this requirement to draft-03's successor. Infrastructure security (eg., preventing threats such as hoarding via authentication) will depend on this basic crypto functionality being available in every host. No matter how (or whether) group keys are pre-configured, host keys and certificate information are pre-configured, or gossip-based protocols are used, basic crypto functionality is required in every host. In other words, the issue of key configuration/management being zeroconf or not is orthogonal. 2. Seamless session migration on renumbering Session encryption is useful if we choose to optionally support secure, seamless migration of sessions to the new address on renumbering (provided only one of two peers has renumbered and the peers remain reachable from each other). Just because two zeroconf nets merged (a flaky router/bridge comes back online) and as a result of conflict resolution my host got renumbered, it does mean that my data flow (streaming audio/video, game session etc.,) has to be interrupted as well. The risk of session hijacking (by exploiting migration) will be high, when not using encryption. Of course, I am assuming that initially the session was established securely (which requires the presence of a chain of trust). Bootstrapping chains of trust in a purely ad hoc environment is a hard problem. Dynamic solutions to this problem will probably be approximate and may require sociological or socio-biological paradigms. However, such solutions will still need cryptography. The ability to whisper (encrypt) is useful and is orthogonal to the ability to always determine if the ear being whispered into is the correct one (trust/authentication). In my opinion, we need encryption in all zeroconf hosts. -Rajesh From owner-zeroconf@merit.edu Fri Apr 7 05:43:45 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05318 for ; Fri, 7 Apr 2000 05:43:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD5BF5DD90; Fri, 7 Apr 2000 05:43:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A6B485DD92; Fri, 7 Apr 2000 05:43:32 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id ACF7B5DD90 for ; Fri, 7 Apr 2000 05:43:28 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id CAA32185; Fri, 7 Apr 2000 02:30:30 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Steve Hanna'" Cc: Subject: RE: home network security Date: Fri, 7 Apr 2000 02:45:50 -0700 Message-ID: <002e01bfa076$0f614040$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <38EC9176.E64F5436@sun.com> Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I would argue that we should take threat a as a fact of life. A home >network is not secure. Assume that malicious parties can send and >receive on the home network at will. Any other assumption is doomed to >failure. I'm not quite this pessimistic, but I would agree that "defense in depth" is probably a sounder approach. However, to get there one needs to start looking at things like IPSEC as a personal firewall. Are we willing to go down that road? >Do we need to preserve the confidentiality of these basic network >messages? Maybe you don't want your neighbors to know what services you >use and when. It's probably something that should be possible, though not necessarily required. >Threat b is out of scope, since we are not considering device control >protocols. I wasn't referring to device control per se, more to end-to-end security in general. From owner-zeroconf@merit.edu Fri Apr 7 07:35:47 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06214 for ; Fri, 7 Apr 2000 07:35:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2BE885DD92; Fri, 7 Apr 2000 07:35:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 108A05DDA5; Fri, 7 Apr 2000 07:35:38 -0400 (EDT) Received: from ids2.idsonline.com (ids2.idsonline.com [205.177.236.32]) by segue.merit.edu (Postfix) with ESMTP id AFA665DD92 for ; Fri, 7 Apr 2000 07:35:36 -0400 (EDT) Received: from 21rst-century.com (laurel-md-98.idsonline.com [209.8.42.98]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id HAA17708; Fri, 7 Apr 2000 07:50:21 -0400 Message-ID: <38EDC800.B840E1C8@21rst-century.com> Date: Fri, 07 Apr 2000 07:35:27 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Steven G. Ungar" Cc: Daniel Senie , PJohansson@aol.com, ZeroConf@merit.edu Subject: Re: home network security References: <852568B9.0067C152.00@notes949.cc.telcordia.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Steven G. Ungar" wrote: > Marshall: > > Thanks for your response, but I think you missed my point: > > I am not so worried about buying an infected DTV from Circuit City: I am > worried about an intruder penetrating my firewall, gaining access to my home > network, finding an unprotected processor, for instance in my nice, clean DTV, > and loading a Trojan Horse into it. It can then do nasty things, in the > background, that I would not know about until it was way too late. > > Given that clarification, how do we classify my television, benign or not? And > if not, how can we make it real hard for the above scenario to happen, without > making it so expensive or inconvenient for the homeowner that she is inclined to > either, a) take the risk or b) do without outside access to the home network. > > Thanks, > > Steven U. > Dear Steven; You are correct, I did misunderstand you. I would still classify this device as benign. It will not kill me, directly, If all I have are benign devices, say a clock, a radio, a TV, and window blinds, on my zeroconfig net, then there is nothing that a neighboring 65 year old hacker (my son is tired of being picked on :) can do to open my doors or burn down my house. If the radio starts spewing Nazi propaganda at 3:00 AM, I can just turn it off. If there are non-benign devices on the zeroconfig net, then their being attacked by my TV is no different from being attacked from the outside. What I think it is reasonable to do here is to recognize that - threats exist (you cannot trust firewalls) - you cannot separate the threat from the application - really serious threats are unlikely to be consistent with zeroconfig. (As an example, my Mother, whom I picture zeroconfig as being for, would not dream of installing her own home security. She would hire / contract with someone to do it.) Here is a first cut on functions and their potential threats. These can be listed under three broad areas : status - real time reporting of the current state of a zeroconfig device - respond to ACK type messages (i.e., "I'm up") - MAY be encrypted - lists of home devices (i.e., "here are the stereo systems on this net") - MUST be encrypted history - reporting of equipment activities over a period of time - equipment state reports (i.e., things not under manual control, like the cycling of the refrigerator) MAY be encrypted - user state reports (i.e., when I open the refrigerator door) MUST be encrypted control - control of equipment - benign equipment - MAY be encrypted - non-benign equipment - MUST be encrypted and MAY subject to authentication Notice that there is no distinction between reports sent on the local net and those sent outside. Firewalls are useful but cannot be trusted - every real penetration of a system that I have direct personal knowledge of occurred (or would have occurred) INSIDE the firewall. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc P.O. Box 99 Clifton, Virginia 20124 Phone : 703-803-8141 Fax : 703-222-3250 e-mail : tme@21rst-century.com From owner-zeroconf@merit.edu Fri Apr 7 09:48:58 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08188 for ; Fri, 7 Apr 2000 09:48:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C55555DEA1; Fri, 7 Apr 2000 09:48:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AD04D5DEA3; Fri, 7 Apr 2000 09:48:11 -0400 (EDT) Received: from apollo.leviton.com (apollo.leviton.com [209.177.59.130]) by segue.merit.edu (Postfix) with ESMTP id 76DEB5DEA1 for ; Fri, 7 Apr 2000 09:48:10 -0400 (EDT) Received: by APOLLO with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Apr 2000 09:44:19 -0400 Message-ID: From: "Rose, William" To: "'tme@21rst-century.com'" , "Steven G. Ungar" Cc: ZeroConf@merit.edu Subject: RE: home network security Date: Fri, 7 Apr 2000 09:44:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA097.5E59FD88" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFA097.5E59FD88 Content-Type: text/plain; charset="iso-8859-1" Marshall Eubanks Wrote: >I would still classify this device as benign. It will not kill me, directly, If all I have are >benign devices, say a clock, a radio, a TV, and window blinds, on my zeroconfig net, then >there is nothing that a neighboring 65 year old hacker (my son is tired of being picked on :) >can do to open my doors or burn down my house. If the radio starts spewing Nazi >propaganda at 3:00 AM, I can just turn it off. If there are non-benign devices on the zeroconfig >net, >then their being attacked by my TV is no different from being attacked from the outside. > >What I think it is reasonable to do here is to recognize that > > - threats exist (you cannot trust firewalls) > - you cannot separate the threat from the application > - really serious threats are unlikely to be consistent with zeroconfig. (As an example, my >Mother, whom I picture zeroconfig as being for, would not dream of installing her own >home security. She would hire / contract with someone to do it.) > >Here is a first cut on functions and their potential threats. These can be listed under three >broad >areas : >status - real time reporting of the current state of a zeroconfig device > - respond to ACK type messages (i.e., "I'm up") - MAY be encrypted > - lists of home devices (i.e., "here are the stereo systems on this net") - MUST be encrypted > >history - reporting of equipment activities over a period of time > - equipment state reports (i.e., things not under manual control, like the cycling of the > refrigerator) MAY be encrypted > - user state reports (i.e., when I open the refrigerator door) MUST be encrypted >control - control of equipment > - benign equipment - MAY be encrypted > - non-benign equipment - MUST be encrypted and MAY subject to authentication > >Notice that there is no distinction between reports sent on the local net and those sent outside. >Firewalls are useful but cannot be trusted - every real penetration of a system that I have >direct personal knowledge of occurred (or would have occurred) INSIDE the firewall. > Some comments and observations for what their worth: Benign is in the eye of the beholder. Flashing lights, radios and TVs turning on and off with or without objectionable material, shades going up and down would be seen by many as very threatening. A system wide transmission of something like Orson Well's "War of the Worlds" masquerading as a news program might also be non-benign. To a customer and therefore a manufacturer receiving the complaint, a device that doesn't do what the customer expects due to a hack is a failed device and a serious expense. That said, I don't think zeroconfig is the right place to fix all of the problems. But at least it should be recognized that there is a lot of gray areas between not burning down the home and truly benign. Door and window locks may not stop a determined thief but they do keep out the riff-raff. Likewise, having no security on a device or network is an invitation for all to come in. Door and window locks, window openers, garage door openers, security systems, HVAC systems, and the like will have heavier security added by the manufacturer since they will be legally liable if they do not. Those that don't do it right will be out of business quickly. Look at garage door openers-they used to transmit in the clear but now all major manufacturers use encrypted transmitters. If I have a home server with my personal files, complete list of devices, control over my home systems, etc. on it, certainly I would want some fairly strong security on it but I am not certain that is zeroconfig's job. I agree with Marshall's approach. I suggest that what manufacturers need is guidance and the tools to do it right. Provide the ability to encrypt and authenticate either directly or by reference to other standards. Give some guidance as to what is a "shall" and "may" situation and then let the individual manufacturer and customer decide from there. But make certain the tools are available and standardized so that the system at a minimum can keep out the riff-raff if not the determined thief. Bill Rose Leviton ------_=_NextPart_001_01BFA097.5E59FD88 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: home network security

Marshall Eubanks Wrote:

>I would still classify this device as benign. It = will not kill me, directly, If all I have are
>benign devices, say a clock, a radio, a = TV, and window blinds, on my zeroconfig net, then
>there is nothing that a neighboring 65 year old = hacker (my son is tired of being picked on :)
>can do to open my doors or burn down my house. = If the radio starts spewing Nazi
>propaganda at 3:00 AM, I can just turn it off. = If there are non-benign devices on the zeroconfig >net,
>then their being attacked by my TV is no = different from being attacked from the outside.
>
>What I think it is reasonable to do here is to = recognize that
>
> - threats exist (you cannot trust = firewalls)
> - you cannot separate the threat from the = application
> - really serious threats are unlikely to = be consistent with zeroconfig. (As an example, my
>Mother, whom I picture zeroconfig as being for, = would not dream of installing her own
>home security. She would hire / contract with = someone to do it.)
>
>Here is a first cut on functions and their = potential threats. These can be listed under three = >broad
>areas :

>status   - real time reporting of the = current state of a zeroconfig device
>     - respond to ACK type = messages (i.e., "I'm up") - MAY be encrypted
>     - lists of home devices = (i.e., "here are the stereo systems on this net") - MUST be = encrypted
>
>history - reporting of equipment activities over = a period of time
>      - equipment state = reports (i.e., things not under manual control, like the cycling of = the
>         = refrigerator) MAY be encrypted
>      - user state = reports (i.e., when I open the refrigerator door) MUST be = encrypted

>control - control of equipment
> - benign = equipment - MAY be encrypted
> - non-benign = equipment - MUST be encrypted and MAY subject to authentication
>
>Notice that there is no distinction between = reports sent on the local net and those sent outside.
>Firewalls are useful but cannot be trusted - = every real penetration of a system that I have
>direct personal knowledge of occurred (or would = have occurred) INSIDE the firewall.
>

Some comments and observations for what their = worth:

Benign is in the eye of the beholder. Flashing = lights, radios and TVs turning on and off with or without objectionable = material, shades going up and down would be seen by many as very = threatening. A system wide transmission of something like Orson Well's = "War of the Worlds" masquerading as a news program might also = be non-benign. To a customer and therefore a manufacturer receiving the = complaint, a device that doesn't do what the customer expects due to a = hack is a failed device and a serious expense. That said, I don't think = zeroconfig is the right place to fix all of the problems. But at least = it should be recognized that there is a lot of gray areas between not = burning down the home and truly benign. Door and window locks may not = stop a determined thief but they do keep out the riff-raff. Likewise, = having no security on a device or network is an invitation for all to = come in.

Door and window locks, window openers, garage door = openers, security systems, HVAC systems, and the like will have heavier = security added by the manufacturer since they will be legally liable if = they do not. Those that don't do it right will be out of business = quickly. Look at garage door openers-they used to transmit in the clear = but now all major manufacturers use encrypted transmitters. If I have a = home server with my personal files, complete list of devices, control = over my home systems, etc. on it, certainly I would want some fairly = strong security on it but I am not certain that is zeroconfig's = job.

I agree with Marshall's approach. I suggest that what = manufacturers need is guidance and the tools to do it right. Provide = the ability to encrypt and authenticate either directly or by reference = to other standards. Give some guidance as to what is a = "shall" and "may" situation and then let the = individual manufacturer and customer decide from there. But make = certain the tools are available and standardized so that the system at = a minimum can keep out the riff-raff if not the determined thief. =

Bill Rose
Leviton

------_=_NextPart_001_01BFA097.5E59FD88-- From owner-zeroconf@merit.edu Fri Apr 7 10:12:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08588 for ; Fri, 7 Apr 2000 10:12:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F066E5DD93; Fri, 7 Apr 2000 10:12:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF87D5DD92; Fri, 7 Apr 2000 10:12:45 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 928265DD90 for ; Fri, 7 Apr 2000 10:12:44 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e37EBUe04274; Fri, 7 Apr 2000 10:11:30 -0400 Message-ID: <38EDEC8E.D425D376@senie.com> Date: Fri, 07 Apr 2000 10:11:26 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com Cc: "'Steve Hanna'" , zeroconf@merit.edu Subject: Re: home network security References: <002e01bfa076$0f614040$428939cc@ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > >I would argue that we should take threat a as a fact of life. A home > >network is not secure. Assume that malicious parties can send and > >receive on the home network at will. Any other assumption is doomed to > >failure. > > I'm not quite this pessimistic, but I would agree that "defense in > depth" is probably a sounder approach. However, to get there one > needs to start looking at things like IPSEC as a personal firewall. > Are we willing to go down that road? IPSec is a non-starter today in home networking. Due to the business policies and practices of the broadband providers, NAT is a key fixture in most home networks. IPSec is unable to traverse NAT, and so is not useful in this environment. Perhaps someday in the future if IPv6 ever becomes viable in the broadband market, or if the work to make IPSec less dependent on checking source and destination IP addresses sees the light of day, we'll have a shot at it. In the mean time, application level security is likely to be the only workable scheme in the home market. > > >Do we need to preserve the confidentiality of these basic network > >messages? Maybe you don't want your neighbors to know what services you > >use and when. > > It's probably something that should be possible, though not necessarily > required. > > >Threat b is out of scope, since we are not considering device control > >protocols. > > I wasn't referring to device control per se, more to end-to-end security > in general. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Fri Apr 7 10:20:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08738 for ; Fri, 7 Apr 2000 10:20:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C3BC5DDAB; Fri, 7 Apr 2000 10:20:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6A8D15DDA9; Fri, 7 Apr 2000 10:20:46 -0400 (EDT) Received: from ids2.idsonline.com (ids2.idsonline.com [205.177.236.32]) by segue.merit.edu (Postfix) with ESMTP id 0D2035DD90 for ; Fri, 7 Apr 2000 10:20:45 -0400 (EDT) Received: from 21rst-century.com (laurel-md-98.idsonline.com [209.8.42.98]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id KAA26522; Fri, 7 Apr 2000 10:35:16 -0400 Message-ID: <38EDEEA9.8DB62DF0@21rst-century.com> Date: Fri, 07 Apr 2000 10:20:24 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Rose, William" Cc: "Steven G. Ungar" , ZeroConf@merit.edu Subject: Re: home network security References: Content-Type: multipart/alternative; boundary="------------5A009DA9F84F42E93B4CD564" Sender: owner-zeroconf@merit.edu Precedence: bulk --------------5A009DA9F84F42E93B4CD564 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Dear Bill; "Rose, William" wrote: > Some comments and observations for what their worth: > > Benign is in the eye of the beholder. Flashing lights, radios and TVs turning on and off with or without objectionable material, shades going up and down would be seen by many as > very threatening. A system wide transmission of something like Orson Well's "War of the Worlds" masquerading as a news program might also be non-benign. To a customer and > therefore a manufacturer receiving the complaint, a device that doesn't do what the customer expects due to a hack is a failed device and a serious expense. That said, I don't > think zeroconfig is the right place to fix all of the problems. But at least it should be recognized that there is a lot of gray areas between not burning down the home and truly > benign. Door and window locks may not stop a determined thief but they do keep out the riff-raff. Likewise, having no security on a device or network is an invitation for all to > come in. > I agree completely. The telephone can be very non-benign if you start to get threatening phone calls. Thus there developed a market for *69 and caller ID. Zeroconfig will develop likewise - the job here is to set things in motion with reasonable guidelines. > > Door and window locks, window openers, garage door openers, security systems, HVAC systems, and the like will have heavier security added by the manufacturer since they will be > legally liable if they do not. Those that don't do it right will be out of business quickly. Look at garage door openers-they used to transmit in the clear but now all major > manufacturers use encrypted transmitters. If I have a home server with my personal files, complete list of devices, control over my home systems, etc. on it, certainly I would > want some fairly strong security on it but I am not certain that is zeroconfig's job. > > I agree with Marshall's approach. I suggest that what manufacturers need is guidance and the tools to do it right. Provide the ability to encrypt and authenticate either directly > or by reference to other standards. Give some guidance as to what is a "shall" and "may" situation and then let the individual manufacturer and customer decide from there. But > make certain the tools are available and standardized so that the system at a minimum can keep out the riff-raff if not the determined thief. > > Bill Rose > Leviton Regards Marshall T.M. Eubanks Multicast Technologies, Inc P.O. Box 99 Clifton, Virginia 20124 Phone : 703-803-8141 Fax : 703-222-3250 e-mail : tme@21rst-century.com --------------5A009DA9F84F42E93B4CD564 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Bill;

"Rose, William" wrote:

Some comments and observations for what their worth:
Benign is in the eye of the beholder. Flashing lights, radios and TVs turning on and off with or without objectionable material, shades going up and down would be seen by many as very threatening. A system wide transmission of something like Orson Well's "War of the Worlds" masquerading as a news program might also be non-benign. To a customer and therefore a manufacturer receiving the complaint, a device that doesn't do what the customer expects due to a hack is a failed device and a serious expense. That said, I don't think zeroconfig is the right place to fix all of the problems. But at least it should be recognized that there is a lot of gray areas between not burning down the home and truly benign. Door and window locks may not stop a determined thief but they do keep out the riff-raff. Likewise, having no security on a device or network is an invitation for all to come in.

I agree completely. The telephone can be very non-benign if you start to get threatening phone calls.
Thus there developed a market for *69 and caller ID. Zeroconfig will develop likewise - the job here is
to set things in motion with reasonable guidelines.

Door and window locks, window openers, garage door openers, security systems, HVAC systems, and the like will have heavier security added by the manufacturer since they will be legally liable if they do not. Those that don't do it right will be out of business quickly. Look at garage door openers-they used to transmit in the clear but now all major manufacturers use encrypted transmitters. If I have a home server with my personal files, complete list of devices, control over my home systems, etc. on it, certainly I would want some fairly strong security on it but I am not certain that is zeroconfig's job.
I agree with Marshall's approach. I suggest that what manufacturers need is guidance and the tools to do it right. Provide the ability to encrypt and authenticate either directly or by reference to other standards. Give some guidance as to what is a "shall" and "may" situation and then let the individual manufacturer and customer decide from there. But make certain the tools are available and standardized so that the system at a minimum can keep out the riff-raff if not the determined thief.
Bill Rose
Leviton

Regards
Marshall

T.M. Eubanks
Multicast Technologies, Inc
P.O. Box 99
Clifton, Virginia 20124
Phone : 703-803-8141
Fax : 703-222-3250
e-mail : tme@21rst-century.com
--------------5A009DA9F84F42E93B4CD564-- From owner-zeroconf@merit.edu Fri Apr 7 11:22:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10271 for ; Fri, 7 Apr 2000 11:22:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 887BE5DD93; Fri, 7 Apr 2000 11:22:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 79A725DD92; Fri, 7 Apr 2000 11:22:31 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 277C85DD90 for ; Fri, 7 Apr 2000 11:22:30 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02439; Fri, 7 Apr 2000 09:22:19 -0600 (MDT) Received: from sunlabs.East.Sun.COM (sunlabs-74.East.Sun.COM [129.148.74.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA12923; Fri, 7 Apr 2000 11:22:17 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA04443; Fri, 7 Apr 2000 11:22:14 -0400 (EDT) Message-ID: <38EDFC74.D66D3AE6@sun.com> Date: Fri, 07 Apr 2000 11:19:16 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com Cc: zeroconf@merit.edu Subject: Re: home network security References: <002e01bfa076$0f614040$428939cc@ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > >I would argue that we should take threat a as a fact of life. A home > >network is not secure. Assume that malicious parties can send and > >receive on the home network at will. Any other assumption is doomed to > >failure. > > I'm not quite this pessimistic, but I would agree that "defense in > depth" is probably a sounder approach. However, to get there one > needs to start looking at things like IPSEC as a personal firewall. > Are we willing to go down that road? IPSEC is not the only solution. There are lots of other security protocols. But let's not jump into an implementation discussion. We're still at the requirements stage. I am arguing that, when analyzing security threats, we should assume that malicious parties can send and receive on the home network at will. I'm sure this won't always be the case. But it will be common and we need to design for it. > >Do we need to preserve the confidentiality of these basic network > >messages? Maybe you don't want your neighbors to know what services you > >use and when. > > It's probably something that should be possible, though not necessarily > required. Agreed. I suspect that we will end up making zeroconf security optional. Maybe mandatory to implement, but can be off by default. That will allow people to buy a device, take it home, and plug it in without bothering with whatever extra work is required for key establishment. Folks who are concerned about security can turn it on. And security-critical devices (what Marshall is calling non-benign), security will be always on. > >Threat b is out of scope, since we are not considering device control > >protocols. > > I wasn't referring to device control per se, more to end-to-end security > in general. I don't understand what you mean here. Could you elaborate? -Steve From owner-zeroconf@merit.edu Fri Apr 7 12:05:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11140 for ; Fri, 7 Apr 2000 12:05:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A96C5DD90; Fri, 7 Apr 2000 12:05:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 57D395DD92; Fri, 7 Apr 2000 12:05:37 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 2BFD85DD90 for ; Fri, 7 Apr 2000 12:05:32 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02107; Fri, 7 Apr 2000 10:05:20 -0600 (MDT) Received: from sunlabs.East.Sun.COM (sunlabs-74.East.Sun.COM [129.148.74.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA25632; Fri, 7 Apr 2000 12:05:15 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id MAA15236; Fri, 7 Apr 2000 12:05:12 -0400 (EDT) Message-ID: <38EE0687.86A97563@sun.com> Date: Fri, 07 Apr 2000 12:02:15 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rose, William" Cc: zeroconf@merit.edu Subject: Re: home network security References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Thanks for the elaboration. Perhaps I should have been clearer in stating that many of my questions were about whether these threats pertain to items within the scope of this working group: host configuration, name-to-address translation, service discovery, and multicast address allocation. > >> � Unauthorized access > No explanation needed. Obvious threat. How do you see this playing out in each of our application domains: host configuration, name-to-address translation, service discovery, and multicast address allocation? > >> � Eavesdropping > Allows outsider to determine lifestyle, do home/away analysis for > break-in, access in-home cameras, etc. I have become convinced that this is an important threat, which should be added to the list of basic threats in our requirements document. > >> � Intercept/Alter (Info is intercepted and altered) > Intercepting a message such as "arm security system" and resend later > as "disarm security system" This is one form of masquerading. Having an existing message to alter may make it easier to masquerade, but it's still the same basic issue. > >> � Masquerade (spoofing or acting as a legitimate device > Numerous issues if the sender cannot be authenticated. Unlocking > doors, opening garage doors, etc. Agreed, although your examples all relate to device control, which is out of scope. A more pertinent example would be masquerading as a printer to capture print jobs. > >> � Replay (Eavesdropped message is replayed at a later time) > With in-the-clear messages, any command can be replayed such as > "disarm security system", "open garage door" etc. Yes. Although your examples still pertain to device control. > >> � Denial of Service > More of a nuisance than a threat unless it keeps a critical message > from being sent or received. If you can jam the security system so that the window sensor can't notify the central unit that the window has been broken, this would be a big problem. But this can be designed around. The central unit should assume that if it hasn't heard from a given sensor in a while, there is a problem. Still, we should add this to the threat analysis. > >> � Resource exhaustion > Overloading a device with minimal resources Isn't this a form of denial of service? > >> � Trojan Horse > Particularly dangerous in Java type systems which will transfer > executable code to a JVM. I don't think that any of the areas this working group is chartered to cover will involve downloading executable code (Java or otherwise). Do you disagree? > There is another potential issue. Just knowing what services are > available lets someone know what devices are in the house and > therefore how profitable a break-in might be. A DTV might have a list > of storage (VCR, TIVO/Replay, PC), playback (DVD, PC, TIVO/Replay), > audio (surround sound, MP3 player), etc. services listed. In the world > of home systems, these are the types of services that are part of the > discovery process and can be accessed by other devices to see what is > available for use at a given time. Yes. This is a good point. That's why it's important to restrict who can access the service discovery system and encrypt traffic so people can't see that you're resolving the name "Super Sony DVD 13". But it occurs to me that seeing any zeroconf traffic at all (even encrypted) indicates that the household is likely to be a good burglary target. To deal with this, people should probably use wired networking or spread-spectrum wireless to avoid detection. We might want to mention this threat as well (detection of traffic as threat). -Steve From owner-zeroconf@merit.edu Fri Apr 7 12:18:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11409 for ; Fri, 7 Apr 2000 12:18:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 129455DDC6; Fri, 7 Apr 2000 12:16:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E31B85DDBF; Fri, 7 Apr 2000 12:16:25 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 1F5625DD92 for ; Fri, 7 Apr 2000 12:16:20 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09181 for ; Fri, 7 Apr 2000 10:16:11 -0600 (MDT) Received: from sunlabs.East.Sun.COM (sunlabs-74.East.Sun.COM [129.148.74.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA28366 for ; Fri, 7 Apr 2000 12:16:10 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id MAA18093 for ; Fri, 7 Apr 2000 12:16:08 -0400 (EDT) Message-ID: <38EE0917.D16C423@sun.com> Date: Fri, 07 Apr 2000 12:13:11 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Is Device Control in the charter? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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. Thanks, Steve From owner-zeroconf@merit.edu Fri Apr 7 15:56:45 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16863 for ; Fri, 7 Apr 2000 15:56:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3FBA65DDC8; Fri, 7 Apr 2000 15:56:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2D65F5DDC6; Fri, 7 Apr 2000 15:56:26 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 3FFD15DD90 for ; Fri, 7 Apr 2000 15:56:21 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id MAA32682; Fri, 7 Apr 2000 12:42:57 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Daniel Senie'" Cc: "'Steve Hanna'" , Subject: RE: home network security Date: Fri, 7 Apr 2000 12:58:18 -0700 Message-ID: <003d01bfa0cb$9efd9f50$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <38EDEC8E.D425D376@senie.com> Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >IPSec is unable to traverse NAT, and so is not useful There are several configuration in which this is not an issue, such as use of IPSEC on the NAT itself, to permit authenticated access to the inner network. >In the mean time, application level security is likely to be the only >workable scheme in the home market. Not sure why you think that application layer security will work either. Most NATs do not allow transit of externally initiated incoming SSL/TLS or even HTTP connections. So if ability to allow transit of incoming connections across today's NAT solutions is a criteria, the solution may be the null set. From owner-zeroconf@merit.edu Fri Apr 7 16:38:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17838 for ; Fri, 7 Apr 2000 16:38:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1C185DDC8; Fri, 7 Apr 2000 16:38:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA41F5DDF6; Fri, 7 Apr 2000 16:38:49 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 7F9D15DDC8 for ; Fri, 7 Apr 2000 16:38:48 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e37Kcfe06809; Fri, 7 Apr 2000 16:38:41 -0400 Message-ID: <38EE474F.A7006518@senie.com> Date: Fri, 07 Apr 2000 16:38:39 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com Cc: "'Steve Hanna'" , zeroconf@merit.edu Subject: Re: home network security References: <003d01bfa0cb$9efd9f50$428939cc@ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > >IPSec is unable to traverse NAT, and so is not useful > > There are several configuration in which this is not an issue, > such as use of IPSEC on the NAT itself, to permit authenticated > access to the inner network. To set this up, one must be able to convince applications to trust the gateway. Yes, this is what RSIP is about, but we're not there yet, and there's a LOT of NAT gear already deployed... Doing IPSec from the gateway does offer LAN-to-LAN possibilities, but that still can be problematic for the telecommuter... especially if there's more than one telecommuter in the household. > > >In the mean time, application level security is likely to be the only > >workable scheme in the home market. > > Not sure why you think that application layer security will work > either. Most NATs do not allow transit of externally initiated > incoming SSL/TLS or even HTTP connections. So if ability to allow > transit of incoming connections across today's NAT solutions is > a criteria, the solution may be the null set. Incoming connections are NOT the issue. Beyond the technical issues, the contracts for cable modems and many DSL services specifically forbid hosting services. I'm talking about end users who sit in their houses and look to the outside. Yes, other parts of this conversation have talked about the outside looking in. Guess what... with NAT (really NAPT, which is what's in use with DSL and cable modems most commonly), you're QUITE limited in terms of having any services up anyway. We're getting somewhat far afield from the base topic, other than the fact that Zeroconf gateways (which have been discussed in the context of devices that don't want to shift to public addresses, even when a DHCP server shows up) would have all the same characteristics of other NAT applications. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Sun Apr 9 20:50:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15527 for ; Sun, 9 Apr 2000 20:50:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6B0B5DDAD; Sun, 9 Apr 2000 20:50:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D60E75DDB2; Sun, 9 Apr 2000 20:50:07 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 408CE5DDAD for ; Sun, 9 Apr 2000 20:50:04 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id RAA41192; Sun, 9 Apr 2000 17:36:44 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Daniel Senie'" Cc: "'Steve Hanna'" , Subject: RE: home network security Date: Sun, 9 Apr 2000 17:52:14 -0700 Message-ID: <006301bfa287$03ff9770$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <38EE474F.A7006518@senie.com> Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Incoming connections are NOT the issue. Wasn't that the whole point of Jeff Schiller's argument? That external threats were the most important ones? The context was that devices might be auto-configured and that this might protect them from external threats. >contracts for cable modems and many DSL services specifically forbid >hosting services. Yes, but they don't prohibit me checking my water heater from the office. From owner-zeroconf@merit.edu Sun Apr 9 22:59:00 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18272 for ; Sun, 9 Apr 2000 22:58:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 199B35DDB3; Sun, 9 Apr 2000 22:58:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 05EF35DDB4; Sun, 9 Apr 2000 22:58:49 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id CBDC45DDB3 for ; Sun, 9 Apr 2000 22:58:48 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e3A2vU123130; Sun, 9 Apr 2000 22:57:30 -0400 Message-ID: <38F14317.2F790C18@senie.com> Date: Sun, 09 Apr 2000 22:57:27 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com Cc: "'Steve Hanna'" , zeroconf@merit.edu Subject: Re: home network security References: <006301bfa287$03ff9770$428939cc@ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > >Incoming connections are NOT the issue. > > Wasn't that the whole point of Jeff Schiller's argument? > That external threats were the most important ones? > The context was that devices might be auto-configured > and that this might protect them from external threats. > > >contracts for cable modems and many DSL services specifically forbid > >hosting services. > > Yes, but they don't prohibit me checking my water heater from > the office. Let's do something of a reality check here... Perhaps I missed something major. I seem to recall zeroconf devices giving themselves addresses by one means or another (an example being the 169.254/16 assignments supported by Win95/98). For you to access your water heater, it would need to either: 1. Autoconfigure itself onto a publicly routable IP address 2. configure itself via DHCP onto a publicly routable IP address (in which case we're out of zeroconf, and more or less out of scope for the WG). 3. Reachable through a gateway that's handling the traffic across a NAT or some such. Before we continue down this path of figuring out security for accessing these various devices in the house, can we figure out where the addresses assigned to your water heater came from? -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Sun Apr 9 23:12:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18473 for ; Sun, 9 Apr 2000 23:12:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 613065DDB4; Sun, 9 Apr 2000 23:11:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4632C5DDB2; Sun, 9 Apr 2000 23:11:58 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by segue.merit.edu (Postfix) with ESMTP id B377F5DDAE for ; Sun, 9 Apr 2000 23:11:56 -0400 (EDT) Received: from bigger-dawgs.cisco.com (pferguso-isdn.cisco.com [171.70.114.134]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id UAA11818; Sun, 9 Apr 2000 20:11:48 -0700 (PDT) Message-Id: <4.3.1.2.20000409231114.00a8bec0@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 09 Apr 2000 23:11:40 -0400 To: Daniel Senie From: Paul Ferguson Subject: Re: home network security Cc: zeroconf@merit.edu In-Reply-To: <38F14317.2F790C18@senie.com> References: <006301bfa287$03ff9770$428939cc@ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 10:57 PM 04/09/2000 -0400, Daniel Senie wrote: >Before we continue down this path of figuring out security for accessing >these various devices in the house, can we figure out where the >addresses assigned to your water heater came from? Ditto. I think a major reality check is needed here. - paul From owner-zeroconf@merit.edu Mon Apr 10 11:12:06 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16605 for ; Mon, 10 Apr 2000 11:12:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 192215DDC0; Mon, 10 Apr 2000 11:11:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0A23D5DDB4; Mon, 10 Apr 2000 11:11:46 -0400 (EDT) Received: from apollo.leviton.com (apollo.leviton.com [209.177.59.130]) by segue.merit.edu (Postfix) with ESMTP id 327C95DD99 for ; Mon, 10 Apr 2000 11:11:43 -0400 (EDT) Received: by APOLLO with Internet Mail Service (5.5.2650.21) id <2TJVVMD4>; Mon, 10 Apr 2000 11:07:43 -0400 Message-ID: From: "Rose, William" To: "'Steve Hanna'" , zeroconf@merit.edu Subject: RE: Is Device Control in the charter? Date: Mon, 10 Apr 2000 11:07:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA2FE.84EF02F4" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFA2FE.84EF02F4 Content-Type: text/plain; charset="iso-8859-1" >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 ------_=_NextPart_001_01BFA2FE.84EF02F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Is Device Control in the charter?

>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

------_=_NextPart_001_01BFA2FE.84EF02F4-- From owner-zeroconf@merit.edu Mon Apr 10 11:35:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18494 for ; Mon, 10 Apr 2000 11:35:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E0E65DD99; Mon, 10 Apr 2000 11:35:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 190865DDB3; Mon, 10 Apr 2000 11:35:27 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id C084A5DD99 for ; Mon, 10 Apr 2000 11:35:25 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e3AFZF126273; Mon, 10 Apr 2000 11:35:15 -0400 Message-ID: <38F1F4B3.8B42A3AF@senie.com> Date: Mon, 10 Apr 2000 11:35:15 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rose, William" Cc: "'Steve Hanna'" , zeroconf@merit.edu Subject: Re: Is Device Control in the charter? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > "Rose, William" wrote: > > >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 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)... > > 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. 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 dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Mon Apr 10 15:35:10 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01312 for ; Mon, 10 Apr 2000 15:35:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 452425DD94; Mon, 10 Apr 2000 15:35:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2DCF65DDAC; Mon, 10 Apr 2000 15:35:02 -0400 (EDT) Received: from apollo.leviton.com (apollo.leviton.com [209.177.59.130]) by segue.merit.edu (Postfix) with ESMTP id 0342D5DD94 for ; Mon, 10 Apr 2000 15:35:00 -0400 (EDT) Received: by APOLLO with Internet Mail Service (5.5.2650.21) id <2TJVV3PH>; Mon, 10 Apr 2000 15:31:04 -0400 Message-ID: From: "Rose, William" To: "'Daniel Senie'" , "Rose, William" Cc: "'Steve Hanna'" , zeroconf@merit.edu Subject: RE: Is Device Control in the charter? Date: Mon, 10 Apr 2000 15:31:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA323.4F06BC0C" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFA323.4F06BC0C Content-Type: text/plain; charset="iso-8859-1" >> 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 >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. >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. I have contacted several people who can answer some of these questions and will get the answers to you ASAA. I have asked them to forward the answers to me, to keep them brief, and to do so within a few days. This may be outside of zeroconfig but at least it might provide some additional insight. Bill Rose ------_=_NextPart_001_01BFA323.4F06BC0C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Is Device Control in the charter?

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

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

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

I have contacted several people who can answer some = of these questions and will get the answers to you ASAA. I have asked = them to forward the answers to me, to keep them brief, and to do so = within a few days.

This may be outside of zeroconfig but at least it = might provide some additional insight.

Bill Rose

------_=_NextPart_001_01BFA323.4F06BC0C-- From owner-zeroconf@merit.edu Mon Apr 10 21:14:11 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08056 for ; Mon, 10 Apr 2000 21:14:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8EBE75DDBA; Mon, 10 Apr 2000 21:13:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7CE345DDA0; Mon, 10 Apr 2000 21:13:51 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id B6B8E5DDAC for ; Mon, 10 Apr 2000 21:13:47 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id SAA42533; Mon, 10 Apr 2000 18:00:22 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Daniel Senie'" , "'Rose, William'" Cc: "'Steve Hanna'" , Subject: RE: Is Device Control in the charter? Date: Mon, 10 Apr 2000 18:15:56 -0700 Message-ID: <010601bfa353$7d75abe0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <38F1F4B3.8B42A3AF@senie.com> Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >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. 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. From owner-zeroconf@merit.edu Wed Apr 12 13:33:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28819 for ; Wed, 12 Apr 2000 13:33:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E09425DDDF; Wed, 12 Apr 2000 13:31:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CD5CA5DDEE; Wed, 12 Apr 2000 13:31:19 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 569EE5DDDF for ; Wed, 12 Apr 2000 13:31:18 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA25628 for ; Wed, 12 Apr 2000 10:31:17 -0700 (MST)] Received: [from az33exi01.corp.mot.com ([199.2.84.10]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA01371 for ; Wed, 12 Apr 2000 10:31:15 -0700 (MST)] Received: by AZ33EXI01 with Internet Mail Service (5.5.2650.21) id <2Y394S94>; Wed, 12 Apr 2000 10:31:14 -0700 Message-ID: From: Austin Bill-P23393 To: zeroconf@merit.edu Subject: RE: home network security Date: Wed, 12 Apr 2000 10:31:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk > -----Original Message----- > From: Paul Ferguson [mailto:ferguson@cisco.com] > Sent: Sunday, April 09, 2000 8:12 PM > To: Daniel Senie > Cc: zeroconf@merit.edu > Subject: Re: home network security > > > At 10:57 PM 04/09/2000 -0400, Daniel Senie wrote: > > >Before we continue down this path of figuring out security > for accessing > >these various devices in the house, can we figure out where the > >addresses assigned to your water heater came from? > > Ditto. I think a major reality check is needed here. > > - paul > > The recent announcement of the industry joint effort for secure mobile electronic transactions (press release below) is somewhat encouraging to me. A successful outcome of that effort will go a long way towards building a common, open, systems approach to secure transactions and may be applicable within the home network "trust" arena as well. -- Bill Austin Motorola Bluetooth http://www.mot.com/bluetooth/ Bluetooth Mailing List http://www.stockhelp.net/bluetooth/ Arizona High-Tech Talent Partnership http://www.azhttp.net/ Ericsson, Motorola and Nokia Team to Develop a Common Framework for Mobile E-business STOCKHOLM, Sweden--(BUSINESS WIRE)--April 11, 2000-- The Industry Joint Effort aims at the Creation of the Personal Trusted Device by Integrating Security and Transaction Applications into Mobile Terminal Platform Ericsson, Motorola and Nokia today announced a joint effort to develop an open and common industry framework for secure mobile electronic transactions. The target of this initiative is to use existing and emerging standards to build a common framework and to create an implementation roadmap in order to enhance the fast adoption of trusted mobile e-business. Representatives from the telecom, financial and the IS/IT industries will be invited to contribute to the effort. The possibility to handle trusted electronic transactions from a personal mobile device is regarded as one of the most important areas of the Mobile Internet. The mobile device can be a tool for a variety of services, such as banking and trading services, credit card and payment services, loyalty/bonus services and ID-card services. The Ericsson, Motorola and Nokia initiative defines an open platform for secure mobile phone transactions. The aim is to offer solutions where security and payment services will be integrated as a standard into hundreds of millions of mobile devices in years to come. There are today several activities ongoing in order to facilitate secure transactions from mobile devices. The initiative from Ericsson, Motorola and Nokia will merge existing initiatives with the de facto standard for secure mobile electronic transactions, including not only the technical capabilities but also the context for how this concept shall be used and executed. Some of the key technology cornerstones will be WAP security functions, such as WTLS (Wireless Transport Layer Security) and WIM (Wireless Identification Module) - as well as wireless Public Key technologies (PKI) and already implemented mobile payment schemes. "For a user, a mobile phone is a highly personal device that today is expected to be easily and securely tailored according to an individual need. These expectations cover also the fast emerging mobile e-business sector. A mobile device will be the platform to bridge the virtual and physical worlds of e-business. Integrating security and transaction applications on a common core standard and platform will create global mass market for mobile e-business. This will benefit all participants from various industries within the value chain, in addition to hundreds of millions of consumers throughout the world," says Matti Alahuhta, President, Nokia Mobile Phones. "The ambition is to formulate an environment which allows mobile operators, financial institutions and other service providers to facilitate secure mobile transactions," says Jan Ahrenbring, Vice President Marketing and Communications at Ericsson Mobile Communications. "Ericsson estimates that by 2004 there will be around one billion users of mobile telephony and some 600 million mobile Internet subscribers worldwide. The most important thing that is needed to get all these consumers to start using mobile e-commerce is a standard, which makes it safe and easy to use," says Ahrenbring. "Motorola is committed to the development of the mobile Internet and making it secure, not only via the Web-enabled phones that make access possible, but also the technologies that enable this world without wires, said Rick Darnaby, Senior Vice President & General Manager of Europe, Middle East & Africa for Motorola's Personal Communications. "Trust is the key element for mobile interaction and transaction. We envision mobile devices will soon play a key role in virtually every aspect of our lives. We want to give consumers the ability of stay securely connected, informed and to conduct sensitive and financial transactions anytime and wherever they are." Creating a standard for secure mobile transactions also opens up the possibility for small transactions to be handled via mobile devices, for example ticketing applications. Mobile devices will also be used to handle short distance payments and transactions enabled by the Bluetooth technology, for example to point of sale machines and parking meters. The initiative includes methods for service providers to expose their brand in mobile devices. Nokia, Ericsson and Motorola are expected to issue technical and other details about the context for secure mobile transactions by the end of May on their web sites and invite others to participate in the work. The ambition is to formulate an open framework before the summer, based upon input from related industries. Nokia is paving the way to the mobile information society with its innovative products and solutions. The company is a leading mobile phone supplier and a leading supplier of mobile, and broadband IP networks, related services as well as multimedia terminals. In 1999, Nokia's net sales totaled EUR 19.8 billion (USD 19.9 billion). Headquartered in Finland, Nokia is listed on the New York (NOK), Helsinki, Stockholm, London, Frankfurt and Paris stock exchanges and employs more than 55,000 people. Visit the Nokia website at http://www.nokia.com Ericsson is the leading provider in the new telecoms world, with communications solutions that combine telecom and datacom technologies with the freedom of mobility for the user. With more than 100,000 employees in 140 countries, Ericsson simplifies communications for its customers - network operators, service providers, enterprises and consumers - the world over. Please visit Ericsson's Press Room at: http://www.ericsson.se/pressroom Motorola, Inc. (NYSE:MOT) is a global leader in providing integrated communications solutions and embedded electronic solutions. Sales in 1999 were $33.1 billion. For more information about Motorola, visit the website at http://www.motorola.com CONTACT: Nokia Mobile Phones Tapio Hedman, + 358 10 505 5750 or Nokia Mobile Phones, Communications, + 358 10 5051 Ericsson Mobile Communications AB Jan Ahrenbring, +46 70 590 9900 or Bo Albertson, + 46 8 764 1388 or +46 70 510 0992 Motorola Natalie Link, +44 1256 790 707 or Jennifer Weyrauch, +1 847 523 0015 From owner-zeroconf@merit.edu Wed Apr 12 16:49:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03124 for ; Wed, 12 Apr 2000 16:49:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 93DBA5DDD0; Wed, 12 Apr 2000 16:49:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F75C5DDC7; Wed, 12 Apr 2000 16:49:44 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 490DD5DDBF for ; Wed, 12 Apr 2000 16:49:43 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e3CKnf111413; Wed, 12 Apr 2000 16:49:41 -0400 Message-ID: <38F4E165.12D74598@senie.com> Date: Wed, 12 Apr 2000 16:49:41 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Austin Bill-P23393 Cc: zeroconf@merit.edu Subject: Re: home network security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Austin Bill-P23393 wrote: > > > -----Original Message----- > > From: Paul Ferguson [mailto:ferguson@cisco.com] > > Sent: Sunday, April 09, 2000 8:12 PM > > To: Daniel Senie > > Cc: zeroconf@merit.edu > > Subject: Re: home network security > > > > > > At 10:57 PM 04/09/2000 -0400, Daniel Senie wrote: > > > > >Before we continue down this path of figuring out security > > for accessing > > >these various devices in the house, can we figure out where the > > >addresses assigned to your water heater came from? > > > > Ditto. I think a major reality check is needed here. > > > > - paul > > > > > > The recent announcement of the industry joint effort for secure mobile > electronic transactions (press release below) is somewhat encouraging to me. > A successful outcome of that effort will go a long way towards building a > common, open, systems approach to secure transactions and may be applicable > within the home network "trust" arena as well. That's all well and good, but rather off the topic of my mail, and Paul's to which you responded. Before we talk about how trust will work and where, we need to figure out if it's even relevant to this working group. This is not the "home networking" working group, it's "zero configuration." The concern I raised is that we haven't talked about whether addresses which are self-assigned through zeroconf are even publicly routable. Previous work in this area argues for non-routable addresses. If that's how we are going to proceed, there'll be NO communication between zeroconf devices and the Internet at large, and thus the trust issue is outside the scope of this working group. Please let us do a reality check, as Paul suggested, and make sure we stay in scope. If there's interest in topics outside this WG's charter, then it may be time to consider additional working groups outside of zeroconf for those discussions. > > -- > Bill Austin > Motorola Bluetooth http://www.mot.com/bluetooth/ > Bluetooth Mailing List http://www.stockhelp.net/bluetooth/ > Arizona High-Tech Talent Partnership http://www.azhttp.net/ > > Ericsson, Motorola and Nokia Team to Develop a Common Framework for Mobile > E-business > STOCKHOLM, Sweden--(BUSINESS WIRE)--April 11, 2000-- > > The Industry Joint Effort aims at the Creation of the Personal Trusted > Device by Integrating Security and Transaction Applications into Mobile > Terminal Platform Ericsson, Motorola and Nokia today announced a joint > effort to develop an open and common industry framework for secure mobile > electronic transactions. > > The target of this initiative is to use existing and emerging standards to > build a common framework and to create an implementation roadmap in order to > enhance the fast adoption of trusted mobile e-business. Representatives from > the telecom, financial and the IS/IT industries will be invited to > contribute to the effort. > > The possibility to handle trusted electronic transactions from a personal > mobile device is regarded as one of the most important areas of the Mobile > Internet. The mobile device can be a tool for a variety of services, such as > banking and trading services, credit card and payment services, > loyalty/bonus services and ID-card services. The Ericsson, Motorola and > Nokia initiative defines an open platform for secure mobile phone > transactions. The aim is to offer solutions where security and payment > services will be integrated as a standard into hundreds of millions of > mobile devices in years to come. > > There are today several activities ongoing in order to facilitate secure > transactions from mobile devices. The initiative from Ericsson, Motorola and > Nokia will merge existing initiatives with the de facto standard for secure > mobile electronic transactions, including not only the technical > capabilities but also the context for how this concept shall be used and > executed. Some of the key technology cornerstones will be WAP security > functions, such as WTLS (Wireless Transport Layer Security) and WIM > (Wireless Identification Module) - as well as wireless Public Key > technologies (PKI) and already implemented mobile payment schemes. > > "For a user, a mobile phone is a highly personal device that today is > expected to be easily and securely tailored according to an individual need. > These expectations cover also the fast emerging mobile e-business sector. A > mobile device will be the platform to bridge the virtual and physical worlds > of e-business. Integrating security and transaction applications on a common > core standard and platform will create global mass market for mobile > e-business. This will benefit all participants from various industries > within the value chain, in addition to hundreds of millions of consumers > throughout the world," says Matti Alahuhta, President, Nokia Mobile Phones. > > "The ambition is to formulate an environment which allows mobile operators, > financial institutions and other service providers to facilitate secure > mobile transactions," says Jan Ahrenbring, Vice President Marketing and > Communications at Ericsson Mobile Communications. "Ericsson estimates that > by 2004 there will be around one billion users of mobile telephony and some > 600 million mobile Internet subscribers worldwide. The most important thing > that is needed to get all these consumers to start using mobile e-commerce > is a standard, which makes it safe and easy to use," says Ahrenbring. > > "Motorola is committed to the development of the mobile Internet and making > it secure, not only via the Web-enabled phones that make access possible, > but also the technologies that enable this world without wires, said Rick > Darnaby, Senior Vice President & General Manager of Europe, Middle East & > Africa for Motorola's Personal Communications. "Trust is the key element for > mobile interaction and transaction. We envision mobile devices will soon > play a key role in virtually every aspect of our lives. We want to give > consumers the ability of stay securely connected, informed and to conduct > sensitive and financial transactions anytime and wherever they are." > > Creating a standard for secure mobile transactions also opens up the > possibility for small transactions to be handled via mobile devices, for > example ticketing applications. Mobile devices will also be used to handle > short distance payments and transactions enabled by the Bluetooth > technology, for example to point of sale machines and parking meters. The > initiative includes methods for service providers to expose their brand in > mobile devices. > > Nokia, Ericsson and Motorola are expected to issue technical and other > details about the context for secure mobile transactions by the end of May > on their web sites and invite others to participate in the work. The > ambition is to formulate an open framework before the summer, based upon > input from related industries. > > Nokia is paving the way to the mobile information society with its > innovative products and solutions. The company is a leading mobile phone > supplier and a leading supplier of mobile, and broadband IP networks, > related services as well as multimedia terminals. In 1999, Nokia's net sales > totaled EUR 19.8 billion (USD 19.9 billion). Headquartered in Finland, Nokia > is listed on the New York (NOK), Helsinki, Stockholm, London, Frankfurt and > Paris stock exchanges and employs more than 55,000 people. Visit the Nokia > website at http://www.nokia.com > > Ericsson is the leading provider in the new telecoms world, with > communications solutions that combine telecom and datacom technologies with > the freedom of mobility for the user. With more than 100,000 employees in > 140 countries, Ericsson simplifies communications for its customers - > network operators, service providers, enterprises and consumers - the world > over. Please visit Ericsson's Press Room at: > http://www.ericsson.se/pressroom > > Motorola, Inc. (NYSE:MOT) is a global leader in providing integrated > communications solutions and embedded electronic solutions. Sales in 1999 > were $33.1 billion. For more information about Motorola, visit the website > at http://www.motorola.com > > CONTACT: Nokia Mobile Phones > Tapio Hedman, + 358 10 505 5750 > or > Nokia Mobile Phones, Communications, + 358 10 5051 > Ericsson Mobile Communications AB > Jan Ahrenbring, +46 70 590 9900 > or > Bo Albertson, + 46 8 764 1388 or +46 70 510 0992 > Motorola > Natalie Link, +44 1256 790 707 > or > Jennifer Weyrauch, +1 847 523 0015 -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Apr 12 17:15:28 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03625 for ; Wed, 12 Apr 2000 17:15:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1160B5DDF1; Wed, 12 Apr 2000 17:15:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1C2925DDA9; Wed, 12 Apr 2000 17:15:11 -0400 (EDT) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by segue.merit.edu (Postfix) with ESMTP id A0C945DDF1 for ; Wed, 12 Apr 2000 17:15:04 -0400 (EDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.2/8.9.2) id OAA04244; Wed, 12 Apr 2000 14:14:11 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14580.59171.361172.577612@kitab.cisco.com> Date: Wed, 12 Apr 2000 14:14:11 -0700 (PDT) To: Daniel Senie Cc: Austin Bill-P23393 , zeroconf@merit.edu Subject: Re: home network security In-Reply-To: <38F4E165.12D74598@senie.com> References: <38F4E165.12D74598@senie.com> X-Mailer: VM 6.74 under 20.4 "Emerald" XEmacs Lucid Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Senie writes: > The concern I raised is that we haven't talked about whether addresses > which are self-assigned through zeroconf are even publicly routable. > Previous work in this area argues for non-routable addresses. If that's > how we are going to proceed, there'll be NO communication between > zeroconf devices and the Internet at large, and thus the trust issue is > outside the scope of this working group. Seems to me there are three basic ways of getting an address: 1) from a DHCP server: This is not "zeroconf", but would be part of the transition to a non-zeroconf network, etc. This address is *probably* routable to the Internet as a whole, but may not be depending upon what address range the DHCP server is handing out. (Obviously, it could be handing out addresses in the 10.0.0.0/8 net which would not be usable on the Internet directly, however there could be a router somewhere doing NAT which would make these systems "accessible" in a limited sorta way.) 2) via some type of zeroconf autoconfig using link-local addressing: This definitely would not be Internet accessible, ... unless there's a router somewhere playing tricks with NAT as in the case above. 3) via some type of zeroconf autoconfig using the configured subnet and mask for the network: This is assuming the zeroconf system can determine the correct subnet number and mask, and then do claim and defend on an address randomly allocated on this network. This type of address would obviously be Internet accessible and would not require NAT, ... unless... It seems that case (3) could actually be case (1) if the "configured network and mask" happens to be 10.0.0.0/8, and it seems that cases (1) and (2) *could* be Internet accessible if there's a NAT box involved somewhere. This just goes to show you that whether or not an address is Internet accessible is really up to the router which has been connected to the network. If that router has been configured to allow the address to pass or traffic from outside to pass to the address (via NAT or without it) to the Internet in some way, then it's Internet accessible, otherwise not. It seems that the issue of whether or not an address is Internet accessible is not really a "zeroconf" problem, per se. It would be probably be good for us to make some recommendations as to what methods should be used in what order such that a system would has the highest likelyhood of getting an Internet accessible address, however. /raj From owner-zeroconf@merit.edu Thu Apr 13 02:00:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16846 for ; Thu, 13 Apr 2000 02:00:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 98E8D5DDC8; Thu, 13 Apr 2000 01:59:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 87A265DDC7; Thu, 13 Apr 2000 01:59:48 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id F19475DD96 for ; Thu, 13 Apr 2000 01:59:42 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id WAA45627; Wed, 12 Apr 2000 22:45:47 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Richard Johnson'" , "'Daniel Senie'" Cc: "'Austin Bill-P23393'" , Subject: RE: home network security Date: Wed, 12 Apr 2000 23:01:29 -0700 Message-ID: <010201bfa50d$b70acf00$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <14580.59171.361172.577612@kitab.cisco.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >This just goes to show you that whether or not an address is Internet >accessible is really up to the router which has been connected to the >network. This is true except if we are talking about 169.254/16. In that case it is NOT up to the router. The router MUST NOT let packets sourced from this address off the link. This applies to multicast as well as unicast. >It seems that the issue of whether or not >an address is Internet accessible is not really a "zeroconf" problem, >per se. Yup. >such that a system would have the highest likelyhood of getting an >Internet accessible address, however. I think that there may be different goals for different classes of hosts. For devices, this may not be a goal because auto-conf (169.254/16) addresses may be fine. For other hosts it may be a goal. From owner-zeroconf@merit.edu Thu Apr 13 08:53:24 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29264 for ; Thu, 13 Apr 2000 08:53:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B01A5DDED; Thu, 13 Apr 2000 08:53:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0AA7F5DDDF; Thu, 13 Apr 2000 08:53:03 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id E8E925DDB5 for ; Thu, 13 Apr 2000 08:53:01 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e3DCq3115613; Thu, 13 Apr 2000 08:52:03 -0400 Message-ID: <38F5C2F2.2C60FF1A@senie.com> Date: Thu, 13 Apr 2000 08:52:02 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com Cc: zeroconf@merit.edu Subject: Re: home network security References: <010201bfa50d$b70acf00$428939cc@ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > >This just goes to show you that whether or not an address is Internet > >accessible is really up to the router which has been connected to the > >network. > > This is true except if we are talking about 169.254/16. In that case > it is NOT up to the router. The router MUST NOT let packets > sourced from this address off the link. This applies to multicast as > well as unicast. Same is true of RFC 1918 addresses. Those also are specifically not to be routed anywhere ever. They can be the private addresses used by a NAT, of course. > > >It seems that the issue of whether or not > >an address is Internet accessible is not really a "zeroconf" problem, > >per se. > > Yup. > > >such that a system would have the highest likelyhood of getting an > >Internet accessible address, however. > > I think that there may be different goals for different classes of > hosts. For devices, this may not be a goal because auto-conf > (169.254/16) addresses may be fine. For other hosts it may be > a goal. If devices don't need to be moved off of 169.254/16, then they also don't need to be accessed from outside, unless via an application-specific gateway, and thus the security question becomes an application gateway issue. You're talking about the zeroconf mode using 169.254/16. If that's the case, then zeroconf mode == private network only. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Thu Apr 13 12:12:41 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05806 for ; Thu, 13 Apr 2000 12:12:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BCDF5DD8C; Thu, 13 Apr 2000 12:12:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 895F55DD90; Thu, 13 Apr 2000 12:12:22 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 39DF95DD8C for ; Thu, 13 Apr 2000 12:12:21 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11126; Thu, 13 Apr 2000 10:12:18 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA19586; Thu, 13 Apr 2000 09:12:16 -0700 (PDT) Received: from sunray-mpkd (sunray-mpkd [129.146.6.31]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA15593; Thu, 13 Apr 2000 09:12:15 -0700 (PDT) Date: Thu, 13 Apr 2000 09:12:16 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: home network security To: Daniel Senie Cc: zeroconf@merit.edu In-Reply-To: "Your message with ID" <38F5C2F2.2C60FF1A@senie.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Same is true of RFC 1918 addresses. Those also are specifically not to > be routed anywhere ever. where is this specified? "not to be routed" is perhaps too strong? did you really mean that rfc1918 addrs are link-local? or just that they are not to be forwarded/routed out of a given 'site'. -gabriel From owner-zeroconf@merit.edu Thu Apr 13 12:35:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06980 for ; Thu, 13 Apr 2000 12:35:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ECAA85DD90; Thu, 13 Apr 2000 12:35:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA7F15DDB5; Thu, 13 Apr 2000 12:35:15 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id BB65A5DD90 for ; Thu, 13 Apr 2000 12:35:14 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e3DGZC116485; Thu, 13 Apr 2000 12:35:12 -0400 Message-ID: <38F5F73F.F59F0F2F@senie.com> Date: Thu, 13 Apr 2000 12:35:11 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gabriel Montenegro Cc: zeroconf@merit.edu Subject: Re: home network security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'll go reread RFC 1918, but I do indeed believe it says these addresses are not to appear on the public network. Well, the language is a little weaker than I thought: It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise. That's from the operational considerations section. You can certainly route RFC 1918 addresses within a private network but they should be filtered at all times (packet and route) from the public network. This is what I meant when I said RFC 1918 addresses shouldn't be routed. In private networks you can indeed route them... -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Thu Apr 13 21:26:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16925 for ; Thu, 13 Apr 2000 21:26:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E8CA95DDC3; Thu, 13 Apr 2000 21:25:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA0365DD9D; Thu, 13 Apr 2000 21:25:42 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 2CFE95DD96 for ; Thu, 13 Apr 2000 21:25:38 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id SAA46670; Thu, 13 Apr 2000 18:11:55 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Daniel Senie'" , "'Gabriel Montenegro'" Cc: Subject: RE: home network security Date: Thu, 13 Apr 2000 18:27:40 -0700 Message-ID: <015801bfa5b0$a0ceae70$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38F5F73F.F59F0F2F@senie.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I'll go reread RFC 1918, but I do indeed believe it says these addresses >are not to appear on the public network. This is not the same thing as linklocal. RFC 1918 addresses can be translated so that they don't appear on the public network. However, my understanding is that linklocal addresses (169.254/16) are not to leave the link, even if they are translated. So the only avenue for connectivity of linklocal devices is application layer gateways (ALGs). From owner-zeroconf@merit.edu Fri Apr 14 02:52:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03566 for ; Fri, 14 Apr 2000 02:52:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF6F45DD8F; Fri, 14 Apr 2000 02:52:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9E3B15DD95; Fri, 14 Apr 2000 02:52:19 -0400 (EDT) Received: from smtp01do.de.uu.net (smtp01do.de.uu.net [192.76.144.61]) by segue.merit.edu (Postfix) with ESMTP id E16255DD8F for ; Fri, 14 Apr 2000 02:52:17 -0400 (EDT) Received: from bommel.kecam-han.de (garfield.kecam-han.de [193.99.158.1] (may be forged)) by smtp01do.de.uu.net (5.5.5/5.5.5) with ESMTP id IAA08574 for ; Fri, 14 Apr 2000 08:52:16 +0200 (MET DST) Received: from dt.kecam-han.de (dt [192.168.10.1]) by bommel.kecam-han.de (8.9.3/8.9.1) with ESMTP id IAA09467 for ; Fri, 14 Apr 2000 08:52:30 +0200 (MET DST) Received: from mozilla.kecam-han.de (mozilla [10.9.1.6]) by dt.kecam-han.de (8.9.3/8.9.3) with ESMTP id IAA10539 for ; Fri, 14 Apr 2000 08:53:24 +0200 (MET DST) Received: from kecam-han.de ([10.2.1.232]) by mozilla.kecam-han.de (Netscape Messaging Server 3.6) with ESMTP id AAA317C for ; Fri, 14 Apr 2000 08:53:22 +0200 Message-ID: <38F6C0FB.2C6B6365@kecam-han.de> Date: Fri, 14 Apr 2000 08:55:55 +0200 From: "Martin Djernaes" Organization: Alcatel Kommunikations-Elektronik GmbH X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,en-US,en-GB,da,de MIME-Version: 1.0 To: zeroconf@merit.edu Subject: 169.254/16 IP addresses Content-Type: text/plain; charset=iso-8859-1 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA03566 Hi, I have here been seeing some discussions about packages sourced from a member of the IP group 169.254/16, should never leave the local network - also not translated via NAT or an equal functionally. I would like to know from you: - Why? - Where is this described? -- Regards, Martin Djern�s -------------------------------------------------------------- Martin Djern�s martin.djernaes@kecam-han.de Dipl.-Ing. Alcatel Kommunikations-Elektronik GmbH Tel:+49 (0511) 6747 741 Postfach 3246 Fax:+49 (0511) 6747 777 30032 Hannover, Germany http://www.ke-online.de -------------------------------------------------------------- From owner-zeroconf@merit.edu Fri Apr 14 03:51:58 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03929 for ; Fri, 14 Apr 2000 03:51:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 97F925DDFA; Fri, 14 Apr 2000 03:51:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7D5A35DDF5; Fri, 14 Apr 2000 03:51:47 -0400 (EDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by segue.merit.edu (Postfix) with ESMTP id D5D185DDF3 for ; Fri, 14 Apr 2000 03:51:45 -0400 (EDT) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA12191; Fri, 14 Apr 2000 08:51:03 +0100 (BST) Received: from mofo.ecs.soton.ac.uk (IDENT:root@mofo.ecs.soton.ac.uk [152.78.65.197]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA04869; Fri, 14 Apr 2000 08:51:00 +0100 (BST) Received: (from mkt@localhost) by mofo.ecs.soton.ac.uk (8.9.3/8.9.3) id IAA01061; Fri, 14 Apr 2000 08:51:23 +0100 Date: Fri, 14 Apr 2000 08:51:23 +0100 From: Mark Thompson To: Martin Djernaes Cc: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses Message-ID: <20000414085123.C913@ecs.soton.ac.uk> References: <38F6C0FB.2C6B6365@kecam-han.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <38F6C0FB.2C6B6365@kecam-han.de>; from martin.djernaes@kecam-han.de on Fri, Apr 14, 2000 at 08:55:55AM +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk On 08:55(GMT) 14-04-00, Martin Djernaes wrote: > Hi, > > I would like to know from you: > - Why? 169.254/16 is the IPv4 "link-local" allocation (do a "whois 169.254.0.0@whois.arin.net"), similar in use to IPv6'es fe80::/8 address allocation. > - Where is this described? In draft-ietf-dhc-ipv4-autoconfig-05.txt at www.ietf.org/internet-drafts "Yet another reverse-applied bolt-on to v4 to mimic the glory of v6?" *ducks* Mark/ -- iam: networks and distributed systems From owner-zeroconf@merit.edu Fri Apr 14 04:29:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04273 for ; Fri, 14 Apr 2000 04:29:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 415865DDF3; Fri, 14 Apr 2000 04:29:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 304AB5DDF5; Fri, 14 Apr 2000 04:29:48 -0400 (EDT) Received: from smtp01do.de.uu.net (smtp01do.de.uu.net [192.76.144.61]) by segue.merit.edu (Postfix) with ESMTP id 6CF345DDF3 for ; Fri, 14 Apr 2000 04:29:46 -0400 (EDT) Received: from bommel.kecam-han.de (garfield.kecam-han.de [193.99.158.1] (may be forged)) by smtp01do.de.uu.net (5.5.5/5.5.5) with ESMTP id KAA13012 for ; Fri, 14 Apr 2000 10:29:45 +0200 (MET DST) Received: from dt.kecam-han.de (dt [192.168.10.1]) by bommel.kecam-han.de (8.9.3/8.9.1) with ESMTP id KAA10373 for ; Fri, 14 Apr 2000 10:29:59 +0200 (MET DST) Received: from mozilla.kecam-han.de (mozilla [10.9.1.6]) by dt.kecam-han.de (8.9.3/8.9.3) with ESMTP id KAA11292 for ; Fri, 14 Apr 2000 10:30:53 +0200 (MET DST) Received: from kecam-han.de ([10.2.1.232]) by mozilla.kecam-han.de (Netscape Messaging Server 3.6) with ESMTP id AAA63A2; Fri, 14 Apr 2000 10:30:51 +0200 Message-ID: <38F6D7D4.2E7C2E6D@kecam-han.de> Date: Fri, 14 Apr 2000 10:33:24 +0200 From: "Martin Djernaes" Organization: Alcatel Kommunikations-Elektronik GmbH X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,en-US,en-GB,da,de MIME-Version: 1.0 To: Mark Thompson Cc: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses References: <38F6C0FB.2C6B6365@kecam-han.de> <20000414085123.C913@ecs.soton.ac.uk> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04273 Hi Mark, Mark Thompson wrote: > > I would like to know from you: > > - Why? > > 169.254/16 is the IPv4 "link-local" allocation (do a "whois > 169.254.0.0@whois.arin.net"), similar in use to IPv6'es fe80::/8 address > allocation. That is also fine that the address group is link local, but why shouldn't it be used as source for a outgoing connection via a NA(P)T gateway? Taken in mind that most ISPs only want to provide one IP address for their end customers, and that the customers wants to connect more than one computer/device to the internet, we have a problem. If a xDSL/ISDN router provide NAT functionality the ISP would be happy, the customer would be happy (and the "protocol people" are unhappy with the "broken" addressing scheme). So the autoconfig functionality would be an ideal way to supply the internal network with local addresses (router and PCs), and the NAT functionality will make sure that the link local addresses never are seen outside the local network. -- Regards, Martin Djern�s -------------------------------------------------------------- Martin Djern�s martin.djernaes@kecam-han.de Dipl.-Ing. Alcatel Kommunikations-Elektronik GmbH Tel:+49 (0511) 6747 741 Postfach 3246 Fax:+49 (0511) 6747 777 30032 Hannover, Germany http://www.ke-online.de -------------------------------------------------------------- From owner-zeroconf@merit.edu Fri Apr 14 04:40:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04400 for ; Fri, 14 Apr 2000 04:40:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F8915DDF5; Fri, 14 Apr 2000 04:40:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F33F75DDFB; Fri, 14 Apr 2000 04:40:29 -0400 (EDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by segue.merit.edu (Postfix) with ESMTP id 6B28B5DDF5 for ; Fri, 14 Apr 2000 04:40:28 -0400 (EDT) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA12415 for ; Fri, 14 Apr 2000 09:40:27 +0100 (BST) Received: from mofo.ecs.soton.ac.uk (IDENT:root@mofo.ecs.soton.ac.uk [152.78.65.197]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA05992 for ; Fri, 14 Apr 2000 09:40:24 +0100 (BST) Received: (from mkt@localhost) by mofo.ecs.soton.ac.uk (8.9.3/8.9.3) id JAA01245 for zeroconf@merit.edu; Fri, 14 Apr 2000 09:40:47 +0100 Date: Fri, 14 Apr 2000 09:40:47 +0100 From: Mark Thompson To: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses Message-ID: <20000414094047.A1198@ecs.soton.ac.uk> References: <38F6C0FB.2C6B6365@kecam-han.de> <20000414085123.C913@ecs.soton.ac.uk> <38F6D7D4.2E7C2E6D@kecam-han.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <38F6D7D4.2E7C2E6D@kecam-han.de>; from martin.djernaes@kecam-han.de on Fri, Apr 14, 2000 at 10:33:24AM +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Hi Martin, On 10:33(GMT) 14-04-00, Martin Djernaes wrote: > Hi Mark, > > That is also fine that the address group is link local, but why > shouldn't it be used as source for a outgoing connection via a NA(P)T > gateway? I think the idea is that link-local addresses are used to communicate *only* with devices on the local link, and that global addresses (or, IYL, NATable addresses from Net10 etc.) are used for the "I want to route to the outside world" cases. Actually, the draft does imply that IPv4 link-local autoconf is used to "hunt" DHCP servers that appear after the local host comes up (Section 4, "Ongoing checks for a DHCP server"). The idea is that your device gets a link-local address when no globally-routable one (or NATed one) is discovered, and then runs with it up until a DHCP server (or NAT gw) becomes available. If you know by *specification* that the link-local addresses are only ever going to be seen by local devices, and that routers by *specification* MUST NOT route/munge/forward packets destined to those addresses, I can see cases where you can make certain assumptions about the communication (topological location, security, etc. etc.) that you can't otherwise. If Steve Deering is listening in on this, I'm sure he'll have valuable input on the reasons the IPngwg work introduced the link-local strictly scoped addresses. Mark/ -- iam: networks and distributed systems From owner-zeroconf@merit.edu Fri Apr 14 05:03:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04567 for ; Fri, 14 Apr 2000 05:03:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 220FB5DDFE; Fri, 14 Apr 2000 05:00:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0DDB05DDFC; Fri, 14 Apr 2000 05:00:40 -0400 (EDT) Received: from smtp01do.de.uu.net (smtp01do.de.uu.net [192.76.144.61]) by segue.merit.edu (Postfix) with ESMTP id A2A495DDFB for ; Fri, 14 Apr 2000 05:00:37 -0400 (EDT) Received: from bommel.kecam-han.de (garfield.kecam-han.de [193.99.158.1] (may be forged)) by smtp01do.de.uu.net (5.5.5/5.5.5) with ESMTP id LAA02002 for ; Fri, 14 Apr 2000 11:00:36 +0200 (MET DST) Received: from dt.kecam-han.de (dt [192.168.10.1]) by bommel.kecam-han.de (8.9.3/8.9.1) with ESMTP id LAA10590 for ; Fri, 14 Apr 2000 11:00:49 +0200 (MET DST) Received: from mozilla.kecam-han.de (mozilla [10.9.1.6]) by dt.kecam-han.de (8.9.3/8.9.3) with ESMTP id LAA11534 for ; Fri, 14 Apr 2000 11:01:44 +0200 (MET DST) Received: from kecam-han.de ([10.2.1.232]) by mozilla.kecam-han.de (Netscape Messaging Server 3.6) with ESMTP id AAA734A; Fri, 14 Apr 2000 11:01:42 +0200 Message-ID: <38F6DF0F.9E514217@kecam-han.de> Date: Fri, 14 Apr 2000 11:04:15 +0200 From: "Martin Djernaes" Organization: Alcatel Kommunikations-Elektronik GmbH X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,en-US,en-GB,da,de MIME-Version: 1.0 To: Mark Thompson Cc: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses References: <38F6C0FB.2C6B6365@kecam-han.de> <20000414085123.C913@ecs.soton.ac.uk> <38F6D7D4.2E7C2E6D@kecam-han.de> <20000414094047.A1198@ecs.soton.ac.uk> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA04567 Hi Mark, Mark Thompson wrote: > > That is also fine that the address group is link local, but why > > shouldn't it be used as source for a outgoing connection via a NA(P)T > > gateway? > > I think the idea is that link-local addresses are used to communicate > *only* with devices on the local link, and that global addresses (or, > IYL, NATable addresses from Net10 etc.) are used for the "I want to > route to the outside world" cases. I can follow you on this one. > Actually, the draft does imply that IPv4 link-local autoconf is used to > "hunt" DHCP servers that appear after the local host comes up (Section > 4, "Ongoing checks for a DHCP server"). The idea is that your device > gets a link-local address when no globally-routable one (or NATed one) > is discovered, and then runs with it up until a DHCP server (or NAT gw) > becomes available. That is were I can't see the idea any longer. I have a Win98 PC (or a Mac) which supports the autoconf feature - the goal is that the user really can plug an ethernet card into his/hers PC and then the network runs. So we know now that the autoconf function is running pr. default, and the machine will try to get an IP address in the link local range. Now the user plug in his/hers xDSL/ISDN router, with a DHCP server. The PC would have to get a new IP address, just as any other device on the local network! The PCs now have another IP address, and I can access the outside world, but all "old" devices with a link local address (evtentually. manually configured) is not reachable any longer! My point is - why is a link local address range chosen for autoconfig, when the place where the biggest need for the autoconfig option is at the home user with little or no knowledge about network topology etc. ? In this way the home user will see one IP address, and then another IP address - I even fear that some users will turn off the xDSL/ISDN router when it is not needed (everybody talks about standby power consumption)!!!! > If you know by *specification* that the link-local addresses are only ever > going to be seen by local devices, and that routers by *specification* > MUST NOT route/munge/forward packets destined to those addresses, I can > see cases where you can make certain assumptions about the communication > (topological location, security, etc. etc.) that you can't otherwise. For the knowledged user - I agree. -- Regards, Martin Djern�s -------------------------------------------------------------- Martin Djern�s martin.djernaes@kecam-han.de Dipl.-Ing. Alcatel Kommunikations-Elektronik GmbH Tel:+49 (0511) 6747 741 Postfach 3246 Fax:+49 (0511) 6747 777 30032 Hannover, Germany http://www.ke-online.de -------------------------------------------------------------- From owner-zeroconf@merit.edu Fri Apr 14 05:18:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04664 for ; Fri, 14 Apr 2000 05:18:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BAE45DDFB; Fri, 14 Apr 2000 05:16:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 691CA5DDFC; Fri, 14 Apr 2000 05:16:45 -0400 (EDT) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by segue.merit.edu (Postfix) with ESMTP id 540395DDFB for ; Fri, 14 Apr 2000 05:16:43 -0400 (EDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.2/8.9.2) id CAA06717; Fri, 14 Apr 2000 02:15:48 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14582.57795.864351.806259@kitab.cisco.com> Date: Fri, 14 Apr 2000 02:15:47 -0700 (PDT) To: Mark Thompson Cc: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses In-Reply-To: <20000414094047.A1198@ecs.soton.ac.uk> References: <38F6C0FB.2C6B6365@kecam-han.de> <20000414085123.C913@ecs.soton.ac.uk> <38F6D7D4.2E7C2E6D@kecam-han.de> <20000414094047.A1198@ecs.soton.ac.uk> X-Mailer: VM 6.74 under 20.4 "Emerald" XEmacs Lucid Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Thompson writes: > I think the idea is that link-local addresses are used to communicate > *only* with devices on the local link, and that global addresses (or, > IYL, NATable addresses from Net10 etc.) are used for the "I want to > route to the outside world" cases. > > Actually, the draft does imply that IPv4 link-local autoconf is used to > "hunt" DHCP servers that appear after the local host comes up (Section > 4, "Ongoing checks for a DHCP server"). The idea is that your device > gets a link-local address when no globally-routable one (or NATed one) > is discovered, and then runs with it up until a DHCP server (or NAT gw) > becomes available. Unless there's some more recent version of the draft than what I've seen, there's no mention of NAT in the draft at all. It says: Addresses allocated by this mechanism MUST NOT be routed by any net- work device. The addresses are designed to be link local addresses. Link local address are to be, by definition, restricted to the local network segment. Allocation of link-local addresses in an IPv6 net- work is described in [IPv6SAC]. It's quite obvious why one would not want these addresses routed, but there are very good reasons why someone may want to NAT these addresses and there's no mention of whether NATing them is looked upon as "good" or "bad". I see no reason why it should be mandated that NATing these addresses shouldn't be done. I would bet that regardless of what any document says, someone will end up allowing an option of NATing these addresses anyway simply because some customer will demand it. > If you know by *specification* that the link-local addresses are only ever > going to be seen by local devices, and that routers by *specification* > MUST NOT route/munge/forward packets destined to those addresses, I can > see cases where you can make certain assumptions about the communication > (topological location, security, etc. etc.) that you can't otherwise. I think the strongest reason here would probably be security, but even that somewhat fails when one starts thinking of wireless networks. Sounds like a false sense of security to me. /raj From owner-zeroconf@merit.edu Fri Apr 14 05:22:30 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04687 for ; Fri, 14 Apr 2000 05:22:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 598455DDFC; Fri, 14 Apr 2000 05:22:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3F1C75DE01; Fri, 14 Apr 2000 05:22:24 -0400 (EDT) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by segue.merit.edu (Postfix) with ESMTP id 83C745DDFC for ; Fri, 14 Apr 2000 05:22:22 -0400 (EDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.2/8.9.2) id CAA06724; Fri, 14 Apr 2000 02:21:22 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14582.58129.756774.471265@kitab.cisco.com> Date: Fri, 14 Apr 2000 02:21:21 -0700 (PDT) To: "Martin Djernaes" Cc: Mark Thompson , zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses In-Reply-To: <38F6DF0F.9E514217@kecam-han.de> References: <38F6C0FB.2C6B6365@kecam-han.de> <20000414085123.C913@ecs.soton.ac.uk> <38F6D7D4.2E7C2E6D@kecam-han.de> <20000414094047.A1198@ecs.soton.ac.uk> <38F6DF0F.9E514217@kecam-han.de> X-Mailer: VM 6.74 under 20.4 "Emerald" XEmacs Lucid Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Martin Djernaes writes: > The PCs now have another IP address, and I can access the outside world, > but all "old" devices with a link local address (evtentually. manually > configured) is not reachable any longer! Actually, I thought the ultimate idea was for the PC to have two addresses associated with the same interface and thus it would use the link-local to talk to the link-local-only devices while still using the Internet accessible one for communicating to the outside world. > My point is - why is a link local address range chosen for autoconfig, > when the place where the biggest need for the autoconfig option is at > the home user with little or no knowledge about network topology etc. ? This is why I think zeroconf needs to allow for autoconfigured addresses in ranges other than just link-local. Given that there are ways to discover the local network number and mask, a device should be able to do "claim and defend" autoconfiguration in that range as well. /raj From owner-zeroconf@merit.edu Fri Apr 14 07:18:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05747 for ; Fri, 14 Apr 2000 07:18:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E85F65DE0F; Fri, 14 Apr 2000 07:17:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D70F75DE0E; Fri, 14 Apr 2000 07:17:55 -0400 (EDT) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by segue.merit.edu (Postfix) with ESMTP id BF95E5DE0D for ; Fri, 14 Apr 2000 07:17:54 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id HAA00950; Fri, 14 Apr 2000 07:17:42 -0400 Message-Id: <200004141117.HAA00950@hygro.adsl.duke.edu> To: Richard Johnson Cc: Mark Thompson , zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses In-Reply-To: Message from Richard Johnson of "Fri, 14 Apr 2000 02:15:47 PDT." <14582.57795.864351.806259@kitab.cisco.com> Date: Fri, 14 Apr 2000 07:17:42 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > Addresses allocated by this mechanism MUST NOT be routed by any net- > work device. The addresses are designed to be link local addresses. > Link local address are to be, by definition, restricted to the local > network segment. Allocation of link-local addresses in an IPv6 net- > work is described in [IPv6SAC]. > It's quite obvious why one would not want these addresses routed, but > there are very good reasons why someone may want to NAT these > addresses and there's no mention of whether NATing them is looked upon > as "good" or "bad". I see no reason why it should be mandated that > NATing these addresses shouldn't be done. I would bet that regardless > of what any document says, someone will end up allowing an option of > NATing these addresses anyway simply because some customer will demand > it. I suspect that one can certainly get away with NATing link-local addresses in some circumstances. However, there are also new problems in the more general case that don't occur when net 10 addresses are used. For example, if a NAT box has 3 interfaces, one to the Internet and two internal (with link-local addresses being used), then you have the potential problems that link-local addresses on the two internal links are not unique. Thus, a NAT implementation would have to do even more tricks to keep track of which interface a specific NAT state entry belongs to. But one might argue that this is a scenario where the exclusive use of link-local addresses is a bad idea anyway, as the nodes on the two links would have trouble talking to each other anyway. Even in the simple case of 2 interfaces (internal plus Internet) one has to deal with the problem of which interface a given link-local address belongs to. Thomas From owner-zeroconf@merit.edu Fri Apr 14 07:58:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06211 for ; Fri, 14 Apr 2000 07:58:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 67D575DE22; Fri, 14 Apr 2000 07:58:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 564295DE21; Fri, 14 Apr 2000 07:58:29 -0400 (EDT) Received: from smtp01do.de.uu.net (smtp01do.de.uu.net [192.76.144.61]) by segue.merit.edu (Postfix) with ESMTP id 8DE665DE1B for ; Fri, 14 Apr 2000 07:58:27 -0400 (EDT) Received: from bommel.kecam-han.de (garfield.kecam-han.de [193.99.158.1] (may be forged)) by smtp01do.de.uu.net (5.5.5/5.5.5) with ESMTP id NAA23542 for ; Fri, 14 Apr 2000 13:58:26 +0200 (MET DST) Received: from dt.kecam-han.de (dt [192.168.10.1]) by bommel.kecam-han.de (8.9.3/8.9.1) with ESMTP id NAA11847 for ; Fri, 14 Apr 2000 13:58:40 +0200 (MET DST) Received: from mozilla.kecam-han.de (mozilla [10.9.1.6]) by dt.kecam-han.de (8.9.3/8.9.3) with ESMTP id NAA12751 for ; Fri, 14 Apr 2000 13:59:34 +0200 (MET DST) Received: from kecam-han.de ([10.2.1.232]) by mozilla.kecam-han.de (Netscape Messaging Server 3.6) with ESMTP id AAA5CD5; Fri, 14 Apr 2000 13:59:31 +0200 Message-ID: <38F708BC.F1BBB48A@kecam-han.de> Date: Fri, 14 Apr 2000 14:02:04 +0200 From: "Martin Djernaes" Organization: Alcatel Kommunikations-Elektronik GmbH X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,en-US,en-GB,da,de MIME-Version: 1.0 To: Thomas Narten Cc: Richard Johnson , Mark Thompson , zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses References: <200004141117.HAA00950@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Thomas, > Even in the simple case of 2 interfaces (internal plus Internet) one > has to deal with the problem of which interface a given link-local > address belongs to. Why? I am so naive that I expect autoconfig mainly will be used in home (or small) networks, where there is no knowledged "administrator" avalible. When this is said, the majority of the "NAT gateways" will be internet access devices like xDSL and ISDN routers. Here the internet access interface should not use/support the autoconfig option, but use DHCP/IPCP/"Static enty" to obtain a valid internet IP addreess. The only interface with autoconfig is the local LAN (what ever technologi) interface, and here addresses are unique. Martin From owner-zeroconf@merit.edu Fri Apr 14 08:51:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06864 for ; Fri, 14 Apr 2000 08:51:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E73EE5DDA7; Fri, 14 Apr 2000 08:51:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D84145DD9A; Fri, 14 Apr 2000 08:51:46 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by segue.merit.edu (Postfix) with ESMTP id 527835DD8F for ; Fri, 14 Apr 2000 08:51:45 -0400 (EDT) Received: from droms-mac (pm3mi2-12.uplink.net [209.173.86.61]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA11180 for ; Fri, 14 Apr 2000 08:51:43 -0400 (EDT) Message-Id: <4.2.2.20000414084859.00a48bd0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 14 Apr 2000 08:51:19 -0400 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: 169.254/16 IP addresses In-Reply-To: <200004141117.HAA00950@hygro.adsl.duke.edu> References: <14582.57795.864351.806259@kitab.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk There is a small issue with DHCP server discovery related to zeroconf addresses - after a host chooses a link-local autoconfig address, should the host's DHCP client use 0.0.0.0 or the host's link-local address when broadcasting to find a DHCP server? My guess would be 0.0.0.0 - either way, the choice ought to be documented somewhere... - Ralph From owner-zeroconf@merit.edu Fri Apr 14 08:58:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07007 for ; Fri, 14 Apr 2000 08:58:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 05D4D5DDAB; Fri, 14 Apr 2000 08:58:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EAAE75DDAA; Fri, 14 Apr 2000 08:58:11 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by segue.merit.edu (Postfix) with ESMTP id A9D225DD9A for ; Fri, 14 Apr 2000 08:58:10 -0400 (EDT) Received: from leo (leo [134.82.56.108]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA11200 for ; Fri, 14 Apr 2000 08:58:10 -0400 (EDT) Date: Fri, 14 Apr 2000 08:58:10 -0400 (EDT) From: "Ralph E. Droms" X-Sender: droms@leo To: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses In-Reply-To: <4.2.2.20000414084859.00a48bd0@mail.bucknell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Or, I suppose, "don't care" is a viable choice, too. In any event, documenting the choice will preempt questions in the future... On Fri, 14 Apr 2000, Ralph Droms wrote: > There is a small issue with DHCP server discovery related to zeroconf > addresses - after a host chooses a link-local autoconfig address, should > the host's DHCP client use 0.0.0.0 or the host's link-local address when > broadcasting to find a DHCP server? > > My guess would be 0.0.0.0 - either way, the choice ought to be documented > somewhere... > > - Ralph > > > > From owner-zeroconf@merit.edu Fri Apr 14 09:22:47 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07251 for ; Fri, 14 Apr 2000 09:22:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F5875DDA7; Fri, 14 Apr 2000 09:22:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2F7EF5DD9A; Fri, 14 Apr 2000 09:22:40 -0400 (EDT) Received: from mw.3com.com (intergate.usr.com [149.112.20.3]) by segue.merit.edu (Postfix) with ESMTP id BEF295DD8F for ; Fri, 14 Apr 2000 09:22:38 -0400 (EDT) Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id IAA20411; Fri, 14 Apr 2000 08:22:31 -0500 (CDT) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 862568C1.0049A67F ; Fri, 14 Apr 2000 08:24:27 -0500 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Richard Johnson Cc: Mark Thompson , zeroconf@merit.edu Message-ID: <862568C1.0049A4E3.00@mwgate02.mw.3com.com> Date: Fri, 14 Apr 2000 08:24:46 -0500 Subject: Re: 169.254/16 IP addresses Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-zeroconf@merit.edu Precedence: bulk People may be NATing linklocal addresses very soon or already. The problem is that quite a few large customers use private space for their networks, but want customized equipment that can be just dropped in (i.e. a small subnet of logically distinct hosts and routers) and work with no IP configuration. The solution is the linklocal space, with a NAT to the outside world. Choosing any other address space would cause major grief. -Mike Richard Johnson on 04/14/2000 04:15:47 AM Sent by: Richard Johnson To: Mark Thompson cc: zeroconf@merit.edu (Mike Borella/MW/US/3Com) Subject: Re: 169.254/16 IP addresses Mark Thompson writes: > I think the idea is that link-local addresses are used to communicate > *only* with devices on the local link, and that global addresses (or, > IYL, NATable addresses from Net10 etc.) are used for the "I want to > route to the outside world" cases. > > Actually, the draft does imply that IPv4 link-local autoconf is used to > "hunt" DHCP servers that appear after the local host comes up (Section > 4, "Ongoing checks for a DHCP server"). The idea is that your device > gets a link-local address when no globally-routable one (or NATed one) > is discovered, and then runs with it up until a DHCP server (or NAT gw) > becomes available. Unless there's some more recent version of the draft than what I've seen, there's no mention of NAT in the draft at all. It says: Addresses allocated by this mechanism MUST NOT be routed by any net- work device. The addresses are designed to be link local addresses. Link local address are to be, by definition, restricted to the local network segment. Allocation of link-local addresses in an IPv6 net- work is described in [IPv6SAC]. It's quite obvious why one would not want these addresses routed, but there are very good reasons why someone may want to NAT these addresses and there's no mention of whether NATing them is looked upon as "good" or "bad". I see no reason why it should be mandated that NATing these addresses shouldn't be done. I would bet that regardless of what any document says, someone will end up allowing an option of NATing these addresses anyway simply because some customer will demand it. > If you know by *specification* that the link-local addresses are only ever > going to be seen by local devices, and that routers by *specification* > MUST NOT route/munge/forward packets destined to those addresses, I can > see cases where you can make certain assumptions about the communication > (topological location, security, etc. etc.) that you can't otherwise. I think the strongest reason here would probably be security, but even that somewhat fails when one starts thinking of wireless networks. Sounds like a false sense of security to me. /raj From owner-zeroconf@merit.edu Fri Apr 14 09:25:22 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07292 for ; Fri, 14 Apr 2000 09:25:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C13215DDAA; Fri, 14 Apr 2000 09:25:13 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B13845DD9A; Fri, 14 Apr 2000 09:25:13 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 96BCE5DD8F for ; Fri, 14 Apr 2000 09:25:12 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e3EDP1h28778; Fri, 14 Apr 2000 09:25:01 -0400 Message-ID: <38F71C21.3E5A8D7D@senie.com> Date: Fri, 14 Apr 2000 09:24:49 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ralph Droms Cc: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses References: <14582.57795.864351.806259@kitab.cisco.com> <4.2.2.20000414084859.00a48bd0@mail.bucknell.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph Droms wrote: > > There is a small issue with DHCP server discovery related to zeroconf > addresses - after a host chooses a link-local autoconfig address, should > the host's DHCP client use 0.0.0.0 or the host's link-local address when > broadcasting to find a DHCP server? > > My guess would be 0.0.0.0 - either way, the choice ought to be documented > somewhere... Operational experience in a mixed datacenter: various platforms do a variety of things. This is bad. If a host is running DHCP to get an address, and has not received such an address from a DHCP server (any DHCP server) then it should use 0.0.0.0. It didn't get the 169.254/16 address from a DHCP server, and thus the DHCP packets sent to a server should be from 0.0.0.0. There are good reasons: 1. The DHCP server could have multiple interfaces on multiple networks. In this case, a link-local address may be somewhat ambiguous. Depending on how the DHCP software is implemented on the server, it may be difficult to communicate back to the client. 2. Stronger reason: DHCP Relay. This is a function implemented in routers. Since routers may well know that 169.254/16 is link local, the DHCP packets are less likely to reach the DHCP Relay code in the router, whereas the 0.0.0.0 sourced ones will be recognized. I agree this should all be documented. I'm willing to write it up if an appropriate WG is willing to sponsor it. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Fri Apr 14 09:27:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07323 for ; Fri, 14 Apr 2000 09:27:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A987F5DDAB; Fri, 14 Apr 2000 09:27:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 995AB5DD9A; Fri, 14 Apr 2000 09:27:05 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 814EF5DD8F for ; Fri, 14 Apr 2000 09:27:04 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e3EDR2h28789; Fri, 14 Apr 2000 09:27:02 -0400 Message-ID: <38F71CA3.B3211F75@senie.com> Date: Fri, 14 Apr 2000 09:26:59 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Borella Cc: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses References: <862568C1.0049A4E3.00@mwgate02.mw.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mike Borella wrote: > > People may be NATing linklocal addresses very soon or already. The problem > is that quite a few large customers use private space for their networks, but > want customized equipment that can be just dropped in (i.e. a small subnet > of logically distinct hosts and routers) and work with no IP configuration. > The solution is the linklocal space, with a NAT to the outside world. Choosing > any > other address space would cause major grief. What method is being used in these cases for discovering the NAT box? I can think of a few ways to do it, but am curious what products are doing this, and which mechanism(s) are used for the discovery. > > -Mike > > Richard Johnson on 04/14/2000 04:15:47 AM > > Sent by: Richard Johnson > > To: Mark Thompson > cc: zeroconf@merit.edu (Mike Borella/MW/US/3Com) > Subject: Re: 169.254/16 IP addresses > > Mark Thompson writes: > > I think the idea is that link-local addresses are used to communicate > > *only* with devices on the local link, and that global addresses (or, > > IYL, NATable addresses from Net10 etc.) are used for the "I want to > > route to the outside world" cases. > > > > Actually, the draft does imply that IPv4 link-local autoconf is used to > > "hunt" DHCP servers that appear after the local host comes up (Section > > 4, "Ongoing checks for a DHCP server"). The idea is that your device > > gets a link-local address when no globally-routable one (or NATed one) > > is discovered, and then runs with it up until a DHCP server (or NAT gw) > > becomes available. > > Unless there's some more recent version of the draft than what I've > seen, there's no mention of NAT in the draft at all. It says: > > Addresses allocated by this mechanism MUST NOT be routed by any net- > work device. The addresses are designed to be link local addresses. > Link local address are to be, by definition, restricted to the local > network segment. Allocation of link-local addresses in an IPv6 net- > work is described in [IPv6SAC]. > > It's quite obvious why one would not want these addresses routed, but > there are very good reasons why someone may want to NAT these > addresses and there's no mention of whether NATing them is looked upon > as "good" or "bad". I see no reason why it should be mandated that > NATing these addresses shouldn't be done. I would bet that regardless > of what any document says, someone will end up allowing an option of > NATing these addresses anyway simply because some customer will demand > it. > > > If you know by *specification* that the link-local addresses are only ever > > going to be seen by local devices, and that routers by *specification* > > MUST NOT route/munge/forward packets destined to those addresses, I can > > see cases where you can make certain assumptions about the communication > > (topological location, security, etc. etc.) that you can't otherwise. > > I think the strongest reason here would probably be security, but even > that somewhat fails when one starts thinking of wireless networks. > Sounds like a false sense of security to me. > > /raj -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Fri Apr 14 11:41:06 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09206 for ; Fri, 14 Apr 2000 11:41:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D03805DD8F; Fri, 14 Apr 2000 11:40:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BD6725DDA3; Fri, 14 Apr 2000 11:40:55 -0400 (EDT) Received: from mw.3com.com (intergate.usr.com [149.112.20.3]) by segue.merit.edu (Postfix) with ESMTP id D58145DD8F for ; Fri, 14 Apr 2000 11:40:53 -0400 (EDT) Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id KAA00622; Fri, 14 Apr 2000 10:40:42 -0500 (CDT) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 862568C1.00564B95 ; Fri, 14 Apr 2000 10:42:34 -0500 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Daniel Senie Cc: zeroconf@merit.edu Message-ID: <862568C1.0056497B.00@mwgate02.mw.3com.com> Date: Fri, 14 Apr 2000 10:42:52 -0500 Subject: Re: 169.254/16 IP addresses Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-zeroconf@merit.edu Precedence: bulk NAT boxes don't need to be discovered, especially on these 1-hop subnets. -Mike Daniel Senie on 04/14/2000 08:26:59 AM Sent by: Daniel Senie To: Mike Borella/MW/US/3Com cc: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses Mike Borella wrote: > > People may be NATing linklocal addresses very soon or already. The problem > is that quite a few large customers use private space for their networks, but > want customized equipment that can be just dropped in (i.e. a small subnet > of logically distinct hosts and routers) and work with no IP configuration. > The solution is the linklocal space, with a NAT to the outside world. Choosing > any > other address space would cause major grief. What method is being used in these cases for discovering the NAT box? I can think of a few ways to do it, but am curious what products are doing this, and which mechanism(s) are used for the discovery. > > -Mike > > Richard Johnson on 04/14/2000 04:15:47 AM > > Sent by: Richard Johnson > > To: Mark Thompson > cc: zeroconf@merit.edu (Mike Borella/MW/US/3Com) > Subject: Re: 169.254/16 IP addresses > > Mark Thompson writes: > > I think the idea is that link-local addresses are used to communicate > > *only* with devices on the local link, and that global addresses (or, > > IYL, NATable addresses from Net10 etc.) are used for the "I want to > > route to the outside world" cases. > > > > Actually, the draft does imply that IPv4 link-local autoconf is used to > > "hunt" DHCP servers that appear after the local host comes up (Section > > 4, "Ongoing checks for a DHCP server"). The idea is that your device > > gets a link-local address when no globally-routable one (or NATed one) > > is discovered, and then runs with it up until a DHCP server (or NAT gw) > > becomes available. > > Unless there's some more recent version of the draft than what I've > seen, there's no mention of NAT in the draft at all. It says: > > Addresses allocated by this mechanism MUST NOT be routed by any net- > work device. The addresses are designed to be link local addresses. > Link local address are to be, by definition, restricted to the local > network segment. Allocation of link-local addresses in an IPv6 net- > work is described in [IPv6SAC]. > > It's quite obvious why one would not want these addresses routed, but > there are very good reasons why someone may want to NAT these > addresses and there's no mention of whether NATing them is looked upon > as "good" or "bad". I see no reason why it should be mandated that > NATing these addresses shouldn't be done. I would bet that regardless > of what any document says, someone will end up allowing an option of > NATing these addresses anyway simply because some customer will demand > it. > > > If you know by *specification* that the link-local addresses are only ever > > going to be seen by local devices, and that routers by *specification* > > MUST NOT route/munge/forward packets destined to those addresses, I can > > see cases where you can make certain assumptions about the communication > > (topological location, security, etc. etc.) that you can't otherwise. > > I think the strongest reason here would probably be security, but even > that somewhat fails when one starts thinking of wireless networks. > Sounds like a false sense of security to me. > > /raj -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Fri Apr 14 11:51:27 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09363 for ; Fri, 14 Apr 2000 11:51:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEA725DDAB; Fri, 14 Apr 2000 11:51:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE5585DDA7; Fri, 14 Apr 2000 11:51:19 -0400 (EDT) Received: from mw.3com.com (intergate.usr.com [149.112.20.3]) by segue.merit.edu (Postfix) with ESMTP id D752F5DDA3 for ; Fri, 14 Apr 2000 11:51:17 -0400 (EDT) Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id KAA01784; Fri, 14 Apr 2000 10:50:54 -0500 (CDT) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 862568C1.0057397E ; Fri, 14 Apr 2000 10:52:43 -0500 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Thomas Narten Cc: Richard Johnson , Mark Thompson , zeroconf@merit.edu Message-ID: <862568C1.00573960.00@mwgate02.mw.3com.com> Date: Fri, 14 Apr 2000 10:53:07 -0500 Subject: Re: 169.254/16 IP addresses Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-zeroconf@merit.edu Precedence: bulk In the 3 interface case, the NAT can map on the MAC. Some NATs allow this. It is a poor way of configuring a network, however, I wouldn't be surprised to see it happen. -Mike Thomas Narten on 04/14/2000 06:17:42 AM Sent by: Thomas Narten To: Richard Johnson cc: Mark Thompson , zeroconf@merit.edu (Mike Borella/MW/US/3Com) Subject: Re: 169.254/16 IP addresses > Addresses allocated by this mechanism MUST NOT be routed by any net- > work device. The addresses are designed to be link local addresses. > Link local address are to be, by definition, restricted to the local > network segment. Allocation of link-local addresses in an IPv6 net- > work is described in [IPv6SAC]. > It's quite obvious why one would not want these addresses routed, but > there are very good reasons why someone may want to NAT these > addresses and there's no mention of whether NATing them is looked upon > as "good" or "bad". I see no reason why it should be mandated that > NATing these addresses shouldn't be done. I would bet that regardless > of what any document says, someone will end up allowing an option of > NATing these addresses anyway simply because some customer will demand > it. I suspect that one can certainly get away with NATing link-local addresses in some circumstances. However, there are also new problems in the more general case that don't occur when net 10 addresses are used. For example, if a NAT box has 3 interfaces, one to the Internet and two internal (with link-local addresses being used), then you have the potential problems that link-local addresses on the two internal links are not unique. Thus, a NAT implementation would have to do even more tricks to keep track of which interface a specific NAT state entry belongs to. But one might argue that this is a scenario where the exclusive use of link-local addresses is a bad idea anyway, as the nodes on the two links would have trouble talking to each other anyway. Even in the simple case of 2 interfaces (internal plus Internet) one has to deal with the problem of which interface a given link-local address belongs to. Thomas From owner-zeroconf@merit.edu Fri Apr 14 12:56:33 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10723 for ; Fri, 14 Apr 2000 12:56:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C3A25DDEB; Fri, 14 Apr 2000 12:56:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7C12F5DDA7; Fri, 14 Apr 2000 12:56:21 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 918E35DDA3 for ; Fri, 14 Apr 2000 12:56:17 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA47741; Fri, 14 Apr 2000 09:42:30 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Mark Thompson'" , Subject: RE: 169.254/16 IP addresses Date: Fri, 14 Apr 2000 10:00:21 -0700 Message-ID: <000e01bfa632$ed48f3a0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20000414094047.A1198@ecs.soton.ac.uk> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 10:33(GMT) 14-04-00, Martin Djernaes wrote: > Hi Mark, > > That is also fine that the address group is link local, but why > shouldn't it be used as source for a outgoing connection via a NA(P)T > gateway? The original purpose of auto-configuration was adhoc networks, not networks with a router. I would note that linklocal behavior applies not only to unicast but also to multicast; routers should not forward packets from linklocal addresses off the link even if they are sent to a global scope multicast address. This is useful in preventing hosts with linklocal scope addresses from interacting globally. From owner-zeroconf@merit.edu Fri Apr 14 13:03:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10884 for ; Fri, 14 Apr 2000 13:03:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E90E05DDA7; Fri, 14 Apr 2000 13:00:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D2FB15DDA3; Fri, 14 Apr 2000 13:00:23 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id B9E885DDFA for ; Fri, 14 Apr 2000 13:00:17 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA47748; Fri, 14 Apr 2000 09:46:11 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Thomas Narten'" , "'Richard Johnson'" Cc: "'Mark Thompson'" , Subject: RE: 169.254/16 IP addresses Date: Fri, 14 Apr 2000 10:04:19 -0700 Message-ID: <000f01bfa633$7a245e90$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200004141117.HAA00950@hygro.adsl.duke.edu> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I suspect that one can certainly get away with NATing link-local >addresses in some circumstances. This can lead to undefined behavior in some circumstances. Suppose I sent to a global multicast address from a linklocal address. What is the expected behavior? Does the router NAT the source address and forward it so that the multicast now has global scope? Or does the router not forward the multicast so it is effectively linklocal scope? One of the reasons we created a linklocal prefix was so that we could get behavior different from private addressing for situations where this made sense. If we blur the distinction then we'll lose the ability to have truly linklocal behavior when we need it. From owner-zeroconf@merit.edu Fri Apr 14 17:14:28 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14585 for ; Fri, 14 Apr 2000 17:14:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE8815DDEB; Fri, 14 Apr 2000 17:14:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CF3475DDA3; Fri, 14 Apr 2000 17:14:14 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 8D9275DD8D for ; Fri, 14 Apr 2000 17:14:13 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.0/8.10.0) with ESMTP id e3ELE8h31092; Fri, 14 Apr 2000 17:14:08 -0400 Message-ID: <38F78A1F.95B93417@senie.com> Date: Fri, 14 Apr 2000 17:14:07 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Borella Cc: zeroconf@merit.edu Subject: Re: 169.254/16 IP addresses References: <862568C1.0056497B.00@mwgate02.mw.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mike Borella wrote: > > NAT boxes don't need to be discovered, especially on these 1-hop > subnets. First client workstation self-assigns an address of 169.254.34.199. Second client self assigns 169.254.250.12. The NAT box self-assigns 169.254.99.123. The IP stacks on the clients need to have a default gateway set to know they should route packets somewhere if the destination is not on the local net (a /16 in this case). How do you propose the default route gets set? If it doesn't get set, no packets will be sent to a NAT box or anywhere else. Some sort of discovery is thus necessary. This could be ICMP router discovery, for example, but the answer can't be "NAT boxes don't need to be discovered." This isn't a point-to-point link where you can assume the box on the other end of the wire is your default gateway. > Daniel Senie on 04/14/2000 08:26:59 AM > > Sent by: Daniel Senie > > To: Mike Borella/MW/US/3Com > cc: zeroconf@merit.edu > Subject: Re: 169.254/16 IP addresses > > Mike Borella wrote: > > > > People may be NATing linklocal addresses very soon or already. The problem > > is that quite a few large customers use private space for their networks, but > > want customized equipment that can be just dropped in (i.e. a small subnet > > of logically distinct hosts and routers) and work with no IP configuration. > > The solution is the linklocal space, with a NAT to the outside world. > Choosing > > any > > other address space would cause major grief. > > What method is being used in these cases for discovering the NAT box? I > can think of a few ways to do it, but am curious what products are doing > this, and which mechanism(s) are used for the discovery. > > > > > -Mike > > > > Richard Johnson on 04/14/2000 04:15:47 AM > > > > Sent by: Richard Johnson > > > > To: Mark Thompson > > cc: zeroconf@merit.edu (Mike Borella/MW/US/3Com) > > Subject: Re: 169.254/16 IP addresses > > > > Mark Thompson writes: > > > I think the idea is that link-local addresses are used to communicate > > > *only* with devices on the local link, and that global addresses (or, > > > IYL, NATable addresses from Net10 etc.) are used for the "I want to > > > route to the outside world" cases. > > > > > > Actually, the draft does imply that IPv4 link-local autoconf is used to > > > "hunt" DHCP servers that appear after the local host comes up (Section > > > 4, "Ongoing checks for a DHCP server"). The idea is that your device > > > gets a link-local address when no globally-routable one (or NATed one) > > > is discovered, and then runs with it up until a DHCP server (or NAT gw) > > > becomes available. > > > > Unless there's some more recent version of the draft than what I've > > seen, there's no mention of NAT in the draft at all. It says: > > > > Addresses allocated by this mechanism MUST NOT be routed by any net- > > work device. The addresses are designed to be link local addresses. > > Link local address are to be, by definition, restricted to the local > > network segment. Allocation of link-local addresses in an IPv6 net- > > work is described in [IPv6SAC]. > > > > It's quite obvious why one would not want these addresses routed, but > > there are very good reasons why someone may want to NAT these > > addresses and there's no mention of whether NATing them is looked upon > > as "good" or "bad". I see no reason why it should be mandated that > > NATing these addresses shouldn't be done. I would bet that regardless > > of what any document says, someone will end up allowing an option of > > NATing these addresses anyway simply because some customer will demand > > it. > > > > > If you know by *specification* that the link-local addresses are only ever > > > going to be seen by local devices, and that routers by *specification* > > > MUST NOT route/munge/forward packets destined to those addresses, I can > > > see cases where you can make certain assumptions about the communication > > > (topological location, security, etc. etc.) that you can't otherwise. > > > > I think the strongest reason here would probably be security, but even > > that somewhat fails when one starts thinking of wireless networks. > > Sounds like a false sense of security to me. > > > > /raj > > -- > ----------------------------------------------------------------- > Daniel Senie dts@senie.com > Amaranth Networks Inc. http://www.amaranth.com -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Fri Apr 14 17:18:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14627 for ; Fri, 14 Apr 2000 17:18:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 989C05DD8D; Fri, 14 Apr 2000 17:15:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 83E1D5DDFA; Fri, 14 Apr 2000 17:15:40 -0400 (EDT) Received: from dieselmeat.bucknell.edu (jgoldsch.resnet.bucknell.edu [134.82.88.3]) by segue.merit.edu (Postfix) with ESMTP id 23E785DD8D for ; Fri, 14 Apr 2000 17:15:39 -0400 (EDT) Received: from localhost (jgoldsch@localhost) by dieselmeat.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA24189 for ; Fri, 14 Apr 2000 17:15:20 -0400 X-Authentication-Warning: dieselmeat.bucknell.edu: jgoldsch owned process doing -bs Date: Fri, 14 Apr 2000 17:15:20 -0400 (EDT) From: Jason Goldschmidt X-Sender: jgoldsch@dieselmeat To: zeroconf@merit.edu Subject: linklocal + DHCP servers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk When a DHCP server comes up on a zeroconf network, are link-local configured devices considered as configured devices to the DHCP server? Or in other words: There is a zeroconf device that has configured itself w/ a link-local address. Can that device, send a DHCPREQUEST for its link-local address? And if so, what should the DHCP server do with that address request? A server might want to allow the zeroconf device to keep the address and then respond w/ additional configuration information in the subsequent DHCPACK. Though, doing so would still bring up the problems that Bernard just mentioned about NATing for link-local addresses. Thanks, -Jason *************************************) Jason Goldschmidt jgoldsch@acm.org *) http://coral.bucknell.edu/~jgoldsch *) "My Reality Check Bounced" *) -Scott Adams *) *************************************) From owner-zeroconf@merit.edu Fri Apr 14 18:38:25 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15275 for ; Fri, 14 Apr 2000 18:38:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DF3D5DDFC; Fri, 14 Apr 2000 18:38:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 22D635DDA7; Fri, 14 Apr 2000 18:38:19 -0400 (EDT) Received: from mw.3com.com (intergate.usr.com [149.112.20.3]) by segue.merit.edu (Postfix) with ESMTP id BBA4D5DDA3 for ; Fri, 14 Apr 2000 18:38:17 -0400 (EDT) Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id RAA02250; Fri, 14 Apr 2000 17:38:12 -0500 (CDT) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 862568C1.007C843D ; Fri, 14 Apr 2000 17:40:03 -0500 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Daniel Senie Cc: zeroconf@merit.edu Message-ID: <862568C1.007C8341.00@mwgate02.mw.3com.com> Date: Fri, 14 Apr 2000 17:40:25 -0500 Subject: Re: 169.254/16 IP addresses Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-zeroconf@merit.edu Precedence: bulk Oops, knee-jerk reaction on my part. Some people have been claiming that apps should be NAT aware and "discover" the NAT. I misread the email. You're right about the ARP issues, of course. -Mike Daniel Senie