Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS and COMMENT)

Donald Eastlake <> Tue, 13 March 2018 20:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2C91126C89; Tue, 13 Mar 2018 13:19:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 S3DMN6mFsPxM; Tue, 13 Mar 2018 13:19:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC89E1201FA; Tue, 13 Mar 2018 13:19:34 -0700 (PDT)
Received: by with SMTP id k135-v6so1720119ite.2; Tue, 13 Mar 2018 13:19:34 -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=dVrybswmB9lWiFP2KwaWIN01cApyUUIXBV24Bm+og6A=; b=WZvqCeei0dBLx4oLFLSvx6IWQduALzFjlktiRC/LA7wZgWkcgzswOQnlU69HINzh/7 3qaZCLkA1TN4P89lwJjau21vddWBrmwzC5ZWTSV3wGNwSMSbfxOkY3SnVJb3XwpiuSw/ 5lp3C2rR8VmNshgerxRDGpUIYoJVUIRelFuvG0Eo4n9wwsKZzH29smUi3JR4QpV24lxm lHDRlJIpG4dAaBDkcPbx8XRYZxE2kK73UjZNRhNBLI7s9bWYwuJRCRtso2QRV9Odgl00 h9iLMsFZmL0KHOI87Wyz4sbakbenSOJMusF4O6O92Ok40jcoZiHcGzGa2MIQju/w+MDS otyQ==
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=dVrybswmB9lWiFP2KwaWIN01cApyUUIXBV24Bm+og6A=; b=L/MAzbFyd02jmmss0GgWC9PcEfflf+yfKX0nJQRvCme0A8VtJkiY55BuINP1Q57JVF GKEMpNhekHFwrdp9TU7V5SD0sbXY3jqLahZWs5YEEjFznyveZiWo1WTCUu5eMq400Qn2 DQBaEwtfNG5azm560wHexoij84kx27tNBaB1wZJdYVBXyoT7Whoqe/sijgxB30+aKIzB DD7UPUTQnd5vsqWCZijPuHxThx2hAhqhooBGX9o6AJJPadgyHaPpekzLDo9W/la/Xx3d 6fNZ6fpirW4iUq8esTS3fOL/4P3ouVVnrQ/F00gtkG3PriDlyjx1clYP9Rw3tzkLyoBi Qj5Q==
X-Gm-Message-State: AElRT7EYRwQFn/o/XH3rYm6tHZ9ed9GdNJd3fGrTcN8CO170bImzgd4q Hz3O3dIQqH4r6sfuLWGOVUCWU8RansqU/F4YmQMyFA==
X-Google-Smtp-Source: AG47ELtx/CySBo4Tlp5QTHHVmvGtQGQwi26/TYN1bQMhBellK7m3+ZKkQwGRYTwt9f5kFVRv4BIPYsXCW1JUwTrJ1qI=
X-Received: by with SMTP id j187mr2402825ita.85.1520972373836; Tue, 13 Mar 2018 13:19:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 13 Mar 2018 13:19:18 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Tue, 13 Mar 2018 16:19:18 -0400
Message-ID: <>
To: Eric Rescorla <>
Cc: The IESG <>,,, Susan Hares <>, trill IETF mailing list <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-smart-endnodes-10: (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: Tue, 13 Mar 2018 20:19:36 -0000

Hi Eric,

A -11 version of draft-ietf-trill-smart-endnodes has been uploaded
with the intent of resolving your Discuss. Please look at it and see
if you can clear.\

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

On Sat, Mar 10, 2018 at 9:22 PM, Donald Eastlake <> wrote:
> Hi Eric,
> On Thu, Mar 8, 2018 at 8:44 AM, Eric Rescorla <> wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-trill-smart-endnodes-10: Discuss
>> ...
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> Review in context at:
>>    Smart Endnodes would not bring more security and vulnerability issues
>>    than the TRILL ES-IS security defined in [RFC8171].
>> IMPORTANT: I think you need to discuss the security implications of
>> checking and/or not checking the smart endnodes MAC address (a MAY in
>> S 5.2). My understanding is that TRILL is kind of wishy-washy on MAC
>> spoofing in general, but if you *do* have some sort of MAC enforcement
>> in place but you don't enforce here, then this obviously bypasses
>> that. Similar comments apply to the SmartHello filtering, I think.
> OK on data.
> Smart Hellos are a very different thing. They are TRILL ES-IS PDUs
> always sent to the TRILL-ES-IS multicast Ethernet address (see
> Sections 5 and 7.6 of RFC 8171). The source MAC address of such PDUs
> is an important protocol field that is made available to the code
> processing the PDU. The first Smart Hello received from an End Station
> would be from an unknown MAC until adjacency is established, unless
> that MAC address was specially configured or something, even if that
> end station is a valid Smart Endnode. You might want an RBridge port
> to drop all Ethernet frames that are not from white-listed MACs or
> something, but that sort of general Ethernet port security feature
> isn't properly part of TRILL.
> Since connections from end stations to edge RBridge ports are
> Ethernet, such ports can always require end stations to authenticate
> themselves with [802.1X} and encrypt and authenticate traffic between
> the end station and the edge RBridge port with [802.1AE] (MACSEC) as
> discussed in the base TRILL protocol specification draft [RFC6325].
> This seems more powerful than just checking a MAC address although you
> could always do both.
> I'm not sure it should be necessary for every TRILL draft the
> optionally further empowers an end station to have to go into all
> these layer 2 security options given that MACSEC is mentioned in the
> base TRILL protocol specification that is referenced.
>>    Smart-Hellos can be secured by using Authentication TLVs based on
>>    [RFC5310].
>> I concur with Ben that you should explain the consequences of doing this or not.
> OK, although I don't think there is much to say other than that
> checking such authentication stops rogue end nodes not in possession
> of the required keying material from being recognized as a valid smart
> end node.
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> If SE1 wishes to correspond with destination MAC D, and no endnode
>>    entry exists, SE1 will encapsulate the packet as an unknown
>> Should D be shown on the diagram below? I don't see it.
> Yeah, probably the network connection to Endnode1 should be labelled D.
>>       the same meaning as the Holding Time field in IS-IS Hellos [IS-IS]
>>       . A Smart Endnode and an Edge RBridge supporting Smart Endnodes
>>       MUST send a Smart-Hello at least three times during their Holding
>> Ooh, bad break here at this period.
> OK.
>>    o  MAC(i): This is a 48-bit MAC address reachable in the Data Label
>>       given from the Smart Endnode that is announcing this APPsub-TLV.
>> does "given from" mean something different than "sent by"?
> No. "sent by" would be more usual wording.
>>    o  When SE1 wishes to send a multi-destination (multicast, unknown
>>       unicast, or broadcast) to the TRILL campus, SE1 encapsulates the
>>       packet using one of the trees that RB1 has specified.
>> I see this called "BUM" in other documents. This is a nit, but do you
>> want to use consistent terminology?
> I think too many documents overuse acronyms. If this draft wants to
> list out the sub-types or use "multi-destination" instead of the
> acronym, I think that's good.
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA