Subject: [CDNi] Liaison Statement on URI Signing for MPEG-DASH

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 11 Nov 2014 23:17:01 +0000

Hello,

Here is the pointer to the liaison statement from MPEG related to URI signing that was discussed during our meeting Yesterday.

https://datatracker.ietf.org/liaison/1342/

Cheers

Francois

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 13 Nov 2014 02:36:41 +0000

Francois, Colleagues,

> https://datatracker.ietf.org/liaison/1342/

I read the liaison statement from MPEG.

If I understand it correctly MPEG have a use case where they want to present something similar to a CDN authorisation token (the URI signature in draft-ietf-cdni-uri-signing) and have the delivery node (could be a server or a CDN, etc) take some action based on the presence and validity of such a token.

At that level it seems very similar to a CDN authorisation token and so it may be that there is significant reuse between draft-ietf-cdni-uri-signing & what MPEG are thinking of.

It is difficult to say more, as the actual use case is not clear to me - e.g. the liaison says "the mechanisms provided by URI signing can also be applied to allow for other use cases, e.g. to prevent a client from skipping pre-roll and mid-roll advertisement"

I am struggling to understand how MPEG envision that use case being implemented, as skipping adverts is a client function not a server function AIUI.

It seems to me that we may be able to help MPEG here and we may already have something of use to them (or most of something that might only require some small tweaks), but without more details from MPEG of their use case(s) and how they envision the "call flow" working it is hard to say more.

Maybe the next step should be to respond to MPEG asking for further details on their use case so we can better assess the re-usability (and applicability) of draft-ietf-cdni-uri-signing for their use case(s).

Ben

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 13 Nov 2014 02:39:12 +0000

Well if you dont mind, I am copying Emmanuel in case he wants to respond. he may comment on the mpeg stuff.

> On Nov 12, 2014, at 4:36 PM, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> Francois, Colleagues,
>

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 13 Nov 2014 07:08:04 +0000

Hi Ben,

I’ve been part of some of the discussion in MPEG, and I understand the 
MPEG use cases to be the following:

The primary use case is to apply access control, as covered by the current 
URI signing draft, to segmented content. Due to the manifest/MPD, regular 
URI signing as specified in our draft does not work, since there is no 
redirect involved. However, by adding some features to the current draft 
(e.g signed cookies or chained requests), we might be able to have the 
same mechanism work for HTTP adaptive streaming content as well. 

Regarding preventing the client from skipping pre-roll ads, I think what 
is meant there is that if you have a mechanism that allows the server/CDN 
to reject certain requests based on a set of (signed) parameters in the 
HTTP request, one could use these same mechanisms for other purposes as 
well. For example, by adding valid-from and segment-pattern enforcement 
attributes, one could make the CDN reject any request for specific 
segments until a give (relative) point in time, thereby preventing the 
client from obtaining any contents segments until the pre-roll segments 
have been downloaded/watched. 

I have had some off-list discussion with Kent on the merits of various 
solution directions during the past few months. I will share those in a 
mail to the list later today.

Best regards,

Ray 

On 13/11/14 02:36, "Ben Niven-Jenkins" <[email-masked]> wrote:

>> Here is the pointer to the liaison statement from MPEG related to URI 
>>signing that was discussed during our meeting Yesterday.
>> 
>If I understand it correctly MPEG have a use case where they want to 
>present something similar to a CDN authorisation token (the URI signature 
>in draft-ietf-cdni-uri-signing) and have the delivery node (could be a 
>server or a CDN, etc) take some action based on the presence and validity 
>of such a token.
>
>At that level it seems very similar to a CDN authorisation token and so 
>it may be that there is significant reuse between 
>draft-ietf-cdni-uri-signing & what MPEG are thinking of.
>
>It is difficult to say more, as the actual use case is not clear to me - 
>e.g. the liaison says "the mechanisms provided by URI signing can also be 
>applied to allow for other use cases, e.g. to prevent a client from 
>skipping pre-roll and mid-roll advertisement"
>
>I am struggling to understand how MPEG envision that use case being 
>implemented, as skipping adverts is a client function not a server 
>function AIUI.
>
>It seems to me that we may be able to help MPEG here and we may already 
>have something of use to them (or most of something that might only 
>require some small tweaks), but without more details from MPEG of their 
>use case(s) and how they envision the "call flow" working it is hard to 
>say more.
>
>Maybe the next step should be to respond to MPEG asking for further 
>details on their use case so we can better assess the re-usability (and 
>applicability) of draft-ietf-cdni-uri-signing for their use case(s).
>
>Ben
>
>> 
>> Cheers
>> 
>> Francois
>> 
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 13 Nov 2014 16:18:11 +0000

Hi all,

As I mentioned in my previous mail, as authors of the URI signing draft, 
Kent, Francois and I have been discussing how to deal with the request 
from MPEG. Now that we’ve somewhat converged on a possible solution 
direction, we would like to ask the WG for an opinion. 

The main problem at hand is the fact that in both DASH as well as other 
HTTP adaptive streaming content (e.g. HLS or Smooth Streaming), a 
manifest/MPD is used. Due to this manifest, content requests do not go 
through a redirect from content provider to CDN and can therefore not be 
signed/validated. 

The general solution direction we’ve been discussing is setting up a sort 
of authorization chain, from the initial request for the manifest/MPD to 
every individual segment request. The idea is that when the UA is 
initially redirected to the CDN, e.g. for the initial manifest request, it 
receives some kind of token. It can then use this token for the first 
segment request, after which it receives a second token for the second 
segment, and so on. By limiting the validity time of each token using a 
method similar to that of the Expiry Time Enforcement Attribute in the 
current URI signing draft, one can limit the vulnerability of the UA 
handing out the token to other malicious UAs.

One of the things we’ve been debating is what is the best way to implement 
this token. Basically, we’ve explored two solutions for this: 

1. Cookie-based. In this case the token is implemented as a cookie. The 
advantage of this solution is that the client doesn’t have to be adapted 
and it is therefore not limited to DASH but also works for e.g. HLS. The 
downside of this solution is that it doesn’t work if the manifest is 
delivered out-of-band, e.g via the Content Provider. 
2. Header-query-string based. In this case, instead of sending the token 
as a Set-Cookie header, it is returned to the UA as a another custom HTTP 
header. The client then extracts the value of the HTTP header and places 
it into the URL query string of the next segment request (as indicated by 
the MPD). MPEG DASH already provides the necessary mechanisms for 
signalling this. The advantage of this mechanism is that it is potentially 
more flexible. The downside is that it requires changes to the client and 
will therefore only work for DASH clients.

Another topic we’ve been discussing is how to signal the set of segments 
for which a particular token is valid. Here we’ve discussed the 
possibility of adding a segment-pattern enforcement attribute. This way it 
would be possible to for example signal that a specific token is only 
valid for segments belonging to the same content item, or even of a 
specific quality. The main question here is how to best signal such a 
segment pattern. One possibility here is to use URI templates. 

Since this has turned into quite a lengthy mail, I think I’ll leave some 
of the other questions for later. 

What do you guys think? Is this a topic that we should be tackling at all? 
And if so, what do you think of the proposed solution directions?

Best regards,

Ray

On 13/11/14 07:08, "Brandenburg, R. (Ray) van" <[email-masked]> 
wrote:

>This message may contain information that is not intended for you. If you 
>are not the addressee or if this message was sent to you by mistake, you 
>are requested to inform the sender and delete the message. TNO accepts no 
>liability for the content of this e-mail, for the manner in which you use 
>it and for damage of any kind resulting from the risks inherent to the 
>electronic transmission of messages.

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 13 Nov 2014 16:57:54 +0000

Hi Ray,

> one could make the CDN reject any request for specific

One note: the CDN may be able to verify that it sent content at a specific time,
but there is no way for the CDN to verify that the user watched the content, or
even that the client consumed the data.  I would expect ad reporting to rely on
beacons from the client (and have code running on the client side that verifies
and/or enforces the playback of an ad).  Relative-time-based restrictions don't
seem terribly useful to me in that particular case?

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray)
> van
> Sent: Thursday, November 13, 2014 2:08 AM
> To: Ben Niven-Jenkins; Francois Le Faucher
> Cc: [email-masked]
> Subject: Re: [CDNi] Liaison Statement on URI Signing for MPEG-DASH
> 
> Hi Ben,
> 
> are not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use it
> and for damage of any kind resulting from the risks inherent to the

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 13 Nov 2014 17:08:07 +0000

Hi Ray,

  Are you proposing that the client generate per-request tokens?

  Or are you proposing that the CDN generate new tokens, when it receives a request
  from the client, to be used by the client in subsequent requests?

  The former has key distribution issues, but does not necessarily impact the CDN
  surrogate implementation?

  The latter, however, could require a certain amount of statefulness or intelligence
  in the CDN surrogate, to make it work for use cases like personalized ad insertion?

  I'm not sure I fully understand the scope of the work here?

thanx.

--  Kevin J. Ma

> Sent: Thursday, November 13, 2014 11:18 AM

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 14 Nov 2014 03:14:13 +0000

Ray, Colleagues,

I think it's worth separating out the two use cases you outline below, hence changing the subject line.

See inline...

> same mechanism work for HTTP adaptive streaming content as well. 

I'll respond to this point by replying to your other e-mail.
 
> have been downloaded/watched. 

I don't completely understand how that is envisioned to work, but I don't think it will actually achieve what people might think it will and it potentially places additional complexity on the delivery server (origin, surrogate, CDN, etc) for no reason.

Unless I've misunderstood (which I may well have), I think preventing skipping of adverts is a policy level choice that exists at a layer above the delivery of the content itself.

E.g. just because something is delivered (i.e. the server sends the bytes), doesn't enforce that those bytes were rendered on the screen.

It would seem to me that the only way to enforce play out is to have a player that understands (somehow) the content provider's policy with respect to adverts and enforces that policy locally. Any other solution is unlikely to be able to enforce that policy in all cases (at least for HTTP adaptive streaming as currently defined).

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 14 Nov 2014 03:42:36 +0000

Ray, Colleagues,

I think what you're suggesting here is changing the scope of the document from how to sign a particular URL to describing how to mint (& possibly present) an "authorisation token" that authorises the client the be able to retrieve the content from 1 or more URLs.

