Re: [trill] TRILL IPsec encapsulation

[Yaron Sheffer <[e-mail]>]

Hi Donald,

Sorry for the late reply.

Please see some comments/responses below.

Thanks,
	Yaron

On 07/23/2015 01:49 PM, Donald Eastlake wrote:
> 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.

You are proposing to add key management functionality into TRILL, 
specifically for multicast/broadcast cases. It doesn't sound like a good 
idea to me.

If this usage is core to TRILL, you should look at RFC 6407 and the 
other MSEC documents, and bear in mind that they are not widely 
implemented. Otherwise, you're better off sticking to plain IKEv2/IPsec.

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

Yes, this is a lot better than a global group key.

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

Sounds good.

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