Subject: [babel] Unicast Hello Messages and IHUs

From: Margaret Cullen <[email-masked]>
Date: Tue, 28 Mar 2017 10:50:04 -0500

I spoke with Julius yesterday about the need for unicast Hello messages to support some security scenarios.  If Babel could be run using only unicast messages, this could also enable support for Babel over Non-Broadcast Multi-Access (NBMA) networks.

I’ve looked into this in some detail, and I believe that we can support unicast Hello messages and IHUs (and therefore a fully unicast implementation of Babel) with a small number of changes to the base specification to allow this practice.  In cases where peers are configured or discovered through other means, this does not involve any changes to the core Babel protocol.  The current use of broadcast Hellos and multicast IHUs would continue to be fully supported.  

We have a specialized implementation of Babel that uses unicast Hello messages and IHUs (as described below), with all of the Babel traffic running over GSSAPI in encrypted peer-to-peer sessions (which is something we need for reasons specific to our application).  We have not seen any problems related to using unicast Hello messages in this manner.

I have included a short set of document changes to rfc6126bis below that I believe would accomplish this goal.

Thoughts?

Margaret

_____

In Section 2.1 (Costs, Metric and Neighbourship)

OLD:
A Babel node periodically broadcasts Hello messages to all of its
neighbours; 

NEW:
A Babel node periodically send Hello messages to all of its
neighbours; 

In Section 3.1 (Message Transmission and Reception):

OLD: 
With the exception of Hello TLVs and acknowledgements, all Babel TLVs
can be sent to either unicast or multicast addresses,

NEW:
All Babel TLVs can be sent to either unicast or multicast addresses,

In Section 3.4.1 (Reverse Reachability Detection)
OLD:
Every Babel node sends periodic Hellos over each of its interfaces.
Each Hello TLV carries an increasing (modulo 2^16) sequence number
and the interval between successive periodic packets sent on this
particular interface.

NEW:
Every Babel node sends periodic Hellos, which may be broadcast over 
each of its interfaces, or sent in unicast messages to each of its peers.
The Hello TLV carries a sequence number
and the interval between successive periodic packets sent on this
particular interface.  The sequence number is increased (modulo 2^16)
for each Hello interval.

In Section 3.4.2 (Bidirectional Reachability Detection)
OLD:
While IHUs are conceptually unicast, they SHOULD be sent to a multicast 
address in order to avoid an ARP or Neighbour Discovery exchange and 
to aggregate multiple IHUs in a single packet.

NEW:
While IHUs are conceptually unicast, they SHOULD be sent to a multicast 
address when broadcast and multicast are in use, in order to avoid
an ARP or Neighbour Discovery exchange and to aggregate multiple IHUs
in a single packet.

In section 4.4.5 (Hello)
OLD:
Since there is a single seqno counter for all the Hellos sent by a
given node over a given interface, this TLV MUST be sent to a
multicast destination.  In order to avoid large discontinuities in link 
quality, multiple Hello TLVs SHOULD NOT be sent in the same
packet.

NEW:
Since there is meant to be a single seqno counter for all the Hellos 
sent by a given node over a given interface, this TLV MUST be sent to a
multicast destination, or the set of unicast Hellos sent on a single interface
in a single Hello interval must use the same seqno.  In order to avoid 
large discontinuities in link quality, multiple Hello TLVs SHOULD NOT 
be sent in the same packet.

---

From: Dave Taht <[email-masked]>
Date: Tue, 28 Mar 2017 09:10:59 -0700

+10.

I will try to attend the meeting remotely today.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 28 Mar 2017 12:17:55 -0500

> I spoke with Julius yesterday about the need for unicast Hello messages
> to support some security scenarios.  If Babel could be run using only
> unicast messages, this could also enable support for Babel over
> Non-Broadcast Multi-Access (NBMA) networks.

> I’ve looked into this in some detail, and I believe that we can support
> unicast Hello messages and IHUs (and therefore a fully unicast
> implementation of Babel) with a small number of changes to the base
> specification to allow this practice.

The main issue is that the Hello seqno is per-interface: if you have two
neighbours on the same interface, and send a unicast Hello to one and not
the other, the seqno counters will become desynchronised.  So either:

  - you make the seqno counter per-neighbour; or
  - you require that the same number of Hellos be sent to each neighbour; or
  - you remove the seqno from unicast hellos; or
  - something else that I'm missing.

I'm sure a solution can be found, but it's not a simple matter of removing
the requirement that Hellos be sent over multicast.

Sending IHUs over unicast is easy (a patch to do that was sent to
babel-users, and tested by Dave).  However, doing it naively breaks the
RTT extension, since RTT is only measured when Hello and IHU are sent in
the same packet.

-- Juliusz

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 28 Mar 2017 13:23:44 -0500

My proposal is that any time we would currently send any Hello on an interface, we could instead choose to send a unicast Hello to _every_ peer on that interface using the same sequence number.  I think that is the least disruptive way to support unicast Hellos.

IHUs could also be sent in the same packet, although it would probably not make sense to include an IHU in the other Hellos that are sent to keep other neighbors on the same link in sync.  The draft should probably mention that.

Sent from my iPhone

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 28 Mar 2017 15:32:39 -0500

> My proposal is that any time we would currently send any Hello on an
> interface, we could instead choose to send a unicast Hello to _every_
> peer on that interface using the same sequence number.

Right.  This works fine, doesn't break existing implementations, and
requires barely any protocol changes.

Is it ambitious enough?  Does it meet all the requirements for unicast
Hellos?  What if you want to send hellos more frequently to one neighbour
than to others, what if you want to use multicast by default and unicast
for selected hosts?

Russ's proposal, if I understand it correctly, was to interpret every
packet as a Hello; then, in order to send a unicast Hello, you just send
an empty problem.  The problem with that is that timestamps are a sub-TLV
of Hello TLVs, so you'd need a place to piggyback timestamps.

My proposal is to define a new TLV, the "seqno-less, interval-less Hello",
which has no payload and can be sent over unicast, multicast, whatever;
any sub-TLV that is allowed on Hello is allowed on NakedHello.

Question to the audience: is it possible to achieve the same without a new
TLV?

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Tue, 28 Mar 2017 13:48:57 -0700

> than to others, what if you want to use multicast by default and unicast

As I mentioned, there is a deployment problem, where if you want to
upgrade an existing network to have unicast hello capabilities, the
participating routers need to agree on what they can send and recieve.

There is another interesting case in the case of wifi or a shared
network - a new (or freshly booted) babel router can snoop on existing
unicast traffic and determine the babel nodes already on it and try to
communicate directly with them, also via unicast, without ever needing
to revert to multicast to announce itself.

> of Hello TLVs, so you'd need a place to piggyback timestamps.

Let me go to my route-update related congestion control problem. A
possible way to cope with that is to embed the timestamp related tlv
inside the message_ack request and response (rather than within the
hello/IHU)

> Question to the audience: is it possible to achieve the same without a new

I like the idea of not needing anything at all in what is basically a
heartbeat message.

But why exclude the interval possibility?

...

There are quite a few things I'd often wanted sometimes embedded in a
hello-like message - they included "number of routes I have", "I'm
(not) a default gw-ish device", "my location is here", "this is my
forwarding rate and how much capacity I have left over", "uptime", and
so on.

... but I've generally tried to refrain from this can of worms.

> -- Juliusz
>
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org