Subject: [homenet] security question for zeroconf stuff inside the homenet...

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Oct 2011 23:13:37 +0100

Hi,

I've been reading the list with interest and have a question.

When various devices in the home figure out which does what,
and do that periodically to handle changes, there's clearly
the potential that a zombied host tries to try take over
stuff with undesirable consequences.

My question is whether this group are planning to think
about that now, or later, or never? (Or don't even think
there's a problem worth attempting to address.)

Note - I'm not trying to argue for any particular level of
security and certainly not for some unachievable fort knox
everywhere, I'm just asking what's the plan?

S.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Oct 2011 21:03:41 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:
    Stephen> I've been reading the list with interest and have a question.

    Stephen> When various devices in the home figure out which does what,
    Stephen> and do that periodically to handle changes, there's clearly
    Stephen> the potential that a zombied host tries to try take over
    Stephen> stuff with undesirable consequences.

We have throught about this.

    Stephen> My question is whether this group are planning to think
    Stephen> about that now, or later, or never? (Or don't even think
    Stephen> there's a problem worth attempting to address.)

We think that the most sophisticated security we can hope for is that
all pieces of equipment can be provided with a "network password"
For devices which have WIFI, this will essentially be the WPA/PSK key,
but used to key other protocols as well.

However, I am thinking that we can perhaps bootstrap equipment that has
never been configured (or has been factory reset) in some fashion such
that if the equipment is "virginal" that it can essentially always try
some default keys, and bring up enough networking to let all equipment
be discovered and identified.  There would be strong nag screens to get
the user to up a network password.

At this point, I think that many users are used to having a network
password. 

    Stephen> Note - I'm not trying to argue for any particular level of
    Stephen> security and certainly not for some unachievable fort knox
    Stephen> everywhere, I'm just asking what's the plan?

I agree: we need something.  It needs to be just enough, and it's okay
if there are ways of subverting the system if you have physical access.

Having said that, I'd like to see optional (MAY) support for stronger
systems, for the Bill Gates-type/Yari Arko-type home...

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Oct 2011 21:38:18 -0400

> the user to up a network password.

A pre-shared key that is pre-shared to every device is the same as no key.   So you might as well not bother with that complexity.   Conceivably CGA could be used to publish public/private key pairs allowing devices to automatically recognize each other and present their relationships in a UI for the end user to approve, but that's not precisely plug and play.

I think the simplest thing would be to require that each device be able to talk to a USB drive.   Each device collects all the public keys on the USB drive, and stores their own there.   Devices then share their public key with other devices identified on the USB drive, so that as each device joins the network, the other devices learn about it.   This isn't bulletproof—an infected PC that's configured with these keys could be used to gain access to the keys, for example.   But it's a lot better than a well-known key.

Of course, this isn't quite as plug and play as you seem to want, and it requires that each device have a USB port, which might not be acceptable.   Plus, it would mean that the IETF would have to talk about hardware, which seems like a bit of a non-starter.   But I think it's the right way to solve the problem.

---

From: Joel jaeggli <[email-masked]>
Date: Tue, 11 Oct 2011 18:45:13 -0700

On 10/11/11 18:38 , Ted Lemon wrote:
> A pre-shared key that is pre-shared to every device is the same as no
> key. 

Not really, it could serve an important hygenic function, notionaly, it
could be filtered by default on all non-home-network gear. that is
serves the purpose of identifying a well-known-service. there are of
course other perhaps better ways to implment that.

>  So you might as well not bother with that complexity.  
> Conceivably CGA could be used to publish public/private key pairs
> allowing devices to automatically recognize each other and present their
> relationships in a UI for the end user to approve, but that's not
> precisely plug and play.
> 
> I think the simplest thing would be to require that each device be able
> to talk to a USB drive.   Each device collects all the public keys on
> the USB drive, and stores their own there.   Devices then share their
> public key with other devices identified on the USB drive, so that as
> each device joins the network, the other devices learn about it.   This
> isn't bulletproof—an infected PC that's configured with these keys could
> be used to gain access to the keys, for example.   But it's a lot better
> than a well-known key.
> 
> Of course, this isn't quite as plug and play as you seem to want, and it
> requires that each device have a USB port, which might not be
> acceptable.   Plus, it would mean that the IETF would have to talk about
> hardware, which seems like a bit of a non-starter.   But I think it's
> the right way to solve the problem.
> 
> 
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Riccardo Bernardini <[email-masked]>
Date: Wed, 12 Oct 2011 10:37:58 +0200

2011/10/12 Joel jaeggli <[email-masked]>

> > be used to gain access to the keys, for example.   But it's a lot better

What about ID-based signature?

Just improvising (so forgive me for any naivety): the ID of the device could
be a triplet (producer-ID, product-ID, serial-number); the "key generator"
could be the producer itself (avoiding in this way the key escrow problem
related to ID-based cryptography) and a certificate with the public key of
the producer could be downloadable from some well-known host (alternatively,
the key of most known producers could be "built in" the device).

The authentication procedure would follow  the usual challenge scheme: the
device receives a challenge string, it appends to it a nonce and signs the
result with its private key (hardwired at production time).  If the
authentication is positive, then you know that you are talking to that type
of device, produced by that producer (if you trust the producer is another
matter).  Of course, this simple scheme would fall to a device-in-the-middle
attack, but maybe in this  context it is not a likely attack.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Oct 2011 10:48:00 +0200

> everywhere, I'm just asking what's the plan?

can we explore some fundamental principles of how and what we need to "secure"?

using the electricity network as an analogy, can we make a distinction between "safety" and "security"?
the electricity network in the home is somewhat self protecting with breakers and earthing.
a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks
and so on.

I don't think it is the networks job to control who has access to the pictures of my grandmother or who can print to my printer. that's application policy.

is it the networks job to control who has access to the network? no, I think that is a layer 2 function.

I think homenet should focus on L3. (and be clear on what it expects from the other layers with regards to security).

cheers,
Ole

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Oct 2011 10:23:32 +0100

> I think homenet should focus on L3. (and be clear on what it expects from the other layers with regards to security).

Reasonable points. However, if the zeroconf stuff provides an easy
way for a bad device to take over the homenet and get everything
interesting routed via it, that seems like a bad thing. That's
really what I was asking about, not application layer security,
nor layer 2 (though some layer 2 security can probably help a bit
if its turned on).

Again, I'm not asking for some complex new scheme to be invented
here, I'm just asking whether the group are planning to address
this issue and roughly when. (In the hope that the answers are
something close to "yes" and "as an integrated part of the work":-)

S.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Oct 2011 08:33:19 -0400

> a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks

I am highly sympathetic to the desire not to try to solve this problem.   However, unfortunately network topology isn't the same as electrical topology, for a couple of reasons.

The first reason is that electrical systems are generally set up by professionals.   Yes, you plug devices into the electrical wiring of your house, but someone skilled set it up (or if not, I hope you sleep in asbestos pajamas).   The devices we are talking about are more analogous to circuit distribution panels than to toasters.

The second reason is that electrical systems are essentially topology-free.   Any point on the system is essentially equivalent to any other.   This is not true of a home network with routing.   What we are talking about is essentially the possibility of rogue distribution panels intentionally or accidentally being connected to your distribution system.   

Which is a result of the third reason: home networks are typically wireless, or partially wireless, and so there is no physical security, unlike an electrical network in a house, which is secure by virtue of being entirely enclosed by the house.

I think what you are getting at is that we cannot be responsible for securing the network.   And that is probably true.   But if the system doesn't have a built-in mechanism for distinguishing between friend and stranger, the autoconfiguration mechanism will create topologies that aren't desired, either by accident or because a stranger wants access to the network.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Oct 2011 14:46:25 +0200

Ted,

> I think what you are getting at is that we cannot be responsible for securing the network.   And that is probably true.   But if the system doesn't have a built-in mechanism for distinguishing betw…

I do agree with that.
I think we can figure out a way of "pairing" devices. whatever layer that ends up being done at.
it will be much more difficult to protect against hostiles injecting default routes, or pretending to be DHCP servers and so on.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Oct 2011 13:50:25 -0400

> it will be much more difficult to protect against hostiles injecting default routes, or pretending to be DHCP servers and so on.

I think pairing and general network security are largely the same problem.   Of course if someone is granted access to the network, they can then inject routes or pretend to be a DHCP server, but that's not the issue I'm concerned with.   I'm more concerned with the scenario Jim Gettys talked about in a subsequent message, where a bunch of things clump together and start talking to each other essentially accidentally.   And of course I'm also somewhat concerned about attackers, although I think that's probably going to happen less often than accidental clumping.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 16:39:30 -0700

In message <[email-masked]>
 
> everywhere, I'm just asking what's the plan?

Watch out for autoconfig of microphones and cameras.  :-)

I call it bonding.  Some ritual has to be performed before specific
types of devices trust each other.  Like the garage door opener and
the clicker thingie.  Same should be true of the audio system and the
wireless speakers.  The TV and remote use IR.  The routers just route,
but they need to be a bit more picky about who can configure them.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 17:51:01 -0700

In message <[email-masked]>
Ted Lemon writes:
 
> key.  So you might as well not bother with that complexity.
> allowing devices to automatically recognize each other and present
> their relationships in a UI for the end user to approve, but that's
> not precisely plug and play.

Agree completely on this.

For example, having bumping the factory default button on a wireless
camera open access to everyone would really be a bad idea.

> I think the simplest thing would be to require that each device be
> able to talk to a USB drive.  Each device collects all the public keys
> on the USB drive, and stores their own there.  Devices then share
> their public key with other devices identified on the USB drive, so
> that as each device joins the network, the other devices learn about
> it.  This isn't bulletproof=97an infected PC that's configured with
> these keys could be used to gain access to the keys, for example.  But
> it's a lot better than a well-known key.
>  
> Of course, this isn't quite as plug and play as you seem to want, and
> it requires that each device have a USB port, which might not be
> acceptable.  Plus, it would mean that the IETF would have to talk
> about hardware, which seems like a bit of a non-starter.  But I think
> it's the right way to solve the problem.

Mandating USB is not practical.

For example I have a set of DECT phones with a single SIP base
station.  You can bond the phone to the base station but you have to
enter a menu on the phone and do something on the base station
(through the web interface or otherwise) within 10 seconds.  Not
perfect, but it works.

There are too many cases like bonding the garage door opener to the
clicker, or bonding the speakers to the audio system, etc, don't need
to store keys on a USB as a boot strap.  For some things USB would be
fine.

And my water heater, as facinating as it might be to the electrical
utility, need not have the key to my garage door opener or my audio
speakers, even though I might want to turn the hot water up or down a
few degrees through a remote device some day.

I would say that reinventing the kerberos KDC with ticket granting
tickets and service tickets is probably overkill and should be out of
scope.  But it would be a truly wonderful thing if the interface could
be made simple enough for a consumer to set up.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 18:36:50 -0700

> can we explore some fundamental principles of how and what we need to

Yes.  Please do.

> using the electricity network as an analogy, can we make a distinction
> between "safety" and "security"?  the electricity network in the home
> is somewhat self protecting with breakers and earthing.  a home
> network must protect 'itself', i.e. handle any device plugged into it,
> in any topology, external and internal attacks and so on.
>  
> I don't think it is the networks job to control who has access to the
> pictures of my grandmother or who can print to my printer. that's
> application policy.

Exactly.  This is a multi-decade old debate.

Should the applications be insecure and rely on a firewall?
(Microsoft advocated this in the 1990s and it has stuck to a large
extent).  Or should the network be open and the applications secure?

I'm strongly with you on this.  The applications should take care of
any security that is necessary *for that application*.

> think that is a layer 2 function.

No. No. No.

Security is not a layer-2 function.  Security is an application
function.  You had it right the first time.  Key exchanges and
certificates are not layer-2 functions.

It is entirely possible that the same computer has pictures of Grandma
that I'm OK with you seeing and has a printer hanging off it that I
don't want anyone in the world to be able to print on.  Same MAC
address.  So that can't be a layer-2 function.

And port filtering at a firewall is a lame excuse for security.  The
bug in relying on a firewall in an enterprise (a little less so for a
home) is that once any one user downloads malware, that malware has
access to everthing behind the firewall largely because of the
assumption that security is not needed because there is a firewall.

Lets not enshine the dumbest practices of the IT world.

> I think homenet should focus on L3. (and be clear on what it expects
> from the other layers with regards to security).
>  
> cheers,
> Ole

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 19:07:28 -0700

In message <[email-masked]>
 
> something close to "yes" and "as an integrated part of the work":-)

You concern may boil down to.

  Should we be worried that Grandma is still running Windows 98?

  [Or that the same company that gave us Windows 95 and 98 can't get
  their act together with security after being beat up about it for
  over a decade.]

Application layer security over a sound foundation is the right place
for security.  A practical consequence of horribly insecure OS code
from one major supplier for more than a decade is that firewall
functionality is also more than just nice to have in enterprise and
home network equipment.

OTOH - If the PC user runs flash for example, there is no way the
network can protect them from the myriad of security holes that keep
popping up and getting fixed all too slowly.  ... and then there are
the discount brokerages that run flash on their web sites insuring
that their users will have flash installed and enabled and probably
won't disable it when going elsewhere on the web.  [oh well].

The network cannot protect the world from really bad application (or
OS) programmers.  Recognizing this may be a first step to solving it
the right way - with a robust OS and more secure applications.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Oct 2011 19:57:18 -0700

In message <[email-masked]>
Ted Lemon writes:
 
> > using the electricity network as an analogy, can we make a
> > distinction between "safety" and "security"?
> > a home network must protect 'itself', i.e. handle any device plugged
> >into it, in any topology, external and internal attacks
> > and so on.
>  
> I am highly sympathetic to the desire not to try to solve this
> problem.  However, unfortunately network topology isn't the same as
> electrical topology, for a couple of reasons.
>  
> The first reason is that electrical systems are generally set up by
> professionals.  Yes, you plug devices into the electrical wiring of
> your house, but someone skilled set it up (or if not, I hope you sleep
> in asbestos pajamas).  The devices we are talking about are more
> analogous to circuit distribution panels than to toasters.
>  
> The second reason is that electrical systems are essentially
> topology-free.  Any point on the system is essentially equivalent to
> any other.  This is not true of a home network with routing.  What we
> are talking about is essentially the possibility of rogue distribution
> panels intentionally or accidentally being connected to your
> distribution system.  =20

