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

Eric Rescorla <ekr@rtfm.com> Mon, 19 March 2018 16:20 UTC

Return-Path: <ekr@rtfm.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 0B72212D7F1 for <trill@ietfa.amsl.com>; Mon, 19 Mar 2018 09:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 wGPkFxrlGH2S for <trill@ietfa.amsl.com>; Mon, 19 Mar 2018 09:20:12 -0700 (PDT)
Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 0ACC612D7E5 for <trill@ietf.org>; Mon, 19 Mar 2018 09:20:12 -0700 (PDT)
Received: by mail-qk0-x244.google.com with SMTP id j73so11466961qke.6 for <trill@ietf.org>; Mon, 19 Mar 2018 09:20:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EicAkduBpgcoP5ToGMEUz9+gTNg0dmtwRQ4yt7a6M/Q=; b=wyeAJAR1UKv6QYCcFd5d/Bdowm2NrISwyPpSWjXSZO1mKi0BN4hUihZsfBJL9/mFCJ XgzYbxfP6MkIunxFk4IP8+3Sxy1DJcvF7On1JyauQ+ecvGu/sen5f6hQa8ovsxbs1UQa hZEhnmXFL0kBC2CtqRi9Kq5p5AW2CzQ+MFKI8ZdqZbMOM3D7n1XfdUpqnds8/vvIo1lD VHmWIqb9Jm93STewPYZpjNCCRLtRZ6QcLPTrRgpPwCNUxf2sLRi4Q6dwY8l7g/VDzF0g SZoo+umgrbgtvh57i+G0Xp1HrIyxzcgVVyVPjvS7DjJk9qVtqYgU83asdLg20biF7HNB D1LQ==
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=EicAkduBpgcoP5ToGMEUz9+gTNg0dmtwRQ4yt7a6M/Q=; b=tYovA9sBPiBLbJNtTnsT0PwkhGjMxtY8tAwvaRQhf3Q+7hMEJKiiOKlQN1ItCPQpoT E4UHZFakvv5eCp8hJcnU+rYN6WeqT49QOK4EUmD0O0jdPRoePo6B05iVSUDhru33vBIB 6IN/e9Mp7p4x5HZWaIT2ujoQMURQs2pMaJsAE5/pYbTtfrtti721/CpCVm/mHBNwyJvR yFOwR/iTC2PBvSv6YSwp98tV2f+ioJgt/irBGBPPha2IREt8Igl6zu4OIsHTlnPIm/zr f/8zO6oJpHSoGkc3uUVLywlnpVub3y3/6aJePanmaCPJmPOqSvc9xMVzRIim4AhJ2fLj ZG3Q==
X-Gm-Message-State: AElRT7FLiPGNP5xztMvV/iwom7lXOydvtY6NWv+CDhYvKY5g4Gt/s3Yw 1MHvAcF/U/14CE3gufIBDQXzY/R0JPJ0kbS9zy22Iw==
X-Google-Smtp-Source: AG47ELsmWQWAyZNwRVN1tMGS8Sd+SNw3lrcEkzD+Kr9Go2SztYldC7z49Tt6dXttPaBXJinjsyVDuExgmhmPfI3tUjU=
X-Received: by 10.55.198.153 with SMTP id s25mr17518324qkl.221.1521476409732; Mon, 19 Mar 2018 09:20:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.37.234 with HTTP; Mon, 19 Mar 2018 09:19:29 -0700 (PDT)
In-Reply-To: <CAF4+nEEdhF=tjSGmf33=6PMdaKRn-pnsS7pJLGhYsFiyiywxrQ@mail.gmail.com>
References: <152051669498.13986.10062778727515004234.idtracker@ietfa.amsl.com> <CAF4+nEHzRcXOpjWLQJbwBLLz2XigV6N17LRBuG1r3v7=EyS7rQ@mail.gmail.com> <CAF4+nEEdhF=tjSGmf33=6PMdaKRn-pnsS7pJLGhYsFiyiywxrQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Mar 2018 16:19:29 +0000
Message-ID: <CABcZeBOE7kF_4ri03uNS3WUa=zEzMvfrCvN4ycNhtWbyGxhsew@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.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: multipart/alternative; boundary="001a11430b28efc81d0567c65438"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/c_7PIFKNydI7GKq0D7_2dz2EyY4>
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: Mon, 19 Mar 2018 16:20:18 -0000

This is fine. I am clearing.

On Tue, Mar 13, 2018 at 8:19 PM, Donald Eastlake <d3e3e3@gmail.com>; wrote:

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