Subject: [homenet] Comments on draft-acee-ospf-ospfv3-autoconfig-00

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 Nov 2011 09:41:40 +0800

Apologies if ther's already a public comment thread on this; I couldn't
find it. Please feel free to hand me a cluepon.

1. I think the OSPFv3 router ID should not be based on the MAC address
because that will encourage people to assume it's unique "most of the
time". I think we should just make it a pseudo-random number so it's clear
that uniqueness is only guaranteed by collision detection and that
collision detection needs to be robust.

2. The draft mentions links but vaguely says they are "not applicable
to auto-configuration".
Should we just clearly say at the beginning that they're out of scope and
will not work? Or do we need them?

3. Can we use normal LSAs to detect collisions? One idea would be "if you
see your own router ID in the list of neighbours of a network LSA or router
LSA, then there is a collision". Will that work? If so we wouldn't need the
hardware fingerprint at all.

4. For security, I think we should pick an auth scheme and stick to
it, otherwise
it will just lead to fragmentation. Some pre-shared key scheme might be
adequate; I don't know much about security so I don't really care what it
is, but I do think we need to have one and it needs to be the same for
everyone. I think we should say MUST here.

Cheers,
lorenzo

---

From: Acee Lindem <[email-masked]>
Date: Mon, 14 Nov 2011 21:25:53 -0500

Hi Lorenzo,

On Nov 14, 2011, at 8:41 PM, Lorenzo Colitti wrote:

> Apologies if ther's already a public comment thread on this; I couldn't find it. Please feel free to hand me a cluepon.
> 
> 1. I think the OSPFv3 router ID should not be based on the MAC address because that will encourage people to assume it's unique "most of the time". I think we should just make it a pseudo-random number so it's clear that uniqueness is only guaranteed by collision detection and that collision detection needs to be robust.

The draft requires duplicate Router-ID detection and resolution. I don't think that the fact that a portion of the MAC address is used as a first try is reason for this detection/resolution not to be implemented or tested. 

> 
> 2. The draft mentions links but vaguely says they are "not applicable to auto-configuration". Should we just clearly say at the beginning that they're out of scope and will not work? Or do we need them?

I think you mean virtual links. They are definitely not needed in the auto-configured environment as they are for providing a backbone path through a transit area and the OSPFv3 auto-configured routing domain assumes only a backbone area. 

> 
> 3. Can we use normal LSAs to detect collisions? One idea would be "if you see your own router ID in the list of neighbours of a network LSA or router LSA, then there is a collision". Will that work? If so we wouldn't need the hardware fingerprint at all.

No. In an arbitrary topology, A router with a duplicate router-id can be multiple hops away. 

> 
> 4. For security, I think we should pick an auth scheme and stick to it, otherwise it will just lead to fragmentation. Some pre-shared key scheme might be adequate; I don't know much about security so I don't really care what it is, but I do think we need to have one and it needs to be the same for everyone. I think we should say MUST here.

If the pre-shared key is hard-coded, it is no better than the OSPFv3 Interface Instance ID that is specified to prevent inadvertent adjacencies with routers not supporting the auto-configuration. If configuration of a pre-shared key is required, you no longer have auto-configuration. 

Thanks, 
Acee

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 Nov 2011 10:46:20 +0800

On Tue, Nov 15, 2011 at 10:25, Acee Lindem <[email-masked]> wrote:

> The draft requires duplicate Router-ID detection and resolution. I don't
> think that the fact that a portion of the MAC address is used as a first
> try is reason for this detection/resolution not to be implemented or tested.
>

In my experience, giving people something that works "most of the time"
will cause the cases where it doesn't work to break. I think it's better to
explicitly provide no guarantees of uniqueness to make it clear that
collision detection needs to be robust. Also, if we rely on collision
detection, then what's the advantage of using the MAC address? We might as
well as make it random all the time - that probably has a lower chance of
collision anyway.

I think you mean virtual links. They are definitely not needed in the
> auto-configured environment as they are for providing a backbone path
> through a transit area and the OSPFv3 auto-configured routing domain
> assumes only a backbone area.
>

Yes, virtual links. Do we need to state explicitly that they cannot exist
and are not supported?

> > 3. Can we use normal LSAs to detect collisions? One idea would be "if
> you see your own router ID in the list of neighbours of a network LSA or
> router LSA, then there is a collision". Will that work? If so we wouldn't
> need the hardware fingerprint at all.
>

