Re: [Rift] RIFT fingerprint coverage

Bruno Rijsman <> Sun, 21 July 2019 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06B5F1200B6 for <>; Sun, 21 Jul 2019 09:04:05 -0700 (PDT)
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_HELO_NONE=0.001, SPF_PASS=-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 j6mt4gPtVBXF for <>; Sun, 21 Jul 2019 09:04:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAB60120075 for <>; Sun, 21 Jul 2019 09:04:02 -0700 (PDT)
Received: by with SMTP id i11so38545157edq.0 for <>; Sun, 21 Jul 2019 09:04:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RvVeD+9LkElmFaZ3VpU0gkQmZGSN9PFFexetzJMsE8I=; b=mwWUFagx/LE/qptDb523v9oiQcg/51u6n0soOWeeiBh+x/pM6FePAx7l8L8joF1mvt lTbR0AFKCeMCfY9SM7dbVQoNP8BFzuR/S7DxORVzsv0nr1K6rU4wAzw6wnANH5sSdF6G 1Hn2mM/P6SgyrFs2CIimHShpK0ROC5Phl86MH06egZsA+8jLbAza7EhIpZqTlEFeqJ52 0uw7lPtzvDCLg+0gjP8XvxKea2gD0Sd8FBdI9J+WtXzhn11ggdBoHPoK4g5xoSmkRZ9j eTeIJD6zhF49IEw08Im2fdd+Xo6Mc5VHc+OOVXWGqz5ofPVjMV6UbOrHoveZwR+pRfHy znMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RvVeD+9LkElmFaZ3VpU0gkQmZGSN9PFFexetzJMsE8I=; b=GA7eOIahOlZv4tHFyMI8XIz5/1BkWbX2qqwwPFlsHEMmTJzRMqXuNtnZb8crEEHjBb TJOvtH0DlFwTlrUIYZzaeNZ7uNLUD3QBQAClRdv9BZhKM5z/FEzCjSsZ+JLhXM0vIAvo cEgKiZZ0yUqTGFltnMQ/UTsGsKK58lcbReaSXkAZbXmWIEzIko+7t7mC9QXyxSdTo23t Uv0Ouq8s7KgyZu6SowqthNt2FY8hU7QzaMVbh2nHBQfedPKMCgBClZUOYohjBsyOp1dR +KCP8YfJEDRtllPJSCY0HOf+PRyelpksegaauB/Vh0KQoGzlPIV16fXgi81RTbYqUTmh A2fQ==
X-Gm-Message-State: APjAAAXzRAJzdZQc++FP4AIGnIWbHysJZx6EfMsNnofuHYDl6xdEKrEP Jx4YwuaG6gsVbKjYM5bhlS0=
X-Google-Smtp-Source: APXvYqwrK8fZ8t7c4TbkiH523A1I9IpvGU34kl8ylM1qpmK49fEuVTT5L31tFK+lV7bLQc+8X/vCPw==
X-Received: by 2002:a17:907:2091:: with SMTP id pv17mr49553225ejb.152.1563725041315; Sun, 21 Jul 2019 09:04:01 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id o18sm10157723edq.18.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 09:04:00 -0700 (PDT)
From: Bruno Rijsman <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BEBC2FDB-9797-41B2-8BD0-3478C4241830"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 21 Jul 2019 18:03:59 +0200
In-Reply-To: <>
Cc: Tony Przygienda <>, "" <>
To: Antoni Przygienda <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Rift] RIFT fingerprint coverage
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Jul 2019 16:04:05 -0000

> On Jul 21, 2019, at 4:22 PM, Antoni Przygienda <> wrote:

> 3. second, even if we do I don't think we improve the attack envelope or actually worsen it. Let's go through it 
> major version is attacked, any change will drop the packet due to mismatch. if we protect it, we calculate the hash and it fails and outcome is the same modulo we can be computationally overrun 
> outer key id is attacked/fingerprint length is attacked, all same outcome ...
> now, you can argue that an attacker can modify stuff _behind_ the fingerprint and with that attack protocol computationally but there is no way around that, we won't detect modification otherwise wheeras modifying major version/key id/fingerprint lenght basically leads to drops on any change and protecting them only exposes us computationally for no benefit

The receiving RIFT router can drop packets with the wrong major version, with a wrong key-id (not in the accept key set), or a wrong fingerprint-length, without validating the fingerprint first.

This is for the same reason that a RIFT router can drop a packet with an out-of-range weak-nonce without validating the fingerprint first.

In general, it is safe to reject a packet when any field has some unacceptable value without validating the fingerprint first.

So, protecting these additional fields does not open up any new CPU denial of service attacks.

If a RIFT router is planning to accept a packet because all fields have an acceptable value, then it must validate the fingerprint first before doing so.

Or if a RIFT router is going to reject a packet but take some protocol action based on some field in that rejected packet anyway, then it would have to validate the fingerprint as well (happily, which currently don’t have this scenario in RIFT, as long as the packet-nr is truly only used for debugging and not for flow-control, for example).

So, the real question is: how sure are you that leaving the major-version, key-id, and fingerprint-lengths fields unprotected will not lead to some problems down the road?  (To quote Dirty Harry: “Do you feel lucky? Well, do ya, punk? :-)

— Bruno