Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-00.txt

From: [email-masked]
Date: Tue, 02 Oct 2012 10:34:31 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.

	Title           : CDN Interconnect Metadata
	Author(s)       : Ben Niven-Jenkins
                          Rob Murray
                          Grant Watson
                          Matt Caulfield
                          Kent Leung
                          Kevin J. Ma
	Filename        : draft-ietf-cdni-metadata-00.txt
	Pages           : 35
	Date            : 2012-10-02

Abstract:
   The CDNI Metadata Interface enables interconnected CDNs to exchange
   content distribution metadata in order to enable content acquisition
   and delivery.  The CDNI metadata associated with a piece of content
   provides a downstream CDN with sufficient information for the
   downstream CDN to service content requests on behalf of an upstream
   CDN.  This document describes both the core set of CDNI metadata and
   the protocol for exchanging that metadata.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-cdni-metadata-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 22 Oct 2012 16:18:29 +0000

Hi,

(As an individual)

A few small comments on Security Considerations of draft-ietf-cdni-metadata-00.txt:

"
The CDNI Metadata Interface is expected to be secured as a function
   of the transport protocol (e.g.  HTTP authentication, HTTPS, or
   inter-domain IPSec).
"
I suggest you include references (at least for "HTTP authentication").

"
   If a malicious metadata server is contacted by a downstream CDN, the
   malicious server may provide metadata to the downstream CDN which
   denies service for any piece of content to any user agent.  The
   malicious server may also provide metadata which directs a downstream
   CDN to a malicious origin server instead of the actual origin server.
"
This paragraph points out the risks, but does not indicate any remedy. (The following paragraph points out the risk in the opposite direction and brings up a remedy).

Cheers

Francois

On 2 Oct 2012, at 19:34, <[email-masked]>
 <[email-masked]> wrote:

> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 22 Oct 2012 16:56:00 +0000

Two other suggestions:

I suggest you discuss separately:
	* the risks associated with one end of the interface being a malicious end, which can be addressed by authentication
	* the risks associated with confidentiality e.g. 3rd party eavesdropping the metadata exchange (e.g. to gain information such as acquisition/credential information), which can be addressed by confidentiality protection mechanisms such as encryption.
	* the risks associated with integrity e.g. 3rd party intercepting and modifying the metadata exchange , which can be addressed by integrity protection mechanisms such as encryption.
And then indicate which protection can be provided in each direction by each mechanism you mention (e.g. HTTPs provides auth + confidentiality + integrity protection, in both S-->C and C-->S directions) 

I suggest you discuss the risks of DoS attack on the Metadata server: i.e. one dCDN deliberately/inadvertently overloads uCDN Metadata server, preventing another dCDN from obtaining metadata. I'd expect that such risk would be fairly low considering that serving metadata is fairly low load (i.e. no processing involved). It could also be mitigated by access control mechanism limiting what devices can access it (e.g. to protect against Bots-based DDOS attacks).