Re: [homenet] time service and DNSSEC

[Curtis Villamizar]

In message <17498.1318559...@marajade.sandelman.ca>
Michael Richardson writes:
 
>  
> > "Curtis" == Curtis Villamizar  writes:
> Curtis> Neither KARP, as defined, or DNSSEC, are candidates for zero
> Curtis> configuration.  If the user can configure KARP and DNSSEC
> Curtis> they are perfectly capable of using a backdoor, like ssh, to
> Curtis> set the time of day after a reboot that lost time-of-day.
>  
> huh?
> DNSSEC just requires the . key be distributed in the router's firmware.


duh.

I'm thinking about acting as a NS and signing the zone.  Never mind.
For DNSSEC resolver no configuration is needed.

For that purpose getting time of day through NTP or even timed (not
suggesting timed) would be fine.

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

Re: [homenet] Thoughts about routing

[Michael Richardson]

> "Joe" == Joe Touch  writes:
Joe> On Oct 13, 2011, at 1:30 PM, Curtis Villamizar
Joe>  wrote:
>> I'm not fond of protocols that rely on time or monotonically
>> increasing reboot counts and have no fallback.

Joe> +1

Joe> Let's not add time as an attack vector.

So, hypothetical attacks via DHCP, which require access to impersonate
the DHCP or PPP server of the ISP are more important than getting a
notion about time so you can prevent DNS attacks?

Tet's talk about what other things you can do if you can hijack the
network connection like that... and how many of them are resolved if
DNSSEC can be used.






pgpc0cm0EGwr0.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] time service and DNSSEC

[Michael Richardson]

> "Curtis" == Curtis Villamizar  writes:
Curtis> Neither KARP, as defined, or DNSSEC, are candidates for zero
Curtis> configuration.  If the user can configure KARP and DNSSEC
Curtis> they are perfectly capable of using a backdoor, like ssh, to
Curtis> set the time of day after a reboot that lost time-of-day.

huh?
DNSSEC just requires the . key be distributed in the router's firmware.

-- 
]   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] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

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

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

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

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

[Lorenzo Colitti]

On Wed, Oct 12, 2011 at 05:33, Ted Lemon  wrote:

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

I'd say that electrical systems are as susceptible to rogue devices just as
much as zeroconf routing systems are. If you plug a short into a socket, you
trip a circuit breaker and you deny service to other appliances (i.e., "your
house goes dark").
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Thoughts about routing

[Lorenzo Colitti]

On Mon, Oct 10, 2011 at 14:16, Curtis Villamizar  wrote:

> Random number selection for router-id and this sort of recovery would
> solve the zero config OSPF issue related to router-id selection.
>
> Not yet solved in existing zospf draft (afaik) but solvable.


zOSPF says what do do in the case of collisions if the router with duplicate
ID is on the same link, but not if it is elsewhere. However, I think it can
be made to work like this:

1. On startup, choose the router ID you had on last boot (if available) or a
random number.
2. Start OSPF with this router ID.
3. If you see a hello packet from a neighbour with your own router ID, you
have a collision on the local link. Change it and back off.
4. If you see a router LSA listing you as a neighbour, but the router ID
that originated this LSA is not a neighbour of yours, you have a duplicate
router ID. Change it and back off.

Are there any cases this does not cover?

As to what to do if there is a collision, I'm not sure. zOSPF says what you
and your neighbours should do if the colliding router is on your link, but I
don't know if that's enough if the colliding router is elsewhere. Any OSPF
experts know the answer to this?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Victor Kuarsingh]

On 11-10-13 7:49 AM, "Russ White"  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).
>
>This won't be the "corner case," it will be the "common case," in most
>all homes. The electricity providers are seeing to that right now, as
>well as the cell phone providers. In a few years, someone is going to
>say, "you only have one internet connection? You poor soul, we need to
>find some government program to help you."

Russ, I agree the mobile network will be used widely in home networks by
the residential and business customers (as you noted electricity
providers).  Although I would suppose those connections will not be using
cell phones for connectivity, but more gateway style devices with a
2G/3G/4G connection.  Most of these devices tend to be somewhat stationary
(I.e. Meters, parking kiosks, etc).  Some devices are nomadic but those
tend to be end points themselves with built in radios.

The corner case I was talking about was the use of a smartphone (generally
nomadic device) as a gateway with the expectation that when at home
becomes an active part of the home network fabric and exchanges routing
information.  When the person turns off their phone, leaves the house, etc
- the device would then be removed from the network (assuming it attached
in the first place).