Yes, but router and network LSAs are flooded, so you'll hear them
regardless of whether your duplicate is multiple hops away, no?

> If the pre-shared key is hard-coded, it is no better than the OSPFv3
> Interface Instance ID that is specified to prevent inadvertent adjacencies
> with routers not supporting the auto-configuration. If configuration of a
> pre-shared key is required, you no longer have auto-configuration.
>

Sorry, that wasn't clear. What I meant to say is that we should pick one
scheme (e.g., HMAC-SHA) and stick to it; we shouldn't support multiple
schemes as that will lead to interoperability issues for devices that use
one scheme and devices that use another scheme.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 14 Nov 2011 22:11:33 -0500

On Nov 14, 2011, at 9:46 PM, Lorenzo Colitti wrote:

> In my experience, giving people something that works "most of the time" will cause the cases where it doesn't work to break. I think it's better to explicitly provide no guarantees of uniqueness to make it clear that collision detection needs to be robust.

In the OSPF WG, the fact that a mechanism is specified implies that it is required to be robust. 

> Also, if we rely on collision detection, then what's the advantage of using the MAC address? We might as well as make it random all the time - that probably has a lower chance of collision anyway.

I can't disagree with this argument and think we could go with a psuedo-random number seeded with a hash on the hardware fingerprint as the first try for router-id. 

> Yes, virtual links. Do we need to state explicitly that they cannot exist and are not supported?

Since the auto-configured routing domain is area 0 only, it is explicit. 

> Yes, but router and network LSAs are flooded, so you'll hear them regardless of whether your duplicate is multiple hops away, no?

Both OSPFv3 and OSPFv2 would consider an unrecognized self-originated LSA, i.e. having our Route-ID, as a stale LSA and purge it. This is a very basic mechanism of OSPF. I'd rather use a separate mechanism for duplicate Router-ID detection. I considered techniques involving the encoding some additional information in the Router-LSA but these all seemed to be hacked. 

> Sorry, that wasn't clear. What I meant to say is that we should pick one scheme (e.g., HMAC-SHA) and stick to it; we shouldn't support multiple schemes as that will lead to interoperability issues for devices that use one scheme and devices that use another scheme.

The OSPFv3 Instance ID is part of the base OSPFv3 specification and I think it is a very good mechanism to prevent inadvertent adjacencies. If we need real authentication, we'll need a pre-shared key. I don't see any advantage of authentication with a well-known pre-shared key to prevent inadvertent adjacencies. 

Thanks for the comments,
Acee

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2011 10:26:35 -0500

>>>>> "Lorenzo" == Lorenzo Colitti <[email-masked]> writes:
    Lorenzo> 4. For security, I think we should pick an auth scheme and
    Lorenzo> stick to it, otherwise
    Lorenzo> it will just lead to fragmentation. Some pre-shared key
    Lorenzo> scheme might be adequate; I don't know much about security
    Lorenzo> so I don't really care what it is, but I do think we need
    Lorenzo> to have one and it needs to be the same for 
    Lorenzo> everyone. I think we should say MUST here.

So, let me go over the options in order to violently agree.

1) OSPF is multicast, so we can't use any bilteral key-agreement
   protocol on it's own.  Statically keyed AH can be used for multicast
   traffic, and a router can trivially ignore an AH validation failure in
   order to provide some diagnostics by evaluating the contents of
   the OSPF frame. (This requires hacks on platforms that already have
   IPsec, but if you implement the AH inside the OSPF daemon....)

   (so diagnostics can say, "I saw router FOO on interface BLAH, but
   the key didn't match, so I ignored it", or even, "I saw router FOO
   on interface BLAH, and since the key didn't match, I treated it as a
   guest network".  What router FOO thinks of the packets it receives is an
   open question)

2) While we could invoke some kind of group-KMP, these essentially work
   out to a series of bilateral trust relationships which results in the
   master machine giving out the pre-shared secret in a secure fashion.
   The bilateral trust mechanism needs to be anchored by something, 
   and you can invoke public key mechanisms, or... shared secret.

   Public key mechanisms with a leap-of-faith and then confirmation via UI,
   would be very cool, but completely exceeds our needs.  

3) my understanding is that OSPFv3 eliminated the plain-text HELLO and
   md5 methods. 

