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 [email protected] On Sat, Mar 10, 2018 at 9:22 PM, Donald Eastlake <[email protected]> wrote: > Hi Eric, > > On Thu, Mar 8, 2018 at 8:44 AM, Eric Rescorla <[email protected]> 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 > [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
