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

From: Eric Rescorla <[email-masked]>
Date: Thu, 08 Mar 2018 05:44:54 -0800

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?

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 10 Mar 2018 21:22:28 -0500

Hi Eric,

On Thu, Mar 8, 2018 at 8:44 AM, Eric Rescorla <[email-masked]> wrote:
> ...

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.

> 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.

Yeah, probably the network connection to Endnode1 should be labelled D.

> Ooh, bad break here at this period.

OK.

> does "given from" mean something different than "sent by"?

No. "sent by" would be more usual wording.

> 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-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 13 Mar 2018 16:19:18 -0400

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Mar 2018 16:19:29 +0000

This is fine. I am clearing.