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

From: Sandra Murphy <[email-masked]>
Date: Thu, 27 Aug 2015 06:46:52 -0400

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

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 28 Aug 2015 15:11:40 -0400

Hi Sandy,

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

Thanks for this review. At this point it is my understanding that the
IESG has approved the draft pending correction of items agreed to in
previous email so I am not entirely sure how new comments should be
handled (I am the document Shepherd) other than that they should
certainly be fixed if sufficiently serious...

(I have change the cc's above so this goes to the ".all" version of
the draft name, so it will get to the routing ADs and WG Chairs so I
also dropped the explicit WG Chairss cc.)

> attachments to the RBridges better than the figure in the draft.  I

At this stage, I would like to minimize changes. Would it be adequate
to include a reference shortly after Figure 3.1 in the draft referring
to Figure 1 in [RFC7379]?

> be good, particularly as the purpose of that RFC is to describe that

[RFC7379] is already in the references in this draft. Perhaps as the
end of the 2nd paragraph of Section 1 of this draft, we could insert
"See [RFC7379] for a discussion of the MAC flip-flop issue."

>    "LAALP Group RBridges" APPsub-TLV included in the TRILL GENINFO TLV (page 11)

There are two forms of the name that should appear: "AA LAALP Group
RBridges" and "AA-LAALP-GROUP-RBRIDGES". The first is the "English"
version and the second is the formal token to appear in the IANA
tables and packet diagrams. If the draft is going to be revised there
should probably be a global replace of "LAALP Grouped" by "LAALP
Group".

>    o  Length: The MAC-Reachability TLV [RFC6165] is contained in the (page 7)

Since [RFC6165] uses the hyphenated form, it would be better to use that here.

> On page 7:

Probably would be good in the "MAC-Reachability sub-TLV:" item below
to replace "... MAC-Reachability TLV as a sub-TLV." with "...
MAC-Reachability TLV as a sub-TLV (see [RFC6165], n is the number of
MAC addresses present)."

> consistency would be a good idea, even if only a mention that it is

Yes, "ports connected to an LAALP" are ports in the LAALP's AAE.

Currently it is typical for LAALPs to be a proprietary MC-LAG
implementations so all the RBridge in the edge group are from the same
manufacturer. (This may change with implementation of 802.1 DRNI.) It
would, in my opinion, be a bad idea to try to constrain the method of
configuration of the edge group RBridges.

> 2.1) - does this consistency need to be maintained at that scale?

No, we are talking about the 2 or 3 or 4 or, maybe in rare cases, 8 or
so ports at a local AAE group that are all connected to the CE.

> configuration parameters.

With regard to how an RBridge port is configured for VLAN admission,
they are the same an 802.1Q bridge ports. There are MIB variable, but
how an RBridge controls one of its own ports, just as how an IP router
or a bridge controls and communicates with one its ports in an
internal implementation issue.

>                                            RFC6345 section 4.9.4 discusses the option

No, I don't think VLAN registration protocols have much of anything to
do with making sure that all the local ports to the CE for an AAE
group have the same VLANs enabled on them.

> transported by TRILL ESADI".

That is a good point. I would suggest adding something like the
following: To the end of Section 4.2: "This APPsub-TLV is expected to
rarely change as it only needs to be updated when RBridge capabilities
change, such as due to an upgrade or reconfiguration." To the end of
Section 4.1.3: "This APPsub-TLV changes whenever the MAC reachability
situation for the LAALP changes." And to the end of Section 4.1.2.:
"This APPsub-TLV is expected to rarely change as it only does so in
cases of the the creation or elimination of an AAE group or of link
failure or restoration to the CE in such a group."

"The APPsub-TLVs specified in this section

Thanks.

>    area or domain password, depending upon the kind of PDU it is.

I believe that, in addition to area or domain wide keys, there can
also be link local keys that can be used for authentication in link
local IS-IS PDUs such as Hellos, PSNPs, and CSNPs.

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

TRILL tries to operate with minimum/zero configuration so where
configuration is required, for example to use non-default VLANs or
security, it is sometimes mentioned.

> authentication for ESADI.  However, a ESADI PDU may include its own

That is correct.

Thanks,
Donald (document Shepherd)
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]