Subject: [babel] self-configuration and Babel

From: Alia Atlas <[email-masked]>
Date: Wed, 25 May 2016 14:37:33 -0400

If I understand the desired requirements discussed in homenet correctly,
there is a need for Babel to have a mode that requires no configuration -
where it simply handles auto-configuration - perhaps from other information.

I don't see this described in RFC 6126 or in
draft-chroboczek-homenet-babel-profile-00.

What work do you see as necessary and where do you picture this being done?

Regards,
Alia

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 25 May 2016 22:10:42 +0300

On 25.5.2016, at 21.37, Alia Atlas <[email-masked]> wrote:
> If I understand the desired requirements discussed in homenet correctly, there is a need for Babel to have a mode that requires no configuration - where it simply handles auto-configuration - perhaps from other information.
> 
> I don't see this described in RFC 6126 or in draft-chroboczek-homenet-babel-profile-00.
> 

It is mostly there. Only annoyance is the router ID, which is assumed to be unique based on EUI64-like process.

It would be about two sentences to add DNCP-like conflict detection (+rerandom) logic to the spec, but I am not sure it is worth it. Juliusz?

Cheers,

-Markus

---

From: Alia Atlas <[email-masked]>
Date: Wed, 25 May 2016 15:15:18 -0400

> be unique based on EUI64-like process.

I thought that it was mostly there, but when I went back with that
perspective, I didn't see it called out or discussed.  This is a major
advantage - and one that extensions and security need to consider and
preserve.

On the Router ID, I think that it is worth considering making it the same
32 bits that a Router ID is in all the other standardized routing
protocols.  That'll make it easier for things like management models to be
reusable.

> It would be about two sentences to add DNCP-like conflict detection
> (+rerandom) logic to the spec, but I am not sure it is worth it. Juliusz?
>

If we want this to be picked up and used with no-config by many people,
having it really work and be clearly documented as to how is very important.

Regards,
Alia

---

From: Teco Boot <[email-masked]>
Date: Thu, 26 May 2016 07:06:18 +0200

> Op 25 mei 2016, om 21:15 heeft Alia Atlas <[email-masked]> het volgende geschreven:
> 
> On Wed, May 25, 2016 at 3:10 PM, Markus Stenberg <[email-masked]> wrote:
> I thought that it was mostly there, but when I went back with that perspective, I didn't see it called out or discussed.  This is a major advantage - and one that extensions and security need to consider and preserve.
> 
> On the Router ID, I think that it is worth considering making it the same 32 bits that a Router ID is in all the other standardized routing protocols.  That'll make it easier for things like management models to be reusable.

This is the wrong direction. It is 64 bits right now. Please keep it (or extend to 256 :-)

RFC 6126 has text that the router-id is assigned. Not how it is assigned automatically. Although one may assume that an unique MAC address would be fine. But what if I write an implementation that takes the neighbor's MAC? Yes, I am the crazy guy.

Probably the duplicate router-id topic needs some work. Analyses on impact and mechanisms for detection. The topic is related to security.

Teco

> If we want this to be picked up and used with no-config by many people, having it really work and be clearly documented as to how is very important.
> 
> Regards,
> Alia
> 
> 
> Cheers,
> 
> -Markus
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Alia Atlas <[email-masked]>
Date: Thu, 26 May 2016 01:19:02 -0400

On Thu, May 26, 2016 at 1:06 AM, Teco Boot <[email-masked]> wrote:

> > > If I understand the desired requirements discussed in homenet
> correctly, there is a need for Babel to have a mode that requires no
> configuration - where it simply handles auto-configuration - perhaps from
> other information.
> > >
> > On the Router ID, I think that it is worth considering making it the
> same 32 bits that a Router ID is in all the other standardized routing

