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

Eric Rescorla <ekr@rtfm.com> Thu, 08 March 2018 13:44 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B59126CD6; Thu, 8 Mar 2018 05:44:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-trill-smart-endnodes@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.74.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152051669498.13986.10062778727515004234.idtracker@ietfa.amsl.com>
Date: Thu, 08 Mar 2018 05:44:54 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/x5A7jGotHCxQTAdjwSsgXYUQdFA>
Subject: [trill] Eric Rescorla's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS and COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2018 13:44:55 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-trill-smart-endnodes-10: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Review in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D3548

   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.

   Smart-Hellos can be secured by using Authentication TLVs based on

I concur with Ben that you should explain the consequences of doing this or not.


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.

      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.

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

   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?