The electricity analogy is not very useful.  Maybe best to drop it.

> Which is a result of the third reason: home networks are typically
> wireless, or partially wireless, and so there is no physical security,
> unlike an electrical network in a house, which is secure by virtue of
> being entirely enclosed by the house.
>  
> I think what you are getting at is that we cannot be responsible for
> securing the network.  And that is probably true.  But if the system
> doesn't have a built-in mechanism for distinguishing between friend
> and stranger, the autoconfiguration mechanism will create topologies
> that aren't desired, either by accident or because a stranger wants
> access to the network.

If applications are secure, the only threat to a wide open network is
theft of service.

WPA provides a knob to stop that.  The only question is whether WPA or
any WiFi security should be enabled by default.

Is it better to leave the possibility of theft of service or is it
better to have the device unusable by default (until configured)?  For
provider equipment that is always configured, the latter (unusable
until configured).  For home equipment where the customer wants to
unpack the box, plug it in and use it, the former is better (make it
usabled but allow possible theft of service).

Every WiFi product I ever bought was open WiFi as shipped.

Curtis

---

From: Russ White <[email-masked]>
Date: Thu, 13 Oct 2011 07:41:05 -0400

> any security that is necessary *for that application*.

In other words, we should abandon door locks and make certain that
anything you don't want stolen is individually secured --because only
the device manufacturer could ever know how valuable it is, and how best
to prevent it being stolen?

