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

[Vincent Roca <[e-mail]>]

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