Last Call Review of draft-ietf-teas-interconnected-te-info-exchange-04
review-ietf-teas-interconnected-te-info-exchange-04-secdir-lc-orman-2016-05-12-00

Problem Statement and Architecture for Information Exchange
Between Interconnected Traffic Engineered Networks
draft-ietf-teas-interconnected-te-info-exchange-05.txt

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

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.

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

Hilarie