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

[Donald Eastlake <[e-mail]>]

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]