> No. No. No.

Security is layered in the physical world, and it should be layered in
the network, as well. That I argue for a default "domain based" posture,
where all machines within a given "domain" are all fully reachable, but
those outside the "domain" are not reachable unless specific actions are
taken to make them reachable, doesn't mean I don't think individual
computers need security at all, or that all security should rely on the
firewall.

"All security must be on the firewall or in the applications" is a false
dichotomy.

> certificates are not layer-2 functions.

Security is an application function, yes. Security is also a network
function, and security is a machine level function. All of these have a
role to play in security.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Thu, 13 Oct 2011 07:44:11 -0400

> better to have the device unusable by default (until configured)?  

This is a false dichotomy, as well...

It is best to find some reasonable ground where 90% of the people in the
world will find the security acceptable, and then let the 10% who care
configure the rest.

But I would also point out that the argument you're making can be
applied to applications as well as network gear.

:-)

Russ

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Oct 2011 09:37:33 -0400

If you autoconfigure a routing topology, you have to make sure that you don't accidentally autoconfigure it to include routers that weren't intended to have been included.

The concern is not for grandma running Windows 98, and the whole hard shell/gooey center debate is completely beside the point.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 11:35:05 -0700

In message <[email-masked]>
Ted Lemon writes:
 
> If you autoconfigure a routing topology, you have to make sure that
> you don't accidentally autoconfigure it to include routers that
> weren't intended to have been included.
>  
> The concern is not for grandma running Windows 98, and the whole hard
> shell/gooey center debate is completely beside the point.

