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

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 09 May 2016 14:43 UTC

Return-Path: <adrian@olddog.co.uk>
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 B129B12D1E8; Mon, 9 May 2016 07:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 Iqy9vxgZ_CzI; Mon, 9 May 2016 07:43:16 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E849912D1E7; Mon, 9 May 2016 07:43:15 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u49EhDCJ023313; Mon, 9 May 2016 15:43:13 +0100
Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u49EhCpA023291 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 9 May 2016 15:43:12 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Hilarie Orman'" <hilarie@purplestreak.com>, <iesg@ietf.org>, <secdir@ietf.org>
References: <201605090647.u496lR3i032182@rumpleteazer.rhmr.com>
In-Reply-To: <201605090647.u496lR3i032182@rumpleteazer.rhmr.com>
Date: Mon, 9 May 2016 15:43:08 +0100
Message-ID: <019701d1aa01$1b5c0640$521412c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQM0Aofw9Q+SCYGjpwhgTv6Z5CXs/Zzr9ckQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22312.000
X-TM-AS-Result: No--16.300-10.0-31-10
X-imss-scan-details: No--16.300-10.0-31-10
X-TMASE-MatchedRID: dL10VBB8yoenykMun0J1wvHkpkyUphL9aSjMyOl1TBnfUZT83lbkEM1S TvaVrDRw9k7ejKn/NFBDHMqEWJcg8Oyt+a9Mtf+e7DzBuedLDxtDGFvBeB2nXJBLkWHr+GTPxlv mHoRzlcrYOJK6UUeDpq8XLD5qB/Bi/kfqE9cRF+aRxwsFDaw1reiY+s2L3xQELO3j+XDwlkPy0h CIU6EV9u8CS9vvFOCxT8D3oVABNiFAFYb6xVW8k6lXXrpOy3q0BWSwVcXsRGWTMTaQzhvoeindB wYVY7dc5Iv7L+NLrJ6iBTvAIT2eAW1yv+64My/eJhFEQZiq2ZQznot5HSrON+qLmFCMpwfU4CUa wQn11ToNgVgOes3NEao0q1fOt8o7qE3fTaEfMDGr17gY+g3e8ZWr6iSXWtgPN15VVRl9DpEbYyS B54LRMbT1+1Gumyg9SRR+Y/NZqWIXXEXrP7ee7QxXJkG8Mv0f1kqyrcMalqXqpu20wiek6B/pZ3 bffunhZfaj0Ej/gOLD/5kXiyVFlslOV51nCIAz7BI2Kjvg8mh4nU6KtjDMA6QMmuFqyUK6o8WMk QWv6iV95l0nVeyiuEIhOWyY9/MAC24oEZ6SpSkj80Za3RRg8GpDr4Ib28DoIKwYGzWnDwTtFee2 MU8oNI+28w5m5IDud0xX2Ii4JpA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/z2a5-jVV-04AAvZUukOingiBAyE>
Cc: draft-ietf-teas-interconnected-te-info-exchange.all@ietf.org
Subject: Re: [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: adrian@olddog.co.uk
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 14:43:19 -0000

Hilarie, thanks!

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

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

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

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

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

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

> Nits
> ----
> 1.1.9.  Abstraction Layer Network
>    ... 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

:-)

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

Ack

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

Ack

Once again, thanks.

Adrian