If there's a strong reason for it to be larger - such as trying to ensure
uniqueness with randomness, that could be different.  My concern is about
aspects like MIBs and even YANG modules where the router-id is assumed to
be 32 bits.  For other protocols, there was a discussion about needing a
router-id that was 128 bits so it would be an IPv6 address instead of an
IPv4 address, but the general consensus was that the 32-bit router-id isn't
intended to be an IPv4 address - even though it is formatted as a dotted
quad and operationally frequently assigned to be the IPv4 loopback address.

If there are different length router-ids, then correlation between
protocols can also be harder.  The question is how much these factors apply
as the manageability discussion happens.

> RFC 6126 has text that the router-id is assigned. Not how it is assigned
> automatically. Although one may assume that an unique MAC address would be
> fine. But what if I write an implementation that takes the neighbor's MAC?
> Yes, I am the crazy guy.
>

Right - Section 3 just says that the router-id is assigned and assumed
unique.  MAC addresses can be tempting to use, but they aren't always as
unique as assumptions have been.  There's work on providing privacy
protecting MACs and I have vague memories about MAC reuse in data-centers;
I'm sure someone can correct me on the details :-)  Maybe those won't apply
here and there aren't privacy concerns around tying the identifiers
together, but I do think it requires some thought.

> Probably the duplicate router-id topic needs some work. Analyses on impact
> and mechanisms for detection. The topic is related to security.
>

I think that would be useful.  The question I have for the mailing list and
future WG chairs is whether this topic is adequately covered in the
proposed charter or needs more text.

One of the potential benefits, from a user's perspective, is the potential
lack of configuration.  If that isn't preserved as a goal and focus, then
it is likely to be compromised.

Regards,
Alia

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 May 2016 08:34:49 +0300

Teco,

> On May 26, 2016, at 8:06 AM, Teco Boot <[email-masked]> wrote:
> 
> 

I like the idea of keeping it 64bits, that is a reasonable size and it won’t be confused with an IP address (v4 or v6).

> Probably the duplicate router-id topic needs some work. Analyses on impact and mechanisms for detection. The topic is related to security.

This is probably going to be challenging.  It’s hard enough to do duplicate detection on a single subnet (like IPv6 DAD), but doing across an AS will be harder.  For example dealing with partitions, routers being added and deleted, etc.   Important to have good recommendations for selecting a unique router ID in the first place.

Bob

---

From: Ferry Huberts <[email-masked]>
Date: Thu, 26 May 2016 09:27:32 +0200

On 26/05/16 07:19, Alia Atlas wrote:
> On Thu, May 26, 2016 at 1:06 AM, Teco Boot <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     > Op 25 mei 2016, om 21:15 heeft Alia Atlas <[email-masked] <mailto:[email-masked]>> het volgende geschreven:
>     >
>     > On Wed, May 25, 2016 at 3:10 PM, Markus Stenberg <[email-masked] <mailto:[email-masked]>> wrote:
>     > On 25.5.2016, at 21.37, Alia Atlas <[email-masked] <mailto:[email-masked]>> wrote:
> If there's a strong reason for it to be larger - such as trying to
> ensure uniqueness with randomness, that could be different.  My concern
> is about aspects like MIBs and even YANG modules where the router-id is
> assumed to be 32 bits.  For other protocols, there was a discussion
> about needing a router-id that was 128 bits so it would be an IPv6
> address instead of an IPv4 address, but the general consensus was that

Using IP addresses as router/stack IDs is not a good idea.
How would you assign one and how would you make that deterministic, 
especially on nodes with many such addresses?

A better idea would be to use UUIDs combined with a de-deplication 
mechanism (that would almost never run).

UUIDs can be generated and almost never clash, if they're wide enough 
bit-wise.

So making the field 128 bits allows for generic UUIDs to be used as well 
as IPv6 address if people really want that.

My 2 cents

Ferry

