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

Vincent Roca <> Wed, 06 January 2016 08:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B15231A89A0; Wed, 6 Jan 2016 00:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.56
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oeqXJ_44L3Ln; Wed, 6 Jan 2016 00:27:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (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 ([]) by 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 <>
In-Reply-To: <>
Date: Wed, 6 Jan 2016 09:27:37 +0100
Message-Id: <>
References: <> <>
To: "Murray, Rob (Rob)" <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: "" <>, IESG <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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