Assuming for now that this will be common case (my iPHone/Android Phone is
part of my home network when I show up at home and then disappears when I
leave) - I would have some concerns if this was all automatic with
absolutely no user intervention or permission.

I can imagine a use cases where a bunch of friends show up at a house
party and become a mesh network with many attachments to the network
(assuming all automatic and happens without user intervention - as one of
the previous comments had noted was a possibility).  Not sure how that
would work - and I would not want to be the guy who's phone was chosen
(automatically) to be the gateway for all (my bill may be quite large that
month).

All that said, I would likely lean toward the notion that smartphone
vendors, if they make their devices full gateways for such use, would not
just make this fully automatic such that it would happen by accident.  A
simple "do you want to attach to X" popup/message may be warranted.  If
so, then the phone can move from "I am a lone gateway with small local
network mode" to "I am now a router in a larger network" and augment
functions accordingly.

The former case, which is very common now, needs to be addressed (and for
a while may have not PD).  I would not also want to assume that all the
smartphone vendors will build amazing gateways for such uses (vendors who
always maximize CPU/Memory to make sure the user has all the power they
will ever need and never cheap out to squeeze as much profit by lowering
COGs).

I would at minimum assume that some smart phones will be very smart and
may attach to bigger networks (I hope with some type of prompt) and others
will be less smart and built to provide bare minimum gateway
functionality. 

Regards,

Victor K


>
>:-)
>
>Russ
>
>___
>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...

[Russ White]

>> It is best to find some reasonable ground where 90% of the people in
>> the world will find the security acceptable, and then let the 10% who
>> care configure the rest.
>>  
>> But I would also point out that the argument you're making can be
>> applied to applications as well as network gear.

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

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

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

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

:-)

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

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

[Russ White]

> Following that analogy, the door locks built my certain OS vendors are
> both flimsy and easily picked.
> 
> And we should not enable tftp and point it at the root directory and
> hope that some smart network appliance will somehow firewall us.

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

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

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

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

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

:-)

Russ

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

Re: [homenet] Thoughts about routing

[Jim Gettys]

On 10/13/2011 05:40 PM, Curtis Villamizar wrote:
> In message <4e973605.50...@freedesktop.org>
> Jim Gettys writes:
>  
>> On 10/13/2011 02:42 PM, Curtis Villamizar wrote:
>>> Yes and there are/were ATM switches that implement RFC1577, LANE,
>>> MPOA, and NHRP.  None of that worked very well and it all is
>>> essentially abandoned work now.  Pre-existence alone is not a worth
>>> while evaluation criteria.
>>>
>>> If zOSPF works perfectly, including in the presence of legacy routers
>>> which don't look at a new 48 bit mac address router-id extension, we
>>> have no reason to continue the discussion.  We just indicate "use
>>> zOSPF" and we're done.
>>>
>>> There seems to be consensus that we're not done.
>>>
>> On my part, I'm interested in understanding the following:
>> o scaling properties: I worry about the apartment building case, and
>>   related dense mesh case.
> Yep.  OSPF as is may not be appropriate for wireless mesh.  WG needs
> to consider this.
>
>> o behaviour when routing both wired and wireless networks.
>> o multicast behaviour and impact on wireless networks.
>> o running code
> Running code is too seldom available when the IETF rushes forward
> these days.  A reference implementation would be great.  I know which
> code base you have in mind.

I've been badly burned by standards committees in the past on this
topic.  Happens to be the IEEE folks, however.  Ergo my belief in both
running code and testing in diverse environments outside of laboratories
and meeting rooms.

And, in the case of the home router market, code has to come from some
place. Advocating something that has to be built from scratch seems like
a losing strategy.
>
>> And I'll ask the same about any other routing protocol you wish to
>> name.  I'm an equal opportunity parade rainer...
>> - Jim
> I haven't checked cerowrt to see how much configuration is required of
> OSPF.  
All Dave did was build and package quagga so that others could
conveniently start to play.

> If it is quagga, then a router-id has to be configured and each
> interface has to have OSPF explicitly enabled all with a Cisco style
> line oriented config.
Quagga has been packaged.  You can build other  stuff and packaged it
too, and the code is available to be modified.
- Jim


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

Re: [homenet] Thoughts about routing

[Joe Touch]

On Oct 13, 2011, at 1:30 PM, Curtis Villamizar  wrote:
> I'm not fond of protocols that rely on time or monotonically
> increasing reboot counts and have no fallback.

+1

Let's not add time as an attack vector. 

Joe

___
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 13, 2011, at 7:02 PM, Curtis Villamizar wrote:
> And therefore risk there is mostly theft of service as I have already
> pointed out.

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

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

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

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

