Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11
"Murray, Rob (Nokia - GB)" <rob.murray@nokia.com> Fri, 18 March 2016 16:08 UTC
Return-Path: <rob.murray@nokia.com>
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 7EBAE12D56F; Fri, 18 Mar 2016 09:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 HEvkuAkqtl0L; Fri, 18 Mar 2016 09:08:51 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8F212D590; Fri, 18 Mar 2016 09:08:43 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 22C1643DE62A8; Fri, 18 Mar 2016 16:08:38 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2IG8epC016560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Mar 2016 16:08:41 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2IG8NZj026753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Mar 2016 17:08:40 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.90]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 18 Mar 2016 17:08:30 +0100
From: "Murray, Rob (Nokia - GB)" <rob.murray@nokia.com>
To: Vincent Roca <vincent.roca@inria.fr>
Thread-Topic: Secdir review of draft-ietf-cdni-control-triggers-11
Thread-Index: AQHRRwzfQRQykiwnh0mW9gDUEP6L557tC9uAgAENeoCAcaifgA==
Date: Fri, 18 Mar 2016 16:08:29 +0000
Message-ID: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com>
References: <AF9FDB2A-3DA1-45C0-A624-F177A72F1DAC@inria.fr> <DB3F24EE-A6AB-44EF-8632-B5B24933CEBC@alcatel-lucent.com> <C7B3A95D-F5C9-4BD9-98FF-E653B292C63E@inria.fr>
In-Reply-To: <C7B3A95D-F5C9-4BD9-98FF-E653B292C63E@inria.fr>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.160212
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4F3156016E03884B91DD157704C7EC8C@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/l47aKF1o3DwMb7VsVWL1MQLdu-s>
X-Mailman-Approved-At: Fri, 18 Mar 2016 09:11:38 -0700
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: Fri, 18 Mar 2016 16:08:53 -0000
Hi Vincent and all, I've just posted a "-12" of the CDNI Triggers draft, hopefully addressing these comments. Responses inline below. Cheers, Rob. On 06/01/2016, 08:27, "Vincent Roca" <vincent.roca@inria.fr> wrote: >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. 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 (?). >>> 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? >>> - 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. 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. >> 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. I've added a note on that in the intro to the Security Considerations section. >>> 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
- [secdir] Secdir review of draft-ietf-cdni-control… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-cdni-con… Murray, Rob (Rob)
- Re: [secdir] Secdir review of draft-ietf-cdni-con… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-cdni-con… Murray, Rob (Nokia - GB)
- Re: [secdir] Secdir review of draft-ietf-cdni-con… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-cdni-con… Murray, Rob (Nokia - GB)
- Re: [secdir] Secdir review of draft-ietf-cdni-con… Murray, Rob (Nokia - GB)