[babel] DTLS and hmac co-existence

[Dave Taht <[e-mail]>]

Have I been enough of a PITA this month?

Section 4 of rfc6126bis-07 states:

   Both the source and destination UDP port are set to a well-known port
   number.  A Babel packet MUST be silently ignored unless its source
   address is either a link-local IPv6 address or an IPv4 address
   belonging to the local network, and its source port is the well-known
   Babel port.

Aside from the fact that all versions of babel prior to now enforced
this requirement that the source and destination port numbers be the
same, which is a major consideration, that idea leaked into the hmac
implementation which does a:

  DO_HTONS(&port, (unsigned short)protocol_port);
  if ((err = blake2s_init_key(&S, key->len, key->value, BLAKE2S_DIGEST_LENGTH)) < 0) goto fail;
  /* Hash the pseudo header. */
  if ((err = blake2s_update(&S, src, 16)) < 0) goto fail;
  if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail;
                                ^^^^^
  if ((err = blake2s_update(&S, dst, 16)) < 0) goto fail;
  if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail;
                                ^^^^

the DTLS branch, on the other hand, mandates that ephemeral ports be
used for DTLS communications. Section 2.1 of
https://tools.ietf.org/html/draft-ietf-babel-dtls-02

   The node acting as DTLS client initiates its DTLS connection from an
   ephemeral UDP port.  Nodes SHOULD ensure that new client DTLS
   connections use different ephemeral ports from recently used
   connections to allow servers to differentiate between the new and old
   DTLS connections.

The rub, here, ultimately, is that I could see HMAC being used to
protect multicast and DTLS used to protect unicast, in which case,
allowing for ephemeral src ports generally in the bis version
would be helpful. I do not see how requiring a fixed src port helps
anything? (besides backward compatability)

Selfishly, I have to admit, that by using an ephemeral udp port for
route transfers and a different, either ephemeral or 6696 for hello/ihu
- fq_codel automagically distinguishes between these two very different
types of traffic and in congested network conditions will drop routes
far more often than hellos.

A backwards compatible mechanism would be to try hellos/ihus from an
ephemeral port and note when you don't get one back, upon starting an
association. A key indicator to other routers no longer respecting the
fixed src port rule would be recieving such.

...

As a side note, I had suggested using UDP-lite for development purposes
or dtls communications. It's easier to use a different protocol than it
is to get a new port number out of iana...

I was queried as to why udp-lite, and my answer that I never got around
to saying was that once you have an HMAC, you don't need a CRC, and
also, to my knowledge, udp-lite is very widely deployed, just not used.
It is the same in all other respects to udp. On a single hop over ipv6,
udp-lite "just works" on the versions of linux and bsd I've tried over
the past 5 years. It's impossible to compile out in linux (although
netfilter support for it can be), for example.