Re: [trill] TRILL IPsec encapsulation

Donald Eastlake <> Thu, 23 July 2015 10:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EE9A51A1A34 for <>; Thu, 23 Jul 2015 03:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h7dQvwaSJmvP for <>; Thu, 23 Jul 2015 03:49:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B8E31A1A06 for <>; Thu, 23 Jul 2015 03:49:35 -0700 (PDT)
Received: by obdeg2 with SMTP id eg2so55565278obd.0 for <>; Thu, 23 Jul 2015 03:49:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WjgDhJv/DIyT/3eAovOvQwsYQJ2Dl9HXtYNwwwRL4WY=; b=eGff0SZYXDdUCVkOdzESSjYETLCdhjNKaNj+mEg/CvKb8CreE9/YabAT/+I22ptdlj b+xY0Z5/kowJjc682doC+J/nUfF69bapb3y2sXbakKjvAjkdi4o2C9JMojm0lGA0/xYN EXbwezklh2w88qkCksq5wETpO7VdG+qEQk9WHlAXtkMAGXjqctprs2R4XwUdBJmemR4T kv6MqJKYAfr5vKBRP55hAj/pRV0bMUOnwmRYmCU/QP2Fso+a9SUOePfnovyauQrHMCqc t/AGcqT37t0JG17P5qsEk8yTgJYhEMduMhAdp1STs5UfLNaB4F9+lOQ/p/JgrH9Ik5Q6 qObg==
X-Received: by with SMTP id r2mr7591063obk.20.1437648574842; Thu, 23 Jul 2015 03:49:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 23 Jul 2015 03:49:20 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Thu, 23 Jul 2015 06:49:20 -0400
Message-ID: <>
To: Yaron Sheffer <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Kathleen Moriarty <>, Stephen Farrell <>, "" <>
Subject: Re: [trill] TRILL IPsec encapsulation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jul 2015 10:49:37 -0000

Hi Yaron,

Thanks for these comments. Below are a few immediate thoughts of mine.

On Wed, Jul 22, 2015 at 1:48 PM, Yaron Sheffer <> wrote:
> I have read the TRILL-over-IP draft (draft-ietf-trill-over-ip-03) as a kind
> of early SecDir review, focusing on its use of IPsec. Thanks to Donald
> Eastlake who graciously provided me with a crash course on TRILL. He's not
> responsible for any stupidity on my part, of course.

You're welcome. Sorry I was still a bit fuzzy from 12 time zone jet
lag when we got together.

> So here are some comments:
> - The draft currently uses IPsec but not IKE or any kind of key management.
> The end result is that data is being encrypted by very long-lived keys, not
> enjoying the benefit of forward secrecy etc. Please use IKEv2 and do NOT use
> IPsec directly. RFC 4107 explains why.
> - There is in fact IPsec-with-multicast, but it's not widely deployed and is
> based on the obsolete IKEv1. Instead, I suggest to use unicast encapsulation
> with IKEv2. I suppose this means that you'd want to only encapsulate data
> but not IS-IS frames.

I've been thinking about this. TRILL supports broadcast links and
handles multicast data also.

There are several different cases but, on a broadcast
(non-point-to-point) TRILL link, there is an elected designated TRILL
router (called the DRB or Designated RBridge) that, in some sense, is
in charge of the link. Perhaps the DRB could generate a group key and
send it to the other TRILL routers/RBridges on the link using pairwise
security between the DRB and the other RBridges.Of course, if the link
is actually configured as point-to-point, then you know there will
only be two RBridges on it and only need straightforward pairwise

> - The draft currently derives encryption keys from IS-IS keys. This is
> problematic at several levels:

TRILL tries hard to default to be minimum configuration so it defaults
to bootstrapping from IS-IS keys. This is not meant to prohibit other
techniques if the network manager wants to use them.

>   * The IS-IS key is common to a large group of devices (a.k.a. "a group
> key") and so is likely to be compromised.

IS-IS has both area wide keying, for authentication of link state PDUs
that are flooded area wide, and link scoped keying for link local
IS-IS PDUs such as Hellos. Link scoped IS-IS keying should be what
TRILL bootstraps from by default.

>   * The key is used directly for encryption, as noted.
>   * The key is derived using HMAC, which is specified incorrectly in the
> draft (one parameter instead of two).

Sorry, the concatenation sign should have been a comma.

>   * The derived key is identical for all routers/links.
> - I would suggest to use a derived key for authentication only, and to
> derive it differently for each link - although I realize that this does not
> raise the security level significantly. Something like: link-psk =
> HMAC(IS-IS-key, 6-byte-system-id-1 | 6-byte-system-id-2).

Right. Since our discussion, it has occurred to me that that is not
quite adequate because you can have multiple point-to-point links
between the same pair of RBridges for which you would get the same
pair of 6-byte IS-IS System IDs. Actually, pairwise security will be
between two RBridge ports and an RBridge post is uniquely identified
by the System ID of the RBridge and the locally unique Port ID of the
port. So we could go for something like

HMAC ( IS-IS key, System ID1 | Port ID1 | System ID2 | Port ID2 )

(Of course, you also need a rules so both ends get the IDs in the same
order, such as using numeric order treating the System IDs as unsigned

> - Note that IKE generates a different encryption key for each link even if
> everybody is using the same authentication key (pre-shared secret). But it's
> still a bad practice for all principals to have the same key...
> - Longer term it would improve security hugely if each router had an
> authenticated identity of its own. In other words, its own certificate and
> private key.
> - Please don't define your own MTI algorithms. Just use RFC 7321.

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

> Thanks,
>     Yaron
> _______________________________________________
> trill mailing list