Eric Rescorla has entered the following ballot position for draft-ietf-trill-smart-endnodes-10: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ ---------------------------------------------------------------------- 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. 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. ---------------------------------------------------------------------- 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. 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. 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"? 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? _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill