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

[Francois Le Faucheur <[e-mail]>]

Vijay, Ben, Nabil, all,

On 16 Apr 2012, at 17:44, Vijay K. Gurbani wrote:
> 
> Major Issues:
> - S6: I believe that expanding the security considerations for each
> 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.

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 rogue upstream CDNs.
  The confidentiality and integrity 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.) 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
> 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} / [e-mail]
> Web:   http://ect.bell-labs.com/who/vkg/



Francois Le Faucheur
Distinguished Engineer
Service Provider Video Technology Group   
[e-mail]
Phone: [phone]
Mobile: [phone]



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