Re: [homenet] Thoughts about routing - trends

[Jeff Tantsura]

Curtis,

At about same time you were moving/re-wiring your new house, I've started to 
use Ethernet over power and have been using it since then :)

Regards,
Jeff  

-Original Message-
From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of 
Curtis Villamizar
Sent: Wednesday, October 12, 2011 19:29
To: Russ White
Cc: homenet@ietf.org
Subject: Re: [homenet] Thoughts about routing - trends


In message <4e957f43.1060...@riw.us>
Russ White writes:
 
>  
> >> You are absolutely right that pulling cable is hard and expensive.
> > Pulling cable is indeed hard and expensive. In my experience, it is
> > the right thing for some applications, such as TV and my home
> > office. Personally, I have both wired and wireless throughout the
> > house; my personal rule is that I use the shared wireless network
> > for activities that move around, to provide convenience at the
> > expense of consistency and bandwidth, and wired for things that
> > stand still, to provide stable bandwidth at the price of a one-time
> > wiring effort.
>  
> I do the same --I pull cable for televisions, and even for locations
> where a desktop or laptop is going to be sitting on a regular
> basis. So I think we should expect wired and wireless as the norm,
> rather than expecting wireless all the time.
>  
> While I wouldn't want to rule OLSRv2 completely out, I think it should
> compete head to head with an extended OSPF and an extended IS-IS, or
> even other efforts afoot. I'd rather see requirements first, and a
> good solid evaluation of what's available against those requirements,
> rather than choosing technologies out of the gate.
>  
> :-)
>  
> Russ


Russ,

At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted
pair.  [Well someone pulled it, but not me.]  Anyone remember vampire
taps in 10base2?  What a reliability headache!

I pulled 10base5 coax at home before I pulled twisted pair and before
trying the early DEC Wavlan stuff that preceeded WiFi (again, at
home).  Too bad I moved and had to pull wire again (but I like the
result).

Back on topic: I do think we should consider OSPF (not so keen on
ISIS, but OK) and should not rule out OLSRv2 or other LLN related work
and MANET work (though I'm far from an expert on LLN or MANET).

We will have to extend OSPF to make zero config possible.  The
extensions should be completely backwards compatible if at all
possible.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Pascal Thubert (pthubert)]

+1

-Original Message-
From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On
Behalf Of Michael Richardson
Sent: jeudi 13 octobre 2011 02:42
To: homenet@ietf.org
Subject: Re: [homenet] Does ND Proxy useful for homenet?


> "Victor" == Victor Kuarsingh  writes:
Victor> These devices (in such operating modes) are however not
Victor> likely to participate in a home network (as the gateway
Victor> device or a router) and it's very unlikely to be the head of
Victor> home network.

I STRONGLY DISAGREE.

Not only will smartphones be pressed into use whenever the primary ISP
is down (I've done this three times in 18 months since I got a
smartphone), but whenever there is an ad-hoc gathering of people who
need network, they will insist that their smartphones be smart. 

I expect my smartphone to provide network to my Personal Area Network
(whether via Bluetooth PAN or Zigbee), and I further expect that PAN to
have an alternate exit via my HAN.

I want to further point out that 3GPP and the mobile operators are no
longer in control of what phones do.  They are network devices.  The
only thing they can control is the protocol on the wire, and if they
piss of the consumer, the consumer will simply tunnel.

It's good that 3G will have PD in the future.
I know that new versions of SIXXS AICCU now include it.

-- 
]   He who is tired of Weird Al is tired of life!   |
firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net
architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[
   Kyoto Plus: watch the video

   then sign the petition. 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Russ White]

> I agree. Since we need to configure unique prefixes to each router in
> the home anyway, it should not be any problem to do the same for a
> router ID (or even just use an address from the configured prefix as
> router ID, which should then be unique). A while ago, there were some
> plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop
> network for configuring prefixes in the network. As in a home network, I
> assume there is always at least one border router with the global
> prefix, specifying something like that seems to be reasonable for me (in
> a MANET, that can be more difficult, because there is not necessarily
> such a central entity as the border router).

I think there will be, by default, multiple "border routers." In my
house I currently have 6 devices that provide internet connectivity, and
I assume that number is going nowhere but up. Each of these devices
could, in theory, be a "border router," in some way.

What saves the day is that I don't allow 4 of them to "talk" on the
internal network, and the other two are carefully segregated. But
there's no reason for any of this --there's no reason I shouldn't be
able to use all of them, especially as some of them might be able to
reach outside networks in addition to the Internet at large that others
might not be able to.

:-)

Russ
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Curtis Villamizar]

In message 
Victor Kuarsingh writes:
> >
> > And if I'm at home with WiFi at home and my laptop plugged into the
> > Internet and plug in the USB (or other tether) to update my contacts
> > list on the phone, because its easier/faster, we have the situation
> > described, even though the intent was not to use the phone as an IP
> > gateway.
>  
> I can see your point. So in this case.. I guess your computer/laptop
> would belong to two networks (wired USB and Home Network over WiFi).
> Not sure if this example shows how the two networks join - unless the
> computer bridges/routes traffic.

Good point.  The computer would have three ways to pick from.

Maybe the phone acting as a WiFi was a better example.

> > This gets back to users plugging things in in seemingly arbitrary way
> > that made sense to them at the time for some reason.
>  
> Would you say this example adds merits to ND for the smartphone
> gateway function, or the opposite?

ND just finds the link local addresses.  Figuring out which way to go
with packets is another story.

You need a routing protocol if there is a loss of connectivity more
than one hop away.  At that point the addresses are still valid, but
the path to the default route has changed.

There is no fast withdraw in ARP proxy, DHCP proxy, ND proxy.  In a
routing protocol, the flooding of bad news is fast.  Plus arbitrary
topologies can be supported.

And as Jim pointed out, we need to be careful about the scalability of
flooding for WiFi networks that may be come dense.

> regards,
>  
> Victor K

Regards,

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <20111013011929.1f7051527...@drugs.dv.isc.org>
Mark Andrews writes:
 
>  
> While talking about hardware.  These these devices all need a battery
> backed clock or all the crypto will be broken.


Having a clock is not hard but I don't think your statement is true.

Some crypto does not require time, but rather just entropy (a nonce or
challenge).  For crypto that does require time the former can be a
bootstrap of sorts, possibly to get ntp going if very accurate time is
needed (for some reason).

For example ssh with rsa or dsa does not require time.  You need to
know what month and year it is to be good enough as far as checking
certificates.

A lot of the KARP work does require knowing the time to prevent
replay attack.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet strawman slides

[Curtis Villamizar]

In message <4c6c6fc3-d1a9-4663-a1e1-802d1a6d0...@apple.com>
james woodyatt writes:
 
> On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote:
> > 
> > A router should not start handing out PD or even IPv4 NAT space
> > until it gets and address from elsewhere.

btw - the valid point about serving the site needs was brought up, so
some assignment would be needed in absense of an uplink.

> Some routers need to do this, i.e. home routers where service
> providers charge prohibitive rates for always-on Internet dial-tone
> and expect subscribers to connect on demand and disconnect after an
> appropriate idle time.

For on-demand routing, it makes sense for the router to hand out an
address while not being connected.  I personally haven't seen that
since 56K modems, but OK.  (And I had FR back then).

For the DSL and MSO services I've used, the service was "always up",
unless of course you powered down the CPE.

> For IPv4 today, these routers typically use PPPoE on the WAN and they
> often handle this by assigning RFC 1918 address to the LAN hosts and
> using DNS queries to signal PPPoE to establish the WAN link.

OK.  Client does DNS and that is the "on demand" part.  Fine.  In in
absence of DNS, a ping or TCP SYN would bring it up.

> For IPv6, I'm not sure what they should do, but I have some ideas.
> Basically, the router should advertise as a default router with a
> single ULA prefix and a DNS server at the router's ULA interface
> address with RFC 6106 and optionally RFC 3736.  When the DNS query
> signals PPPoE to establish the WAN link, the DHCPv6 client will ask
> for a IA_PD and update the prefix advertised on the LAN accordingly.
>  
> I'm not sure this model can be made to work with IPv6, but I wouldn't
> put it past the telcos to try.

