[babel] DTLS and hmac co-existence

Dave Taht <dave@taht.net> Wed, 28 November 2018 21:56 UTC

Return-Path: <dave@taht.net>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BBD131063 for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 13:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69GBVR9HERi7 for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 13:56:33 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9731310AD for <babel@ietf.org>; Wed, 28 Nov 2018 13:56:32 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 8257121B39; Wed, 28 Nov 2018 21:56:29 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: babel-users@lists.alioth.debian.org, babel@ietf.org
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com> <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <CAA93jw5gaYgyUX-ABX156_TnFX25Sy5SLyuRgd28fMLfRW4UHA@mail.gmail.com> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <CAPDSy+5QDu_kW-f=JWO1cPJJnDwDNpVwxwVC9SxfcE5+EOMpRg@mail.gmail.com> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net>
Date: Wed, 28 Nov 2018 13:56:17 -0800
In-Reply-To: <8736rl16yj.fsf@taht.net> (Dave Taht's message of "Wed, 28 Nov 2018 08:51:16 -0800")
Message-ID: <87o9a8zx1a.fsf_-_@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/Ako1T-aB5-Mg3kNOs4QJsLs4qyE>
Subject: [babel] DTLS and hmac co-existence
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2018 21:56:39 -0000

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.