You've said what the problem *isn't*, so what *is* the problem on a
homenet?

Surely the provider is not going to accept a unauthenticated
auto-config hello request and start peering, nor will it accept a
hello from a legacy router configured with router-id and a "be
adjacent to anything" policy.

If the electric meter wants to be a router with a slow link on the
power line, then it needs to act like a provider router, but perhaps
only advertising reachability to the electric utility, not the whole
Internet.  The more specific prefix (than default) should get the
attention of the water heater if it has to try to reach the electric
utility.

Curtis

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Oct 2011 14:42:45 -0400

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 12:59:25 -0700

> to prevent it being stolen?

Following that analogy, the door locks built my certain OS vendors are
both flimsy and easily picked.

And we should not enable tftp and point it at the root directory and
hope that some smart network appliance will somehow firewall us.

> "All security must be on the firewall or in the applications" is a false

Ideally the firewall should be unnecessary.  In some cases a firewall
is out of the question.  For example, a router cannot rely on sitting
behind a firewall.  That is not to say that packet filters at the
border don't serve as a valuable denial of service protection against
pure traffic based attacks.

Firewalls more often get in the way than do any good.  They also give
a false sense of security which results in the occasional "our LAN is
currently swamped as a result of the latest virus run amuck on our
LAN" coming from IT.

> role to play in security.

The operations staff for the T3-NSFNET had no firewall and was
security audited by some of the best in the field.  Of course we did
not allow the use of a PC with Windows in operations.  No such thing
could sit on the same subnet.

Another division in ANS that relied on a firewall was the only part of
the company that even had to have all computers taken down and
scrubbed before they could be used again.  [Requirement at that time
of having certain government customers].  Every computer had to be
physically removed, rebooted from other media, backed up, reinstalled,
user files restored from a backup prior to the breach, and returned to
the rack or the user's desk.  Users had to fetch any lost work from
the backups and were supposed to insure that no changes where made to
recovered source code.  Sound painful and costly?  It was!

Network protection of insecure host applications is false security.
It takes just one host breach to compromise the whole internal
network.  I've seen it first hand many times.  [not quite first hand
since my computers never relied on a firewall for security but a few
times on the corporate LAN they were sitting on.]

IPSEC also got it wrong.  The application really is the right place
for security.

:-)

btw- Anti-virus software is a cruel hoax.  [that someone makes money on]

:-)

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 13:05:33 -0700