The major thing we need to specify for zOSPF is that we need to pick a
well-known SPI value for the AH header.  That SPI value will need to
specify an algorithm (HMAC-SHA1, HMAC-SHA2, HMAC-SHA3...) and perhaps a
key length.  We should publish a few choices for future interop, but we
will need to pick one MUST for today.  We can't really be resistant
against a bid-down attack, but even HMAC-SHA1 is pretty resistant today
(vs bare SHA1), and I think that we can count upon being able to specify
HMAC-SHA3 for this work.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2011 10:27:58 -0500

>>>>> "Acee" == Acee Lindem <[email-masked]> writes:
    >> 4. For security, I think we should pick an auth scheme and stick
    >> to it, otherwise it will just lead to fragmentation. Some
    >> pre-shared key scheme might be adequate; I don't know much about
    >> security so I don't really care what it is, but I do think we
    >> need to have one and it needs to be the same for everyone. I
    >> think we should say MUST here. 

    Acee> If the pre-shared key is hard-coded, it is no better than the
    Acee> OSPFv3 Interface Instance ID that is specified to prevent
    Acee> inadvertent adjacencies with routers not supporting the
    Acee> auto-configuration. If configuration of a pre-shared key is
    Acee> required, you no longer have auto-configuration.  

I agree.

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 15 Nov 2011 12:10:47 -0500

Hi Acee,

On 11/14/2011 10:11 PM, Acee Lindem wrote:
>> On Tue, Nov 15, 2011 at 10:25, Acee Lindem <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     > 1. I think the OSPFv3 router ID should not be based on the MAC
>>     address because that will encourage people to assume it's unique
>>     "most of the time". I think we should just make it a pseudo-random
>>     number so it's clear that uniqueness is only guaranteed by
>>     collision detection and that collision detection needs to be robust.
>>
>>     The draft requires duplicate Router-ID detection and resolution. I
>>     don't think that the fact that a portion of the MAC address is
>>     used as a first try is reason for this detection/resolution not to
>>     be implemented or tested.
>>
>>
>> In my experience, giving people something that works "most of the
>> time" will cause the cases where it doesn't work to break. I think
>> it's better to explicitly provide no guarantees of uniqueness to make
>> it clear that collision detection needs to be robust. 
> 
>> Also, if we rely on collision detection, then what's the advantage of
>> using the MAC address? We might as well as make it random all the time
>> - that probably has a lower chance of collision anyway.
> 
> I can't disagree with this argument and think we could go with a
> psuedo-random number seeded with a hash on the hardware fingerprint as
> the first try for router-id. 
> 

As a side note, what's your opinion on citing and suggesting/requiring
<http://tools.ietf.org/html/rfc5642#section-4> for manageability?

Thanks,

-- Carlos.

>>
>>     I think you mean virtual links. They are definitely not needed in
>>     the auto-configured environment as they are for providing a
>>     backbone path through a transit area and the OSPFv3
>>     auto-configured routing domain assumes only a backbone area.
>>
>>
>>     > 3. Can we use normal LSAs to detect collisions? One idea would
>>     be "if you see your own router ID in the list of neighbours of a
>>     network LSA or router LSA, then there is a collision". Will that
>>     work? If so we wouldn't need the hardware fingerprint at all.
>>
> Both OSPFv3 and OSPFv2 would consider an unrecognized self-originated
> LSA, i.e. having our Route-ID, as a stale LSA and purge it. This is a
> very basic mechanism of OSPF. I'd rather use a separate mechanism for
> duplicate Router-ID detection. I considered techniques involving the
> encoding some additional information in the Router-LSA but these all
> seemed to be hacked. 
> 
> 
>>  
>>
>>     If the pre-shared key is hard-coded, it is no better than the
>>     OSPFv3 Interface Instance ID that is specified to prevent
>>     inadvertent adjacencies with routers not supporting the
>>     auto-configuration. If configuration of a pre-shared key is
>>     required, you no longer have auto-configuration.
>>
>>
>> Sorry, that wasn't clear. What I meant to say is that we should pick
>> one scheme (e.g., HMAC-SHA) and stick to it; we shouldn't support
>> multiple schemes as that will lead to interoperability issues for
>> devices that use one scheme and devices that use another scheme.
> 
> The OSPFv3 Instance ID is part of the base OSPFv3 specification and I
> think it is a very good mechanism to prevent inadvertent adjacencies. If
> we need real authentication, we'll need a pre-shared key. I don't see
> any advantage of authentication with a well-known pre-shared key to
> prevent inadvertent adjacencies. 
> 
> Thanks for the comments,
> Acee 
> 
> 
> 
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Acee Lindem <[email-masked]>
Date: Tue, 15 Nov 2011 13:38:51 -0500

