Hi Eric, On Thu, Mar 8, 2018 at 8:44 AM, Eric Rescorla <e...@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 d3e...@gmail.com _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