Re: [homenet] time service and DNSSEC

[Jim Gettys]

On 10/13/2011 06:15 PM, Curtis Villamizar wrote:
> In message <4e974d95.3000...@freedesktop.org>
> Jim Gettys writes:
>>> Sorry, but I lost track of why this is an issue for homenet.  What
>>> zero config crypto are we talking about that may care if it loses time
>>> of day?
>>>
>> DNSSEC.
>>  
>> And as routers are already being attacked, getting DNSSEC secure
>> end-to-end seems like the right strategy.
>> - Jim
>
> Trimmed response.
>
> I don't follow the logic here.
>
> I don't see any relationship between "routers are already being
> attacked" and DNSSEC.
>
> The homenet user is not going to get DNS or DNSSEC configured for the
> LAN addresses on their network so I'm not sure why the topic is even
> relevant to homenet.

Why not? Plug in a named computer, and publish it's name into the global
DNS... Proof of principle was demonstrated by Dave Taht and Evan Hunt
when they brought up
bind on CeroWrt even if it isn't in today's CeroWrt build.  It isn't
that hard...


>
> Back in the days when I was involved in big-I Internet operations
> routers purposely didn't run rely on DNS to avoid a chicken and egg
> problem (router can't reach DNS therefore routing is down).  Even logs
> used IP addresses and could be translated after the fact if need be.
>
> I'm quite knowledgeable in routers getting attacked.  The homenet
> routing protocol would be wise to use GTSM on things like OSPF.  Open
> routing on wireless might still be a bad idea.  Maybe keys or shared
> secret has to be added for wireless making it non-zero config.

Could be.  I have no clue what the community networking people are doing
about routing protocol security in OLSR or other protocols.  I certainly
*hope* they are doing something, as some of their networks are now in
the hundreds or even thousands of nodes...
- Jim


___
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 <7d42549b-0ec1-463e-8e62-765c295a2...@fugue.com>
Ted Lemon writes:
 
> On Oct 13, 2011, at 5:23 PM, Curtis Villamizar wrote:
> > And I responded to that in the same email and you trimmed that part of
> > the response in this email.
>  
> The problem has to do with customer-owned devices and
> customer-neighbor-owned devices forming networks together.  It's got
> nothing to do with the ISP.  Chances are, the ISP link is the one
> thing that won't be gotten wrong here, because only one device you own
> will be connected to it (at least in typical networks today).

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

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

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

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

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

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

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

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

Re: [homenet] time service and DNSSEC

[Curtis Villamizar]

In message <4e974d95.3000...@freedesktop.org>
Jim Gettys writes:
> >
> > Sorry, but I lost track of why this is an issue for homenet.  What
> > zero config crypto are we talking about that may care if it loses time
> > of day?
> >
> DNSSEC.
>  
> And as routers are already being attacked, getting DNSSEC secure
> end-to-end seems like the right strategy.
> - Jim


Trimmed response.

I don't follow the logic here.

I don't see any relationship between "routers are already being
attacked" and DNSSEC.

The homenet user is not going to get DNS or DNSSEC configured for the
LAN addresses on their network so I'm not sure why the topic is even
relevant to homenet.

Back in the days when I was involved in big-I Internet operations
routers purposely didn't run rely on DNS to avoid a chicken and egg
problem (router can't reach DNS therefore routing is down).  Even logs
used IP addresses and could be translated after the fact if need be.

I'm quite knowledgeable in routers getting attacked.  The homenet
routing protocol would be wise to use GTSM on things like OSPF.  Open
routing on wireless might still be a bad idea.  Maybe keys or shared
secret has to be added for wireless making it non-zero config.

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

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <4e973605.50...@freedesktop.org>
Jim Gettys writes:
 
> On 10/13/2011 02:42 PM, Curtis Villamizar wrote:
> >
> > Yes and there are/were ATM switches that implement RFC1577, LANE,
> > MPOA, and NHRP.  None of that worked very well and it all is
> > essentially abandoned work now.  Pre-existence alone is not a worth
> > while evaluation criteria.
> >
> > If zOSPF works perfectly, including in the presence of legacy routers
> > which don't look at a new 48 bit mac address router-id extension, we
> > have no reason to continue the discussion.  We just indicate "use
> > zOSPF" and we're done.
> >
> > There seems to be consensus that we're not done.
> >
> On my part, I'm interested in understanding the following:
> o scaling properties: I worry about the apartment building case, and
>   related dense mesh case.

Yep.  OSPF as is may not be appropriate for wireless mesh.  WG needs
to consider this.

> o behaviour when routing both wired and wireless networks.
> o multicast behaviour and impact on wireless networks.
> o running code

Running code is too seldom available when the IETF rushes forward
these days.  A reference implementation would be great.  I know which
code base you have in mind.

> And I'll ask the same about any other routing protocol you wish to
> name.  I'm an equal opportunity parade rainer...
> - Jim

I haven't checked cerowrt to see how much configuration is required of
OSPF.  If it is quagga, then a router-id has to be configured and each
interface has to have OSPF explicitly enabled all with a Cisco style
line oriented config.

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

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

[Ray Bellis]

On 11 Oct 2011, at 18:13, Stephen Farrell wrote:

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

We're certainly expecting to think about it.

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

Ray

___
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 13, 2011, at 5:23 PM, Curtis Villamizar wrote:
> And I responded to that in the same email and you trimmed that part of
> the response in this email.

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

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

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

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

[Mark Townsley]

On Oct 13, 2011, at 5:23 PM, Curtis Villamizar wrote:

> 
> In message <300ce19e-b3d6-4742-82ed-02f8167c9...@fugue.com>
> Ted Lemon writes:
> 
>> On Oct 13, 2011, at 2:35 PM, Curtis Villamizar wrote:
>>> You've said what the problem *isn't*, so what *is* the problem on a
>>> homenet?
>> 
>> I did say what the problem is:
>> 
 If you autoconfigure a routing topology, you have to make sure that
 you don't accidentally autoconfigure it to include routers that
 weren't intended to have been included.

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

- Mark

> 
> 
> And I responded to that in the same email and you trimmed that part of
> the response in this email.
> 
> 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] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <300ce19e-b3d6-4742-82ed-02f8167c9...@fugue.com>
Ted Lemon writes:
 
> On Oct 13, 2011, at 2:35 PM, Curtis Villamizar wrote:
> > You've said what the problem *isn't*, so what *is* the problem on a
> > homenet?
>  
> I did say what the problem is:
>  
> >> If you autoconfigure a routing topology, you have to make sure that
> >> you don't accidentally autoconfigure it to include routers that
> >> weren't intended to have been included.


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

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

Re: [homenet] time service and DNSSEC

[Jim Gettys]

On 10/13/2011 04:41 PM, Curtis Villamizar wrote:
> In message <17165.1318514...@marajade.sandelman.ca>
> Michael Richardson writes:
>  
>>> "Curtis" == Curtis Villamizar  writes:
>> >> While talking about hardware.  These these devices all need a
>> >> battery backed clock or all the crypto will be broken.
>>  
>>  
>> Curtis> Having a clock is not hard but I don't think your statement
>> Curtis> is true.
>>  
>> Curtis> Some crypto does not require time, but rather just entropy
>> Curtis> (a nonce or challenge).  For crypto that does require time
>> Curtis> the former can be a bootstrap of sorts, possibly to get ntp
>> Curtis> going if very accurate time is needed (for some reason).
>>  
>> Curtis, Mark, as a DNSSEC implementer knows of what he speaks.  DNSSEC
>> requires time.  Not to the second or even minute, but at least hour.
>>  
>> DNSSEC is a core protocol at this point, and we need to be aware of
>> it.  It doesn't matter today, because we have a broken home DNS
>> system, but that's within homenet to fix.
>>  
>> Bootstraping time enough to get DNSSEC to work is important.
>
> I was thinking routing protocols and KARP.
>
> We are talking about routers and relying on DNS to get routing up is
> always a really bad idea.  Relying on NTP to get routing up is also a
> bad idea.
>
> Neither KARP, as defined, or DNSSEC, are candidates for zero
> configuration.  If the user can configure KARP and DNSSEC they are
> perfectly capable of using a backdoor, like ssh, to set the time of
> day after a reboot that lost time-of-day.
>
> Sorry, but I lost track of why this is an issue for homenet.  What
> zero config crypto are we talking about that may care if it loses time
> of day?
>
DNSSEC.

And as routers are already being attacked, getting DNSSEC secure
end-to-end seems like the right strategy.
- Jim

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

Re: [homenet] time service and DNSSEC

[Curtis Villamizar]

In message <17165.1318514...@marajade.sandelman.ca>
Michael Richardson writes:
 
> > "Curtis" == Curtis Villamizar  writes:
> >> While talking about hardware.  These these devices all need a
> >> battery backed clock or all the crypto will be broken.
>  
>  
> Curtis> Having a clock is not hard but I don't think your statement
> Curtis> is true.
>  
> Curtis> Some crypto does not require time, but rather just entropy
> Curtis> (a nonce or challenge).  For crypto that does require time
> Curtis> the former can be a bootstrap of sorts, possibly to get ntp
> Curtis> going if very accurate time is needed (for some reason).
>  
> Curtis, Mark, as a DNSSEC implementer knows of what he speaks.  DNSSEC
> requires time.  Not to the second or even minute, but at least hour.
>  
> DNSSEC is a core protocol at this point, and we need to be aware of
> it.  It doesn't matter today, because we have a broken home DNS
> system, but that's within homenet to fix.
>  
> Bootstraping time enough to get DNSSEC to work is important.


I was thinking routing protocols and KARP.

We are talking about routers and relying on DNS to get routing up is
always a really bad idea.  Relying on NTP to get routing up is also a
bad idea.

Neither KARP, as defined, or DNSSEC, are candidates for zero
configuration.  If the user can configure KARP and DNSSEC they are
perfectly capable of using a backdoor, like ssh, to set the time of
day after a reboot that lost time-of-day.

Sorry, but I lost track of why this is an issue for homenet.  What
zero config crypto are we talking about that may care if it loses time
of day?

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

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <14861.1318513...@marajade.sandelman.ca>
Michael Richardson writes:
 
> > "Mark" == Mark Andrews  writes:
> >> Or you solve the time problem some other way...
> >> 
> >> Batteries die too...  Jim
>  
> Mark> Indeed.  It should be a user servicable part.
>  
> Mark> As to solving it other way, "leap of faith" springs to mind.
>  
> DHCP has an NTP server option.  Does IP6CP?


If you are trying to validate keys or certificates or proteocol
extensions that require knowing the time of day, then using the DHCP
supplied NTP server might not be a great idea.

I'm not fond of protocols that rely on time or monotonically
increasing reboot counts and have no fallback.  I advocated in OSPF
discussions relevant to KARP (to no avail) having at least a fallback
to a mechanism in which time of day or reboot count was not
significant.

This means no certificate expiration check is possible for the
fallback but its better than no connectivity.  The lack of certificate
expiration can be compensated for by creating an explicit revokation
after the key expires and storing that.

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

Re: [homenet] Thoughts about routing - trends

[Curtis Villamizar]

Off list.

In message <4e96d145.5090...@riw.us>
Russ White writes:
 
>  
> > 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!
>  
> Pulled from cable hanging in a "plenum" in a secure building... Because
> there was no way to get cable floor to floor other than through that
> single shaft. For a Xerox Star system. Then there was the token bus for
> the little Novell network over in legal --another disaster. 

I managed to avoid token ring and novell.

> > 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).
>  
> IS-IS is easier to get to "zero config," and it's actually simpler in
> operation... Which is why I brought it up. :-)

