This is fine. I am clearing. On Tue, Mar 13, 2018 at 8:19 PM, Donald Eastlake <[email protected]> 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 > [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