I have no objection to that, but just want to make sure we're all on the same page.

More inline...

> through a redirect from content provider to CDN and can therefore not be 

Can you expand a bit more on this. i.e. I am not seeing the relevance of the manifest and how it prevents "signing/validation"?

Are you saying content providers do not want to create per-user manifests or something else?

> handing out the token to other malicious UAs.

Why have the complexity of an authorisation chain? If you had an authorisation token that authorised access to multiple URLs with a single expiry time, would that be sufficient?

> delivered out-of-band, e.g via the Content Provider. 

When you say out of band, do you really mean that the manifest is served from a different domain to the video chunks?

> will therefore only work for DASH clients.

I think there may be other solutions that provide the flexibility you desire, without requiring custom client logic as required by having a special HTTP header.

Once I have a better idea of the scenario you are envisaging, i.e. answers to my questions above, I may be able to suggest a 3rd way.

> segment pattern. One possibility here is to use URI templates. 

URI templates are one way, something like the PatternMatch in the metadata document is another (simpler but less expressive) way.

Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 14 Nov 2014 07:25:03 +0000

Hi Kevin,

Please see inline.

Ray

>  from the client, to be used by the client in subsequent requests?

Yes. In practice, what the CDN would do would not be dissimilar to what we 
expect the CSP to do now, except the token is stored in a Cookie or other 
HTTP header instead of in the redirection URL.

>  in the CDN surrogate, to make it work for use cases like personalized 

I don’t see how statefulness would be necessary. The idea would be to 
package everything that the CDN needs to generate the token (e.g. 
expiration time, key ID) in the query string, as communicated through the 
MPD/manifest. This would still allow the MPD/manifest to be static, in 
contrast to adding signed URLs in the manifest itself.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 14 Nov 2014 07:33:19 +0000

Hi Ben,

On 14/11/14 03:42, "Ben Niven-Jenkins" <[email-masked]> wrote:

>Ray, Colleagues,
>
>I think what you're suggesting here is changing the scope of the document 
>from how to sign a particular URL to describing how to mint (& possibly 
>present) an "authorisation token" that authorises the client the be able 
>to retrieve the content from 1 or more URLs.

I think it depends on your definition. Effectively, the method of signing 
a particular URL and ‘minting’ a token are quite similar. The only 
difference is that one is placed in the query string of the redirection 
URL, and the other is placed in the Set-Cookie field of a returned 200 OK. 

>Can you expand a bit more on this. i.e. I am not seeing the relevance of 
>the manifest and how it prevents "signing/validation"?
>

One way around this would be to create per-used manifests, where each URL 
in the manifest is signed. The problem with that is that once you have a 
60min content item, the URLs need to be valid for at least 60 minutes. 
That gives a malicious UA plenty of time to distribute the signed manifest 
to others, thereby reducing the effectiveness of signing the URLs in the 
first place. By instead only including in the segment URLs in the manifest 
the attributes necessary for the CDN to create a new token every time a 
request is made, you can have both a generic MPD as well as significantly 
shorter expiration times.

>Why have the complexity of an authorisation chain? If you had an 
>authorisation token that authorised access to multiple URLs with a single 
>expiry time, would that be sufficient?

No, I don’t think so. If you would have a token that is valid for 60 
segments, than by definition the expiration time of that token should be 
at least 60 segment lengths. This would reduce the effectiveness of having 
a token authorization in the first place.

>When you say out of band, do you really mean that the manifest is served 
>from a different domain to the video chunks?

I’m thinking of the common scenario where the CSP is the one who is 
serving the manifest (e.g. because it is performing some custom ad 
insertion in the manifest), while the CDN is serving the chunks. 

>I think there may be other solutions that provide the flexibility you 
>desire, without requiring custom client logic as required by having a 
>special HTTP header.
>
>Once I have a better idea of the scenario you are envisaging, i.e. 
>answers to my questions above, I may be able to suggest a 3rd way.

I’m interested :)

>URI templates are one way, something like the PatternMatch in the 
>metadata document is another (simpler but less expressive) way.

Yes, that might indeed be an alternative. 

Best regards,

Ray

>>>> e.g. the liaison says "the mechanisms provided by URI signing can 
>>>>also 
>>>> be 
>> This message may contain information that is not intended for you. If 
>>you are not the addressee or if this message was sent to you by mistake, 
>>you are requested to inform the sender and delete the message. TNO 
>>accepts no liability for the content of this e-mail, for the manner in 
>>which you use it and for damage of any kind resulting from the risks 
>>inherent to the electronic transmission of messages.
>

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 14 Nov 2014 07:35:40 +0000

Hi Ben,

On 14/11/14 03:14, "Ben Niven-Jenkins" <[email-masked]> wrote:

>I don't completely understand how that is envisioned to work, but I don't 
>think it will actually achieve what people might think it will and it 
>potentially places additional complexity on the delivery server (origin, 
>surrogate, CDN, etc) for no reason.
>
>Unless I've misunderstood (which I may well have), I think preventing 
>skipping of adverts is a policy level choice that exists at a layer above 
>the delivery of the content itself.
>
>E.g. just because something is delivered (i.e. the server sends the 
>bytes), doesn't enforce that those bytes were rendered on the screen.
>
>It would seem to me that the only way to enforce play out is to have a 
>player that understands (somehow) the content provider's policy with 
>respect to adverts and enforces that policy locally. Any other solution 
>is unlikely to be able to enforce that policy in all cases (at least for 
>HTTP adaptive streaming as currently defined).