With IPv6 there is no reason that the CPE can't be assigned a
persistant address but bring the connection down.  On power up it
could connect and get it, then bring the link down in the absence of
traffic.  Usually if it is powered up it is because someone want to
use it, so this would be fine.

There is no reason not to hold the IA_PD assignment at the CPE when an
on demand link is down.  That prefix can be requested in the IA_PD
request when there is demand again, just to refresh it and confirm.
The same DNS query can be used as the trigger in on-demand IPv6 as
well.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Victor Kuarsingh]

>
>
>
> And if I'm at home with WiFi at home and my laptop plugged into the
> Internet and plug in the USB (or other tether) to update my contacts
> list on the phone, because its easier/faster, we have the situation
> described, even though the intent was not to use the phone as an IP
> gateway.
>

I can see your point. So in this case.. I guess your computer/laptop would
belong to two networks (wired USB and Home Network over WiFi).  Not sure if
this example shows how the two networks join - unless the computer
bridges/routes traffic.


>
> This gets back to users plugging things in in seemingly arbitrary way
> that made sense to them at the time for some reason.
>

Would you say this example adds merits to ND for the smartphone gateway
function, or the opposite?


regards,

Victor K


> Curtis
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Victor Kuarsingh]

On Wed, Oct 12, 2011 at 8:41 PM, Michael Richardson wrote:

>
> > "Victor" == Victor Kuarsingh  writes:
>Victor> These devices (in such operating modes) are however not
>Victor> likely to participate in a home network (as the gateway
>Victor> device or a router) and it's very unlikely to be the head of
>Victor> home network.
>
> I STRONGLY DISAGREE.
>

That's fine. My statement was based on an aggregate set of behaviors over
millions of endpoints.  Corner cases always exist (and perhaps not so corner
in the future).


>
> Not only will smartphones be pressed into use whenever the primary ISP
> is down (I've done this three times in 18 months since I got a
> smartphone), but whenever there is an ad-hoc gathering of people who
> need network, they will insist that their smartphones be smart.
>

Sure, a number of people seem to do this and tether their phones for
Internet Access.  Although performance is
somewhat degraded as Smartphones don't seem to make very good routers
(performance wise - but this may change).  Notice I did not say "never", I
said "not likely".


>
> I expect my smartphone to provide network to my Personal Area Network
> (whether via Bluetooth PAN or Zigbee), and I further expect that PAN to
> have an alternate exit via my HAN.
>

Understood.  However is that what most people will expect?  Perhaps one can
argue yes.


>
> I want to further point out that 3GPP and the mobile operators are no
> longer in control of what phones do.  They are network devices.


I guess this is true to some extent.  There is value in having standards in
this area which make things work in a relatively complex environment.


>  The
> only thing they can control is the protocol on the wire, and if they
> piss of the consumer, the consumer will simply tunnel.
>

I guess some may tunnel.  Not sure if most would.


>

It's good that 3G will have PD in the future.
> I know that new versions of SIXXS AICCU now include it.
>
>
PD is in the spec.  But when it sees the light of day in actual deployments
(network + devices) is the key.




regards,

Victor K

--
> ]   He who is tired of Weird Al is tired of life!   |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>   Kyoto Plus: watch the video 
>   then sign the petition.
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Curtis Villamizar]

In message 
Victor Kuarsingh writes:
 
> Mark,
>  
> A few points on this topic.
>  
> As noted, the Cell system will have PD capabilities until a future 3GPP
> release (Rel-10) as noted.  Although, even when the functionality is in
> place (generally), small devices like Smartphone and the mini gateways
> (3G/LTE devices which allow for 4-5 hosts to attached to Cell system) -
> PDs may not be used.
>  
> Many of these devices (I.e in the case of the smartphone) have modes of
> operation where they "tether", which turns them into a mini gateway.  They
> are not likely to be be full blown gateways equivalent to what you see
> common CPEs.
>  
> In the IPv4 case, these devices "NAT" the IPv4 private addresses used by
> hosts behind the device to the network assigned address.  In the case of
> IPv6, it will have access to the network assigned ::/64.  PCs (maybe other
> devices) behind such devices will need access to the IPv6 network, but may
> not have access to PD space.  This was one of the specific use cases I was
> eluding to before.
>  
> These devices (in such operating modes) are however not likely to
> participate in a home network (as the gateway device or a router) and it's
> very unlikely to be the head of home network.
>  
> With this explanation, I am not sure if this should/would be considered as
> such in HomeNet.  These devices technically become gateways/bridges to the
> Internet.  And the hosts that use them are often the same type of devices
> which connect to common home networks.
>  
> Regards,
>  
> Victor K


Victor,

And if I'm at home with WiFi at home and my laptop plugged into the
Internet and plug in the USB (or other tether) to update my contacts
list on the phone, because its easier/faster, we have the situation
described, even though the intent was not to use the phone as an IP
gateway.

This gets back to users plugging things in in seemingly arbitrary way
that made sense to them at the time for some reason.

Curtis


> On 11-10-10 4:51 PM, "Rajeev Koodli"  wrote:
>  
> >
> >Hi,
> >
> >The smartphone will only get a /64 in the current 3G/4G releases (rel-8,
> >rel-9).
> >
> >Prefix delegation is specified in Rel-10.
> >
> >-Rajeev
> >
> >
> >
> >On 10/10/11 1:01 PM, "Mark Townsley"  wrote:
> >
> >>> 
> >>> Or are you saying a mobile device (a smartphone) will only ever get a
> >>> /64 to share?
> >> 
> >> My (limited) understanding of the various 3/4G standards are that a PD
> >>for a
> >> phone is something that is very, very, recent. Perhaps Rajeev (cc'd) or
> >> someone else here can elucidate.
> >> 
> >> - Mark
> >> 
> >
> >___
> >homenet mailing list
> >homenet@ietf.org
> >https://www.ietf.org/mailman/listinfo/homenet
>  
>  
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Curtis Villamizar]

In message 
Ted Lemon writes:
 
> On Oct 12, 2011, at 4:48 AM, Ole Troan wrote:
> > 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 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <4e95836d.4020...@riw.us>
Russ White writes:
 
>  
> > Russ> You need a unique identifier at the equipment level for
> > Russ> anything you intend to auto-configure --autoconfiguring
> > Russ> uniqueness is a very hard, probably impossible, problem on a
> > Russ> global scale. So we need to count on this one thing, no matter
> > Russ> what else we might need to back in to.
> > 
> > Russ> Now, it might be possible to some hash over a GPS location for
> > Russ> a "base," and then add on MAC addresses, or some such, but
> > 
> > We've assumed a unique MAC, which is 48 bits long. 
> > But OSPF router-id is 32 bits.What is the likelyhood of a collision 
> > in the bottom 32-bits of the MAC? 
>  
> Ah, I see the problem... There is a pretty high likelihood of a
> collision, actually, at least as long as you use multiple vendors in
> your home network. It's bound to happen to someone, someplace.
>  
> So, a suggestion to resolve this:
>  
> 1. Use the lower 32 bits of one of the mac addresses on the box as the
> initial id.
>  
> 2. Add a new field to the router capabilities that carries the full 48
> bit mac address, or even some munged together "longer id," based on
> multiple mac addresses on the device, or some such.

Not backwards compatible.  The older OSPF routers will see only the
non-unique 32 bits and the network won't work.

> 3. During initial setup, if you receive a capability that appears to be
> from yourself, you open this secondary id section to find out if it's
> really you, or someone else who happens to have the same 32 bit id.
>  
> 4. If it's really you, discard the packet.
>  
> 5. If it's not really you, and if the other router's "large id" is lower
> than yours, choose another mac address from which to take your local id,
> and restart your ospf process.
>  
> 6. If it's not really you, and the other router's "large id" is higher
> than yours, then send a router capabilities LSA unicast to this "other
> router," so the "other router" knows to change its id.
>  
> I don't think IS-IS would have this problem.
>  
> :-)
>  
> Russ

