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

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 9 May 2016 00:47:27 -0600

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 May 2016 15:43:08 +0100

Hilarie, thanks!

> lesser abstraction would be "private."

While I understand the idea you are suggesting, I wonder how well it works in a
commercial world. You are suggesting that Company A might share information with
Company B on the condition that that information is not passed on to Company C.
Now, that could certainly be agreed between  A and B, and the data could be
flagged accordingly, but A will have no way of knowing whether the information
has been shared with C. Practically, the only way A can control what is shared
with C is to take direct responsibility for that interaction.

But this goes further. If we assume that the default position is that B must not
share any information from A into C then we have exactly the same problem.

Thus (I suggest) the only safe way for A to behave is to assume that any and all
of the information it shares with any party may be subsequently shared with any
other party.

But part of the value of abstraction is that it helps to hide the details of
reality. That is, the information shared by A can have only sparse relationship
to the network it actually operates. No-one can tell whether the existence of an
abstract link from x to y with bandwidth Z means that there is exactly that
bandwidth available on a single physical link, or many multiples of that
bandwidth available on a collection of LSPs that could be set up some time in
the future. Conversely, the absence of an abstract link from x to y may mean
nothing more than "I don't fancy letting you do that today".

> Should addresses have labels that define the domain of interpretation?

They do! The context is provided by IGP instance, AS, area, or level.

This is business as usual. Address spaces are re-used. Operators (and your home)
use private address spaces that are used by devices in other networks.

And, if you tried to manage a single network consisting of public addresses, the
addresses of the operators' nodes and links, and the addresses of a number of
homes and enterprises, "human operators would become confused."

> it is apparently "stability".  Some wordsmithing for clarification

OK. Thanks for identifying that porridge. I'll rework the text.

>    ... networks and one or more client network (should be networks)

Ah. Interesting catch.
Actually should be

   between one or more server
   network and one or more client network

:-)

> should be "that the less ..."

Ack

>  "Thus, while the data shared in reduced," should be "is reduced"

Ack

Once again, thanks.

Adrian