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

From: Vincent Roca <[email-masked]>
Date: Mon, 4 Jan 2016 17:27:31 +0100

Hello,

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.

Summary: not totally ready

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

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

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.

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

Typo:

** Section 8.3: « ... prevents parties other party..."

Cheers,

  Vincent

---

From: "Murray, Rob (Rob)" <[email-masked]>
Date: Tue, 5 Jan 2016 16:23:08 +0000

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

Cheers,
Rob.

> From: Vincent Roca <[email-masked]>Date: Monday, 4 January 2016 at 16:27
> To: IESG <[email-masked]>, <[email-masked]>, <[email-masked]>
> Cc: Vincent Roca <[email-masked]>
> Subject: Secdir review of draft-ietf-cdni-control-triggers-11
>
> Hello,
>
> 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.

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

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

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

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

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

> ** Section 8.3: « ... prevents parties other party..."

Will fix, thanks.

---

From: Vincent Roca <[email-masked]>
Date: Wed, 6 Jan 2016 09:27:37 +0100

Hello Rob,

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

You’re welcome.

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

>   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 […]

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

>   filtering the response based on the uCDN with which the HTTP client

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.

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

> The CI/T interface does not expose any dCDN information about end-clients to

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