Re: [Rift] RIFT fingerprint coverage

Bruno Rijsman <> Sun, 21 July 2019 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CB39120020 for <>; Sun, 21 Jul 2019 08:31:35 -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 UXbbXYM8Q2Yy for <>; Sun, 21 Jul 2019 08:31:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 143EF120019 for <>; Sun, 21 Jul 2019 08:31:33 -0700 (PDT)
Received: by with SMTP id w20so38477355edd.2 for <>; Sun, 21 Jul 2019 08:31:33 -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=/n5ROHILOp09XQezJE4Z6QtoBY0uBx/JnGFwytqKwz8=; b=Mz4ldHbIYapmQ/U94bMlUg7wwsDzww0uhZsL3WhgISrpNu1g7M8+9xuO0a6/Hgbel2 mUfd5EmbmXZHsUYJMvPUTTsWxYE/PIeFhUQkvV5928VIgKvdoDJlcin5PZv5Rh7mgvgQ 2cJqczmfXaU+ZgAdSWSscVfUptcO0rb+zXlhXRCH8EL/74sCAAgkFrrz8m+sNlvDrZt1 pGce2BkPHbjp7TyZtoEu6Ungz8N7GiasCKdMY6SlpbxU/zuo2JUgDD4DU8b/uCBMjw1R Z/JnO3NlRBzBkzkhMgv2ybqKfOh6B8J6W99li8Asz5tKa+3zxWGtrv6NtbwpsBv6CqWB hwbA==
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=/n5ROHILOp09XQezJE4Z6QtoBY0uBx/JnGFwytqKwz8=; b=FG4IFWfiyRTKlcpdhzK8nTBogric8TFq+hhnDtZGAGAYui2b6A3LgHbhD73grgm1/j l8DtY9kZQ/uIIrv98UFbtlBthWhYueQpJs6okWeYri2i0Qoz4dYYPxpBWkYeyvOzLNqQ cWXR81WrnzfUUbHhVkGvKWyhgUDXj+nZCs+12di9qjCMr0dISYjhChIOqmcolUM1vW1a HOYKZITSpjXMNDmJU2r2H/ZvAW4Lj9UmYP2O3I6UYPalgFE+zxLe4/RR2mNPS9Uaj0Oi zN9l49nsahsDmOSeFG3nlaqIzMTM/p92C/Q2Cf3mzq9ltAz+Lhy8u8JGF8sm61HEKhmi JHjg==
X-Gm-Message-State: APjAAAVtU2w/kUK6yDaDc5qpcEfk78G/b9y3tNVSKPntT7IJspykBxT6 VmIVmUWG5E/m7ESrD5fLHNs=
X-Google-Smtp-Source: APXvYqxboK2Hhiz92UWuuHvs8GCNr8RpmfE9tIwCif/9HfeHK0YVFg3+7Xb0+gNWk1oqKAND+p7gQg==
X-Received: by 2002:a17:906:7281:: with SMTP id b1mr50347276ejl.63.1563723091483; Sun, 21 Jul 2019 08:31:31 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id b30sm10431406ede.88.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 08:31:30 -0700 (PDT)
From: Bruno Rijsman <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BE08B7AE-78F2-41CB-A4FC-C96C77437945"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 21 Jul 2019 17:31:29 +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 15:31:35 -0000

> I don't like the change of inner security key name, we may one day protect something else than TIEs with it and on top it makes the naming less intuitive, the outer and inner works really well IMO

I am perfectly fine with calling it inner security key instead of TIE origin security key.  Actually, I also like that better.

I only called it TIE origin security key because it is part of what is currently called (and AFAIK has always been called) the TIE Origin Security Envelope Header.  So, I was just trying to be consistent with what was already there.

Soooo…. if we agree to call it inner security key then we should consistently call it inner security key / inner security key id / inner security fingerprint / inner security envelope header everywhere and purge any mention of TIE origin key / TIE origin key id / TIE origin security fingerprint / TIE origin security envelope header completely from the draft (and code for that matter, at least the CLI and yaml files).

Speaking of consistency: we should decide whether it is “inner key” or “inner security key” or “inner authentication key” and be consistent about that as well.  In RIFT-Python followed your RIFT-Juniper example and used “authentication key” instead of just “key” or “security key”.

I propose we use the following going forward:

outer authentication key
outer authentication key id
outer authentication fingerprint
outer authentication envelope (or "outer authentication envelope header” but that seems redundant)

inner authentication key
inner authentication key id
inner authentication fingerprint
inner authentication envelope (or “inner authentication envelope header” but that seems redundant)

Final obsessive compulsive nitpick :-) :  in the Thrift data model we should be consistent in CamelCaseNamingStyle for types and underscore_naming_style for variables (for example: type InnerAuthenticationKeyID and constant invalid_inner_authentication_key_id).

— Bruno