[Babel-users] DTLS and hmac co-existence

[David Schinazi]

Hi Dave,

The Babel over DTLS spec states that
- unicast traffic is sent over DTLS, where DTLS client uses an ephemeral
port, and DTLS server uses a well-known port different from 6696
- multicast traffic still uses 6696 for source and destination

I don't see any issues with protecting Hellos with HMAC and everything else
with DTLS.

David

On Wed, Nov 28, 2018 at 1:56 PM Dave Taht <dave at taht.net> wrote:

>
> 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.
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/babel-users/attachments/20181128/2d808cdf/attachment.html>