> the 32-bit router-id isn't intended to be an IPv4 address - even though
> it is formatted as a dotted quad and operationally frequently assigned
> to be the IPv4 loopback address.
>
> protocols can also be harder.  The question is how much these factors
> apply as the manageability discussion happens.
>
>
>     RFC 6126 has text that the router-id is assigned. Not how it is
>     assigned automatically. Although one may assume that an unique MAC
>     address would be fine. But what if I write an implementation that
>     takes the neighbor's MAC? Yes, I am the crazy guy.
>
>
> protecting MACs and I have vague memories about MAC reuse in
> data-centers; I'm sure someone can correct me on the details :-)  Maybe
> those won't apply here and there aren't privacy concerns around tying
> the identifiers together, but I do think it requires some thought.
>
>
>     Probably the duplicate router-id topic needs some work. Analyses on
>     impact and mechanisms for detection. The topic is related to security.
>
>
> I think that would be useful.  The question I have for the mailing list
> and future WG chairs is whether this topic is adequately covered in the
> One of the potential benefits, from a user's perspective, is the
> potential lack of configuration.  If that isn't preserved as a goal and
> focus, then it is likely to be compromised.
>
> Regards,
> Alia
>
>
>
>     Teco
>
>
>     >
>     > [email-masked] <mailto:[email-masked]>

-- 
Ferry Huberts

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 26 May 2016 12:37:53 +0200

> uniqueness with randomness, that could be different.

The intent here is that router-ids are similar to IPv6 node identifiers,
and should be allocated in the same manner.  (RFC 6126 was written before
modified EUI-64 was deprecated, and the wording reflects that.)

In addition, 64 bits is large enough to fit an identifier from some other
protocol, such as an OSPF router ID (32 bits) or an amateur radio
call-sign (up to 6 ASCII characters).

> My concern is about aspects like MIBs and even YANG modules where the
> router-id is assumed to be 32 bits.

Please fix SNMP and YANG.  32 bits is tiny, not enough to do random
allocations with a sufficient probability of uniqueness.

> If there are different length router-ids, then correlation between protocols
> can also be harder.

Right.  If you already have an OSPF router-id, then you can just pad it to
64 bits.  The other way doesn't work, obviously.

> Right - Section 3 just says that the router-id is assigned and assumed unique.
> MAC addresses can be tempting to use, but they aren't always as unique as
> assumptions have been.

Randomly chosen router-ids are fine.  In a 64 bit space, the probability
of a collision in a network with 10000 routers, assuming a perfect RNG, is
roughly 3×10^-12.  This means that if you renumber every second, in
a network with 10000 routers you'll run into one collision roughly once
per 10 millenia.

> lack of configuration.

Pick the router-id randomly, and be done with it.  Or use a MAC address,
and deal with the consequences in case of duplication.

> (+rerandom) logic to the spec, but I am not sure it is worth

Not sure, given the probability of collision.  Perhaps describe it in an
informational appendix as an optional mechanism?

I'm more interested in being able to detect spurious collisions (stale
data making routes unfeasible after you reboot and lose your state).  I'm
not sure if it can be done.

– Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 26 May 2016 15:23:37 +0300

> On 26.5.2016, at 13.37, Juliusz Chroboczek <[email-masked]> wrote:

Birthday paradox => given real PRNG problems start cropping _certainly_ near 2^32 devices with 64-bit ids (it is roughly sqrt when you get 50% chance of collision). That said..

I am not sure I agree with you, given how bad PRNGs can be on embedded devices etc. _Given_ cryptographically strong PRNG, I agree with your point, but I have seen (and used) so many broken ones over the time that I would not count on it.

For example, the classic srand(time(NULL)) breaks if you have two devices starting at same time; that is not a problem unless you want to reboot your network or electricity goes down.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 26 May 2016 14:48:11 +0200

> I am not sure I agree with you, given how bad PRNGs can be on embedded
> devices etc. _Given_ cryptographically strong PRNG, I agree with your
> point, but I have seen (and used) so many broken ones over the time that
> I would not count on it.

