[secdir] secdir review of draft-ietf-trill-aa-multi-attach

[Sandra Murphy <[e-mail]>]

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.

This is a late review, thankfully with no large issues specific to the draft.

This draft provides a new TRILL sub-sub-TLV to convey MAC attachment
information through the TRILL cloud in a way that permits
active-active node attachment point movement in the cloud.

As a person not particularly familiar with TRILL, I found that I
struggled.  Not the authors fault, I was not familiar with the suite
of RFCs the draft says it presumes the reader is familiar with.  There
is a lot of background reading here, so I'd not be surprised to find
that I have missed something somewhere.  I’ve quoted the RFC’s
I’ve read to indicate where I derived my possibly faulty information.

General comments first, then security (mostly a discourse on routing
security and TRILL authentication)

General document comments:

I found that Figure 1 in RFC 7379 conveyed the many-many aspect of
attachments to the RBridges better than the figure in the draft.  I
recommend it.

I found that RFC7379's explanation of Address Flip-Flop gave a more
understandable explanation of what this draft calls "Mac
Flip-flopping", which I believe to be the same thing.  In particular,
it explained the hardware inability to keep multiple MAC-nickname
mappings, which is key to the problem.  A reference to that RFC would
be good, particularly as the purpose of that RFC is to describe that
issue (among others).

The text is not consistent in the names of the fields - spelling, hyphenation, etc.

----

   the "AA LAALP Group RBridges" TRILL APPsub-TLV defined in Section (page 7)
