Subject: Re: [babel] babel Digest, Vol 9, Issue 19

From: Tony Przygienda <[email-masked]>
Date: Wed, 1 Jun 2016 10:34:31 -0700

In this context I recommend the lecture of
https://tools.ietf.org/html/draft-ietf-isis-auto-conf-01 which deals with
lots of those issues already. As in "most sincere form of flattery" and
such ;-)

-- tony

On Wed, May 25, 2016 at 11:05 PM, Tony Przygienda <[email-masked]>
wrote:

> right, on MACs you loose if you assume they're unique, the IEEE block
> stuff doesn't hold up anymore with VMs and whatever not and on  top you
> always have to contend with the U/L MAC bit
>
> That was one of my original comments, the unique router-ID as anchor for
> self-config. Well, other people fought the problem so it's probably just
> finding the right reference. Recent OSPF/ISIS work comes to mind, previous
> attempts @ ZEROCONF, http://dl.acm.org/citation.cfm?id=2140282.2140307 and
> so on ...
>
> thanks
>
> -- tony
>
>
> Alia proclaimed:
>
>>
>> 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: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Jun 2016 20:14:23 +0200

Hi Tony,

> lots of those issues already.

Tony, please recall the Tao of Babel: we prefer to ensure that the
protocol is naturally robust against a kind of pathology rather than
defining ad-hoc mechanisms to detect the pathology.  Babel is reasonably
safe against router-id duplication: if a router-id is duplicated,
everything will still work, you'll just get slightly worse behaviour in
the presence of route failures (lower route diversity).

Suppose that routers A and B have the same router-id.  A announces
prefixes P and Q, while B announces prefixes Q and R:

  P --- A
       /  .
      /    .
  Q -+      ..... C
      \    .
       \  . 
  R --- B

Then C will correctly route to P through A and R through B.  It will also
correctly route prefix Q through exactly one of A and B -- however, the
feasibility condition will prevent it from routing through the alternate
route until the prefix expires from the feasibility table.

In other words, you get no catastrophic failures until the chosen router
crashes, and then all you get is a spurious blackhole for a few minutes.

For this reason, I'd argue that Babel needs a mandatory mechanism for
detecting router-id duplication.  Of course, this should not prevent
a management tool from detecting duplicate ids, and ringing an alarm when
it does.

Regards,

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Thu, 2 Jun 2016 14:34:15 -0400

> crashes, and then all you get is a spurious blackhole for a few minutes.

Router IDs are much more important in link state than in DUAL based
protocols. The one place where this is eventually going to be harder problem
to solve is with redistribution, though. Because you lose the original
metric in the redistribution process, it's often important/useful to have
something like an originator ID in the cluster list of BGP (RR's) to prevent
some forms of loops by rejecting things that "I" originated into the routing
domain. If you have duplicate router ID's, this is difficult.

So far, there's seems to be no consideration of externals in BABEL,
though...

:-)

Russ

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 2 Jun 2016 11:47:43 -0700

Pretty radical stuff, this, and I have a hunch from practical experience
something will prove completely infeasible in operations/protocol if you go
down the path of 'duplicate router-ids are no big deal in the protocol',
starting already from trivial DoS attacks or hijacking of traffic which
will be undetectable ...

--- tony

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Jun 2016 20:59:50 +0200

> So far, there's seems to be no consideration of externals in BABEL,

Could you please explain?

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Jun 2016 21:12:47 +0200

> I have a hunch from practical experience something will prove completely
> infeasible in operations/protocol if you go down the path of 'duplicate
> router-ids are no big deal in the protocol', starting already from
> trivial DoS attacks or hijacking of traffic which will be undetectable
> ...

I think we're in violent agreement.  There's no contradiction:

  1. Babel doesn't collapse with duplicate router-ids;
  2. duplicate router-ids cause issues.

It would certainly be good to work out a reliable way to detect duplicate
router-ids (which is more difficult in Babel than in IS-IS, by the way,
I'm not sure it's even doable reliably -- recall that we don't flood
redundant routes in the whole network).  Given a sufficiently elegant
procedure (and implementation experience), I'd certainly be in favour of
making it a strongly recommended part of the spec.

-- Juliusz

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 2 Jun 2016 12:18:43 -0700

+1 here ...