If the other router doesn't implement the extension you've described,
the network is hosed forever.

If you have more than one link you should receive the LSA (or LSPDU)
that you advertised.  If you have one link, you won't.

If you receive a LSA (or LSPDU) that clearly you didn't advertise,
then you have a collision.  *Both* routers should pick a new router-id
if this condition is detected and they implement this extension.

Don't even bother using a MAC address for the router-id.  Use a random
number.  If a collision occurs, use a different random number.  This
should also work for interfaces without a MAC (not that many homes run
POS today, but maybe some layer-2 in the future).

Here is where it if fuzzy if one router is a legacy router.  It may
not look at LSA (or LSPDU) apparently from itself or may just log a
problem and continue.  When backing off, the bogus advertisements need
to be withdrawn.  A possible backward compatibility wrinkle exists if
the legacy router does not readvertise (being legacy it will not pick
a new router-id).  The problem could persist for maxage.  Better than
forever but still not good.

Don't use a non-configured router-id if you don't support this ability
to back off.  (Routers today don't pick a random router-id and they
shouldn't unless they can backoff).

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Curtis Villamizar]

In message <4e957f43.1060...@riw.us>
Russ White writes:
 
>  
> >> You are absolutely right that pulling cable is hard and expensive.
> > Pulling cable is indeed hard and expensive. In my experience, it is
> > the right thing for some applications, such as TV and my home
> > office. Personally, I have both wired and wireless throughout the
> > house; my personal rule is that I use the shared wireless network
> > for activities that move around, to provide convenience at the
> > expense of consistency and bandwidth, and wired for things that
> > stand still, to provide stable bandwidth at the price of a one-time
> > wiring effort.
>  
> I do the same --I pull cable for televisions, and even for locations
> where a desktop or laptop is going to be sitting on a regular
> basis. So I think we should expect wired and wireless as the norm,
> rather than expecting wireless all the time.
>  
> While I wouldn't want to rule OLSRv2 completely out, I think it should
> compete head to head with an extended OSPF and an extended IS-IS, or
> even other efforts afoot. I'd rather see requirements first, and a
> good solid evaluation of what's available against those requirements,
> rather than choosing technologies out of the gate.
>  
> :-)
>  
> Russ


Russ,

At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted
pair.  [Well someone pulled it, but not me.]  Anyone remember vampire
taps in 10base2?  What a reliability headache!

I pulled 10base5 coax at home before I pulled twisted pair and before
trying the early DEC Wavlan stuff that preceeded WiFi (again, at
home).  Too bad I moved and had to pull wire again (but I like the
result).

Back on topic: I do think we should consider OSPF (not so keen on
ISIS, but OK) and should not rule out OLSRv2 or other LLN related work
and MANET work (though I'm far from an expert on LLN or MANET).

We will have to extend OSPF to make zero config possible.  The
extensions should be completely backwards compatible if at all
possible.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Curtis Villamizar]

In message <4e955c94.3060...@cs.tcd.ie>
Stephen Farrell writes:
 
> On 10/12/2011 09:48 AM, Ole Troan wrote:
> >> 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?
> >
> > 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).
>  
> 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.



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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Ulrich Herberg]

On 10/12/11 7:51 PM, Russ White wrote:
> [...]
>
> While I wouldn't want to rule OLSRv2 completely out, I think it should
> compete head to head with an extended OSPF and an extended IS-IS, or
> even other efforts afoot. I'd rather see requirements first, and a good
> solid evaluation of what's available against those requirements, rather
> than choosing technologies out of the gate.

Hi Russ,

I fully agree. There should be an evaluation against the requirements.
My point was just not to rule out OLSRv2 (or other protocols) based on
the fact that a protocol is used, amongst other, in mesh network
deployments.

Ulrich
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Curtis Villamizar]

In message <78ce7d95-48c9-4de4-9707-f11ac2a05...@cisco.com>
Ole Troan writes:
 
> > 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?
>  
> can we explore some fundamental principles of how and what we need to
> "secure"?

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

> is it the networks job to control who has access to the network? no, I
> 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Mark Andrews]

In message <669f4202-6fd4-4f13-ae7b-e725d53ad...@gmail.com>, Jim Gettys writes:
> Or you solve the time problem some other way...
> 
> Batteries die too...
>   Jim

Indeed.  It should be a user servicable part.

As to solving it other way, "leap of faith" springs to mind.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Mark Andrews]

While talking about hardware.  These these devices all need a battery
backed clock or all the crypto will be broken.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <4e95096e.5020...@herberg.name>
Ulrich Herberg writes:
 
> Jari,
>  
> On 10/11/11 12:05 PM, Jari Arkko wrote:
> > Home routers would also have MAC addresses, but again, if we need a
> > 32-bit quantity then shortened 48/64 bit identifiers may
> > (theoretically) have collisions.
> >
> > That being said, if the home routers have to discover their IPv6
> > prefix through a protocol and store it in flash, they could probably
> > do so also for a router ID. Unless there was some chicken and egg
> > problem that required the router ID for all this discovery to work...
> I agree. Since we need to configure unique prefixes to each router in
> the home anyway, it should not be any problem to do the same for a
> router ID (or even just use an address from the configured prefix as
> router ID, which should then be unique). A while ago, there were some
> plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop
> network for configuring prefixes in the network. As in a home network, I
> assume there is always at least one border router with the global
> prefix, specifying something like that seems to be reasonable for me (in
> a MANET, that can be more difficult, because there is not necessarily
> such a central entity as the border router).
>  
> Regards
> Ulrich


Ulrich,

Whatever ends up being specified should require no configuration and
work when there are:

  zero border routers providing a prefix (outage and/or partition)

  one border router providing a prefix (the easy case)

  multiple border routers providing a prefix

For the large apartment building example that Jim gave, we really
should consider scaling behavior when there are a large number of
border routers providing a prefix within a given mesh.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Curtis Villamizar]

In message <159dbf45-107c-4c12-ae01-9bb494e8e...@fugue.com>
Ted Lemon writes:
 
> On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote:
> > 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.
>  
> 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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Michael Richardson]

> "Victor" == Victor Kuarsingh  writes:
Victor> These devices (in such operating modes) are however not
Victor> likely to participate in a home network (as the gateway
Victor> device or a router) and it's very unlikely to be the head of
Victor> home network.

I STRONGLY DISAGREE.

Not only will smartphones be pressed into use whenever the primary ISP
is down (I've done this three times in 18 months since I got a
smartphone), but whenever there is an ad-hoc gathering of people who
need network, they will insist that their smartphones be smart. 

I expect my smartphone to provide network to my Personal Area Network
(whether via Bluetooth PAN or Zigbee), and I further expect that PAN to
have an alternate exit via my HAN.

I want to further point out that 3GPP and the mobile operators are no
longer in control of what phones do.  They are network devices.  The
only thing they can control is the protocol on the wire, and if they
piss of the consumer, the consumer will simply tunnel.

It's good that 3G will have PD in the future.
I know that new versions of SIXXS AICCU now include it.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <17786.1318379...@marajade.sandelman.ca>
Michael Richardson writes:
 
> > "Russ" =3D=3D Russ White  writes:
> Russ> You need a unique identifier at the equipment level for
> Russ> anything you intend to auto-configure --autoconfiguring
> Russ> uniqueness is a very hard, probably impossible, problem on a
> Russ> global scale. So we need to count on this one thing, no matter
> Russ> what else we might need to back in to.
>  
> Russ> Now, it might be possible to some hash over a GPS location for
> Russ> a "base," and then add on MAC addresses, or some such, but
>  
> We've assumed a unique MAC, which is 48 bits long.=20
> But OSPF router-id is 32 bits.What is the likelyhood of a collision=20
> in the bottom 32-bits of the MAC?=20


