Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11

Vincent Roca <vincent.roca@inria.fr> Wed, 06 January 2016 08:27 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15231A89A0; Wed, 6 Jan 2016 00:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 oeqXJ_44L3Ln; Wed, 6 Jan 2016 00:27:40 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195781A8997; Wed, 6 Jan 2016 00:27:39 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.20,528,1444687200"; d="asc'?scan'208";a="195815698"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2016 09:27:38 +0100
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CB7C5BBA-397B-4033-B4B8-357BB548950F"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <DB3F24EE-A6AB-44EF-8632-B5B24933CEBC@alcatel-lucent.com>
Date: Wed, 6 Jan 2016 09:27:37 +0100
Message-Id: <C7B3A95D-F5C9-4BD9-98FF-E653B292C63E@inria.fr>
References: <AF9FDB2A-3DA1-45C0-A624-F177A72F1DAC@inria.fr> <DB3F24EE-A6AB-44EF-8632-B5B24933CEBC@alcatel-lucent.com>
To: "Murray, Rob (Rob)" <rob.murray@alcatel-lucent.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/zLnkKOnE-q1xIeoqTQhhzKo2Ono>
Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" <draft-ietf-cdni-control-triggers@tools.ietf.org>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 06 Jan 2016 08:27:43 -0000

Hello Rob,

> Hi Vincent - many thanks for the review, responses inline below…

You’re welcome.


>> There are several topics I’d like to discuss:
>> 
>> 1- Concerning the use of TLS to carry CI/T traffic, I see it is mandatory
>> to implement, but still optional to use (1st sentence of Section 8.1). Is
>> it still reasonable in current Internet? At a minimum I would expect a
>> « MUST support » / « SHOULD use ».
> 
> Section 8.1 goes on to say ...
> 
>   [ ... description of benefits of HTTPS ... ]
> 
>   In an environment where any such protection is required, mutually
>   authenticated encrypted transport MUST be used to ensure
>   confidentiality of the CI/T information. To that end, TLS MUST be
>   used by CI/T, including authentication of the remote end.
> 
> ... the Internet is clearly an environment where such protection is
> required, and it'll often be used for these interfaces - we could state
> that explicitly, would that address the concern?
> 
> But, CI/T could also be deployed to run over a VPN or private network
> between two interconnected CDNs, in such an environment HTTPS transport
> would not have the same benefits.

Yes, that’s my point. Say explicitly that Internet is an example of environment where
such a protection is mandatory.


>> 2- Section 8.1, please check the paragraph « Note that in a « diamond »
>> configuration […] ». This paragraph is rather confusing to me. Confusion
>> comes from:
>> - the lack of description of the « diamond configuration ». I understand
>> there is one dCDN on top and multiple uCDN directly connected below, am I
>> right?
> 
> Yes, that's right. The draft says:
> 
>   Note that in a "diamond" configuration, where one uCDN's content can
>   be acquired via more than one directly-connected uCDN,
> 
> Would the following rearrangement help? ...
> 
>   A "diamond" configuration is one where a dCDN can acquire a uCDN's
>   content via more than one directly-connected uCDN. Note that
>   in a diamond configuration […]

Yes, I prefer this version. However, can the same « uCDN’s content » be
available at several uCDNs in this diamond configuration? Said differently,
what about the following text:

	A « diamond » configuration is one where a dCDN can acquire a given
	content via more than one directly-connected uCDN. Note that […]