In message <[email-masked]>
Russ White writes:
 
> It is best to find some reasonable ground where 90% of the people in
> the world will find the security acceptable, and then let the 10% who
> care configure the rest.
>  

We are talking about whether to bring up routing.  The risk is theft
of service.  This is like locking the screen door if the inside door
deadbolt is already locked.

It is only an issue if the inside door has no locks or has very
ineffective locks and even then locking the screen door doesn't really
help much anyway.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 14:23:23 -0700

> >> weren't intended to have been included.

And I responded to that in the same email and you trimmed that part of
the response in this email.

Curtis

---

From: Mark Townsley <[email-masked]>
Date: Thu, 13 Oct 2011 17:25:39 -0400

>>>> weren't intended to have been included.

That's part of the "border discovery" aspect that, if we can't nail down, everything else we do is pretty much moot. 

- Mark

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Oct 2011 17:29:30 -0400

> the response in this email.

The problem has to do with customer-owned devices and customer-neighbor-owned devices forming networks together.   It's got nothing to do with the ISP.   Chances are, the ISP link is the one thing that won't be gotten wrong here, because only one device you own will be connected to it (at least in typical networks today).

Of course, if your devices unintentionally include your neighbor in the home network topology, your network will suddenly be multihomed, but this is an artifact of the failure mode I'm talking about.  Eliminating that failure mode would solve the multihoming problem as well.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 13 Oct 2011 21:32:35 +0000

> everywhere, I'm just asking what's the plan?

We're certainly expecting to think about it.

However mandating any particular mechanism for how a device can identify itself as part of the "trusted" home would likely be out of scope.

Ray

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Oct 2011 16:02:32 -0700

In message <[email-masked]>
Ted Lemon writes:
 
> The problem has to do with customer-owned devices and
> customer-neighbor-owned devices forming networks together.  It's got
> nothing to do with the ISP.  Chances are, the ISP link is the one
> thing that won't be gotten wrong here, because only one device you own
> will be connected to it (at least in typical networks today).

And therefore risk there is mostly theft of service as I have already
pointed out.

A WiFi AP will not connect to another AP and wireless routers are
typically AP by default.  So if two wireless routers autoconfig to
being AP and using open routing, then there is only a risk if
something that is an WiFi client is also a configured to be a router.

> Of course, if your devices unintentionally include your neighbor in
> the home network topology, your network will suddenly be multihomed,
> but this is an artifact of the failure mode I'm talking about.
> Eliminating that failure mode would solve the multihoming problem as
> well.

Some would call that a feature, not a failure mode.  :-)

But it usually does violate the service provider agreement and
therefore open routing (or bridging) over wireless creates a potential
theft of service.  Ignoring that AP don't talk to AP.

This is really an issue for wireless not for wired and is nothing new.
AFAIK all wireless products today ship "open" and configured as an
"AP" and have to be changed to enable some form of authentication.
And many users never bother to change this.

So what is new about a wireless router vs existing wireless bridges
that do this?

Curtis

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Oct 2011 19:28:07 -0400

> And therefore risk there is mostly theft of service as I have already

No, that is a side issue.   The risk is that two networks will self-configure into a single topology without being told to do so. 

> Some would call that a feature, not a failure mode.  :-)

Your optimism is charming.   However, the more likely case is that the network topology that automatically forms will not work, or will direct all traffic out a single internet link and go over someone's service limits.   And there will be nobody within shouting distance of this fiasco who will be qualified to even guess what might be happening, much less fix it.

---

From: Russ White <[email-masked]>
Date: Thu, 13 Oct 2011 20:26:29 -0400

> hope that some smart network appliance will somehow firewall us.

My point is that you need both. This is not an either/or situation, it's
a both/and situation. The network needs to provide some pieces of the
security, and the devices some more, and the applications some more.

Putting all your eggs in one basket will just mean a lot more broken
eggs in the end.

> could sit on the same subnet.

And you're willing to lend out that staff, free, to anyone and everyone
who needs a secure network?

