Re: [trill] TRILL IPsec encapsulation

[Donald Eastlake <[e-mail]>]

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 <[e-mail]> 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
security.

> - 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
integers.)

> - 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.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Thanks,
>     Yaron
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>