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

Donald Eastlake <d3e3e3@gmail.com> Tue, 13 March 2018 20:19 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 F2C91126C89; Tue, 13 Mar 2018 13:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
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: 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 S3DMN6mFsPxM; Tue, 13 Mar 2018 13:19:34 -0700 (PDT)
Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 BC89E1201FA; Tue, 13 Mar 2018 13:19:34 -0700 (PDT)
Received: by mail-it0-x243.google.com 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; d=gmail.com; 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; d=1e100.net; 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 10.36.50.196 with SMTP id j187mr2402825ita.85.1520972373836; Tue, 13 Mar 2018 13:19:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.58.193 with HTTP; Tue, 13 Mar 2018 13:19:18 -0700 (PDT)
In-Reply-To: <CAF4+nEHzRcXOpjWLQJbwBLLz2XigV6N17LRBuG1r3v7=EyS7rQ@mail.gmail.com>
References: <152051669498.13986.10062778727515004234.idtracker@ietfa.amsl.com> <CAF4+nEHzRcXOpjWLQJbwBLLz2XigV6N17LRBuG1r3v7=EyS7rQ@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 13 Mar 2018 16:19:18 -0400
Message-ID: <CAF4+nEEdhF=tjSGmf33=6PMdaKRn-pnsS7pJLGhYsFiyiywxrQ@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/ybYeU_Ici1L4OmxyGZar_qUknAM>
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: 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.\

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Sat, Mar 10, 2018 at 9:22 PM, Donald Eastlake <d3e3e3@gmail.com>; wrote:
> 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