Secure Content Delivery between a Streamer and User by using CDS-IS and ACE

Document

Mon, 05/28/2012 - 23:22
May 28th, 2012
Table of Contents 


Introduction

This article discusses how to secure content delivery from CDS Internet Streamer towards the end-user, with HTTPS. The user starts by sending the request over HTTPS towards the Service Router (SR). This request will get redirected, over HTTPS, and will eventually open a session with a streamer, over HTTPS. Because the CDS-IS  don't support SSL offloading, we will use an ACE to offload SSL and present plain HTTP traffic to both the service router and the streamers. This can be combined with SR loadbalancing. Private key and certificate will be uploaded on ACE, in order to decrypt SSL. This delivery method is suitable for any content to be delivered over HTTP.


Network Diagram

CDS-ACE.png

Traffic Flow

1. Client requests the content over https, e.g. https://ds1.cds.xyz.com/video1.m3u8 and sends DNS query to D-Proxy

2. D-Proxy returns A record pointing to VIP on ACE

3. Client sends HTTPS request to ACE VIP

4. ACE decrypts SSL and sends plain HTTP request to SR

5. SR issues 302 redirection to client

6. ACE rewrite "Location" header from http to https, re-encrypt the response from SR and forward to client via https

7. Client open new session to Streamer (destination IP is real streamer IP)

8. ACE is on the path between client and streamer and receives the request. ACE offload SSL and forward the request to streamer over HTTP

9. Streamer serves client (HTTP)

10. ACE re-encrypt and forwards to client


Service Router

This section discusses the setup between client and Service Router.

DNS

The D-Proxy resolves ds1.cds.xyz.com to the ACE VIP 10.48.68.5

ACE

The client will send an https request like https://ds1.cds.company.com/video1.m3u8 to ACE VIP. ACE will offload the SSL and forward plain HTTP to SR. ACE will parse the 302 Redirect and rewrite it, as the router will issue a Location header of this type: Location: http://se1.se.ds1.cds.xyz.com/video1.m3u8 and needs to be rewriten to Location: https://se1.se.ds1.cds.xyz.com/video1.m3u8


ACE Configuration

// this is the action-list that will be applied in a policy in order to match any "Location" header that as an http:// URL and resplace by https://

action-list type modify http SSL_URL_REWRITE

  header rewrite response Location header-value "http://(.*)" replace "https://%1"


//the service router

rserver host LB-SR1

  ip address 10.1.22.4

  inservice


// the ssl-proxy that will allow decrypting SSL, for that we ahd uploaded a private key and cert. In this case we use a self-signed certificate for demo purpose.

ssl-proxy service HTTPS_CDS

  key mbr_priv.pem

  cert mbr_cert.pem


//the serverfarm with one SR. There could be more than one if we would like to loadbalance.

serverfarm host CDE-SR

  rserver LB-SR1 80

    inservice


// the vip that the DNS resolves to and that the client initially tries to access

class-map match-all VIP_SR

  2 match virtual-address 10.48.68.5 tcp eq https


//class binding the serverfarma and calling the Location header rewrite

policy-map type loadbalance first-match HTTPS_SR

  class class-default

    serverfarm CDE-SR

    action SSL_URL_REWRITE


// the policy that will be applied to client facing interface. we call the ssl-proxy here in order to offload SSL.

policy-map multi-match GENERIC

  class VIP_SR

    loadbalance vip inservice

    loadbalance policy HTTPS_SR

    ssl-proxy server HTTPS_CDS


// in our example, vlan 120 is the vlan facing the client

interface vlan 120

  ip address 10.1.20.11 255.255.255.0

  service-policy input GENERIC

  no shutdown


Streamers

The above sections showed how to have the initial redirection working. We have now the client requesting https://se1.se.ds1.cds.xyz.com.video1.m3u8


Flow

This is a little bit different here as we do not use a VIP on ACE. The traffic will route through the ACE, either "naturally", or via policy-routing.

Hence, when the request will hit the ACE, it will have a source IP address of the client, and a destination IP of the streamer. This is due to the fact that the SR already points the redirection to one particular CDE, "se1" in our example.


ACE Configuration

// the real server in this case is not a CDE but the next-hop towards the CDE

rserver host MSFC_33

  ip address 33.33.33.1

  inservice


// same as with SR

ssl-proxy service HTTPS_CDS

  key mbr_priv.pem

  cert mbr_cert.pem


// serverfarm containing the next-hop. 'transaparent' keyword means to send the forward the request towards CDE without changing destination IP.

serverfarm host MSFC

  transparent

  rserver MSFC_33 80

    inservice


// no vip but a catch-all rule that will match any destination IP on tcp 443

class-map match-all TRANSPARENT_VIP_CDE

  4 match virtual-address 0.0.0.0 0.0.0.0 tcp eq https


// same as with SR

policy-map type loadbalance first-match TRANSPARENT_LB

  class class-default

    serverfarm MSFC


// same as with SR

policy-map multi-match GENERIC

  class TRANSPARENT_VIP_CDE

    loadbalance vip inservice

    loadbalance policy TRANSPARENT_LB

    ssl-proxy server HTTPS_CDS


// in our example, vlan 130 is facing the client. Traffic towards streamers arrive here either via normal routing or policy-based routing.

interface vlan 130

  ip address 10.1.30.11 255.255.255.0

  service-policy input GENERIC

  no shutdown


Related Information

Cisco Internet Streamer CDS 2.5 Software Configuration Guide

Configure ACE to Monitor CDS-IS

Loading.

Actions

This Document