I've used both.  Why do you think ISIS is simpler in operation?
Because people love to deal with NSAPs?

> > We will have to extend OSPF to make zero config possible.  The
> > extensions should be completely backwards compatible if at all
> > possible.
>  
> Yes, I agree... Or we need w new wired/wireless protocol that jumps both
> worlds, and would actually be acceptable and implemented by a large
> number of vendors. But that's another entire problem space...

We agree on something.  That's good.  :-)

The clueless vendor problem space is a tough one.

> :-)
>  
> Russ

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

Re: [homenet] Homenet strawman slides

[Curtis Villamizar]

In message <4e96cfad.6090...@riw.us>
Russ White writes:
 
>  
> >> A router should not start handing out PD or even IPv4 NAT space until
> >> it gets and address from elsewhere.
>  
> In other words, your home network should be unusable unless at least one
> edge device is connected to the "real world." I can just imagine the
> support calls the local provider will get when they have a local outage.
>  
> "I'm sorry, sir, but that's the way it works --you can't print or stream
> movies from your console unless your internet connection is up."
>  
> Yeah, that's going to fly.
>  
> :-)
>  
> Russ


Maybe mail crossed.  IPv6 can function with just link local and ULA
until it gets a routeable prefix.  IPv4 is stuck handing out a NAT
address if it has no other configuration so modify the second part of
that sentence.

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 <4e96cf0b.8060...@riw.us>
Russ White writes:
 