Hi Carlos,

> <http://tools.ietf.org/html/rfc5642#section-4> for manageability?

I think the dynamic host-name is less applicable in an auto-configured routing domain than other domains. In the auto-configured routing domain, you hope that little monitoring, debugging, or interaction is required. 
Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 15 Nov 2011 13:52:14 -0500

Hi Michael,

> (vs bare SHA1), and I think that we can count upon being able to specify

We will soon have non-IPsec authentication for OSPFv3:

   http://www.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-10.txt 

The point that I don't understand from this E-mail thread is where the Security Association (SA) comes from to use for auto-configured OSPFv3 routers? 
I guess it is from a USB flash drive ;^)). Also, are you and Lorenzo suggesting we make authentication MANDATORY in for auto-configured OSPFv3 routers? 

Thanks,
Acee

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2011 17:51:53 -0500

>>>>> "Acee" == Acee Lindem <[email-masked]> writes:
    Acee> We will soon have non-IPsec authentication for OSPFv3:

    Acee> http://www.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-10.txt 

    Acee> The point that I don't understand from this E-mail thread is
    Acee> where the Security Association (SA) comes from to use for
    Acee> auto-configured OSPFv3 routers?  
    Acee> I guess it is from a USB flash drive ;^)). 

The SA would be keyed from the shared material.
The details of the SA (SPI#, transform, hash) would either be mandated
by document, or from the shared material.

    Acee> Also, are you and
    Acee> Lorenzo suggesting we make authentication MANDATORY in for
    Acee> auto-configured OSPFv3 routers?  

I don't know.  

I sure would like to make it so, but I sure want this thing to work.

We discussed the fact that the home owner needs to enter their "network
key" into every device, and the WPA/WEP keys for non-guest access would
be based upon this.   

Do we need security for wired connections?  It's an open question.
Do we need security for closed wifi connections?  I think maybe.
Do we need security for open/guest wifi connections?  I think definitely.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 15 Nov 2011 22:34:37 -0500

Hi Acee,

> I think the dynamic host-name is less applicable in an auto-configured routing domain than other domains. In the auto-configured routing domain, you hope that little monitoring, debugging, or inter…

I agree that a goal is for less monitoring and interaction in this deployment model -- however sometimes less troubleshooting is aspirational, and debugging cannot be avoided :-) for those cases, a human-parseable node string is quite handy (especially when with pseudo-random -- potentially changing on reload or electrical hiccup (?) -- router-ids).  Thinking aloud a bit as I see both sides; but acknowledging that a stable node reference can help in troubleshooting (if/when required)

Thanks!

Carlos P.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 16 Nov 2011 10:11:26 -0500

Hi Carlos, 

> I agree that a goal is for less monitoring and interaction in this deployment model -- however sometimes less troubleshooting is aspirational, and debugging cannot be avoided :-) for those cases, a…

If the router has little to no configuration, from where would the dynamic host name originate?

Thanks,
Acee

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 16 Nov 2011 10:51:32 -0500

Hi, Acee,

> If the router has little to no configuration, from where would the dynamic host name originate?

There is a bit of a potential chicken-egg, but (to not answer and
instead ask more generically, sorry) is a homenet requirement to have
local name services for all devices?

Thanks,

-- Carlos.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 18 Nov 2011 04:58:34 +0100

> Do we need security for open/guest wifi connections?  I think definitely.

When it comes to wired connections why don't we consider both closed and guest access as in the wireless case? In a densely connected home, some wired points could be intended to be used by, say, someone coming to make some maintenance work…

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Russ White <[email-masked]>
Date: Fri, 18 Nov 2011 08:26:23 -0500

> When it comes to wired connections why don't we consider both closed and guest access as in the wireless case? In a densely connected home, some wired points could be intended to be used by, say, s…

I think this is a possible requirement, but... I don't know how you're
going to know what's guest and what's not. I suppose you could do
something like the "plug this usb into your machine to gain access," or
something, but I'm not certain how we could solve this just on the
network side.

:-)

Russ

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Nov 2011 14:04:48 -0500

