Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-over-ip-15: (with DISCUSS and COMMENT)

Donald Eastlake <> Sun, 18 March 2018 12:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E276127871; Sun, 18 Mar 2018 05:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZgzAi5Nmjfm6; Sun, 18 Mar 2018 05:21:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3BEA12704A; Sun, 18 Mar 2018 05:21:32 -0700 (PDT)
Received: by with SMTP id v13so3875822iob.6; Sun, 18 Mar 2018 05:21:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KveGR6zL/I789mdJbqI4Jt3b1XZMZ2sgtu0fMwlygtE=; b=OKVlO2HW5BisT0UU4Mzz6N8rReBbQ0/kmXYkCbm1eTgQe086GWa23d1SrTe7ViTCxh GneviopCdtBKIFxj0h/rTNaGiARBoLGWb4ZxWsa71rHD2yz1peonNTIKmILAcIIXf0kf 5Fy8PKRLBcHagfCx3shXm6jdNHVp7On5OpG/1/akcjeI89qFJqsPcv8AkedT/Y9a3DT0 ff3KYjim6z8suJPsEJEpa3/mJEnlTa3BKI5lkoxqMCMcrDzDlxCNt2TevP4SAZRzAgmK z+v0CIyHPgHdgI2pbehkagnV9y+HLeTLOMSDxp+iCWb6IMx5NYbUeeOd46LOyfdWwtdN ai1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KveGR6zL/I789mdJbqI4Jt3b1XZMZ2sgtu0fMwlygtE=; b=l3qUr8UVmBgEsGCUcO/TBwUGZXXheKH+bnquA1OwM6Vsm9neKcYI7/CNjoyuHRS6bd 75JtORYJZjVFodIBtkPV3CFTlGxd9XY2iCEFk/sCMLeHGibDpOOQoQiHJQ9DHHBDeq+R bOuCsq9MuACoob0LAZB18mw5Yd1E9c64hbtCxvHX3Mawg+3vAhx94G2PMaIg3akY3/Yc QpKEmhbGZ9/uoDxnoTORTRlgaU1K53JASY2uuaVmwlwQEZyKhX6Bvg77sZ55KeR166F+ eq1tPDAlmo0zT6zW3Yw7tKbfVqcRZpjvpmFAG4CR6xdnB3w/FhTrqvN6JstvUiWwfpvK AVPw==
X-Gm-Message-State: AElRT7GtvvRF8G5nrqh7o6WkQWbF6Kb3AmN0YZQpKdfsjANFFMGc0mBZ Otw5wJOZIPOb9qn66laImwOWHAn5nVlbTpRISZE=
X-Google-Smtp-Source: AG47ELtLvIlmYSB/JAh5sb+5+RzW9dRq3j4YRRKqBsG7SKF71hSUTgQrXBRst3X2gQHZR4M5H+Je8vXty5xZPAZTNQ0=
X-Received: by with SMTP id j79mr4871943iod.14.1521375692013; Sun, 18 Mar 2018 05:21:32 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 18 Mar 2018 05:21:16 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Sun, 18 Mar 2018 08:21:16 -0400
Message-ID: <>
To: Eric Rescorla <>
Cc: The IESG <>,,, Susan Hares <>, trill IETF mailing list <>
Content-Type: multipart/alternative; boundary="001a113eb788b165ea0567aee16b"
Archived-At: <>
Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-over-ip-15: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Mar 2018 12:21:35 -0000

Hi Eric,

On Sun, Mar 18, 2018 at 4:56 AM, Eric Rescorla <> wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-over-ip-15: Discuss
> ...
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Hopefully this is easy to resolve. In the best case, you will be
> able to demonstrate that this is not a problem in practice and
> document that. If not, the actual fix is straightforward, though
> incompatible.
> S 7.1.1.
> I am concerned about the use of the IS-IS key in this way. First, on
> general principles, you should not use a single key both as input to a
> KDF and directly as a working key. Specifically, however, RFC 5310
> defines the use of HMAC authentication with IS-IS-key as the HMAC
> key, and HKDF-Expand is really just SHA-256. Thus, if an attacker
> was able to observe (or cause to be created) an IS-IS packet that
> happened to have the same contents as the HKDF Info value you
> provide would then know the IKE PSK.
> The correct practice here is to separately expand both the IS-IS
> key *and* the IKE PSK from the same original value. If you cannot
> do that, you should at least generate an Info value which is
> guaranteed to not be the input to any RFC 5310 MAC.

The source may not be easily accessible.

The first byte of the data to which the RFC 5310 MAC is applied is always
0x83, the Interdomain Routeing Discriminator. The first byte of the data
below is 0x54 ('T') so they cannot be the same.

     HKDF-Expand-SHA256 ( IS-IS-key,
         "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port )

Could also add some text such as "Note that the value to which the HKDF
function is applied starts with 0x54 ('T') while the data to which RFC 5310
authentication is applied (an IS-IS PDU) starts with 0x83, the Interdomain
Routeing Discriminator, thus, although they are both SHA256 based, they are
never applied to the same value."

>    When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that
>    incorporates the IS-IS shared key in order to bind the TRILL data
>    session to the IS-IS session.  The pre-shared key that will be used
> The technique you provide does not guarantee a binding between the
> sessions. It merely ensures (modulo the caveat above) that both sides
> know the IS-IS Key. It's easy to see this by noting that you could
> move IS-IS traffic from one IPsec association to another. If you
> actually want to bind these sessions, you must do something different.

I think the idea was just that, in conjunction with the text later in this
section, the IPsec key wouldn't be used for longer than the IS-IS key.

How about just deleting the words "in order to bind the TRILL data session
to the IS-IS session."?

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I see that native encapsulation is incompatible with NATs (S 8).
> That's probably worth stating upfront to minimize confusion.
> S 5.4.2.
>       f. No middleboxes are allowed in the TRILL over IP transport link
>          because middlebox support is beyond the scope of this document.
> How would you know if no middleboxes were in the link?

Well, if they map IP addresses, the "neighbor" values inside the Hellos
will not get mapped, will not match, and thus you will be unable to
establish adjacency and nothing will flow over the link except Hellos (no
data, LSPs, etc.). You need an application specific gateway for TRILL to
operate through a NAT. On the other hand, a sufficiently benign middlebox
(if there are such things) which, for example, only had a black list of
some IP protocols / ports / addresses, that had no effect on the TRILL data
or control traffic would be pretty invisible and TRILL should work fine
through it.

How about the following replacement text:

f. This document assumes there are no middleboxes in the path and thus does
not cover restrictions on such middleboxes. Middlebox support is beyond the
scope of this document.

> S 5.5.
> Can you use VXLAN with IPsec?

"VXLAN" is really Ethernet over VXLAN over UDP. I don't see a problem with
doing Ethernet over VXLAN over UDP over IPsec.

> S 5.6.
> What security mechanism do you expect to use for TCP? IPsec again?


>    the timing and implementation details may be such that P! and P2 each
> Nit: P1, right?

Yes, sorry about that pesky shift key...

 Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
 155 Beaver Street, Milford, MA 01757 USA