>  
> > Is it better to leave the possibility of theft of service or is it
> > better to have the device unusable by default (until configured)?  
>  
> This is a false dichotomy, as well...
>  
> It is best to find some reasonable ground where 90% of the people in
> the world will find the security acceptable, and then let the 10% who
> care configure the rest.
>  
> But I would also point out that the argument you're making can be
> applied to applications as well as network gear.
>  
> :-)
>  
> Russ


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

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

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] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <4e96ce51.7020...@riw.us>
Russ White writes:
 
>  
> > 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*.
>  
> In other words, we should abandon door locks and make certain that
> anything you don't want stolen is individually secured --because only
> the device manufacturer could ever know how valuable it is, and how best
> to prevent it being stolen?

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

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

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

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

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

> > 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.
>  
> Security is an application function, yes. Security is also a network
> function, and security is a machine level function. All of these have a
> role to play in security.
>  
> :-)
>  
> Russ

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

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

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

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

:-)

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

:-)

> > 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] Homenet strawman slides

[Curtis Villamizar]

In message <2aa0f4ae-cade-4dd3-9701-fc0671712...@townsley.net>
Mark Townsley writes:
 
> On Oct 12, 2011, at 6:23 PM, james woodyatt wrote:
>  
> > 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.
>  
> Every IPv4 home router I have ever seen hands out RFC 1918 space
> regardless of whether an ISP connection is active. This is needed, if
> nothing else, to manage the router with the classic IPv4 literal in a
> web browser (yes, this could be done with link-local, but that's not
> something you can hard-code in documentation or a sticker on the side
> of the box).

