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

Donald Eastlake <d3e3e3@gmail.com> Sun, 11 March 2018 02:22 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160FC124B18; Sat, 10 Mar 2018 18:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L3kNnDiJbNf; Sat, 10 Mar 2018 18:22:45 -0800 (PST)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F16124234; Sat, 10 Mar 2018 18:22:45 -0800 (PST)
Received: by mail-io0-x235.google.com with SMTP id m22so7628667iob.12; Sat, 10 Mar 2018 18:22:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QGYNfZc6GtqnRbeC2P4wG+9ZCrulrTDUvy+SUTS+X7c=; b=cFMl9grsHFYkkxX/wC5yGttLOXtOqc7epJRSVPS9yxNJ5swyv+SH5Mw9zrbyBf4/MT FOoM0Iu4Ro+LJbYOOttgpKy0DCPaL7yvob0Xifdld5zJVZzixig8GcPDMSHLLm4CEWFE YvTMLSx92tY5gQyK4d86rKye+PC/92WhhIJmKFtGLgDVjGy6ksE5IqK4lFapbwefeCzY F2GxX9aQq22IlgniauRTxtm+VUeLfsmaaFcn4+dGcMw46dF6PD+3DlcMVfwSfHcTPaJC ccKiTn5TXabrX1GJkxh85m7VWAI5dO7LUlxAyGDQSrV5dy/Xmw/aBYTW5k7TEQl2TNn8 LU1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QGYNfZc6GtqnRbeC2P4wG+9ZCrulrTDUvy+SUTS+X7c=; b=KTfMTYM0irTASmlTuUqzg1+Kx5MnBRX5TAzSF3VjaIVyklOZNj+/77zFs9iu55vRwH dIDDUUncTvocBv6PtSLCcR3phCTxSEaEGrLBVQ+ZvRwfjHIglJlBN0YTBeRMWrtbx090 xxUV/juDZKiS184lwyJCNAPdmCgIUeF60cCABKHeyaSGMAxYghaJmuiHsn8yby+y3kpp ERjIKDbC6mHyZKZLhdwfNk/amsoaSvE3vkZNciWyC6yHzqCh/EAGVeN286r0LWkrT77N VExxaMXEQ9ZA9vcCcd/rYlxOCqJ65vODccYdHRv5if92jqF+tWeZOci4jIMdoPuMelbT JYRw==
X-Gm-Message-State: AElRT7FJzikBCH+H0xKW+jDd7YB9yP7KTu59lOBvEj5UdbWO6P2i6wqM gQZZEV1BFgAc5OcVakHGyk+wDGVGw4mqTOuPteA=
X-Google-Smtp-Source: AG47ELuJQRq87mMRwdKvc+lRgs5b+KP60VbMq4pnxlMeO02i1f25bAe4xQpVO428B6/B+WhaEnAw95jmwjqbhbRYlbI=
X-Received: by 10.107.12.32 with SMTP id w32mr4125679ioi.132.1520734964368; Sat, 10 Mar 2018 18:22:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.58.193 with HTTP; Sat, 10 Mar 2018 18:22:28 -0800 (PST)
In-Reply-To: <152051669498.13986.10062778727515004234.idtracker@ietfa.amsl.com>
References: <152051669498.13986.10062778727515004234.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sat, 10 Mar 2018 21:22:28 -0500
Message-ID: <CAF4+nEHzRcXOpjWLQJbwBLLz2XigV6N17LRBuG1r3v7=EyS7rQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-trill-smart-endnodes@ietf.org, trill-chairs@ietf.org, Susan Hares <shares@ndzh.com>, trill IETF mailing list <trill@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/9osvRkW9foeF9UTIvsoAVMbvLLo>
Subject: Re: [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
Precedence: list
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: Sun, 11 Mar 2018 02:22:47 -0000

Hi Eric,

On Thu, Mar 8, 2018 at 8:44 AM, Eric Rescorla <ekr@rtfm.com>; wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-smart-endnodes-10: Discuss
>
> ...
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 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.

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.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> 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
 d3e3e3@gmail.com