Subject: [apps-discuss] Review of draft-ietf-cdni-problem-statement-04

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Apr 2012 10:44:09 -0500

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-cdni-problem-statement-04
Title: Content Distribution Network Interconnection (CDNI) Problem
        Statement
Reviewer: Vijay K. Gurbani
Review Date: Apr-16-2012
IETF Last Call Date: Not known
IESG Telechat Date: Not known

Summary: This draft is ready for publication as an Informational.

Major Issues: 1
Minor Issues: 5
Nits:         4

Major Issues:
- S6: I believe that expanding the security considerations for each
  CDNI interface will help in the long run.  Here is a first stab at
  this that you may want to consider replacing the second paragraph
  with (please feel free to expand this since you are the subject
  matter experts here).  Suggested text:

  6.1 Security of the CDNI Request Routing Interface

    Appropriate levels of authentication and confidentiality must be
    used in this interface because it allows an upstream CDN to
    query capabilities of a downstream CDN, and conversely, allows
    the downstream CDN to control the upstream CDN's Request Routing
    function.

    Absent appropriate security on this interface, a rogue upstream
    CDN can inundate downstream CDNs with bogus requests, or have the
    downstream CDN send the rogue upstream CDN private information
   (e.g., load, resources).

  6.2 Security of the CDNI Control Interface

    Information on this interface is of a very private nature as well.
    A pair of CDNs use this interface to allow bootstrapping of content
    acquisition; an upstream CDN may pre-position content in a downstream
    CDN, or it may purge the contents at a downstream CDN; a downstream
    CDN may provide administrative information to an upstream CDN, etc.
    All of these operations require that the peer CDNs are appropriately
    authenticated and that the confidentiality of information flowing
    between them is maintained.

  6.3 Security of the CDNI Metadata Interface

    Because this interface allows a downstream CDN to request metadata
    from an upstream CDN, the latter must ensure that the former is
    appropriately authenticated before sending the data.  Conversely,
    a downstream CDN must authenticate an upstream CDN before requesting
    metadata to insulate itself from poisoning by rouge upstream CDNs.
    The confidentiality of the information exchanged between the peers
    must be protected.

  6.4 Security of the CDNI Logging Interface

    Logging data consists of potentially sensitive information (which
    user accesses which media resource, IP addresses of users, potential
    names and subscriber account information, etc.)  This information
    must be protected as the log records are moved between hosts.

Minor Issues:

- S1: Your problem statement essentially is an interplay between
  four logical entities: end user, CSP, CDN, and NSP.  I think this
  interplay needs to be laid out a bit more explicitly.  It seems to me
  that your model is that a user is subscribed to a CSP.   The CSP has
  arrangements with various CDN providers to distribute content.  The
  user, at a certain point in time, is in a network owned by a NSP that
  uses a CDN that does not have receive content from CSP.  Thus CSP is
  at a disadvantage since it will have to serve the user from a CDN that
  is not necessarily close to the user, thereby introducing a reduced
  quality of experience for the user.

  What CDNI does is enable the CSP to contract with an "authoritative"
  CDN provider for the delivery of content and that that
  authoritative CDN Provider could contract with one or more downstream
  CDN Provider(s) to distribute and deliver some or all of the content
  on behalf of the authoritative CDN Provider.  Because the downstream
  CDN Provider(s) will be closer to the user, the user is subjected to
  a better viewing experience than he or she would be had the content
  been delivered from a farther CDN.

  I think that laying out the interplay between the four entities in
  the second paragraph of S1 more explicitly may provide better context
  to the reader who is not already well versed with CDNs.

- S1: I would advise to order the terms defined by an alphabetical
  order (if possible).

- S3, last paragraph: The term "where to go" is rather ambiguous.
  Do you mean, "which upstream CDN to acquire content from"?  Or
  something else?  It will help to make this more explicit.

- S4, last paragraph: it is stated that "we assume that this [developing
  a new protocol] is unnecessary".  Based on the contents of S4.1-
  S4.4, I believe you do more than "assume".  You clearly enunciate a
  list of protocols that can be used for the various interfaces, thus
  providing a first order reasoning for why a new protocol for CDNI
  is not needed.

  Therefore, I would exhort you to use a stronger word than "assume";
  something like:

    Secondly, although a new application protocol could be designed
    specifically for CDNI, our analysis below shows that this is
    unnecessary ...

