Re: [babel] [Babel-users] DTLS and hmac co-existence

David Schinazi <> Wed, 28 November 2018 22:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBAEE130DC0 for <>; Wed, 28 Nov 2018 14:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xRbiWkQwYjJb for <>; Wed, 28 Nov 2018 14:50:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0B4D130E27 for <>; Wed, 28 Nov 2018 14:50:04 -0800 (PST)
Received: by with SMTP id g9so5630331plo.3 for <>; Wed, 28 Nov 2018 14:50:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9jZv700NU65/Uq9KRRm4nPlTJvoN9O9SHVTPZpobWa0=; b=j0tyNed207NOFUXTKsWcIczXYT/GWjSOUGR64DZQnAEcS8If2oqvyFdFvMVzORJLn7 Crn88nYpUGhoxLXnVUaashLBCB8fHfrGgjBQf3KVN8NH4gvOvHALzrfnqiOaj9plARkE M0tGVOpGetSNNO9m4/gywsTvK/t3e/ahHb4Obhwpgx5WhqElEe9wKvDsT6GFp5IikEyO v9nvZqQWsRcW+S45p7DDc47Xo6M1xFUi5Cy18EdgsKZffrBraXUVnzSLGYexKrqnsgjZ nnrkC6k1FfOBEKvZvAYrY+fzU66+gDluxcTHih4LcCrG3Qb6E1OrWsZNfOQUoGdjJ4k1 ue3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9jZv700NU65/Uq9KRRm4nPlTJvoN9O9SHVTPZpobWa0=; b=ny16EAKs4P3bbJxuCueWrdLJ5f29kDid8TKSB42FpS1cf6GUU092ZRE8ohviUgJPo/ ujhhZoZHxVRtZAzVECuwTKcQ3L0WXmEL3iUa4CIaXjYZKgNqFAKxFRhKACSPVQXGaNGA 8XBgputYsIgm/1DH0TlN9xREtnu/vwa0+9O5SAdmMtJGmDGbmuaqUftJ/xTGKVOKoLgH C9E2l6+PJ8xJXT9l/c8HlxKy2Ra5IIsp4/G+g49vF4UXk3+JlZ+1E/R3ATVLQg1fJWs4 lOH67w4wtj80Xt6uGm5jQSMIViLtW/BMkS//V8Jjt89+bvGwdT7NPMSkFfd2joRnD77e bDTQ==
X-Gm-Message-State: AA+aEWbUr0F2qv4wczpPTxCcb4PMn5rUWVNzSFOcepf9reNRWfzgPNcn nNQlt7SuKXzDLTDK+zbnzgUhyTMCpisAVe1Nu7s=
X-Google-Smtp-Source: AFSGD/WgJvHe5plde2k4Ld/8YmT/30Nh++fKo7AH8dWdXgF6pVFPlx9liVuP1ZpkqmaG6U8tT2zD+9vvZDOy5AUHtpg=
X-Received: by 2002:a17:902:aa0a:: with SMTP id be10mr38244557plb.266.1543445403967; Wed, 28 Nov 2018 14:50:03 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Wed, 28 Nov 2018 14:49:52 -0800
Message-ID: <>
Cc: Juliusz Chroboczek <>,,
Content-Type: multipart/alternative; boundary="00000000000008a5b2057bc1634b"
Archived-At: <>
Subject: Re: [babel] [Babel-users] DTLS and hmac co-existence
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Nov 2018 22:50:09 -0000

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.


On Wed, Nov 28, 2018 at 1:56 PM Dave Taht <> 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
>    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