You’re absolutely right, you can only control what is downloaded and what 
is played. I think the idea here was that for pre-roll ads, the two 
concepts are not necessarily that different in practice. Anyway, I agree 
with your concerns. I think the question here is: would it help at all, 
e.g. for clients that use a generic player, to be able to limit when 
particular segments are downloaded?

Ray

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Fri, 14 Nov 2014 15:55:54 +0000

Hi Ray,

Could you explain in more detail the signaling mechanism that DASH provides for the header-query-string method below? And why it might be superior the Cookie method?

Regarding how to group content - I recall that we had considered adding a "Grouping" object to the CDNI Metadata for this purpose exactly. Or are we trying to avoid relying on metadata?

Thanks,
Matt 

> From: CDNi [mailto:[email-masked]] On Behalf Of Brandenburg,
> R. (Ray) van
> To: Ben Niven-Jenkins; Francois Le Faucheur (flefauch)
> Cc: [email-masked]
> you
> are requested to inform the sender and delete the message. TNO
> accepts no liability for the content of this e-mail, for the manner in which
> you use it and for damage of any kind resulting from the risks inherent to
> the electronic transmission of messages.

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Fri, 14 Nov 2014 16:02:34 +0000

IMO - ensuring that ads are played sits squarely in the DRM domain. Guarantees about whether or not an ad is played out requires a cryptographically signed player. 

URI-signing (access control) is separate. 

> Sent: Friday, November 14, 2014 2:36 AM
> To: Ben Niven-Jenkins
> Cc: [email-masked]
> Subject: Re: [CDNi] (Not) Skipping adverts
> 
> Hi Ben,
> 
> 
> 
>

---

From: Kevin Ma J <[email-masked]>
Date: Sat, 15 Nov 2014 22:30:12 +0000

Hi Ray,

  Are you talking about non-URI-specific tokens?

  For personalized ad insertion (where the ADS/ADM is not part of the CDN),
  especially when you include timeshifted (pause/rewind live), shared copy
  nDVR, or catchup viewing, the actual asset that will be requested next is
  not necessarily going to be known to the CDN a priori.  For URI-specific
  tokens, it's not clear to me how the CDN would track the validity of client
  requests without tracking sessions and having insight into what time ranges
  and to which ads that particular client might have access.  Do you envision
  client specific tokens with content entitlements built in?  To Matt's point,
  and my other email, these sound like DRM/Entitlement enforcement issues?

thanx.

--  Kevin J. Ma

> From: Brandenburg, R. (Ray) van [mailto:[email-masked]]
> Sent: Friday, November 14, 2014 2:25 AM
> To: Kevin Ma J; Ben Niven-Jenkins; Francois Le Faucher
> Cc: [email-masked]

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Sun, 16 Nov 2014 07:37:01 +0000

Hi Matt,

> Could you explain in more detail the signaling mechanism that DASH 
>provides for the header-query-string method below? And why it might be 
>superior the Cookie method?

For all the details I will have to ask my colleague who attends MPEG, but 
from what I understand, they have created a URL Parameter Insertion 
mechanism that allows the MPD to specify to the Client which values to 
insert at which locations in the URL (e.g. 
http://example.com/content.mp4?data=<insert_current_bitrate>). 

I don’t necessarily think this method is superior to the Cookie-method. 
Both have their pros and cons. The problem with the Cookie method is that 
it doesn’t work when the manifest is served by the Content Provider (which 
can be quite a common case). The problem with the header-query-string 
method is that it only works for DASH clients, and not for standard HLS 
clients. 

> Regarding how to group content - I recall that we had considered adding 
>a "Grouping" object to the CDNI Metadata for this purpose exactly. Or are 
>we trying to avoid relying on metadata?

In the CDNI case, this might indeed be a route we could investigate, 
although I would prefer a method that also works for non-CDNI use cases.

Thanks,

Ray

On 14/11/14 15:55, "Matt Caulfield (mcaulfie)" <[email-masked]> wrote:

>Hi Ray,
>
>Could you explain in more detail the signaling mechanism that DASH 
>provides for the header-query-string method below? And why it might be 
>superior the Cookie method?
>
>Regarding how to group content - I recall that we had considered adding a 
>"Grouping" object to the CDNI Metadata for this purpose exactly. Or are 
>we trying to avoid relying on metadata?
>
>Thanks,
>Matt 
>
>> accepts no
>>which

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Sun, 16 Nov 2014 07:54:26 +0000

Hi Kevin,

Just to be clear, my primary concern is the ‘make URI signing work for HAS 
content’-use case. While it would be nice if the solution we come up with 
would also help other use cases, such as helping to prevent ad-skipping, I 
consider that a nice to have. 

Regarding your question: I don’t think we need URI-specific tokens. At 
least not in the sense that they apply to individual files. My proposal 
was to include in the segment URI (as communicated through the MPD), some 
form of identifier that allows the CDN to check whether the requested 
segment belongs to the group of segments that the UA has access to. The 
CDN will receive the request and extract the relevant information from the 
Request URL just as it does with some of the other attributes in the URI 
Signing draft. In most cases the group of segments that the UA has access 
to will consist of all segments belonging to the same content item. One 
way to encode this group would be using PatternMatch, another would be URI 
templates. In both cases, the CDN doesn’t have to be stateful or track any 
client-specific metrics. All the information it needs will be in the 
request URL. 

In the current uri-signing draft, the URI signing validation procedure 
broadly consists of the following steps:

1. Receive request, extract attributes from query string
2. Compute signature, check if signature matches that in URI. If signature 
doesn’t match reject request
3. Check Expiration Time Enforcement attribute (and possible Client IP)
4. If not expired, grant request and serve requested file

What I propose is to add a step 3b) "Check if PatternMatch/URI-Template 
attribute in Request URL matches requested URI. If not, reject request."