Each organization has one or more unique OUI which includes one of the
bottom four bytes.  The next three (of those four) are unique only
within the OUI which is the top three bytes (but with two bits given
special meaning).

So what are the chances that two organization start numbering the
bottom bits at zero and work their way up until the bottom three bits
are filled.  Since there are way more than 256 organizations that have
an OUI, collisions, while rare, can happen.

If there is a way to recover from a collision, then its a complete
non-issue and a random number can be used.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Curtis Villamizar]

In message <4e94bf91.4060...@cs.tcd.ie>
Stephen Farrell writes:
 
>  
> 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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Curtis Villamizar]

In message <4e9494a9.4030...@freedesktop.org>
Jim Gettys writes:
 
> Having said this, I do note the following technological trends:
>  
> 1) As soon as we get real "plug and play" routers that don't need manual
> configuration that work, we'll see a lot more routers in a home
> environment.  Other radio technologies (e.g. zigbee) may encourage this
> trend.  It seemed like the working group agreed that getting to the
> point that just hooking things together would really "just worked" was a
> fundamental requirement (and I agree entirely with this sentiment, as it
> reflects reality of what already happens in the homes of hackers and
> non-hackers alike).
>  
> 2) wireless is much cheaper to implement than wired networking,
> particularly in most houses where pulling cable is hard.  I know this
> first hand, where I've pulled a lot of cat 6 and wish I could get it to
> places I don't have it.
>  
> Unless power line networking really works, I believe that this trend
> isn't going to change.  Is there any progress in this area?  I've seen
> many promises, and few reliable working products.
>  
> 3) As soon as you have two routers, you have at least two paths; the
> wired connection between them and the wireless.  You may have 3 paths,
> if you have both 2.4 and 5ghz radios. Frequency diversity routing
> becomes immediately interesting, along with using your ethernet when
> it's available in preference to wireless.
>  
> 4) an apartment building look like a mesh, and possibly with multiple
> backhauls possibly with multiple ISP's. One should at least think about
> what happens when you have "homes", in such a building, and make sure
> nothing breaks. Wireless is messy: it isn't limited to where a wire
> goes.  Taking down an entire apartment building/blocks/city would not be
> fun.  I know, I've been there (at least to the point of taking down
> buildings, and came within a week of a much larger scale disaster).
>  
> If you believe 1 + 2 + 3 +4  (as I do), then if you look a few years
> out, you end up with something in the "home" that begins to resemble
> very strongly what the community mesh networking folks are doing at a
> higher scale geographically and in terms of # of nodes today, with
> many/most of the same concerns and solutions. Understanding the problems
> they've faced/are facing is therefore worth a bit of investment; Radio
> diversity is one of the concerns, and interference (of various sorts).


Very good points.  Much of the discussion has been focused on the
single home in isolation.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet strawman slides

[Curtis Villamizar]

In message <4e94829e.2010...@cisco.com>
Erik Nordmark writes:
 
> On 10/10/11 5:33 PM, Curtis Villamizar wrote:
> > In message<4e93358f.7050...@cisco.com>
> > Erik Nordmark writes:
> >
> >> On 10/8/11 6:13 AM, Jari Arkko wrote:
> >>> I like this, with the possible exception of using ULAs and your desire
> >>> to deprecate prefixes as soon as connectivity goes down. (Speaking as
> >>> someone whose prefixes got invalidated two months ago but who hasn't
> >>> been home long enough to fix the problem, but my devices still happily
> >>> communicate with each other using the old prefixes :-) I also agree with
> >>> Erik that loop and arbitrary topologies is not really required. But the
> >>> people in the interim at least seemed to say yesterday that we want to
> >>> go there.
> >>
> >> I think there are different scopes being discussed.
> >>
> >> The one I put forth is how to enable existing IPv4 NATting consumer home
> >> routers (which all have a designated uplink port, and support multiple
> >> home routers by nested NATting) have a way to support IPv6 without
> >> requiring any IPv6 NATs. That doesn't seem to be a difficult problem
> >> (which perhaps makes it uninteresting for some of us), but to me it
> >> seems like an important short-term problem to solve.
> >>
> >> The larger scope is around arbitrary topologies, no designated uplink
> >> port, and perhaps also multihoming. Plenty of problems to solve around
> >> autoconfiguring routing protocols, stable prefix assignment to links,
> >> multihoming, etc.
> >
> >
> > Erik,
> >
> > I really don't know how many support calls are just the consumer
> > plugging the computer into the wrong Ethernet port on the NAT box and
> > the uplink on the other port and then not being able to figure out
> > what is wrong.  All the cables fit in the connector.  It should work!
>  
> It sure would be good to try to find some data on this.
>  
> > If all the ports are the same, no designated uplink, that is better.
>  
> While I can see that we can build the internals of the home network with 
> devices without a designated uplink (automatically configure prefixes, 
> the routing protocol etc), what I don't understand is how the 
> connectivity to the ISP would happen.
>  
> How do you see that working?
> Will each router try the protocols it would use against the ISP (PPPOE, 
> DHCP PD, etc) on every port? Or on every port where it doesn't find a 
> OSPF (or whatever home routing protocol we choose) neighbor? Or does the 
> user have to configure the Customer Edge Router to say "port eth0 is the 
> WAN port?"

On a DOCSIS or DSL router the provider connection will always (maybe
always) need some configuration, if for no other reason the provider
wants to see an account name and password.

If the provider ships out the DOCSIS or DSL router or installs it,
then they would do that configuration.

Everything *on the homenet side* would be autoconfig and would never
have a need to run certain protocols such as PPPOE.

If the user chooses to set the SSIDs and enable security on WiFi, that
would have to be optional if we wanted true zero config.

> FWIW I haven't seen any discussion to try to automate this. The manual 
> configuration would be just as error prone as making the distinction 
> between the yellow WAN port and the blue LAN ports on current home gear.

The goal is to get zero configuration on the homenet side of
homenet/provider demarc.  If the provider supplies equipment, then the
demarc is that equipment with the homenet side of the homenet/provider
link configured ethernets the ethernets and any routers/hosts on the
homenet side zero config.

> > If you get an IP address via DHCP on one and none of the others, it
> > may be the uplink and try doing NAT.  What may be needed is a IPv4
> > equivalent to the IPv6 IA_PD and a provider DSL or docsis modem/router
> > that knows how to respond to it.  The other routers ask for a IA_PD
> > and the provider modem/router responds with part of 10/8 on each
> > interface (and does NAT).
>  
> Presumably DHCP could be used within the home for address (and 
> potentially prefix) configuration, thus I don't think we can assume that 
> just because some neighbor on some port responds to a DHCP packet that 
> it is the WAN port. For all we know, the neighbor might be a DHCP relay 
> for the home network.

The reason that a routing protocol is needed is DHCP is quite dumb
about this and DHCP proxy and ARP proxy, and ND proxy provide at most
very limited kludges.

Let us separate DHCP6 from DHCP4 for the moment.  In DHCP4 the
assumption is that the client is always a host (excluding proxy) and
returns a single address.  In DHCP6 link local communication is
possible without an uplink.  With link local and a routing protocol, a
default route can be discoverd if there is one (or more).  Only when
one of the routers on (or adjacent to, depending on demarc style)
acquires a globally routeable prefix (IA_PD or configured, doesn't
matter)

Re: [homenet] Homenet strawman slides

[james woodyatt]

On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote:
> 
> A router should not start handing out PD or even IPv4 NAT space until it gets 
> and address from elsewhere.


Some routers need to do this, i.e. home routers where service providers charge 
prohibitive rates for always-on Internet dial-tone and expect subscribers to 
connect on demand and disconnect after an appropriate idle time.

For IPv4 today, these routers typically use PPPoE on the WAN and they often 
handle this by assigning RFC 1918 address to the LAN hosts and using DNS 
queries to signal PPPoE to establish the WAN link.