Again, throwing the security problem at the application isn't a good
solution.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Thu, 13 Oct 2011 20:28:55 -0400

> deadbolt is already locked.

No, we're talking about what sort of reachability to provide once
routing is up.

> ineffective locks and even then locking the screen door doesn't really

I completely disagree. Even a screen door can be an effective component
of an overall security system. Having a system is the key, not a single
component that handles all security of all types in all situations.

:-)

Russ

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Oct 2011 18:13:07 -0700

On Wed, Oct 12, 2011 at 05:33, Ted Lemon <[email-masked]> wrote:

> The second reason is that electrical systems are essentially topology-free.
>   Any point on the system is essentially equivalent to any other.   This is
> not true of a home network with routing.   What we are talking about is
> essentially the possibility of rogue distribution panels intentionally or
> accidentally being connected to your distribution system.
>

I'd say that electrical systems are as susceptible to rogue devices just as
much as zeroconf routing systems are. If you plug a short into a socket, you
trip a circuit breaker and you deny service to other appliances (i.e., "your
house goes dark").

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Oct 2011 21:24:42 -0400

On Oct 13, 2011, at 9:13 PM, Lorenzo Colitti wrote:
> I'd say that electrical systems are as susceptible to rogue devices just as much as zeroconf routing systems are. If you plug a short into a socket, you trip a circuit breaker and you deny service to other appliances (i.e., "your house goes dark").

This is true, but I think I hear the sound of shrieking as you torture this poor analogy...   :)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Oct 2011 23:21:29 -0400

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:
    Curtis> A WiFi AP will not connect to another AP and wireless
    Curtis> routers are typically AP by default.  So if two wireless
    Curtis> routers autoconfig to being AP and using open routing, then

OUT OF THE BOX:  not every device plugged into a home network have
    no prior configuration.  For instance, someone bringing a newsed
    device to grandma's house.

    Curtis> there is only a risk if something that is an WiFi client is
    Curtis> also a configured to be a router.

laptop, smartphone, wii, stereo mp3 player, ...

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 19 Oct 2011 12:30:36 -0700

In message <[email-masked]>
 
>     device to grandma's house.

He who configures it needs to fix it.  Or press the factory default
button (if there is one).  The example is two AP.  Most AP can be
restored to factory default with a button press.  Grandma may toss it
or call in a geek before figuring out some of the hidden "restore to
factory default" procedures like the unmarked "press, hold, and power
cylce while holding" trick.  This is sort of like the old BIOS that
had "secret" ways to get in, different across vendors.  They now have
a very clear "to enter BIOS do this" to avoid those support calls.

> laptop, smartphone, wii, stereo mp3 player, ...

I don't have any windows systems or wii on hand (what's the plural of
wii, wiii?).  And my portable mp3 is (*really old* and only used
occasionally on an airplane and ..) USB only.  But ...

On BSD and I suspect Linux as well, the default for:

  net.inet.ip.forwarding
  net.inet6.ip6.forwarding

are both zero.

A router forwards IP traffic.  By default no routing protocols are
enabled on a host such as a BSD or Linux system.  Even if enabled, a
host may run a routing protocol but not forward packets not destined
to itself from one interface to another.  I would be surprised if any
of the devices you have listed above have forwarding enabled by
default today, except a smartphone which has been configured to act as
a WiFi hub (which itself is not a default).

If we define the zeroconf defaults well, then it would be OK if they
all forward.  As I pointed out in a prior email, the best routing
protocol for wired and the best for wireless may not be the same.

There will be legacy stuff and we can be compatible with it.  We can't
work in any arbitrarily misconfigured legacy environment, because you
can already make that not work without adding anything.  Even with
zeroconfig support, we can't work in any arbitrarily misconfigured
environment, and maybe the best we can do is provide better hints on
what is wrong.  [example: a graphical dump of addressing/routing.]

Curtis

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Oct 2011 14:17:29 -0700

On 10/19/2011 12:30 PM, Curtis Villamizar wrote:
>
> In message<[email-masked]>
>>>>>>> "Curtis" == Curtis Villamizar<[email-masked]>  writes:
> restored to factory default with a button press.