Thanks,

Ray

On 15/11/14 22:30, "Kevin Ma J" <[email-masked]> wrote:

>> >  Or are you proposing that the CDN generate new tokens, when it 
>>receives
>> >a request
>> >  The former has key distribution issues, but does not necessarily 
>>impact
>> >the CDN
>> >  The latter, however, could require a certain amount of statefulness 
>>or
>> >intelligence
>>R.
>> >>(Ray)
>> >> initially redirected to the CDN, e.g. for the initial manifest 
>>request,
>> >>it
>> >> it into the URL query string of the next segment request (as 
>>indicated
>> >>by
>> >> possibility of adding a segment-pattern enforcement attribute. This 
>>way
>> >>it
>> >> >>At that level it seems very similar to a CDN authorisation token 
>>and
>> >>so
>> >> >>use case(s) and how they envision the "call flow" working it is 
>>hard
>> >>to
>> >> >>say more.
>> >> >>
>>accepts
>> >>no
>> >> >liability for the content of this e-mail, for the manner in which 
>>you
>> >>use

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Mon, 17 Nov 2014 05:46:19 +0000

Hi Ray,

Thanks for the response, please see below.

Matt

> Sent: Sunday, November 16, 2014 2:37 AM
> To: Matt Caulfield (mcaulfie); Ben Niven-Jenkins; Francois Le Faucheur
> (flefauch)
> Cc: [email-masked]

Yes - but is there a standardized way to reference an HTTP header that was sent along with the MPD?

> method is that it only works for DASH clients, and not for standard HLS

In the case where the manifest is served by the Content Provider and the segments are served by the CDN, wouldn't the MPD need to contain absolute URLs? Meaning that segment URLs would go through regular request routing and URI signing?
 
> >> through a redirect from content provider to CDN and can therefore
> not
> >> be
> >> signed/validated.
> >>
> >> >>It seems to me that we may be able to help MPEG here and we
> may
> >> already
> >> >>require some small tweaks), but without more details from MPEG
> of
> >> their
> >> you use it and for damage of any kind resulting from the risks
> inherent
> >>to

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 17 Nov 2014 10:27:36 +0000

Hi Matt,

Please see inline.

Ray

-----Original Message-----
From: Matt Caulfield (mcaulfie) [mailto:[email-masked]] 
Sent: maandag 17 november 2014 6:46
To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins; Francois Le Faucheur (flefauch)
Cc: [email-masked]
Subject: RE: [CDNi] Liaison Statement on URI Signing for MPEG-DASH

Hi Ray,

Matt