For IPv6, I'm not sure what they should do, but I have some ideas.  Basically, 
the router should advertise as a default router with a single ULA prefix and a 
DNS server at the router's ULA interface address with RFC 6106 and optionally 
RFC 3736.  When the DNS query signals PPPoE to establish the WAN link, the 
DHCPv6 client will ask for a IA_PD and update the prefix advertised on the LAN 
accordingly.

I'm not sure this model can be made to work with IPv6, but I wouldn't put it 
past the telcos to try.


--
james woodyatt 
member of technical staff, core os networking

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - flash/stable storage constraints

[Curtis Villamizar]

In message <4e95c231.5030...@freedesktop.org>
Jim Gettys writes:
 
> On 10/11/2011 12:05 AM, Jari Arkko wrote:
> > Home routers would also have MAC addresses, but again, if we need a
> > 32-bit quantity then shortened 48/64 bit identifiers may
> > (theoretically) have collisions.
> >
> > That being said, if the home routers have to discover their IPv6
> > prefix through a protocol and store it in flash, they could probably
> > do so also for a router ID. Unless there was some chicken and egg
> > problem that required the router ID for all this discovery to work...
> As to storing in flash, since most in homenet have not typically worked
> on embedded systems, worse luck...
>  
> There is typically a read/write file system that can store state on a
> current Linux home router (e.g. OpenWrt); it may or may not mapped over
> the entire flash (which is desirable, as you'd like wear levelling to
> use all blocks on the flash).
>  
> The bulk of the firmware is likely contained in a read-only file system
> called Squashfs, which does LZW compression on a per file basis;
> overlayed on top may be a read/write file system.
>  
> Most commonly the read/write file system has been a file system called
> jffs2 over bare flash, originally implemented on the Compaq iPAQ
> handheld, a project I helped lead after I got sick of HTTP.  And OLPC
> had a gigabyte of flash (which pushes jffs2 to/beyond it's design
> limits). There are later flash file systems under development, but I
> don't have first hand experience with any of them.
>  
> Flash has the characteristic that write is relatively slow, and erase is
> generally glacial.  Most interesting flash file systems try to do lazy
> erasure (erase freed blocks when they have a chance later, rather than
> at the time you may free a file).
>  
> Since you don't want to wear out the flash, the jffs2 does journaling;
> one write will commit (potentially) a bunch of changes to multiple
> files, rather than each write generating one write.
>  
> How many writes you get depends on the flash technology, whether the
> flash is "bare" or has some "smart" controller, and the wear levelling
> technology (if any) in use, along with whether all blocks participate in
> the wear levelling or not (jffs2 does good wear levelling; but using a
> big squashfs file system + a very small jffs2 file system will reduce
> the effectiveness; some cheap USB storage devices only do wear levelling
> on the free blocks, and try to hide the fact it is flash from the system
> above.  I put "smart" in quotes, because they've often been hideously
> stupid, with their smarts limited to looking like IDE with a very lame
> flash translation layer.  The most recent "smart" flash disks for
> laptops are actually getting very smart, with some help from the OS to
> help with the erasure problem.  But they still cost substantially more,
> I suspect.
>  
> I think most home routers currently use bare flash, though it's not
> clear to me if this will continue or not since the volume market may
> make the economics change.
>  
> In any case, with flash of any sort, you don't want to sit there and
> demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime,
> for example). 
>  
> All this being said, storing state at the rate of machines/routers
> appearing or disappearing on a home network, or your ISP going down,
> isn't likely to cause a problem.  You just have to be careful enough to
> not do anything really stupid; e.g. you map daemons with chatty logs to
> run their logs to /dev/null, or to tempfs in RAM. And you might take a
> big latency hit if you have to guarantee the write is stable before
> continuing an algorithm (if you run into needing to erase a block for
> some reason).  And obviously you don't write tons of data when you don't
> half to. And update in place may be a bad idea relative to other
> techniques (which is why journaling file systems such as jffs2 are so
> desirable).
>  
> - Jim


Jim,

Nice reminder on the limitations of flash and some of the workarounds.
Some neat hardware does erase on write and buffers the write itself,
and can store enough energy in a small battery to flush the writes on
power down.  Its faster and maximized flash life.  Its essentially a
RAM front ended flash.  I think it was expensive for consumer use.
For provider equipement it makes logging to flash feasible thereby
avoiding spinning media which may object to a 65 C ambient.

Routing protocols are even less stateful than DHCP in this regard.
There is no "lease" to be preserved between boots.  The configuration
(today in non-zero-config situations) is not sufficiently immuatable
to put in a squashfs but may not be changed for months or years.  Any
old filesystem over bare flash is OK for that.

Everthing else in a routing protocol is acquired at run time and
therefore should be in RAM (ramfs or in application space RAM).

With a zero config routing protocol at worst there would be a 

Re: [homenet] Homenet strawman slides

[Curtis Villamizar]

In message <17350.1318379...@marajade.sandelman.ca>
Michael Richardson writes:
>

We may all be in violent agreement.
 
>  
> > "Erik" =3D=3D Erik Nordmark  writes:
> >> Erik,
> >>
> >> I really don't know how many support calls are just the consumer
> >> plugging the computer into the wrong Ethernet port on the NAT box
> >> and the uplink on the other port and then not being able to
> >> figure out what is wrong.  All the cables fit in the connector.
> >> It should work!
>  
> Erik> It sure would be good to try to find some data on this.
>  
> But, for many many years, ISPs did not support having a sharing device.
>  
> Not that they do, ISP insist that the box be *their* box, and as that
> box is sometimes broken, limited, etc. the customer has to provide their
> own.  Again, if the ISP is called, it's "not their problem".


The ISP often has a dumb box that gets a DHCP allocation when turned
on and then does NAT.  For small business service, it may also get a
fixed single IPv4 address, or less often a block and have the ability
to accept an ARP from the customer side in that range (no DHCP).  By
default it does NAT and DHCP for everything else.

If the ISP is an MSO and doing VOIP, their staff usually plugs it in.
Otherwise if left to the customer, they would get the call.

If it Vonage or similar VOIP provider, then they get the call.


> Erik> While I can see that we can build the internals of the home
> Erik> network with devices without a designated uplink
> Erik> (automatically configure prefixes, the routing protocol etc),
> Erik> what I don't understand is how the connectivity to the ISP
> Erik> would happen.
>  
> Erik> How do you see that working?  Will each router try the
> Erik> protocols it would use against the ISP (PPPOE, DHCP PD, etc)
> Erik> on every port? Or on every port where it doesn't find a OSPF
> Erik> (or whatever home routing protocol we choose) neighbor? Or
> Erik> does the user have to configure the Customer Edge Router to
> Erik> say "port eth0 is the WAN port?"
>  
> Basically what you suggest.
> For Cable and any access link that uses DHCP and Ethernet directly, the
> fact that you get a DHCP with a PD is a clue that this is the WAN link.
> For DSL using PPPoE (those who pay a bit more can have DSL without
> PPPoE), then a username/password is required, and yes, the user has to
> configure this.

This is generally the case.  A router should not start handing out PD
or even IPv4 NAT space until it gets and address from elsewhere.  If
it gets a real address (not a PI), then that should be preferred over
some device that handed out a NAT address with a default route to
itself even though it had no uplink.

Case in point: DHCP is not a routing protocol.  You have one shot to
hand over a default route.  If its wrong it can be bandaided with ICMP
redirects for hosts that don't have a zero config routing protocol
running.  But that is the best that can be done with the NAT and DHCP
kludge that is in place today.

We can whine about it or we can define something better with
sufficient backwards compatibility.

> However. in many cases, this is pre-configured by the ISP, as the
> "router" and DSL modem is combined into a single box.  Often this also
> means that you can't plug it in wrong, as the uplink is an RJ11 rather
> than RJ45.

This is true only where where "it" is a VOIP product giving you an
RJ11 and it is integrated into the same box as the DOCSIS or DSL modem
and home router.