For IPv4, routes can be installed for non-local link-local addresses
or ULA prefixes can be used if no address is available.

The practice of using 192.168.1.1 should be changed.  The change could
be as simple as a DNS mapping of "local-router." to the link local
addres.  A DHCP host query would get an offer of a DNS server which
would respond with a DNS entry for local-router.  The dot is
significant though if omitted the domain search list would be used
with the last entry presumed blank.  As long as there is no
"local-router." TLD glogally defined this should be OK.  A user with
multiple routers on the subnet can just paste the link-local address
in place.  Maybe routers can look for others and offer a
"local-router-N." for each other router detected.  Then
"http://"local-router."; or "http://"local-router-N."; can be used if
the user does need to do any config.

There could also be some improvement on the common practice of
allowing a default password on any port except the designated uplink.
In an auto-config router this would never change.  Perhaps this could
be enabled only 10 seconds or so after power up if the factory default
password is in place, at least limiting the exposure.  This could fit
in the manual and maybe even on a sticker.

But yes, IPv4 must hand out a PI address if it has nothing else to
hand out.

> > 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.
>  
> "Update" or just advertise the new global prefix alongside the ULA?
>  
> - Mark


I meant "update" in the context of refreshing the IA_PD request at the
provider DHCP server that handed it out the last time the demand
circuit was up.

If the prefix was held while the demand circuit was unused and down,
then no change is needed on the homenet side when the demand circuit
comes back up.

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

Re: [homenet] Thoughts about routing

[Jim Gettys]

On 10/13/2011 02:42 PM, Curtis Villamizar wrote:
>
> Yes and there are/were ATM switches that implement RFC1577, LANE,
> MPOA, and NHRP.  None of that worked very well and it all is
> essentially abandoned work now.  Pre-existence alone is not a worth
> while evaluation criteria.
>
> If zOSPF works perfectly, including in the presence of legacy routers
> which don't look at a new 48 bit mac address router-id extension, we
> have no reason to continue the discussion.  We just indicate "use
> zOSPF" and we're done.
>
> There seems to be consensus that we're not done.
>
On my part, I'm interested in understanding the following:
o scaling properties: I worry about the apartment building case, and
related dense mesh case.
o behaviour when routing both wired and wireless networks.
o multicast behaviour and impact on wireless networks.
o running code
And I'll ask the same about any other routing protocol you wish to
name.  I'm an equal opportunity parade rainer...
- Jim


___
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 13, 2011, at 2:35 PM, Curtis Villamizar wrote:
> You've said what the problem *isn't*, so what *is* the problem on a
> homenet?

I did say what the problem is:

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

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

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <15691.1318514...@marajade.sandelman.ca>
Michael Richardson writes:
 
> > "Curtis" == Curtis Villamizar  writes:
> >> 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.
>  
> Curtis> Not backwards compatible.  The older OSPF routers will see
> Curtis> only the non-unique 32 bits and the network won't work.
>  
> There are no zOSPF routers today.

Yes and there are/were ATM switches that implement RFC1577, LANE,
MPOA, and NHRP.  None of that worked very well and it all is
essentially abandoned work now.  Pre-existence alone is not a worth
while evaluation criteria.