> For example, the classic srand(time(NULL)) breaks if you have two
> devices starting at same time; that is not a problem unless you want to
> reboot your network or electricity goes down.

Yes, stupid people will do stupid things.  srand(time(NULL)) is obviously
stupid.

Concatenate tv_sec, tv_usec, all the MAC addresses you can find and all
the IP addresses you can find, push that through sha1, truncate to 64
bits, and you've got a serious chance of being unique.  This doesn't
require any hardware support.

IMHO, the fact that it is possible to be stupid doesn't imply that we
should be protecting against that in the spec, but we should be detecting
collisions in quality implementations.  Whether this is possible without
getting confused when a node reboots without changing its router-id is
something I don't know.

-- Juliusz

---

From: Ferry Huberts <[email-masked]>
Date: Thu, 26 May 2016 14:50:20 +0200

> getting confused when a node reboots without changing its router-id is

Easily avoided by 'un-announcing' itself before rebooting

-- 
Ferry Huberts

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 26 May 2016 16:09:44 +0300

> On 26.5.2016, at 15.48, Juliusz Chroboczek <[email-masked]> wrote:

tv_* in the power reset case are close to each other given NTP. tv_usec accuracy is usually far from what you would hope (e.g. 1ms accuracy is entirely likely -> results are more or less always same given same hardware and same boot time, +- little).

In virtualized case (hello, VM) or cheapo vendor case, MACs uniqueness is not guaranteeable.

I would say your PRNG is not good either. I am fine if we define idiot-proof PRNG that actually fullfills these criteria in the spec but I would rather not, and therefore detecting collisions is the lower hanging fruit (this is why DNCP went that way; of course, HNCP, with the shorter router ids, is more vulnerable to this as well).

Cheers,

-Markus

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 26 May 2016 15:40:48 +0100

---- On Thu, 26 May 2016 11:37:53 +0100 Juliusz Chroboczek<[email-masked]> wrote ---- 
 > call-sign (up to 6 ASCII characters).
[...]

Ham callsigns roughly correspond to BGP AS numbers, not router IDs. And sometimes they may require prefixes and suffixes. But technicalities aside, would it help to try to state the problem the router ID is expected to solve?

As far as I recall now, the very minimal requirements to a router ID would be:
* must be unique
* must remain persistent as long as the protocol instance keeps running
* should be persistent across reboots (from a network engineer's point of view to keep troubleshooting simpler)

And as far as EUI-64 goes, it does the small job one expects it to do: unique input => unique output. If the expectations from the router ID are higher, can we try to state those?

With regard to unique input, in the case of routers the [traditional hard] disk activity and the audio input as discussed in RFC 4086 are out of scope. I don't have the competence to estimate how much entropy flash storage provides, it is quite possible a proper MAC address is still way ahead of PRNG if you have a few hundred small plastic boxes at hand.

Of course, in practice hardware MAC addresses do occasionally happen to be duplicate or made-up or both. But that's just a factory defect and is best handled as such. It would be useful for a Babel speaker to detect the situation and "blow the fuse" but going beyond and trying to hide the problem doesn't seem to be quite right.

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 27 May 2016 03:40:31 +0200

> Easily avoided by 'un-announcing' itself before rebooting

We already do, but we're running over an unreliable lower layer.  Nothing
guarantees that the retraction doesn't get lost.

We're also trying to be robust against nodes crashing or being power-cycled
uncleanly (which is the normal way to reboot a home router).

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 27 May 2016 03:42:57 +0200

> I am fine if we define idiot-proof PRNG that actually fullfills these
> criteria in the spec but I would rather not, and therefore detecting
> collisions is the lower hanging fruit (this is why DNCP went that way;
> of course, HNCP, with the shorter router ids, is more vulnerable to this
> as well).

Okay, point duly noted.  I think I'm still disagreeing with you, I'll
think it over.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 27 May 2016 03:55:26 +0200

> would it help to try to state the problem the router ID is expected to solve?

Yes, let's.

> As far as I recall now, the very minimal requirements to a router ID would be:

Yes.

> * must remain persistent as long as the protocol instance keeps running

Not necessarily.  You can change router-ids gracefully, you just
reannounce all of your routes with the new router-id then retract all
routes with the old router-id.  Everytime you do that, you destroy the
loop-avoidance state about you, so you run a small risk of creating
transient routing loops if the retraction gets lost and then there's
a metric increase.

>   of view to keep troubleshooting simpler)