> Erik> I don't think arbitrarily stupid way can possibly work, since
> Erik> that doesn't ensure that the home network is internally
> Erik> connected. If the user connects three routers in the den
> Erik> together, but those are not connect to the rest of the house,
> Erik> then no protocol we come up with can fix that.
>  
> a) That's okay, because the three routers in the Den plugged in that way
>won't affect the router in the basement which is doing fine.
>  
> b) Actually, the three routers in the Den might see the wifi from the
>basement, and might join it.

That would be nice.  I think Erik's point is that the audio system
should still get a DHCP address and a (bogus) default route so that it
can talk to the wireless speakers in the room which also get
addresses.

Michaels point about going through the WiFi is interesting in that in
the current model this wouldn't work.  An access point doesn't talk to
another access point over the radio by default.  They usually pick
different channels specifically to avoid each other.  If the access
point was integral to or hanging off the routers by a Ethernet, in the
uplink model, it wouldn't help even if they did talk to each other.

> Erik> Supporting arbitrary topology (as opposed to just trees) is
> Erik> good in that it enables redundant internal topologies. But
> Erik> getting to a redundant topology requires a deeper knowledge b

Re: [homenet] draft-chown-homenet-arch-00.txt

[james woodyatt]

On Oct 12, 2011, at 4:58 AM, Russ White wrote:

> No, not really, because it assumes just what I don't want to assume
> --that end-to-end reachability is the default, and I must take specific
> actions in order to block specific pieces of reachability.

Those of us who still bear the scars of the debate over RFC 6092 well remember 
that the Simple Security document takes great pains to make no such assumption.

>> 1.2.  Use of Normative Keywords
>> 
>>   NOTE WELL: This document is not a standard, and conformance with
>>   it is not required in order to claim conformance with IETF
>>   standards for IPv6.  It uses the normative keywords defined in the
>>   previous section only for precision.
>> 
>>Particular attention is drawn to recommendation REC-49, which calls
>>for an easy way to set a gateway to a transparent mode of operation.
>> 
>> [...]
>> 3.4.  Passive Listeners
>> 
>> REC-49: Internet gateways with IPv6 simple security capabilities MUST
>>provide an easily selected configuration option that permits a
>>"transparent mode" of operation that forwards all unsolicited flows
>>regardless of forwarding direction, i.e., not to use the IPv6 simple
>>security capabilities of the gateway.  The transparent mode of
>>operation MAY be the default configuration.
>> 
>>In general, "transparent mode" will enable more flexibility and
>>reliability for applications that require devices to be contacted
>>inside the home directly, particularly in the absence of a protocol
>>as described in REC-48.  Operating in transparent mode may come at
>>the expense of security if there are IPv6 nodes in the home that do
>>not have their own host-based firewall capability and require a
>>firewall in the gateway in order not to be compromised.

The "MAY" in that recommendation was the subject of about two years of teeth 
gnashing and garment rending, which I hope this working group shall not repeat.


--
james woodyatt 
member of technical staff, core os networking



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

On Oct 12, 2011, at 8:46 AM, Ole Troan wrote:
> 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.

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - flash/stable storage constraints

[Jim Gettys]

On 10/11/2011 12:05 AM, Jari Arkko wrote:
> Home routers would also have MAC addresses, but again, if we need a
> 32-bit quantity then shortened 48/64 bit identifiers may
> (theoretically) have collisions.
>
> That being said, if the home routers have to discover their IPv6
> prefix through a protocol and store it in flash, they could probably
> do so also for a router ID. Unless there was some chicken and egg
> problem that required the router ID for all this discovery to work...
As to storing in flash, since most in homenet have not typically worked
on embedded systems, worse luck...

There is typically a read/write file system that can store state on a
current Linux home router (e.g. OpenWrt); it may or may not mapped over
the entire flash (which is desirable, as you'd like wear levelling to
use all blocks on the flash).

The bulk of the firmware is likely contained in a read-only file system
called Squashfs, which does LZW compression on a per file basis;
overlayed on top may be a read/write file system.

Most commonly the read/write file system has been a file system called
jffs2 over bare flash, originally implemented on the Compaq iPAQ
handheld, a project I helped lead after I got sick of HTTP.  And OLPC
had a gigabyte of flash (which pushes jffs2 to/beyond it's design
limits). There are later flash file systems under development, but I
don't have first hand experience with any of them.

Flash has the characteristic that write is relatively slow, and erase is
generally glacial.  Most interesting flash file systems try to do lazy
erasure (erase freed blocks when they have a chance later, rather than
at the time you may free a file).

Since you don't want to wear out the flash, the jffs2 does journaling;
one write will commit (potentially) a bunch of changes to multiple
files, rather than each write generating one write.

How many writes you get depends on the flash technology, whether the
flash is "bare" or has some "smart" controller, and the wear levelling
technology (if any) in use, along with whether all blocks participate in
the wear levelling or not (jffs2 does good wear levelling; but using a
big squashfs file system + a very small jffs2 file system will reduce
the effectiveness; some cheap USB storage devices only do wear levelling
on the free blocks, and try to hide the fact it is flash from the system
above.  I put "smart" in quotes, because they've often been hideously
stupid, with their smarts limited to looking like IDE with a very lame
flash translation layer.  The most recent "smart" flash disks for
laptops are actually getting very smart, with some help from the OS to
help with the erasure problem.  But they still cost substantially more,
I suspect.

I think most home routers currently use bare flash, though it's not
clear to me if this will continue or not since the volume market may
make the economics change.

In any case, with flash of any sort, you don't want to sit there and
demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime,
for example). 

All this being said, storing state at the rate of machines/routers
appearing or disappearing on a home network, or your ISP going down,
isn't likely to cause a problem.  You just have to be careful enough to
not do anything really stupid; e.g. you map daemons with chatty logs to
run their logs to /dev/null, or to tempfs in RAM. And you might take a
big latency hit if you have to guarantee the write is stable before
continuing an algorithm (if you run into needing to erase a block for
some reason).  And obviously you don't write tons of data when you don't
half to. And update in place may be a bad idea relative to other
techniques (which is why journaling file systems such as jffs2 are so
desirable).

- Jim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - scaling

[Jim Gettys]

I've alluded to having suffered from routing problems in the past, and
urged people to be very careful about scaling, and interacting with
unexpected/unintended neighbours, something that seldom happens in wired
networking.

I thought I'd elaborate slightly to help people focus on the problems.

Both of these experiences come from my tenure at OLPC, which attempted
to deploy mesh networking, where I worried about the base system
software (but not the networking, in particular; Michailis Bletsas was
in charge of that).  Both added grey hair to my head and scars to our
backs.

1) we had a situation, in which one of our machines tickled a bug in
existing routers being used in an apartment building causing most all of
the home networks in the apartment building to crash, to the point of
needing reboot.  It wasn't our bug; but it was sure our problem :-(.
This is about all I can say on an open list about what happened here.

The moral: lots of people can hear the packets you transmit; ensuring
nothing bad will happen is "interesting".  The packets escape into the
"ether" and may have consequences you don't anticipate.  And just
because you think that there are only a few participants in a
conversation doesn't make it so.

2) The 802.11s committee, in their infinite wisdom, specified a routing
protocol at layer 2. At least in the draft standard we were working
from, the properties of this routing algorithm had the consequence of
N^2 messages where N was determined by the number of machines that could
hear each other simultaneously (each machine that heard you looking for
the exit to the mesh would each turn around and send another message). I
don't know if the current version of the standard is so brain-dead or
not: the committee had ruled the scaling problem "out of scope" for the
group: after all, no one would ever think of running a mesh in such a
circumstance.  Reality is that kids show up at school at the same time,
(or people enter a conference room at the same time), and it happens.
Let us not suffer from the attitude the IEEE did with 802.11s.

 It doesn't take many machines (somewhere between 15 and 30), that can
hear each other to fry your channel entirely.  It was so bad that we
could only get about 14-16 bits into the preamble of the message before
someone else would transmit and step on the attempted transmission:
another words, the network completely collapsed with scale.