vs
   "LAALP Group RBridges" APPsub-TLV included in the TRILL GENINFO TLV (page 11)
   in FS-LSPs [RFC7180bis].

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type = AA-LAALP-GROUP-RBRIDGES| (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and
      tbd3(254)  AA-LAALP-GROUP-RBRIDGES  [This document] (page 14)

----
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type = AA-LAALP-GROUP-MAC     | (2 bytes)  (page 7)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
vs
   o  Type: AA LAALP Grouped MAC (TRILL APPsub-TLV type tbd1)  (page 7)
and
      tbd1(252)  AA-LAALP-GROUP-MAC       [This document] (page 14)

-----

   5.3.2. The MAC Reachability TLVs [RFC6165] are composed in a way that (page 7)
vs
   o  Length: The MAC-Reachability TLV [RFC6165] is contained in the (page 7)
and
   (many other places)



On page 7:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
      | MAC-Reachability TLV            (7 + 6*n bytes) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+

I presume the "n" here is the same as "n" in RFC6165 where the
MAC-Reachability TLV   is defined.  It would be good to mention it.

page 12:

   All enabled VLANs MUST be consistent on all ports connected to an
   LAALP. So the enabled VLANs need not be included in the AA-LAALP-
   GROUP-RBRIDGES TRILL APPsub-TLV. They can be locally obtained from
   the port attached to that LAALP.

Does this mean consistency across all RBridges in the LAALP's AAE?  Is
that consistency provided by the LAALP?  If not, it sounds like a
difficult configuration task.  Since it appears that this consistency
is important to the design of the active-active multi-attachment, I
would think that some mention of how to produce or maintain the
consistency would be a good idea, even if only a mention that it is
provided by XYZ.

RFC7357 speaks of the possibility of hundreds or thousands of ESADI
routers in an RBridge cloud (section 4), and of all ESADI routers
being "directly connected by a multi-access virtual link" (section
2.1) - does this consistency need to be maintained at that scale?

RFC6325 section 4.4.3 says that an RBridge maintains a list of enabled
VLANs per port, but not how that information is obtained. RFC6345
section 5.3 lists C-VLAN IDs as one of an RBridge's per-port
configuration parameters.  RFC6345 section 4.9.4 discusses the option
for an RBridge to implement a VLAN registration protocol (VRP) to
request that a VLAN be enabled on a port.  Could the VRP maintain the
consistency needed across all RBridges in an LAALP's AAE?  I have
found some statements that GVRP does not synchronize between switches,
but MVRP propagates information to other bridges.  However, the text
in 4.9.4 indicates that an RBridge requests that a VLAN be enabled on
its ports, and that it sends VRP frames to request Designated VLAN
traffic but "to not request traffic in any other VLAN".


IANA Considerations section:

The IANA considerations section of RFC7357 says of registration of new
APPsub-TLV Types:

                                                The RFC causing such an
      assignment will also include a discussion of security issues and
      of the rate of change of the information being advertised.

I do not see a discussion of the rate of change of the new TLVs
introduced by this draft.  The security considerations section of this
draft refers to RFC7357 for any discussion of the "extensions
transported by TRILL ESADI".

+++++++++++++

Security comments and a discourse:

I have no security concerns specific to this draft.

The security considerations section refers to RFC6325 (which defines
TRILL), RFC5310 (which defines authentication for IS-IS, which TRILL
uses), and RFC7357 (which defines the ESADI protocol, which is a sub
protocol of/in/for TRILL, and which this draft extends).

IS-IS authentication, and hence TRILL, hence ESADI, hence this draft,
authenticates the speaker (to some granularity), but does not provide
authorization information.  Any legitimate speaker of the protocol is
able to produce bogus information in its packets, speak for other
participants, etc.  This is recognized, though seldom stated
explicitly, in routing protocols in general.  The difficulty is not
with this draft but the underlying protocols it extends.

It is very difficult to protect a routing protocol from bad behavior
by legitimate participants.  I would not expect that protocol
designers would be required to provide such protection.  I do wonder
if any one is giving any thought to the damage that could be created
by a legitimate participant introducing bogus data.  (Any such
analysis could be mentioned as a caution to the operator.)

For example.  In TRILL, has anyone considered what would happen if a
RBridge sent TRILL Control or TRILL Data packets with another
RBridge's nickname?  I see several drafts that are concerned with
prevention of duplicate nicknames, which would hint that duplicates
would be bad for the protocol, but I have not worked out just what
damage would be produced.  (see the following drafts which mention
solutions for nickname collisions
draft-hu-trill-pseudonode-nickname-01
draft-perlman-trill-rbridge-multilevel
draft-zhang-trill-multilevel-single-nickname-01)

RFC5310 notes that the authentication is not to the level of an
individual IS-IS speaker:

   It should be noted that authentication method described in this
   document is not being used to authenticate the specific originator of
   a PDU, but is rather being used to confirm that the PDU has indeed
   been issued by an intermediate system that had access to either the
   area or domain password, depending upon the kind of PDU it is.

RFC6325's Security Considerations section discussion of bad protocol
data is focused on rogue end stations, nor rogue RBridges.

   The best defense against forged TRILL-Hello frames or other IS-IS
   messages is the use of IS-IS security [RFC5304] [RFC5310].  Rogue end
   stations would not normally have access to the required IS-IS keying
   material needed to forge authenticatible messages.

RFC7178 (which RFC7175 builds on, where RFC7175 is used by RFC7177,
which updates RFC6325) specifically notes the lack of protection of
the nickname:

   See [RFC6325] for general TRILL security considerations.  As stated
   therein, no protection is provided by TRILL against forging of the
   Ingress Nickname in a TRILL Data formatted channel message or the
   Outer.MacSA in a native RBridge Channel frame on an Ethernet link.

(I did not find this "stated therein" in RFC6325, unless you could
call absence of statement as a statement.)

For many routing protocols, the excuse/reason for not considering
rogue participants is that the protocol is used by a single operator,
so damage would be limited.  RFC7455 (TRILL Fault Management) says
this clearly:

   Generally, a single operator manages each TRILL campus; hence, there
   is no risk of security exposure.  However, in the event of multi-
   operator deployments, operators should be aware of possible exposure
   of device-specific information, and appropriate measures must be
   taken.

Recently, however, there has been work to extend TRILL to BGP
environments.  (See draft-hao-idr-trill-ls and
draft-ietf-l2vpn-trill-evpn-02.) The use case is frequently data
centers, which you might argue is still a single operator.  But a
feature built into BGP, intended for use in such restricted
circumstances, could be used in other inter-domain environments.  In
either scenario, TRILL carried inter-domain would present security
problems, if only in configuration of the authentication strings/keys.

Authentication keying material:

The chain of RFCs describing authentication keying makes it look like
the configuration of keying material for inter-domain transport of
TRILL PDUs might be complicated.  Or maybe operators are used to this
configuration by now.  Or maybe they just configure all the
authentication keys to be the same (likely, but I'm not recommending
that and it would not work well in inter-domain).

RFC5310 says that the Level 1 Sequence Number and Link State PDUs
(TRILL uses only Level 1) are authenticated using the "Area
Authentication string" and HELLO PDUs are authenticated using the
"Link Level Authentication string".  [Level 2 PDUs have a "domain
authentication string" - which means that multi-level TRILL, currently
under consideration in the TRILL wg, may have to stipulate what key
TRILL will use.]

RFC6325 says only that IS-IS authentication should be used, but not
which string to use.  Perhaps it was too obvious to mention that the
TRILL HELLO protocol will use the "Link Level Authentication string"
just as for IS-IS HELLO, and the TLVs defined in RFC7156 that are
carried in IS-IS LSPs will use the "Area Authentication string".

RFC6325 says to use IS-IS authentication for the IS-IS PDUs but says
nothing about the Data PDUs.  (So perhaps the absence of any stated
protection for TRILL Data packets is what RFC7178 meant by the "stated
therein" mentioned above.)

   Countermeasures are available such as to configure the TRILL IS-IS
   and ESADI protocols to use IS-IS security [RFC5304] [RFC5310] and
   ignore unauthenticated TRILL control and ESADI frames received.
   RBridges using IS-IS security will need configuration.

(I like the "need configuration" part - sorts of sums it up, doesn't it?)

RFC7357 (ESADI) says that ESADI packets are carried as TRILL Data packets:

   TRILL ESADI packet payloads are structured like IS-IS Extended
   Level 1 Circuit Scope (E-L1CS) LSP, CSNP, and PSNP PDUs [RFC7356],
   except as indicated below, but are always TRILL encapsulated on the
   wire as if they were TRILL Data packets.

which if I interpret RFC6325 about authentication correctly (see above
about Data PDUs) means that TRILL does not provide IS-IS
authentication for ESADI.  However, a ESADI PDU may include its own
Authentication TLV.

The ESADI authentication key can be derived from the TRILL key:

                                        The ESADI
   authentication keying material used is derived from the IS-IS LSP
   shared secret keying material as detailed below.
...

           HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key )

and "LSP" part seems consistent with the obvious suggestion above that
TRILL would be using the IS-IS "Area Authentication string", as that
is what is used with LSPs.

RFC7175 (TRILL BFD Support) says that the BFD key is derived from the TRILL key:

                                                                The BFD
   authentication keys between neighbor RBridges by default are derived
   from the IS-IS shared secret authentication keys for Hellos between
   those RBridges as detailed below.  However, such BFD authentication
   keys MAY be configured to some other value.

     HMAC-SHA256 ( ( "TRILL BFD Control" | originPortID | originSysID ),
                   IS-IS-shared-key )

which if I'm right about the TRILL HELLO protocol would mean that the
IS-IS-shared-key would be the IS-IS "Link Level Authentication string".

--Sandy