If zOSPF works perfectly, including in the presence of legacy routers
which don't look at a new 48 bit mac address router-id extension, we
have no reason to continue the discussion.  We just indicate "use
zOSPF" and we're done.

There seems to be consensus that we're not done.

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 <8031f94c-66bf-4748-aa97-5efa12bb8...@fugue.com>
Ted Lemon writes:
 
> If you autoconfigure a routing topology, you have to make sure that
> you don't accidentally autoconfigure it to include routers that
> weren't intended to have been included.
>  
> The concern is not for grandma running Windows 98, and the whole hard
> shell/gooey center debate is completely beside the point.


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

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

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

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

Re: [homenet] Thoughts about routing

[Curtis Villamizar]

In message <1e8bbe2e-357a-4681-bb84-4e694afd9...@ericsson.com>
Acee Lindem writes:
 
> One assumption could be that a legacy router would not support
> auto-config and, if deployed, would have to be configured with a
> unique Router ID (as they are today).

Got that.

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

> Thanks,
> Acee

The key uncertainty is the effect of a collision on a legacy router.

This looks like it is covered.  (indentation changed)

  [RFC2328]  13.4.  Receiving self-originated LSAs

It is a common occurrence for a router to receive self- originated
LSAs via the flooding procedure. A self-originated LSA is detected
when either 1) the LSA's Advertising Router is equal to the
router's own Router ID or 2) the LSA is a network- LSA and its
Link State ID is equal to one of the router's own IP interface
addresses.

However, if the received self-originated LSA is newer than the
last instance that the router actually originated, the router must
take special action.  The reception of such an LSA indicates that
there are LSAs in the routing domain that were originated by the
router before the last time it was restarted.  In most cases, the
router must then advance the LSA's LS sequence number one past the
received LS sequence number, and originate a new instance of the
LSA.

[...] In all these cases, instead of updating the LSA, the LSA
should be flushed from the routing domain by incrementing the
received LSA's LS age to MaxAge and reflooding (see Section 14.1).

  [RFC5340]  4.5.1.  Receiving Link State Update Packets

[...]  In IPv4, eight steps are executed for each LSA, as
described in Section 13 of [OSPFV2].  For IPv6, all the steps are
the same, except that Steps 2 and 3 are modified as follows:

  [stub or nssa or reserved scope changes]

It seems then that if the auto-config router picks a new router-id,
the legacy router will correct any damage.  Perhaps the legacy router
will do this for the wrong reasons (collisions, not stale leftovers
from a restart elsewhere), but it seems like it will take action to
fix it.

Acee - should this move to OSPF?  Others - No cross posting please.

Curtis


> On Oct 12, 2011, at 10:46 PM, Curtis Villamizar wrote:
>  
> > 
> > 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 di

Re: [homenet] Thoughts about routing

[Jim Gettys]

Or you solve the time problem some other way...

Batteries die too...
  Jim




On Oct 12, 2011, at 9:19 PM, Mark Andrews  wrote:

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

Re: [homenet] Homenet strawman slides

[Michael Richardson]

> "Russ" == Russ White  writes:
>>> A router should not start handing out PD or even IPv4 NAT space until
>>> it gets and address from elsewhere.

Russ> In other words, your home network should be unusable unless at
Russ> least one 
Russ> edge device is connected to the "real world." I can just imagine the
Russ> support calls the local provider will get when they have a
Russ> local outage. 

Russ> "I'm sorry, sir, but that's the way it works --you can't print
Russ> or stream 
Russ> movies from your console unless your internet connection is up."

Russ> Yeah, that's going to fly.

Please don't mistake idle comments about the history of some devices on
the mailing list for requirements!

I think that we are pretty much in agreement that the home network has
to operate independently of the ISP(s), which is one of the reasons for
ULA, and RFC6204 (Basic Requirements for IPv6 Customer Edge Routers)
already provides for this.  At the 10,000ft level, homenet is "Advanced
Requirements for ..."


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


pgpp53hYA7rMO.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] time service and DNSSEC

[Jim Gettys]

On 10/13/2011 10:05 AM, Michael Richardson wrote:
>> "Curtis" == Curtis Villamizar  writes:
> >> While talking about hardware.  These these devices all need a
> >> battery backed clock or all the crypto will be broken.
>
>
> Curtis> Having a clock is not hard but I don't think your statement
> Curtis> is true.
>
> Curtis> Some crypto does not require time, but rather just entropy
> Curtis> (a nonce or challenge).  For crypto that does require time
> Curtis> the former can be a bootstrap of sorts, possibly to get ntp
> Curtis> going if very accurate time is needed (for some reason).
>
> Curtis, Mark, as a DNSSEC implementer knows of what he speaks.
> DNSSEC requires time.  Not to the second or even minute, but at least
> hour.
>
> DNSSEC is a core protocol at this point, and we need to be aware of it.
> It doesn't matter today, because we have a broken home DNS system, but
> that's within homenet to fix.
>
> Bootstraping time enough to get DNSSEC to work is important.
>
Yup. And DNSSEC does not require precise time as you note.