> For all the details I will have to ask my colleague who attends MPEG, 
> but from what I understand, they have created a URL Parameter 
> Insertion mechanism that allows the MPD to specify to the Client which 
> values to insert at which locations in the URL (e.g.

[Ray] Currently, this is not part of the text. However, the good thing about working together with MPEG on this is that we can make sure that whatever client-side behavour is needed we can define together.

> Both have their pros and cons. The problem with the Cookie method is 
> that it doesn’t work when the manifest is served by the Content 
> Provider (which can be quite a common case). The problem with the 
> header-query-string method is that it only works for DASH clients, and 
> not for standard HLS clients.

[Ray] Yes, it would contain absolute URLs. It would be possible for the CSP to sign these URLs, however, that would mean signing them with an expiration time of at least the length of the content item. For an MPD of a 90min movie, that would mean expiration times of at least 90mins, which would reduce, if not negate altogether, the effectiveness of signing the URLs in the first place.

> >> The general solution direction we’ve been discussing is setting up 
> >>a sort  of authorization chain, from the initial request for the 
> >>manifest/MPD
> to
> >>request, it  receives some kind of token. It can then use this token 
> >>for the first  segment request, after which it receives a second 
> >>token for the
> second
> >> segment, and so on. By limiting the validity time of each token 
> >> using a method similar to that of the Expiry Time Enforcement 
> >> Attribute in
> the
> >> current URI signing draft, one can limit the vulnerability of the 
> >> UA handing out the token to other malicious UAs.
> >>
> >> One of the things we’ve been debating is what is the best way to 
> >> implement this token. Basically, we’ve explored two solutions for 
> >> this:
> >>
> >> and it is therefore not limited to DASH but also works for e.g. 
> >> HLS. The downside of this solution is that it doesn’t work if the 
> >> manifest is delivered out-of-band, e.g via the Content Provider.
> >> as a Set-Cookie header, it is returned to the UA as a another 
> >> custom HTTP header. The client then extracts the value of the HTTP 
> >> header and
> places
> >>indicated by  the MPD). MPEG DASH already provides the necessary 
> >>mechanisms
> for
> >> signalling this. The advantage of this mechanism is that it is 
> >>potentially  more flexible. The downside is that it requires changes 
> >>to the client and  will therefore only work for DASH clients.
> >>
> >> would be possible to for example signal that a specific token is 
> >> only valid for segments belonging to the same content item, or even 
> >> of a specific quality. The main question here is how to best signal 
> >> such a segment pattern. One possibility here is to use URI templates.
> >>
> >> Since this has turned into quite a lengthy mail, I think I’ll leave 
> >> some of the other questions for later.
> >>
> >> >The primary use case is to apply access control, as covered by the 
> >> >current URI signing draft, to segmented content. Due to the 
> >> >manifest/MPD,
> >> regular
> >> >URI signing as specified in our draft does not work, since there 
> >> >is no redirect involved. However, by adding some features to the 
> >> >current
> >> draft
> >> >Regarding preventing the client from skipping pre-roll ads, I 
> >> >think
> >>what
> >> >to reject certain requests based on a set of (signed) parameters 
> >> >in
> the
> >> >segments until a give (relative) point in time, thereby preventing 
> >> >the client from obtaining any contents segments until the pre-roll
> segments
> >> >I have had some off-list discussion with Kent on the merits of 
> >> >various solution directions during the past few months. I will 
> >> >share those in a mail to the list later today.
> >> >
> >> >Best regards,
> >> >
> >> >Ray
> >> >
> >> >
> >> >
> >> >>> Here is the pointer to the liaison statement from MPEG related 
> >> >>> to
> >> URI
> >> >>present something similar to a CDN authorisation token (the URI 
> >> >>signature in draft-ietf-cdni-uri-signing) and have the delivery 
> >> >>node (could be
> a
> >> >>server or a CDN, etc) take some action based on the presence and 
> >> >>validity of such a token.
> >> >>
> >> >>It is difficult to say more, as the actual use case is not clear 
> >> >>to
> >>me -
> >> >>applied to allow for other use cases, e.g. to prevent a client 
> >> >>from skipping pre-roll and mid-roll advertisement"
> >> >>
> >> >>implemented, as skipping adverts is a client function not a 
> >> >>server function AIUI.
> >> >>
> >> >>details on their use case so we can better assess the 
> >> >>re-usability
> >>(and
> >> >are not the addressee or if this message was sent to you by 
> >> >mistake,
> >> you
> >> >it and for damage of any kind resulting from the risks inherent to 
> >> This message may contain information that is not intended for you. 
> >>If you  are not the addressee or if this message was sent to you by 
> >>mistake,
> you
> >>accepts no liability for the content of this e-mail, for the manner 
> >>in which  you use it and for damage of any kind resulting from the 
> >>risks
> inherent
> >>to
> you are not the addressee or if this message was sent to you by 
> mistake, you are requested to inform the sender and delete the 
> message. TNO accepts no liability for the content of this e-mail, for 
> the manner in which you use it and for damage of any kind resulting 
> from the risks inherent to the electronic transmission of messages.

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Tue, 18 Nov 2014 21:16:40 +0000

> In the case where the manifest is served by the Content Provider and
> the segments are served by the CDN, wouldn't the MPD need to contain
> absolute URLs? Meaning that segment URLs would go through regular
> request routing and URI signing?
> 
> [Ray] Yes, it would contain absolute URLs. It would be possible for the
> CSP to sign these URLs, however, that would mean signing them with an
> expiration time of at least the length of the content item. For an MPD of
> a 90min movie, that would mean expiration times of at least 90mins,
> which would reduce, if not negate altogether, the effectiveness of
> signing the URLs in the first place.

My point is that if we have absolute URLs in the MPD, then every single segment request is going through the uCDN and can be validated using whatever non-standardized mechanism the uCDN / content provider cares to use. The uCDN / CP can handle access control in this scenario. The implication here is that we wouldn't need to worry about the case where the MPD is served by the uCDN and the segments are served by the dCDN and, therefore, could use the Cookie method.

Matt

> Sent: Monday, November 17, 2014 5:28 AM
> > >provides for the header-query-string method below? And why it
> might
> > be
> [Ray] Currently, this is not part of the text. However, the good thing
> about working together with MPEG on this is that we can make sure that
> whatever client-side behavour is needed we can define together.
> 
> >
> In the case where the manifest is served by the Content Provider and
> the segments are served by the CDN, wouldn't the MPD need to contain
> absolute URLs? Meaning that segment URLs would go through regular
> request routing and URI signing?
> 
> [Ray] Yes, it would contain absolute URLs. It would be possible for the
> CSP to sign these URLs, however, that would mean signing them with an
> expiration time of at least the length of the content item. For an MPD of
> a 90min movie, that would mean expiration times of at least 90mins,
> which would reduce, if not negate altogether, the effectiveness of
> signing the URLs in the first place.
> 
> >
> > >provides for the header-query-string method below? And why it
> might
> > be
> > >> manifest/MPD is used. Due to this manifest, content requests do
> not
> > go
> > >> >I’ve been part of some of the discussion in MPEG, and I
> understand
> > the
> > >> >On 13/11/14 02:36, "Ben Niven-Jenkins" <ben@niven-
> jenkins.co.uk>
> > >> wrote:
> > >> >
> > >> >>Francois, Colleagues,
> > >> >>
> > >> >>If I understand it correctly MPEG have a use case where they
> want
> > to
> > If

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 19 Nov 2014 14:35:22 +0000

On 18/11/14 21:16, "Matt Caulfield (mcaulfie)" <[email-masked]> wrote:

>My point is that if we have absolute URLs in the MPD, then every single 
>segment request is going through the uCDN and can be validated using 
>whatever non-standardized mechanism the uCDN / content provider cares to 
>use. The uCDN / CP can handle access control in this scenario. The 
>implication here is that we wouldn't need to worry about the case where 
>the MPD is served by the uCDN and the segments are served by the dCDN 
>and, therefore, could use the Cookie method.

I find it highly unlikely that CDNs will want to work in a scenario in 
which for every individual segment request, there will be a redirect 
between uCDN and dCDN. Remember that it is not uncommon to have segments 
of 3 seconds in length. One could argue that such segment-level redirects 
would almost negate the benefits of offloading to another CDN in the first 
place. 

Regarding the CSP-CDN case: even the Cisco CDN documentation explicitly 
says that using Cookies for out-of-band manifests is not recommended.

Ray

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Wed, 19 Nov 2014 16:25:04 +0000

> Sent: Wednesday, November 19, 2014 9:35 AM

Completely agree about avoiding a redirect for every segment. Based on your comment, I think I am missing something. I was assuming that the only (standard) way you could convince a DASH client to fetch the MPD from the uCDN and segments from the dCDN would be by using absolute URLs for the segments. Is there a way to accomplish this without absolute URLs?

Thanks,
Matt

> >> To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins; Francois Le
> Faucheur
> >> (flefauch)
> >> Cc: [email-masked]
> >> Yes - but is there a standardized way to reference an HTTP header
> that
> >> was sent along with the MPD?
> >>
> >> > >a "Grouping" object to the CDNI Metadata for this purpose
> exactly. Or
> >> > are
> >> > On 14/11/14 15:55, "Matt Caulfield (mcaulfie)"
> <[email-masked]>
> >> > wrote:
> >> >
> >> > >Hi Ray,
> >> > >
> >> > >"Grouping" object to the CDNI Metadata for this purpose exactly.
> Or
> >> > are
> >> > >> 1. Cookie-based. In this case the token is implemented as a
> cookie.
> >> > The
> >> > >> >(e.g signed cookies or chained requests), we might be able to
> have
> >> > the
> >> > >> >>I am struggling to understand how MPEG envision that use
> case
> >> > being
> >> > >> >>have something of use to them (or most of something that
> might
> >> > only

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 20 Nov 2014 09:43:30 +0000

Hi Matt,

> Completely agree about avoiding a redirect for every segment. Based on 
>your comment, I think I am missing something. I was assuming that the 
>only (standard) way you could convince a DASH client to fetch the MPD 
>from the uCDN and segments from the dCDN would be by using absolute URLs 
>for the segments. Is there a way to accomplish this without absolute URLs?

As long as the MPD is delivered from the uCDN and the segments from the 
dCDN, I don’t think there’s a problem (see also RFC6983). However, you 
bring up another interesting question. Is it even possible for CDNI to 
work effectively in the case where the MPD is delivered from the CSP? In 
that case, the CSP will have to rewrite the manifest to include the URLs 
in the dCDN. However, the CSP might not be aware of any dCDN. This sounds 
like a pretty fundamental problem. 

Ray

On 19/11/14 16:25, "Matt Caulfield (mcaulfie)" <[email-masked]> wrote:

>> >> expiration time of at least the length of the content item. For an 
>>MPD
>> >>of
>Completely agree about avoiding a redirect for every segment. Based on 
>your comment, I think I am missing something. I was assuming that the 
>only (standard) way you could convince a DASH client to fetch the MPD 
>from the uCDN and segments from the dCDN would be by using absolute URLs 
>for the segments. Is there a way to accomplish this without absolute URLs?
>
>Thanks,
>Matt
>
>> 
>> >> expiration time of at least the length of the content item. For an 
>>MPD
>> >>of
>> >> > >> As I mentioned in my previous mail, as authors of the URI 
>>signing
>> >> > draft,
>> >> > >> The main problem at hand is the fact that in both DASH as well 
>>as
>> >> > other
>> >> > >> 2. Header-query-string based. In this case, instead of sending 
>>the
>> >> > token
>> >> > >> What do you guys think? Is this a topic that we should be 
>>tackling
>> >> > >>at all?

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 20 Nov 2014 20:34:10 +0000

Hi Matt/Ray,

> > Completely agree about avoiding a redirect for every segment.

This would only apply to HTTP redirects?  A DNS-based approach might be ok?

> the CSP will have to rewrite the manifest to include the URLs
> in the dCDN.

Note: There may already be a proxy rewriting URLs for other reasons.

--  Kevin J. Ma

> Sent: Thursday, November 20, 2014 4:44 AM
Based on

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 20 Nov 2014 23:50:21 +0000

Ray,

I haven't caught up with the whole thread yet, but wanted to respond to a couple things you say below.

On 17 Nov 2014, at 10:27, Brandenburg, R. (Ray) van <[email-masked]> wrote:

>> From: Brandenburg, R. (Ray) van [mailto:[email-masked]]I don’t necessarily think this method is superior to the Cookie-method.
> [Ray] Yes, it would contain absolute URLs. It would be possible for the CSP to sign these URLs, however, that would mean signing them with an expiration time of at least the length of the content item.

Isn't that the same for the case where both the manifest & content is served by the dCDN? The Content Provider only gets one chance to sign a cookie in that case too?

I also don't understand why the Content Provider delivering the manifest and the dCDN delivering the content results in the Content Provider having to sign the individual URLs in the manifest.

AFAIK (I haven't tested it), the Content Provider can deliver the manifest from manifest.video.example.com and deliver the content via the uCDN/dCDN by using URLs pointing to chunks.video.example.com and share cookies across the domains by setting the token in a cookie with a Domain attribute of ".video.example.com".

Alternatively the Content Provider could use CORS to enable cookie sharing across domains.

> For an MPD of a 90min movie, that would mean expiration times of at least 90mins, which would reduce, if not negate altogether, the effectiveness of signing the URLs in the first place.

There are other approaches to avoid long expiration times, e.g defining the semantics of the token so that it expiration applies to TCP connection setup and so multiple requests are allowed on a persistent connection past the expiration time of the token. 

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 22 Nov 2014 18:35:40 +0000

Ray,

> URL, and the other is placed in the Set-Cookie field of a returned 200 OK. 

Agreed. In my mind both are authorisation tokens, the method they are presented differs (query string vs cookie) and the scope differs (single URL vs >1 URL).

Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 24 Nov 2014 08:29:18 +0000

Hi Ben,

Thanks for you thoughts.

On 20/11/14 23:50, "Ben Niven-Jenkins" <[email-masked]> wrote:

>>> From: Brandenburg, R. (Ray) van [mailto:[email-masked]]I 
>>>don’t necessarily think this method is superior to the Cookie-method.
>>expiration time of at least the length of the content item.
>
>Isn't that the same for the case where both the manifest & content is 
>served by the dCDN? The Content Provider only gets one chance to sign a 
>cookie in that case too?

The initial cookie yes. But the dCDN has the chance of 
refreshing/resigning the cookie every time a new request comes in. 

>
>I also don't understand why the Content Provider delivering the manifest 
>and the dCDN delivering the content results in the Content Provider 
>having to sign the individual URLs in the manifest.
>
>AFAIK (I haven't tested it), the Content Provider can deliver the 
>manifest from manifest.video.example.com and deliver the content via the 
>uCDN/dCDN by using URLs pointing to chunks.video.example.com and share 
>cookies across the domains by setting the token in a cookie with a Domain 
>attribute of ".video.example.com".

I believe most browser implementations reject cross-domain cookies, unless 
using CORS. 

>Alternatively the Content Provider could use CORS to enable cookie 

I haven’t thought of using CORS before. In theory I guess it should be 
possible. Do you have any idea on whether such a mechanism is used in 
practice by players/CDNs?

>
>> For an MPD of a 90min movie, that would mean expiration times of at 
>>least 90mins, which would reduce, if not negate altogether, the 
>>effectiveness of signing the URLs in the first place.
>
>There are other approaches to avoid long expiration times, e.g defining 
>the semantics of the token so that it expiration applies to TCP 
>connection setup and so multiple requests are allowed on a persistent 
>connection past the expiration time of the token. 

Hmm, yes, that would probably work, although it would give issues in case 
of dropped TCP connections. It does sound a bit like a cross-layer 
violation. Are you aware of any implementations that work like this?

Ray

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 30 Nov 2014 11:38:34 +0000

Ray,

See inline...

> refreshing/resigning the cookie every time a new request comes in. 

I'm struggling a little to get a picture of how you imagine this working?

If the dCDN is seeing a valid (token in a) cookie and then setting a new (token in a) cookie to effectively extend the validity of authorisation to access the content, it is not clear to me how that is in practice any different to setting a single cookie with a long expiration time.

Could you explain a bit what the difference are?

> I believe most browser implementations reject cross-domain cookies, unless 

What I described are not really cross-domain cookies, the situation I describe above is allowed by RFC6265 for instance and is not the same as say manifest.bar.com trying to set a cookie for chunks.foo.com

Having said that I have no idea whether browsers typically have a stricter policy than specified in RFC6265 but I have seen references on various help websites (e.g. stack overflow) suggesting what I describe above as being allowed by browsers.

> practice by players/CDNs?

We have customers that use CORS as part of their video services/players (where we are the CDN) but I am not in a position to share many details. I have seen CORS used to deliver video to Chromecast devices.

> violation. Are you aware of any implementations that work like this?

I am not aware of any implementations that work like that.

Another way to minimise the possible exposure of a long expiration time would be to "lock" the token to the client's IP address, although that is not perfect in all cases either.

Ben