We called this the "dense mesh" problem. Any routing protocol used on
wireless should be evaluated for its scaling properties carefully.

Your first ARP would, of course, trigger this melt down.

The third problem we had in networking we didn't figure out at all: that
awaited my personal encounter with bufferbloat to understand.
- Jim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Does ND Proxy useful for homenet?

[Victor Kuarsingh]

Mark,

A few points on this topic.

As noted, the Cell system will have PD capabilities until a future 3GPP
release (Rel-10) as noted.  Although, even when the functionality is in
place (generally), small devices like Smartphone and the mini gateways
(3G/LTE devices which allow for 4-5 hosts to attached to Cell system) -
PDs may not be used.

Many of these devices (I.e in the case of the smartphone) have modes of
operation where they "tether", which turns them into a mini gateway.  They
are not likely to be be full blown gateways equivalent to what you see
common CPEs.

In the IPv4 case, these devices "NAT" the IPv4 private addresses used by
hosts behind the device to the network assigned address.  In the case of
IPv6, it will have access to the network assigned ::/64.  PCs (maybe other
devices) behind such devices will need access to the IPv6 network, but may
not have access to PD space.  This was one of the specific use cases I was
eluding to before.

These devices (in such operating modes) are however not likely to
participate in a home network (as the gateway device or a router) and it's
very unlikely to be the head of home network.

With this explanation, I am not sure if this should/would be considered as
such in HomeNet.  These devices technically become gateways/bridges to the
Internet.  And the hosts that use them are often the same type of devices
which connect to common home networks.

Regards,

Victor K


On 11-10-10 4:51 PM, "Rajeev Koodli"  wrote:

>
>Hi,
>
>The smartphone will only get a /64 in the current 3G/4G releases (rel-8,
>rel-9).
>
>Prefix delegation is specified in Rel-10.
>
>-Rajeev
>
>
>
>On 10/10/11 1:01 PM, "Mark Townsley"  wrote:
>
>>> 
>>> Or are you saying a mobile device (a smartphone) will only ever get a
>>> /64 to share?
>> 
>> My (limited) understanding of the various 3/4G standards are that a PD
>>for a
>> phone is something that is very, very, recent. Perhaps Rajeev (cc'd) or
>> someone else here can elucidate.
>> 
>> - Mark
>> 
>
>___
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet strawman slides

[Erik Nordmark]

On 10/10/11 1:17 PM, Michael Richardson wrote:



"Erik" == Erik Nordmark  writes:

 Erik>  There might be some more difficult aspects if we want to allow
 Erik>  a router or its interfaces to be repurposed, such as splitting
 Erik>  an existing link into two separate links. In that case it
 Erik>  might be hard to avoid renumbering. The requirements question

Moving/repurposing a router without a factory reset seems like the
perhaps the most important source of conflict in the architecture that
we discussed.  Particularly if the router is put into a junk drawer for
a few months until it is needed.

So, we might need to consider if we can expire persisted settings after
some long (from the point of view of the network) time, like 1 week...


FWIW My existing IPv4 NATting home routers don't need to be quaranteened 
for a week; I can just rewire. At worst I have to power cycle.


I thought IPv6 would make things better ;-)

   Erik

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ole Troan]

Ted,

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

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

On Oct 12, 2011, at 4:48 AM, Ole Troan wrote:
> 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 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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Russ White]

> Russ> You need a unique identifier at the equipment level for
> Russ> anything you intend to auto-configure --autoconfiguring
> Russ> uniqueness is a very hard, probably impossible, problem on a
> Russ> global scale. So we need to count on this one thing, no matter
> Russ> what else we might need to back in to.
> 
> Russ> Now, it might be possible to some hash over a GPS location for
> Russ> a "base," and then add on MAC addresses, or some such, but
> 
> We've assumed a unique MAC, which is 48 bits long. 
> But OSPF router-id is 32 bits.What is the likelyhood of a collision 
> in the bottom 32-bits of the MAC? 

Ah, I see the problem... There is a pretty high likelihood of a
collision, actually, at least as long as you use multiple vendors in
your home network. It's bound to happen to someone, someplace.

So, a suggestion to resolve this:

1. Use the lower 32 bits of one of the mac addresses on the box as the
initial id.

2. Add a new field to the router capabilities that carries the full 48
bit mac address, or even some munged together "longer id," based on
multiple mac addresses on the device, or some such.

3. During initial setup, if you receive a capability that appears to be
from yourself, you open this secondary id section to find out if it's
really you, or someone else who happens to have the same 32 bit id.

4. If it's really you, discard the packet.

5. If it's not really you, and if the other router's "large id" is lower
than yours, choose another mac address from which to take your local id,
and restart your ospf process.

6. If it's not really you, and the other router's "large id" is higher
than yours, then send a router capabilities LSA unicast to this "other
router," so the "other router" knows to change its id.

I don't think IS-IS would have this problem.

:-)

Russ
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet strawman slides

[Henk Uijterwaal]

On 11/10/2011 14:23, Michael Richardson wrote:
> 
>> "Curtis" == Curtis Villamizar  writes:
> Curtis> I really don't know how many support calls are just the consumer 
> Curtis> plugging the computer into the wrong Ethernet port on the NAT box
> and Curtis> the uplink on the other port and then not being able to figure
> out Curtis> what is wrong.  All the cables fit in the connector.  It should
> work!
> 
> So, I was interrupted yesterday, reading homenet email, in order to go to
> my neighbour's house and sort out this EXACT problem.

My box and the cables at home have connectors in different colors, making
it easy to plug the right cable in the right port.

Henk

-- 
--
Henk Uijterwaal   Email: henk(at)uijterwaal.nl
  http://www.uijterwaal.nl
  Phone: +31.6.55861746
--

There appears to have been a collective retreat from reality that day.
 (John Glanfield, on an engineering project)
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft-chown-homenet-arch-00.txt

[Russ White]

> I think you are quoting from the "Transparent End-to-End Communications"
> section on pages 14/15 which is to do with communications _within_ the home 
> network.

Yes... I understand the rational behind not wanting a NAT within the
home, but the text reads in a much larger way. And the anti-NAT bits
aren't just limited to that one section, but rather scattered throughout.

So I would say --

1. Take out the bits about "we don't want NAT."
2. Replace them with a single section detailing exactly what you want in
terms of "transparent end-to-end communications" specifically within the
home.

> Is this really true? When I want to secure a physical space, I block off
> all access, then put in carefully thought out access control points. I
> don't pile all my goods in the middle of the street, and then actively
> monitor every person who walks by, hiring more people to do the
> monitoring as needed.
> ...
> 
> Generally speaking, I want open access within my home network,
> but may add specific rules to stop e.g. guest wi-fi getting to certain
> servers.

You want guests to be able to get to all servers by default, unless you
specifically go into a configuration on some device?

What's really needed is the ability to divide things into "domains,"
probably requiring some form of local directory server, and then
controlling who is in what domain. Anything within a domain can access
anything else within the same domain by default, and cannot access
anything in the other domain by default, including network connections.

> See " Security, Borders, and the elimination of NAT" section on page 5.
> ---
>   [RFC6092] provides recommendations for an IPv6 firewall that
>   applies "limitations on end-to-end transparency where security
>   considerations are deemed important to promote local and Internet
>   security."  The firewall operation is "simple" in that there is an
>   assumption that traffic which is to be blocked by default is
>   defined in the RFC and not expected to be updated by the user or
>   otherwise.  The RFC also discusses an option for CPEs to have an
>   option to be put into a "transparent mode" of operation.
> 
>   It is important to distinguish between addressability and
>   reachability; i.e.  IPv6 through use of globally unique addressing
>   in the home makes all devices potentially reachable from anywhere.
>   Whether they are or not should depend on firewall or filtering
>   behaviour, and not the presence or use of NAT. ...
> ---
> 
> Does this address you concerns?