In the short term, in CeroWrt, which has running DNSSEC, Dave plans to
do insecure lookups initially to resolve NTP server addresses to get the
time, and then switch over to secure once time has been established.

There may be other options possible.  Ideally, something like a well
known anycast address we can get approximate time on would suffice, for
some high velocity hand waving.
- Jim

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

[homenet] time service and DNSSEC

[Michael Richardson]

> "Curtis" == Curtis Villamizar  writes:
>> While talking about hardware.  These these devices all need a
>> battery backed clock or all the crypto will be broken.


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

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

Curtis, Mark, as a DNSSEC implementer knows of what he speaks.
DNSSEC requires time.  Not to the second or even minute, but at least
hour.

DNSSEC is a core protocol at this point, and we need to be aware of it.
It doesn't matter today, because we have a broken home DNS system, but
that's within homenet to fix.

Bootstraping time enough to get DNSSEC to work is important.

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

[Michael Richardson]

> "Curtis" == Curtis Villamizar  writes:
>> 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.

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

There are no zOSPF routers today.

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

[Michael Richardson]

> "Mark" == Mark Andrews  writes:
>> Or you solve the time problem some other way...
>> 
>> Batteries die too...  Jim

Mark> Indeed.  It should be a user servicable part.

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

DHCP has an NTP server option.  Does IP6CP?

-- 
]   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] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

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

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

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

Re: [homenet] Thoughts about routing - trends

[Russ White]

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

Pulled from cable hanging in a "plenum" in a secure building... Because
there was no way to get cable floor to floor other than through that
single shaft. For a Xerox Star system. Then there was the token bus for
the little Novell network over in legal --another disaster. 

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

IS-IS is easier to get to "zero config," and it's actually simpler in
operation... Which is why I brought it up. :-)

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

Yes, I agree... Or we need w new wired/wireless protocol that jumps both
worlds, and would actually be acceptable and implemented by a large
number of vendors. But that's another entire problem space...

:-)

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

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

[Russ White]

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

This won't be the "corner case," it will be the "common case," in most
all homes. The electricity providers are seeing to that right now, as
well as the cell phone providers. In a few years, someone is going to
say, "you only have one internet connection? You poor soul, we need to
find some government program to help you."

:-)

Russ

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

Re: [homenet] Homenet strawman slides

[Russ White]

>> A router should not start handing out PD or even IPv4 NAT space until
>> it gets and address from elsewhere.

In other words, your home network should be unusable unless at least one
edge device is connected to the "real world." I can just imagine the
support calls the local provider will get when they have a local outage.

"I'm sorry, sir, but that's the way it works --you can't print or stream
movies from your console unless your internet connection is up."

Yeah, that's going to fly.

:-)

Russ

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

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

[Russ White]

> Is it better to leave the possibility of theft of service or is it
> better to have the device unusable by default (until configured)?  

This is a false dichotomy, as well...

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

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

:-)

Russ

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

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

[Russ White]

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

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

In your own words:

> No. No. No.

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

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

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

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

:-)

Russ

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

Re: [homenet] Thoughts about routing

[Acee Lindem]

One assumption could be that a legacy router would not support auto-config and, 
if deployed, would have to be configured with a unique Router ID (as they are 
today).  
Thanks,
Acee
On Oct 12, 2011, at 10:46 PM, Curtis Villamizar wrote:

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



smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet strawman slides

[Sander Steffann]

Hi,

>> 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.
> 
> "Update" or just advertise the new global prefix alongside the ULA?

Alongside. The ULA addresses should be stable so that they can always be used 
internally, independent on the link to the ISP.

- Sander



smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet strawman slides

[Mark Townsley]

On Oct 12, 2011, at 6:23 PM, james woodyatt wrote:

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

Every IPv4 home router I have ever seen hands out RFC 1918 space regardless of 
whether an ISP connection is active. This is needed, if nothing else, to manage 
the router with the classic IPv4 literal in a web browser (yes, this could be 
done with link-local, but that's not something you can hard-code in 
documentation or a sticker on the side of the box). 

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

"Update" or just advertise the new global prefix alongside the ULA?

- Mark

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

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