That's a management issue, not something the protocol cares about.  In
fact, the protocol works better if router-ids are changed at every restart
(since it prevents interference of the loop-avoidance state).

> Of course, in practice hardware MAC addresses do occasionally happen to
> be duplicate or made-up or both. But that's just a factory defect and is
> best handled as such. It would be useful for a Babel speaker to detect
> the situation and "blow the fuse" but going beyond and trying to hide
> the problem doesn't seem to be quite right.

So you're suggesting that « A Babel speaker that detects a duplicate
router-id SHOULD log the issue to system management and cease functioning.
While it MAY pick a new router-id and continue functioning, doing that is
NOT RECOMMENDED. » ?

No opinion on that, but it leaves open the problem of whether detecting
duplicates is REQUIRED or not.  I think we should refrain from discussing
that until somebody exhibits a suitable implementation and we can see how
simple and robust it is.

-- Juliusz

---

From: Teco Boot <[email-masked]>
Date: Fri, 27 May 2016 08:09:52 +0200

> Op 27 mei 2016, om 03:55 heeft Juliusz Chroboczek <[email-masked]> het volgende geschreven:
> 

(not postponing my opinion...)
Having a mechanisms handling duplicate router-IDs makes the protocol more robust against a spoofing attack or bugs. Maybe there are unwanted side effects (network overload, DOS attack vector), so rate limiting in router_ID changes would be a SHOULD.

Teco

---

From: Denis Ovsienko <[email-masked]>
Date: Fri, 27 May 2016 10:46:37 +0100

---- On Fri, 27 May 2016 02:55:26 +0100 Juliusz Chroboczek  wrote ---- 
>(since it prevents interference of the loop-avoidance state). 

I agree this is a management issue. But with regard to the last two points, in the context of remote troubleshooting and tech support it is generally helpful to look into a packet dump and be able to compare it with a packet dump from yesterday or a month ago. Just my little bit of experience.

>So you're suggesting that &laquo; A Babel speaker that detects a duplicate 
>NOT RECOMMENDED. &raquo; ? 
> 

Something along those lines. Maybe just stop routing and flash the alarm LED.

Imagine someone buys a new refrigerator, plugs it in and the washing machine stops working immediately. They can correlate the two facts, reproduce it a few more times on their own and decide on the next step:
* return the refrigerator to the shop
* call an electrician and hand the obvious problem over
* just get rid of the washing machine

If instead the washing machine goes off a few months later (refrigerator returns no more accepted) for no visible reason and after a long expensive investigation the electrician starts "Do you remember, the refrigerator you added back then, it..." the frustrated end user would reasonably ask: "Why didn't they both just blow their fuses immediately? It would be so much simpler to resolve on the day!".

Whatever particular normative clauses and technical means we agree upon, if in the end we manage to signal engineering faults earliest possible and in a way that is difficult to misunderstand just watching the LEDs, it would be a very worthwhile design goal.

I agree running code would be a good argument here.

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 27 May 2016 15:28:36 +0200

>> I think we should refrain from discussing that until somebody exhibits
>> a suitable implementation and we can see how simple and robust it is.

> Having a mechanisms handling duplicate router-IDs makes the protocol
> more robust against a spoofing attack or bugs.

I agree, but we need running code.

-- Juliusz