- S4.3: Are these "log lines" or "log records"?  Presumably, one or
  more lines will aggregate to one log record.  It seems appropriate
  in this document to talk about "log records" instead of "log lines".
  The CDNI logging interface draft can tease out more precisely how
  many lines comprise a record, etc.

  Secure ftp and secure copying (scp) appears to be missing in the list
  of protocols.  I would suspect that sftp would be preferred over
  normal ftp.

Nits:

- Global: In the Abstract and S1, "End Users" is employed multiple
  times.  End Users is defined in the Terminology section as a
  definition.  I would propose that attach the acronym "EU" on
  the first encounter of "End User" in the Abstract and S1,
  and from then on simply use "EU".

- S1, second paragraph: "attachment network" sounds incomplete.
  Maybe you meant "attachment to the network"?

- S3: s/existing protocols: this is/existing protocols; this is/

- S4.1, last paragraph: May be good to give a reference to ALTO.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 25 Apr 2012 20:34:06 +0200

Vijay, Ben, Nabil, all,

On 16 Apr 2012, at 17:44, Vijay K. Gurbani wrote:
> CDNI interface will help in the long run.

Below is an edited/expanded version of the Security Considerations section that integrates Vijay's comment and also captures a couple of high-level points from the Security Considerations section of the cdni-framework. Can you guys review and refine if needed?

I think we can integrate Vijay's Minor comments and nits offline.

Thanks much to Vijay for the useful review.

Francois

6.  Security Considerations

Distribution of content by a CDN comes with a range of security
   considerations such as how to enforce control of access to the
   content by users in line with the CSP policy, or how to trust the logging information generated by the CDN for the purposes of charging the CSP. These security aspects
   are already dealt with by CDN Providers and CSPs today in the context
   of standalone CDNs.  However, interconnection of CDNs introduces a
   new set of security considerations by extending the trust model to a chain of trust (i.e.
   the CSP "trusts" a CDN that "trusts" another CDN).
The mechanisms used to mitigate these risks in multi-CDN environments may be similar to those used in the single CDN case, but their
   suitability in this more complex environment must be validated.

   Maintaining the security of the content itself, its associated
   metadata (including delivery policies) and the CDNs
   distributing and delivering it, are critical requirements for both
   CDN Providers and CSPs and the CDN Interconnection interfaces must
   provide sufficient mechanisms to maintain the security of the overall
  system of interconnected CDNs as well as the information (content,
   metadata, logs, etc) distributed and delivered through any set of interconnected CDNs.

6.1 Security of the CDNI Control Interface

  Information on this interface is of a very private nature.
  A pair of CDNs use this interface to allow bootstrapping of all the other CDNI interfaces possibly including establishment of the mechanisms for securing these interfaces. Therefore, corruption of that interface may result in corruption of all other interfaces. 
Using this interface, an upstream CDN may pre-position or delete content or metadata in a downstream
  CDN and a downstream CDN may provide administrative information to an upstream CDN, etc.
  All of these operations require that the peer CDNs are appropriately
  authenticated and that the confidentiality and integrity of information flowing
  between them can be ensured.

6.2 Security of the CDNI Request Routing Interface

  Appropriate levels of authentication and confidentiality must be
  used in this interface because it allows an upstream CDN to
  query the downstream CDN in order to redirect requests, and conversely, allows
  the downstream CDN to influence the upstream CDN's Request Routing
  function.

  Absent appropriate security on this interface, a rogue upstream
  CDN can inundate downstream CDNs with bogus requests, or have the
  downstream CDN send the rogue upstream CDN private information. Also, a rogue downstream CDN could influence the upstream CDN so the uCDN redirects requests to the rogue dCDN or another dCDN in order to attract additional delivery revenue.

  Because this interface allows a downstream CDN to request metadata
  from an upstream CDN, the latter must ensure that the former is
  appropriately authenticated before sending the data.  Conversely,
  a downstream CDN must authenticate an upstream CDN before requesting
  metadata to insulate itself from poisoning by rogue upstream CDNs.
  The confidentiality and integrity of the information exchanged between the peers
  must be protected.

  Logging data consists of potentially sensitive information (which
  user accesses which media resource, IP addresses of users, potential
  names and subscriber account information, etc.) Confidentiality of this information
  must be protected as the log records are moved between hosts.
This information may also be sensitive from the viewpoint that it can be the basis for charging across CDNs. Therefore, appropriate levels of protection are needed against corruption, duplication and loss of this information. 

>  Here is a first stab at

Francois Le Faucheur
Distinguished Engineer
Service Provider Video Technology Group   
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html