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

[Eric Rescorla <[e-mail]>]

This is fine. I am clearing.

On Tue, Mar 13, 2018 at 8:19 PM, Donald Eastlake <[e-mail]> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
>
> On Sat, Mar 10, 2018 at 9:22 PM, Donald Eastlake <[e-mail]> wrote:
> > Hi Eric,
> >
> > On Thu, Mar 8, 2018 at 8:44 AM, Eric Rescorla <[e-mail]> 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   [phone] (cell)
> >  155 Beaver Street, Milford, MA 01757 USA
> >  [e-mail]
>