Re: [secdir] Secdir review of draft-ietf-trill-multilevel-unique-nickname-05

Roman Danyliw <rdd@cert.org> Tue, 06 March 2018 15:25 UTC

Return-Path: <rdd@cert.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E673124D68; Tue, 6 Mar 2018 07:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhaE-xl5IkVY; Tue, 6 Mar 2018 07:25:24 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AA9120454; Tue, 6 Mar 2018 07:25:23 -0800 (PST)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w26FPJ0Z005132; Tue, 6 Mar 2018 10:25:20 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w26FPJ0Z005132
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1520349920; bh=1obRh+W5po8OVN8Mb/x7W6aOCdkp+3S+4kvqaOY9ADE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=iVafzgIaT+WR+JwJ7U4jiHGY8F9Auj8vqBLnzmkKHOyZW5ZQN99kY6LWp1AWn/a0Y Jb/vAX971z3BVEQ1iY3wMRQ6YNMQfLS+xFD/dtzlcA8L4Gvu70xSc5WihaFqU5K83v ouwneOW05Xnvsbv0i+7rG8fipel2eq8pZ9gFZga8=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w26FPIS4032527; Tue, 6 Mar 2018 10:25:18 -0500
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Tue, 6 Mar 2018 10:25:18 -0500
From: Roman Danyliw <rdd@cert.org>
To: Donald Eastlake <d3e3e3@gmail.com>
CC: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-trill-multilevel-unique-nickname.all@ietf.org" <draft-ietf-trill-multilevel-unique-nickname.all@ietf.org>
Thread-Topic: Secdir review of draft-ietf-trill-multilevel-unique-nickname-05
Thread-Index: AdOyXwuroB0yJVJhRMeJvvm4FEzIkQBtZpAAAFHgKEA=
Date: Tue, 6 Mar 2018 15:25:17 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC0137F70BBB@marathon>
References: <359EC4B99E040048A7131E0F4E113AFC0137F6E1D1@marathon> <CAF4+nEHUNkiXOJrKpeb-esX75mH6xC6_C1scR4Mf8dOugRHohA@mail.gmail.com>
In-Reply-To: <CAF4+nEHUNkiXOJrKpeb-esX75mH6xC6_C1scR4Mf8dOugRHohA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/CIxA0fdOdZhlEvmef5foSU8oC_0>
Subject: Re: [secdir] Secdir review of draft-ietf-trill-multilevel-unique-nickname-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2018 15:25:31 -0000

Hi Donald,

> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
> Sent: Sunday, March 04, 2018 1:58 PM
> To: Roman Danyliw <rdd@cert.org>;
> Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-trill-multilevel-unique-
> nickname.all@ietf.org
> Subject: Re: Secdir review of draft-ietf-trill-multilevel-unique-nickname-05
> 
> Hi Roman,
> 
> Thanks for doing a review. See responses below.
> 
> On Fri, Mar 2, 2018 at 9:00 PM, Roman Danyliw <rdd@cert.org>; wrote:
> > 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?
> 
> Typically "link state" information stays within a Level 1 area or within the
> Level 2 routers. Occasionally there is information that it is desirable to  flood
> throughout the domain at both Level 1 and Level 2. IS-IS "link state"
> information is in the form of TLVs. Typically this domain wide flooding is
> accomplished by using two flags in the value portion of the TLV. One flag
> indicates the the TLV is to be flooded domain wide while the other is initially
> zero and is set when the TLV is flooded from Level 2 to Level 1 -- this second
> flag is to stop a TLV from being flooded from Level 2 to Level 1 and then back
> to Level 2 again resulting in TLV looping. See, for example, the IS-IS Router
> Capabilities TLV D and S flags as specified in Section 2 of RFC 7981.  This is all
> standard IS-IS machinery that someone familiar with IS-IS would know --
> there is nothing TRILL specific about it.

Understood.  I was struggled with the wording "... unless there are specific ..." as this didn't imply to me a fixed set of previously understood constraints.  I would have chosen "... beyond the expected provisions ... between levels necessary for protocol function."

[snip]
 
> > (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
> 
> This is basic to multilevel IS-IS and anyone familiar with that would
> understand. We could add a reference to IS-IS.

Agreed.  It makes sense to add the reference.

> > ** 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.
> 
> I suggest the following replacement text:
> 
>    Since TRILL multilevel uses the existing IS-IS multilevel facilities [IS-IS],
> flooding of control traffic for link state information is automatically confined
> to a Level 1 area or to Level 2 except (for limited types of information that
> can be specifically flagged for wider flooding). This addresses the TRILL
> scalability issues as specified in Section 2 of [RFC8243] and also, except of the
> wider flooding case, this confines the scope of the effects of malicious
> events that could be communicated through the link state.

The suggested wording works for me.

> > (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.
> 
> Since nicknames must be unique across the multi-level domain, and
> nicknames in TRILL are auto-allocated, clearly RBridges inside an area need to
> know what nicknames are in use, which is the effect and purpose of leaking
> nickname claim information across levels. I suggest the following wording:
> 
>     However, due to the nature that unique nickname areas share a common
> nickname space, border RBridges still have to leak nickname information
> between levels. Such leaking means that nickname related events in one
> area can affect other areas. For this purpose, border RBridges need to
> fabricate the nickname announcements as specified in Section 4.3.

The suggested wording works for me.

[snip]
> 
> > (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."
> 
> I would agree that RFC 5310 security is superior to RFC 5304 security.
> Perhaps references to 5304 can be removed.

I'd recommend the more agile RFC5310 too.

> > ** 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."
> 
> Suggest replacing "to secure the network" with "to authenticate those PDUs
> and discard them if they are forged."

The suggested wording works for me.

[snip]

Thanks,
Roman

> Thanks,
> Donald