[secdir] Security review of draft-ietf-teas-interconnected-te-info-exchange-05.txt

"Hilarie Orman" <hilarie@purplestreak.com> Mon, 09 May 2016 06:49 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0C55112B05F; Sun, 8 May 2016 23:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_12LTRDOM=0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mUaJiiZD7EZW; Sun, 8 May 2016 23:49:07 -0700 (PDT)
Received: from out03.mta.xmission.com (out03.mta.xmission.com []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3CF12B024; Sun, 8 May 2016 23:49:07 -0700 (PDT)
Received: from in02.mta.xmission.com ([]) by out03.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1azf06-0000vf-3S; Mon, 09 May 2016 00:49:06 -0600
Received: from [] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1azf04-0005hf-PL; Mon, 09 May 2016 00:49:05 -0600
Received: from rumpleteazer.rhmr.com (localhost []) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u496lRM8032183; Mon, 9 May 2016 00:47:27 -0600
Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u496lR3i032182; Mon, 9 May 2016 00:47:27 -0600
Date: Mon, 09 May 2016 00:47:27 -0600
Message-Id: <201605090647.u496lR3i032182@rumpleteazer.rhmr.com>
From: Hilarie Orman <hilarie@purplestreak.com>
To: iesg@ietf.org, secdir@ietf.org
X-XM-AID: U2FsdGVkX19qaJhu+Q53lhkDoYxuEQWv
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ****;iesg@ietf.org, secdir@ietf.org
X-Spam-Timing: total 897 ms - load_scoreonly_sql: 0.08 (0.0%), signal_user_changed: 5 (0.6%), b_tie_ro: 3.7 (0.4%), parse: 1.18 (0.1%), extract_message_metadata: 6 (0.7%), get_uri_detail_list: 2.9 (0.3%), tests_pri_-1000: 3.7 (0.4%), tests_pri_-950: 1.69 (0.2%), tests_pri_-900: 0.96 (0.1%), tests_pri_-400: 28 (3.1%), check_bayes: 26 (2.9%), b_tokenize: 6 (0.7%), b_tok_get_all: 9 (1.0%), b_comp_prob: 3.5 (0.4%), b_tok_touch_all: 4.0 (0.4%), b_finish: 0.96 (0.1%), tests_pri_0: 842 (93.9%), check_dkim_signature: 0.45 (0.1%), check_dkim_adsp: 442 (49.2%), tests_pri_500: 5 (0.6%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Frir5yBhmmzMPpxrSaddKMU4abM>
Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org
Subject: [secdir] Security review of draft-ietf-teas-interconnected-te-info-exchange-05.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
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: Mon, 09 May 2016 06:49:09 -0000

Problem Statement and Architecture for Information Exchange
Between Interconnected Traffic Engineered Networks

Do not be alarmed.  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

The document includes the problem statement:
    A mechanism is required that allows TE-path computation in one
    domain to make informed choices about the TE-capabilities and exit
    points from the domain when signaling an end-to-end TE path that
    will extend across multiple domains. [TE is "traffic engineering".]

The document describes, in general terms, the need for exchanging
information about reachability between domains without revealing
the totality of routing information.  To this end, the document
anticipates the use of abstracted reachability information.  The
information suggests that a path might exist, but it is not a
guarantee of reachability.

The numerous examples definitely motivate the need for exchange of
"meta routing information" (my term), but my concern is about the
privacy of the information.  In fact, one reason for using abstracted
information may be to obscure the details because they are sensitive:

In section 3.2 "Confidentiality", 

   ... an operator of a domain may desire to keep confidential the
   details about its internal network topology and loading.  This
   information could be construed as commercially sensitive.

also 4.1.1

   While abstraction uses available TE information, it is subject to
   policy and management choices.  Thus, not all potential
   connectivity will be advertised to each client.  The filters may
   depend on commercial relationships, the risk of disclosing
   confidential information, and concerns about what use is made of
   the connectivity that is offered.

>From a security viewpoint, I wonder if the architecture should have
sensitivity labels for abstracted reachability information.  Although
one domain may be willing to share some partly redacted reachability
information with another domain with which it has a limited trust
relationship, the first domain might want the second domain to
refrain from disclosing that information to other domains.  Perhaps
the first domain might offer two records with different abstraction
levels, and the most abstracted one would be "shareable" while the
lesser abstraction would be "private."

I found the notion of situational address interpretation
disconcerting.  In "4.5.  Addressing Considerations", we learn that
"one address may mean one thing in the client network, yet the same
address may have a different meaning in the abstraction layer network
or the server network" and "human operators may well become confused."
Should addresses have labels that define the domain of interpretation?

The notion of some kind of anticipatory information being generated
and dispersed to neighboring networks was confusing.  Section 4.3
"Considerations for Dynamic Abstraction" discusses "fluidity".  The
second sentence is an impenetrable run-on word sequence.  However, it
is followed by something that is asserted to be more significant ---
it is apparently "stability".  Some wordsmithing for clarification
would be helpful.

1.1.9.  Abstraction Layer Network
   ... networks and one or more client network (should be networks)

3.2, last sentence
"understanding that less information that is made available the more"
should be "that the less ..."

3.5, last sentence
 "Thus, while the data shared in reduced," should be "is reduced"