Re: [trill] Kathleen Moriarty's Discuss on draft-ietf-trill-transport-over-mpls-07: (with DISCUSS)

Donald Eastlake <> Tue, 13 March 2018 02:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40B0712785F; Mon, 12 Mar 2018 19:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 6nnrK5nxXWWp; Mon, 12 Mar 2018 19:01:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DFF161201F2; Mon, 12 Mar 2018 19:01:51 -0700 (PDT)
Received: by with SMTP id m83so1325043ioi.8; Mon, 12 Mar 2018 19:01:51 -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=D6X/DjLoNdmwDkQDtIWVoDNVjzt3CTBsSzIZWhjk+PQ=; b=J7kA7HLU785MyogW1y35lEtWwIh1i+du1flMDkZVGmdoU4dk0W+Cd/GzI13DwOpPhQ 7AjxCbzsdkkMUonJQWAvGvNo9ivAYwaHz23owuWbsW9VlKeVof1EM9rCPzaTRCRqDSbb 9DfMlEpWxlH9NwACu1V0U3rmD+OEOL7FovNSj9wi5JP4n+t5nKoD16OC6hkr68quetym C2Ezh92ep1Jmu3sVn9kq7gNbbsZEi1XbFounlxViI9ThHhO6mSV0esPHO4taBdSunvDP AQ6iqSoxNrEhcA+Zu0YfxRGwLtIwlSIBBaeSRp5esEZuoghzNoOnDzbGdo+4mkqvUb4I tNVQ==
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=D6X/DjLoNdmwDkQDtIWVoDNVjzt3CTBsSzIZWhjk+PQ=; b=buoneUtcq4cVd4WanjU6RneCiFKLiac1iAktjKIHg/uxTCAB8PTUsby5wYQWQWibT9 5sjslgKyXS4BgtVKiEUFJOpXyRzR83OmVNrKK2tLjYD1V/Ip65RfV825wGpBTdp5TsGi kF9jjDe/FTwz1DpHl4jYzB4XU4LVpBskh3ffHFruP5ri4SMI/t5AJJ+w3QsjuzBTy3dp mQmrbK54HXCR0JLvTI4Ircp8syMH63Yo4wFLZVGGJXf0I9NybXt+3eoPf5dNV6vCLkX9 lWaZdhcpI/RBOI8Z6mISlZ4IHgYdrepYXTlguoshQ5o8/eeR2FQH+cqwsaMnEC5CTXNo wrGg==
X-Gm-Message-State: AElRT7HvyoRAqTwgWZpdKjoC3Md05pMPip5hQm04ptVE6DFGbhrl0qzw gx/GjHhmYNAhuR19aTmRuDxdCpR3u343dweK+x9SjoO6
X-Google-Smtp-Source: AG47ELvFy0P4EAtcjGqP6QGX+Lo3GQBShasu/jHiKtHStURk0g6JVfxoYfVrwBNyIB/WM/GajJIc/rcWq9nSDURCiOE=
X-Received: by with SMTP id k195mr10953716iok.131.1520906511042; Mon, 12 Mar 2018 19:01:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 12 Mar 2018 19:01:35 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Mon, 12 Mar 2018 22:01:35 -0400
Message-ID: <>
To: Kathleen Moriarty <>
Cc: The IESG <>,,, Susan Hares <>, trill IETF mailing list <>, "Andrew G. Malis" <>
Content-Type: multipart/alternative; boundary="001a114041aa53cb59056741a4a8"
Archived-At: <>
Subject: Re: [trill] Kathleen Moriarty's Discuss on draft-ietf-trill-transport-over-mpls-07: (with DISCUSS)
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: Tue, 13 Mar 2018 02:01:54 -0000

Hi Kathleen,

Would the following replacement Security Considerations section for
draft-ietf-trill-transport-over-mpls be adequate?

   This document specifies methods using existing standards and
   facilities in ways that do not create new security problems.

   For general VPLS security considerations, including discussion of
   isolating customers from each other, see [RFC4761] and [RFC4762].

   For transport of TRILL by Pseudowires security consideration, see
   [RFC7173]. In particular, since pseudowires are support by MPLS or IP
   which are in turn supported by a link layer, that document recommends
   using IP security or the lower link layer security.

   For added security against the compromise of data end-to-end
   encryption and authentication should be considered; that is,
   encryption and authentication from source end station to destination
   end station.

   For general TRILL security considerations, see [RFC6325].

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

On Wed, Mar 7, 2018 at 5:35 PM, Andrew G. Malis <> wrote:

> Kathleen,
> I don’t want to speak for the authors. However, I did contribute to this
> draft (although not this specific section). So that said, here’s my two
> cents ….
> I agree that first sentence could have been worded better, but the bottom
> line is that depending on the model used, the security considerations for
> RFC 7173, 4761, or 4762 applies, including the discussions in those RFCs on
> issues such as isolation and end-to-end security. Those RFCs are referenced
> in the security section. So the substance is already there, perhaps the
> draft just needs better pointers to it.
> Cheers,
> Andy
> On Wed, Mar 7, 2018 at 5:01 PM, Kathleen Moriarty <
>> wrote:
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-trill-transport-over-mpls-07: Discuss
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> Please refer to
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> I was very surprised to see the following in the security considerations
>> section and would like to work with you on improvements.
>>    As an informational document specifying methods that use only
>>    existing standards and facilities, this document has no effect on
>>    security.
>> Having watched many TRILL documents go by in the last 4 years, we didn't
>> push
>> too hard on security in some cases as a result of the restriction to a
>> campus
>> network.  This particular document extends into multi-tenancy where there
>> are
>> certainly security considerations introduced to be able to provide
>> isolation
>> properties.  MPLS offers no security and it is being used to join TRILL
>> campuses as described int his draft.  This is done without any
>> requirement of
>> an overlay protocol to provide security - why is that the case?
>> Minimally, the
>> considerations need to be explained.  Ideally, a solution should be
>> offered to
>> protect tenants when TRILL campuses are joined.
>> _______________________________________________
>> trill mailing list