No, not really, because it assumes just what I don't want to assume
--that end-to-end reachability is the default, and I must take specific
actions in order to block specific pieces of reachability.

If you want, I'll try and suggest wording later today or tomorrow.

:-)

Russ

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[C Chauvenet]

Le 12 oct. 2011 à 13:51, Russ White a écrit :

> 
>>> You are absolutely right that pulling cable is hard and expensive.
>> 
>> Pulling cable is indeed hard and expensive. In my experience, it is the 
>> right thing for some applications, such as TV and my home office. 
>> Personally, I have both wired and wireless throughout the house; my personal 
>> rule is that I use the shared wireless network for activities that move 
>> around, to provide convenience at the expense of consistency and bandwidth, 
>> and wired for things that stand still, to provide stable bandwidth at the 
>> price of a one-time wiring effort.
> 
> I do the same --I pull cable for televisions, and even for locations
> where a desktop or laptop is going to be sitting on a regular basis. So
> I think we should expect wired and wireless as the norm, rather than
> expecting wireless all the time.


I agree.
I may have precised "pulling *NEW* cable is hard and expensive" in my sentence.

> 
> While I wouldn't want to rule OLSRv2 completely out, I think it should
> compete head to head with an extended OSPF and an extended IS-IS, or
> even other efforts afoot. I'd rather see requirements first, and a good
> solid evaluation of what's available against those requirements, rather
> than choosing technologies out of the gate.
> 
> :-)

I think it is a good process, for each competing protocol.

> 
> Russ

Cédric.

> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Russ White]

>> You are absolutely right that pulling cable is hard and expensive.
> 
> Pulling cable is indeed hard and expensive. In my experience, it is the right 
> thing for some applications, such as TV and my home office. Personally, I 
> have both wired and wireless throughout the house; my personal rule is that I 
> use the shared wireless network for activities that move around, to provide 
> convenience at the expense of consistency and bandwidth, and wired for things 
> that stand still, to provide stable bandwidth at the price of a one-time 
> wiring effort.

I do the same --I pull cable for televisions, and even for locations
where a desktop or laptop is going to be sitting on a regular basis. So
I think we should expect wired and wireless as the norm, rather than
expecting wireless all the time.

While I wouldn't want to rule OLSRv2 completely out, I think it should
compete head to head with an extended OSPF and an extended IS-IS, or
even other efforts afoot. I'd rather see requirements first, and a good
solid evaluation of what's available against those requirements, rather
than choosing technologies out of the gate.

:-)

Russ
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Stephen Farrell]

On 10/12/2011 09:48 AM, Ole Troan wrote:

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?


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


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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[Fred Baker]

On Oct 12, 2011, at 3:44 AM, C Chauvenet wrote:

> You are absolutely right that pulling cable is hard and expensive.

Pulling cable is indeed hard and expensive. In my experience, it is the right 
thing for some applications, such as TV and my home office. Personally, I have 
both wired and wireless throughout the house; my personal rule is that I use 
the shared wireless network for activities that move around, to provide 
convenience at the expense of consistency and bandwidth, and wired for things 
that stand still, to provide stable bandwidth at the price of a one-time wiring 
effort.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ole Troan]

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

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



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Riccardo Bernardini]

2011/10/12 Joel jaeggli 

> On 10/11/11 18:38 , Ted Lemon wrote:
> > On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote:
> >> 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.
> >
> > 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.
>

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.

>
> > 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
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet strawman slides

[Ole Troan]

Erik,

btw, "border discovery" needs to be done regardless of topology or prefix 
assignment solution choice.
on a border you (may) want firewall on, you want a ULA border, you want a 
organisational or site multicast border...

cheers,
Ole
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing - trends

[C Chauvenet]

Hi Jim, 

I agree with you.

Let me just add a few words on #2 : 

You are absolutely right that pulling cable is hard and expensive.
That is the rationale of PLC : Using existing wires.

PLC is already used reliabily for high speed networking, but you are correct 
that it is
not as popular as Wireless. Mostly because networking devices already embed a 
Wifi and/Or Ethernet
interface, rather than a PLC interface. 
So people don't see the need of buying additional material for a connectivity 
they already have…

Though people use PLC because they feel surrounded by RF, or they cannot reach 
some point of the network with wireless, 
or the PLC device is provided by their ISP (like in France).
(There are others reasons for using PLC outside the home, but I think it is out 
of the scope of Homenet).

PLC also suffers from a lack of standardization, and different 
technologies/Standards are often non-interoperable, or simply cannot coexist on 
the same electrical grid.

An effort is ongoing in IEEE P1901.2 to create a standard for low frequency 
narrowband PLC.

Just my 2 cts,
Cédric.

Le 11 oct. 2011 à 21:10, Jim Gettys a écrit :

> On 10/07/2011 03:48 AM, Fred Baker wrote:
>> 4) The use of OLSR in mesh network scenarios 
>> 
>> Jim Gettys commented on the fact of OLSR use. The general sense of the room 
>> was that OLSRv2 is interesting but out of scope for this discussion as mesh 
>> networks are quite different from typical residential and SOHO networks.
>> 
> Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my
> area of expertise. 
> 
> Babel/BabelZ is appearing in CeroWrt today as the people who are
> interested in such things are doing the work (we don't need a routing
> protocol in the simple single home router case), and it provided the
> functionality we needed.
> 
> For those who want something else, quagga is in the CeroWrt build for
> your hacking pleasure.
> 
> And I'm not advocating the homenet working group do anything unusual
> about routing at this date; as I said, it's not my area of expertise.
> 
> Having said this, I do note the following technological trends:
> 
> 1) As soon as we get real "plug and play" routers that don't need manual
> configuration that work, we'll see a lot more routers in a home
> environment.  Other radio technologies (e.g. zigbee) may encourage this
> trend.  It seemed like the working group agreed that getting to the
> point that just hooking things together would really "just worked" was a
> fundamental requirement (and I agree entirely with this sentiment, as it
> reflects reality of what already happens in the homes of hackers and
> non-hackers alike).
> 
> 2) wireless is much cheaper to implement than wired networking,
> particularly in most houses where pulling cable is hard.  I know this
> first hand, where I've pulled a lot of cat 6 and wish I could get it to
> places I don't have it.
> 
> Unless power line networking really works, I believe that this trend
> isn't going to change.  Is there any progress in this area?  I've seen
> many promises, and few reliable working products.
> 
> 3) As soon as you have two routers, you have at least two paths; the
> wired connection between them and the wireless.  You may have 3 paths,
> if you have both 2.4 and 5ghz radios. Frequency diversity routing
> becomes immediately interesting, along with using your ethernet when
> it's available in preference to wireless.
> 
> 4) an apartment building look like a mesh, and possibly with multiple
> backhauls possibly with multiple ISP's. One should at least think about
> what happens when you have "homes", in such a building, and make sure
> nothing breaks. Wireless is messy: it isn't limited to where a wire
> goes.  Taking down an entire apartment building/blocks/city would not be
> fun.  I know, I've been there (at least to the point of taking down
> buildings, and came within a week of a much larger scale disaster).
> 
> If you believe 1 + 2 + 3 +4  (as I do), then if you look a few years
> out, you end up with something in the "home" that begins to resemble
> very strongly what the community mesh networking folks are doing at a
> higher scale geographically and in terms of # of nodes today, with
> many/most of the same concerns and solutions. Understanding the problems
> they've faced/are facing is therefore worth a bit of investment; Radio
> diversity is one of the concerns, and interference (of various sorts).
> 
> Julius' talk about why frequency diversity is an issue is here:
> 
> http://www.youtube.com/watch?v=1VNzm0shSA8
> 
> While the issues outlined above are not where home networking is today,
> my gut feel is they will be in five years.
> 
> If there is *anything* I can urge on the group, is to respect the
> scaling problems that can/will occur, and to internalise wireless
> !=wired: wireless goes where wireless goes and does not behave like
> ethernet. The group needs to ensure nothing "bad" happens when people
> start building systems in ways