Telechat Review of draft-ietf-trill-multilevel-unique-nickname-05
review-ietf-trill-multilevel-unique-nickname-05-secdir-telechat-danyliw-2018-03-08-00

Reviewer: Roman Danyliw
Review result: Ready with nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is Ready with nits.

My feedback is as follows:

(1) Section 4.1, Multilevel TRILL Basics, Page 8

Thus Level 1 link state
information stays within a Level 1 area and Level 2 link state
information stays in Level 2 unless there are specific provisions for
leaking (copying) information between levels.

** What are these provisions where such leakage of information should occur
beyond expected routing behavior?

(2) Section 4.2, Nickname Allocation, Page 8-9.

Level 2 RBridges contend for nicknames in the range from 0xF000
through 0xFBFF the same way as specified in [RFC6325], using Level 2
LSPs. The highest priority border router for a Level 1 area should
contend with others in Level 2 for smallish blocks of nicknames for
the range from 0x0001 to 0xEFFF. Blocks of 64 aligned on multiple of
64 boundaries are RECOMMENDED in this document.

** This text provides guidance to allocate nicknames from the range 0x0001 -
0xFBFF (0x0001 - 0xEFFF and 0xF000 - 0xFBFF); and Section 3.7 of RFC6325 says
that 0xFFC0 - 0xFFFF and 0x0 are reserved.  Collectively, these two documents
leave the range of 0xFC00 - 0xFFBF unspecified.  If that's intentional,
describe how these values should be handled. Or, perhaps there a typo and L2
Rbridges should allocate from 0xF000 - 0xFFBF (i.e., s/0xFBFF/0xFFBF/)? **
(Editorial) The language "smallish blocks of nicknames" seems imprecise.

(3) Section 6, Security Considerations, Page 12.

With TRILL multilevel, flooding of control traffic for link state
information of Level 1 and Level 2 is separated. This addresses the
TRILL scalability issues as specified in Section 2 of [RFC8243] and
also confines the effective scope of possible malicious events.

** Per the sentence "With TRILL ... is separated", I recommend clarifying the
language on what and in what way there is separation ** Per the follow-up
sentence, "... also confines the effective scope of possible malicious events",
I recommend discussing in more detail how the scope of malicious events is
reduced with this approach.

(4) Section 6, Security Considerations, Page 12.

However, due to the nature that unique nickname areas share a unique
nickname space, border RBridges still have to leak nickname
information between levels. For this purpose, border RBridges need to
fabricate the nickname announcements as specified in Section 4.3.

** As it is raised as an issue with a mitigation, I recommend articulating the
implication of leaking nicknames across levels.

(5) Section 6, Security Considerations, Page 12.

Malicious devices may also fake the NickBlockFlags APPsub-TLV to
announce a range of nicknames. By doing this, the attacker can
attract TRILL data packets that are originally to reach a bunch of
other RBridges.

** Recommend articulating the implications of a rogue device changing the path
-- it might deny service, expose traffic to inspection, etc. ** (Editorial)
Recommend alternate language for the colloquial "... bunch of other RBridges"

(6) Section 6, Security Considerations, Page 12.

For this reason, RBridges SHOULD be configured to
include the IS-IS Authentication TLV (10) in the IS-IS PDUs that
contains the NickBlockFlags APPsub-TLV, so that IS-IS security
([RFC5304] [RFC5310]) can be used to secure the network.

** Should a preference be expressed for RFC5310 over RFC5304?  To quote
RFC5310, "[while at the time of this writing there are no openly published
attacks on the HMAC-MD5 mechanism, some reports ([Dobb96a], [Dobb96b]) create
concern about the ultimate strength of the MD5 cryptographic hash function."

** Recommend being more specific with the language "to secure the network". 
Perhaps "For this reason, RBridges SHOULD authenticate their peer by using the
IS-IS Authentication TLV (10) in the IS-IS PDUs that contains the
NickBlockFlags APPsub-TLV."

(7) Section 6, Security Considerations, Page 12.

If border RBridges do not prune multi-destination distribution tree
traffic in Data Labels that are configured to be area local, then
traffic that should have been contained within an area might be
wrongly delivered to end stations in that Data Label in other areas.
This would generally violate security constraints.

** Recommend being more specific on the security constraints being violated.

(8) There appear to be a few instances of key protocol behavior not using
RFC2119 language.  I'd suggest:

Section 3.2.2, Global Distribution Tree, Page 6
(old) Also, this border RBridge needs to advertise the set of local
distribution trees by providing another set of nicknames (new) Also, this
border RBridge MUST advertise the set of local distribution trees by providing
another set of nicknames

Section 3.2.2, Global Distribution Tree, Page 6
(old) If a border RBridge has been assigned both as a global tree root and a
local tree root, it has to acquire both a global tree root nickname(s) and
local tree root nickname(s) (new) If a border RBridge has been assigned both as
a global tree root and a local tree root, it MUST acquire both a global tree
root nickname(s) and local tree root nickname(s)

Section 4.3, Nickname Announcements, Page 9
(old) Besides its own nickname(s), a border RBridge needs to announce, in its
area, the ownership of all external nicknames that are reachable from this
border RBridge. (new) Besides its own nickname(s), a border RBridge MUST
announce, in its area, the ownership of all external nicknames that are
reachable from this border RBridge.

Section 4.3, Nickname Announcements, Page 9
(old) Also, a border RBridge needs to announce, in Level 2, the ownership of
all nicknames within its area. From listening to these Level 2 announcements,
border RBridges can figure out the nicknames used by other areas. (new) Also, a
border RBridge MUST announce, in Level 2, the ownership of all nicknames within
its area. From listening to these Level 2 announcements, border RBridges can
figure out the nicknames used by other areas.

Section 4.3, Nickname Announcements, Page 9
(old) To address this issue, border RBridges should make use of the
NickBlockFlags APPsub-TLV to advertise into the Level 1 area the inclusive
range of nicknames that are available or not for self allocation by the Level 1
RBridges in that area. (new) To address this issue, border RBridges SHOULD use
the NickBlockFlags APPsub-TLV to advertise into the Level 1 area the inclusive
range of nicknames that are available or not for self allocation by the Level 1
RBridges in that area.

Section 4.4, Capability Indication, Page 11
(old) If there are RBridges that do not understand the NickBlockFlags
APPsub-TLV, border RBridges of the area will also use the traditional Nickname
Sub-TLV [RFC7176] to announce into the area those nicknames covered by the
nickname blocks of the NickBlockFlags APPsub-TLV whose OK is 0. (new) If there
are RBridges that do not understand the NickBlockFlags APPsub-TLV, border
RBridges of the area MUST also use the traditional Nickname Sub-TLV [RFC7176]
to announce into the area those nicknames covered by the nickname blocks of the
NickBlockFlags APPsub-TLV whose OK is 0.

Section 5, Mix with Aggregated nickname Areas, Page 11
(old) Usage of nickname space must be planed so that nicknames used in any one
unique nickname area and Level 2 are never used in any other areas which
includes unique nickname areas as well as aggregated nickname areas. (new)
Usage of nickname space MUST be planed so that nicknames used in any one unique
nickname area and Level 2 are never used in any other areas which includes
unique nickname areas as well as aggregated nickname areas.

Section 5, Mix with Aggregated nickname Areas, Page 11
(old) Border RBridges of an aggregated area need to announce nicknames heard
from Level 2 into their area like just like an unique nickname border RBridge.
(new) Border RBridges of an aggregated area MUST announce nicknames heard from
Level 2 into their area like just like an unique nickname border RBridge.

Regards,
Roman