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

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Sat, Mar 10, 2018 at 9:22 PM, Donald Eastlake <[e-mail]> wrote:
> 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]