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

Vincent Roca <vincent.roca@inria.fr> Tue, 22 March 2016 14:57 UTC

Return-Path: <vincent.roca@inria.fr>
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 74A6D12D9F5; Tue, 22 Mar 2016 07:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 Ae5e_P8u6_4R; Tue, 22 Mar 2016 07:57:41 -0700 (PDT)
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 5611E12D975; Tue, 22 Mar 2016 07:57:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,377,1454972400"; d="asc'?scan'208,217";a="209498763"
Received: from geve.inrialpes.fr ([194.199.28.1]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2016 15:57:38 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_060E29B6-ECD5-44E4-BC08-AB14B7CE2E8D"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com>
Date: Tue, 22 Mar 2016 15:57:37 +0100
Message-Id: <61B94AAC-920E-4909-9680-6FF212E8901D@inria.fr>
References: <AF9FDB2A-3DA1-45C0-A624-F177A72F1DAC@inria.fr> <DB3F24EE-A6AB-44EF-8632-B5B24933CEBC@alcatel-lucent.com> <C7B3A95D-F5C9-4BD9-98FF-E653B292C63E@inria.fr> <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com>
To: "Murray, Rob (Nokia - GB)" <rob.murray@nokia.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/lxCTdiLIGWtPwSNZfoEvOLUmCoA>
Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" <draft-ietf-cdni-control-triggers@tools.ietf.org>, "cdni@ietf.org" <cdni@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.17
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: Tue, 22 Mar 2016 14:57:43 -0000

Hi Rob,

> I've just posted a "-12" of the CDNI Triggers draft, hopefully addressing these comments. Responses inline below.

I see you've added section 2.2.1 to clarify many architectural aspects. That's quite useful.


>>>> 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.
> 
> In "-12" I've aligned the text above with the text used in the cdni-metadata draft:
> 
>  TLS MUST be used by the server-side (dCDN) and the client-side (uCDN) of
>  the CI/T interface, including authentication of the remote end, unless
>  alternate methods are used for ensuring the confidentiality of the
>  information in the CI/T interface requests and responses (such as setting
>  up an IPsec tunnel between the two CDNs or using a physically secured
>  internal network between two CDNs that are owned by the same corporate
>  entity).
> 
> I think that covers it better (?).

This is much better. Just a minor comment: "... for insuring the security" instead of
"... for ensuring the confidentiality", since confidentiality is only one aspect of security.


>>>> 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 […]
> 
> Yes, more than one uCDN will have the same content - but the important point is that ultimately they will all have acquired it from the same uCDN, and that uCDN owns the metadata.
> 
> I've tried to provide a better intro/explanation in new section 2.2.1 "Multiple interconnected CDNs". Hopefully that makes it a bit clearer?

Yes, as said above, section 2.2.1 is rather useful.
Just a comment for this section 2.2.1, third paragraph, last sentence. You mention
both "intermediate CDN" and just after "intermediate uCDN". This is a bit confusing.

Another detail: in second paragraph you mention ""intermediate" CDN" with extra " "
around intermediate. Please harmonize.


>>>> 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.
> 
> Sorry, I'd missed your point.
> 
> Interactions can be inefficient, but are otherwise harmless because the strongest of "invalidate" or "purge" will win, and content can always be re-acquired if it's still available from any uCDN.
> 
> I've given some examples in new section 2.2.1 "Multiple interconnected CDNs", and added a pointer to that from the Security Considerations section.

Once again, the examples of section 2.2.1 answer my comments. Thanks.


>>> 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).
> 
> When a content owner, the origin, delegates delivery to a CDN it is trusting that CDN to deliver the right content on its behalf. A malicious CDN could deliver anything instead, but it would soon lose the trust of the origin.
> 
> CDN-interconnection simply extends that trust to the further-downstream CDNs acting on behalf of the original.
> 
> So establishment/enforcement of the trust relationship itself, the contract between the origin and the CDN, is outside the scope of CDNI and in the land of commercial agreements.

Sure, I agree.


> I've added a note on that in the intro to the Security Considerations section.

That's perfect.

To conclude the document is okay from my point of view.

Thanks for your detailed answers.
Cheers,

   Vincent