>>>>> "Russ" == Russ White <[email-masked]> writes:
    >> When it comes to wired connections why don't we consider both
    >> closed and guest access as in the wireless case? In a densely
    >> connected home, some wired points could be intended to be used
    >> by, say, someone coming to make some maintenance work…

    Russ> I think this is a possible requirement, but... I don't know
    Russ> how you're going to know what's guest and what's not. I
    Russ> suppose you could do something like the "plug this usb into
    Russ> your machine to gain access," or something, but I'm not
    Russ> certain how we could solve this just on the network side.

I think that it's entirely reasonable that some parts of the house
(for instance Fred Baker's home office) would refuse access to his wired
network unless the device authenticated, and if they refused, the switch
would drop them onto a guest network.

This is relatively common deployed 802.1x.  While this switch (and the
radius server behind it) won't be present at Grandma's house, I've
noticed it's available on inexpensive managed switches made by Fred's
preferred network supplier. 

Or, to put it another way: if you need wired security, we have it,
and homenet doesn't need to deal with this.  If you need to plug
additional homenet routers into the secured wire, then they need to get
past the wired security first.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Nov 2011 14:29:00 +0900

On Tue, Nov 15, 2011 at 12:11, Acee Lindem <[email-masked]> wrote:

> Both OSPFv3 and OSPFv2 would consider an unrecognized self-originated LSA,
> i.e. having our Route-ID, as a stale LSA and purge it. This is a very basic
> mechanism of OSPF. I'd rather use a separate mechanism for duplicate
> Router-ID detection. I considered techniques involving the encoding some
> additional information in the Router-LSA but these all seemed to be hacked.
>

I think you misunderstood my suggestion.

I'm not suggesting that you listen for router and network LSAs with your
own router-ID. I'm suggesting that you listen for router and network LSAs
*that list your router-ID as a neighbour*. If you see one, but have no
neighbour relationship with the router-ID that originated the LSA, then
there is a collision.

Does that make sense?

> think it is a very good mechanism to prevent inadvertent adjacencies. If we
> need real authentication, we'll need a pre-shared key. I don't see any
> advantage of authentication with a well-known pre-shared key to prevent
> inadvertent adjacencies.
>

Again, that wasn't clear. What I'm saying is that I think we need to pick
one mechanism (ipsec, SHA1, whatever - I don't even know what the possible
mechanisms are) to implement security. If the user enables security and
configures a key on all the network devices, we use that scheme to secure
the network. All homenet devices MUST support that scheme. If the user
doesn't enable security, then we can leave the packets unauthenticated.

Setting the instance ID to some random number will help in some cases, but
it won't help if by chance you happen to be adjacent to another network
that uses the same value. So I'm not sure if it's a good idea; people might
assume that since collisions are unlikely, then they don't need to support
them. But I don't really know enough about this to comment.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 22 Nov 2011 09:57:28 -0500

On Nov 22, 2011, at 12:29 AM, Lorenzo Colitti wrote:

> I'm not suggesting that you listen for router and network LSAs with your own router-ID. I'm suggesting that you listen for router and network LSAs *that list your router-ID as a neighbour*. If you see one, but have no neighbour relationship with the router-ID that originated the LSA, then there is a collision.
> 
> Does that make sense?

I understand what you are proposing but it is contrary to the way OSPF floods, stores, and interprets LSAs. Only the most recent instance of every LSA is maintained and any uni-directional links are treated as stale and not used in the routing computation. So, it would be a very common event to receive an LSA containing a link to you but to which you no longer have a link. I agree one could probably come up with a heuristic that would be correct most of the time but why do this when a simple hardware fingerprint will do the trick without all the complexity. 

> Again, that wasn't clear. What I'm saying is that I think we need to pick one mechanism (ipsec, SHA1, whatever - I don't even know what the possible mechanisms are) to implement security. If the user enables security and configures a key on all the network devices, we use that scheme to secure the network. All homenet devices MUST support that scheme. If the user doesn't enable security, then we can leave the packets unauthenticated.
> 
> Setting the instance ID to some random number will help in some cases, but it won't help if by chance you happen to be adjacent to another network that uses the same value. So I'm not sure if it's a good idea; people might assume that since collisions are unlikely, then they don't need to support them. But I don't really know enough about this to comment.

I wasn't suggesting the instance ID would provide authentication - simply to prevent inadvertent adjacencies with routers not being auto-configured. Even with auto-configuration, I'm against making authentication a MUST. Since OSPFv3 only runs on a single link, a connected network must be compromised in order for a successful attack. 

Thanks,
Acee