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

[Donald Eastlake <[e-mail]>]

Hi Sandy,

On Thu, Aug 27, 2015 at 6:46 AM, Sandra Murphy <[e-mail]> wrote:
>
> 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.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

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.

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

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
> +++++++++++++
>
> Security comments and a discourse:
>
> I have no security concerns specific to this draft.

Thanks.

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

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.

> 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?)

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.

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

That is correct.

Thanks,
Donald (document Shepherd)
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> 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