What happens if you have two of them and they're BOTH configured to boot 
as the "master" home access point?

...
>>      Curtis>  also a configured to be a router.

Yes, but we want to assume that at least one of these will be configured 
as a router as a default, which means we KNOW someone will turn on two 
of them....

> On BSD and I suspect Linux as well, the default for:

Right, but that cannot be the default for a homenet box.

Joe

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 19 Oct 2011 20:50:26 -0700

> as the "master" home access point?

Master home access point?  What is that?  We are not talking about
today's primitive NAT boxes that pretend to be routers.

They either have a default route to the Internet or they don't.  If
they have a defailt route and they are at equal distance to that
default route, then there are some arbitrary tie breakers.

Worst case for AP might be if they are hard configed to the same
channel and are very close to each other so they have about the same
S/N and hosts can't decide which one to associate with, plus the
interference with each other.

In any case a press of the factory settings button should fix it.

> as a router as a default, which means we KNOW someone will turn on two 

We want to assume that *all* AP are configured as routers except the
legacy ones that want to be a dumb bridge with NAT to one port.

> Right, but that cannot be the default for a homenet box.

You are mixing the discussion of what we want in routers with what we
don't want enabled by default in every *legacy* PC, toaster and coffee
maker.  If the coffee maker is a competent IPv6 router with extensions
to let it autoconfig, then let it be a router.

I really don't want my dumb old kitchen appliances trying to NAT for
each other.  But that new IPv6 espresso maker that knows how to act as
a router - that would be OK.  :-)

You lost the context.  You snipped out the statement I was replying
to.  A little too much trimming on the response.  It happens.

Curtis

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Oct 2011 10:38:10 -0700

Hi, Curtis,

On 10/19/2011 8:50 PM, Curtis Villamizar wrote:
...
> legacy ones that want to be a dumb bridge with NAT to one port.

AFAICT, you want to assume that:

- all AP routers are configured as per homenet

- all other APs are bridges only

I.e., if IP routing is supported then homenet is supported.

I would prefer if that were true, but I don't think it's a reasonable 
assumption to make in an home environment, because...

> to let it autoconfig, then let it be a router.

I would like to make the same assumption, but we all know that Linux 
doesn't listen to the IETF standards. For any Linux parameter, we ought 
to assume that it *will* change and we need to deal with it.

Since Linux is used in even dumb APs, that means that "future legacy" 
(i.e., non-homenet) APs *will* end up routing at some point, and will 
not support homenet.

We need to deal with that eventuality too.

Joe

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Oct 2011 20:52:39 -0700

> assumption to make in an home environment, because...

Possible confusion here due to overload of the word "configured".

All AP routers which are capable as per homenet are zero config
routers out of the box.

Hope that all legcacy stuff is bridges only, but recognized that some
may insist on trying to NAT on one port.

Note that some product is so stupid as to always announce default
route to the "LAN side", even with nothing connected on the uplink
port (and then blackhole the traffic) and won't let a default route be
configured or accepted by a routing protocol on any port except the
designated uplink.  Being backward compatible with anything that
stupid may not be possible.  Grandma may have to toss that one in the
recycle bin.

> to assume that it *will* change and we need to deal with it.

sysctl is meant for changing it.

> (i.e., non-homenet) APs *will* end up routing at some point, and will 

Today's dumb(est) APs that run Linux NAT and bridge or just bridge.
If the box says router it does NAT (and is useless IMHO) if its just
an AP it bridges to it's (usually one) Ethernet.

Some of these NAT boxes run RIP on the "LAN side" and call that
routing and enable it by default.  Fortunately we can detect this
brain damage too.  If it speaks RIP only, it's not homenet aware.

> We need to deal with that eventuality too.

Maximizing backwards compatibility to all reasonable devices is
clearly one of the biggest challenges.  Some devices out there may be
just plain too braindead to work with unless the vendor can offer a
firmware upgrade and then I can't see Grandma loading a new flash
image on her router.

Curtis