>> - the notion of « content acquired from a uCDN ». If I understand correctly,
>> it means « content that has been acquired after a uCDN request to do so ».
>> I initially thought there were some mistakes in the use of uCDN / dCDN…
> 
> A dCDN will always acquire content from a uCDN because it's been requested
> to do so (without a request it won't know the URL in the uCDN).
> 
> The request can be from an end-client or a further-downstream CDN, in which
> case the content will be acquired on-demand, or it can be a CI/T
> pre-positioning request from a uCDN.
> 
> Does that help? I’m not sure what change or clarification you're asking for.

Forget my comment, I misunderstood the notion of uCDN… I should have read
RFC 6707 before!


>> 3- With this « diamond configuration », since several uCDN can act upon the
>> same content, what happens if they behave in a non coordinated manner (i.e.,
>> in the general case)? For instance let’s imagine one of them asks the dCDN
>> to delete the content or cancel the initial command. What happens if another
>> uCDN then asks the dCDN to invalidate this content, providing the URL of the
>> Trigger Status Resource which (if I understand correctly) is no longer valid?
>> This « diamond configuration » can be a little bit tricky and no clear
>> guideline is provided in the document.
> 
> A trigger status resource belongs to one uCDN and cannot be accessed or
> manipulated by any other CDN, section 3 para 3 says:
> 
>   Trigger Status Resources belonging to a uCDN MUST NOT
>   be visible to any other CDN. The dCDN could, for example, achieve
>   this by offering different collection URLs to each uCDN, and/or by
>   filtering the response based on the uCDN with which the HTTP client
>   is associated.

I see… However, if multiple uCDNs can act on the same content (what is said),
even if each uCDN uses a different URL, will simultaneous CI/T commands for
the same content be managed correctly? This is not said in section 3
paragraph 3 either and this is a key point.


> Content always originates from one uCDN, but in a diamond configration there
> may be multiple routes (via other CDNs) to a given dCDN.
> 
> The most common scenario may well be that the uCDN will initiate all of the
> CI/T commands related to its content, and those commands will simply be
> forwarded by intermediate CDNs.
> 
> But, there's nothing to stop an intermediate CDN initiating or modifying
> CI/T commands - and some modifications of the command will be necessary
> (for example, metadata URLs will need to be changed).
> 
> By analysis of log files it will probably be possible to work out which
> uCDN an individual cache in the dCDN acquired each cached resource from.
> But the cache is not required to keep a live record of that, and it
> probably won't. In that case, when it receives a CI/T command to invalidate
> or purge content, the dCDN should apply that command to any content it
> may have acquired from the uCDN it got the CI/T command from.
> 
> So there is scope for a malicious intermediate CDN to cause extra processing
> and acquisition by a dCDN (and that's mentioned in section 8). But a
> malicious CDN is likely to find itself removed from the CDN federation fairly
> quickly - there will necessarily be a level of trust between interconnected
> CDNs.
> 
> Would it help to spell out some of that in the draft? (The same or very
> similar text has been used in several of the CDNI drafts.)

Yes, this paragraph is worth being detailed a little bit.

In your explanations you mention intermediate CDNs while original text only
mentions directly connected uCDNs. The notion of « intermediate CDN » is
only discussed in sections 2.3 and 4.8. Since malicious intermediate CDNs are
part of a valid attack model, it is worth to explain it (or give a reference to another
document).


>> 4- Concerning privacy aspects, I would be much more cautious than the authors.
>> For instance, I wouldn't claim "there are no privacy concerns for End Users"
>> because the CI/T protocol does not carry information about individual End
>> Users (section 8.3). The dCDN knows that there are users interested (or at
>> the opposite no user interested) by a certain content in the region served
>> by a uCDN. Therefore, the protocol only provides k-anonymity, where k is the
>> number of End Users in the region. Depending on the content sensitivity and
>> k value, this k-anonymity may still raise privacy issues, even if the
>> individual End User activity logs are not available to the dCDN (I assume
>> TLS is used to prevent eavesdropping…).
> 
> I don't think that analysis is correct...
> 
> Irrespective of CI/T, the dCDN will always know who's accessing the content,
> clients are making their requests directly to it.
> 
> The CI/T interface is only a small part of CDN Interconnection. There are
> other interfaces for distribution of metadata, request routing, and retrieval
> of dCDN log files by the uCDN.
> 
> Significant work went in to the CDNI logging interface to make it possible
> to anonymise/aggregate end-client information before sharing it with a
> uCDN - but that's not relevant to the CI/T interface, which does not carry
> any end-user specific information.
> 
> The CI/T interface does not expose any dCDN information about end-clients to
> the uCDN.

My comment is also caused by my misunderstanding of uCDN in the architecture.
So yes, I agree with you that there’s no privacy issue here.

In any case, thanks for your detailed answer. And sorry for my misunderstanding
of the architecture.

Cheers,

   Vincent