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

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 7 Jan 2015 23:54:28 +0000

Hi Ray. Is it possible to summarize the conclusion of this discussion if any consensus was reached? I'd like to see if we need to make any edits for the next version of the draft. Thanks!

Kent

-----Original Message-----
From: CDNi [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Tuesday, December 02, 2014 4:58 AM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] Liaison Statement on URI Signing for MPEG-DASH

Hi Ben,

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: zondag 30 november 2014 12:39
To: Brandenburg, R. (Ray) van
Cc: Matt Caulfield (mcaulfie); Francois Le Faucher; [email-masked]
Subject: Re: [CDNi] Liaison Statement on URI Signing for MPEG-DASH

Ray,

See inline...

On 24 Nov 2014, at 08:29, Brandenburg, R. (Ray) van <[email-masked]> wrote:

> On 20/11/14 23:50, "Ben Niven-Jenkins" <[email-masked]> wrote:
> 
>> 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: Matt Caulfield (mcaulfie) [mailto:[email-masked]]
>>>> From: Brandenburg, R. (Ray) van [mailto:[email-masked]]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.
>>> 
>>> 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.
>> 
>> 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'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?

[Ray] The assumption is that a cookie that is only valid for e.g. 30 seconds before it has to be refreshed is inherently safer than one that is valid for 90 minutes. Let me put it differently: if you have a token that is valid for 90 minutes (or possibly more) what is the purpose of having a token at all? If you look at URI Signing from a broader perspective, not just at HAS content, is it really that much more difficult to share the deep-link to the CDN that sharing the deep-link to the CDN in combination with the Cookie? 

>> 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.

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.

[Ray] Agree, as long as it is the same domain. However, in the typical CSP-CDN scenario, you're talking about different domains. 

>> Alternatively the Content Provider could use CORS to enable cookie 
>> sharing across domains.
> 
> 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?

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.

[Ray] Ok. That's good news. So I guess using CORS to set cross-domain cookies would be possible. 

Ray

>>> 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?

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

> 
> Ray
> 
>> 
>> Ben
> 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.

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

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 20 Jan 2015 10:34:14 +0000

Hi,

Thanks all for the feedback and discussions. Let me try to summarize what was discussed.

We seem to agree that it is worthwhile to consider the request from MPEG.
We seem to agree that we should focus on the access control use case. The ad skipping use case from MPEG is of secondary importance and we first need some more information from MPEG on that. 
We prefer a solution that is not necessarily limited to DASH, and would also work for other adaptive streaming mechanisms (e.g. HLS). 

We discussed two possible solutions for conveying information between requests: cookie-based and header-query-string based. The advantage of a cookie-based solution is that we don't need to change anything in the client. Using CORS it would even work in cases where the MPD is delivered by the CSP. The only downside is that all segments need to be delivered by the same domain (which is known a-priori). The header-query-string method is considerably more complex. The advantage is that it is potentially more flexible, but at the cost of being limited to DASH clients. 

At this point, I think consensus is that we prefer the cookie method, while the header-query-string method might at best be an optional feature that we could include to handle more advanced cases. Does anybody disagree with that statement?

What we didn't discuss yet in any detail is the type of information that needs to be carried inside the cookie (or header), to allow the (d)CDN to determine whether the requested segment falls within the allowed set of segments. 

At this point, I would be interested to hear your opinion on whether you think we need to tackle the problem of URI Signing for HAS within the current draft-ietf-cdni-uri-signing, or whether we need to create a separate draft for this. On this aspect, I would like to note that I consider having a standardized mechanism for URI Signing to also be useful outside the scope of CDNI, where it could be beneficial for regular CDN applications as well.

Best regards,

Ray

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: donderdag 8 januari 2015 0:54
To: Brandenburg, R. (Ray) van; Ben Niven-Jenkins
Cc: [email-masked]
Subject: RE: [CDNi] Liaison Statement on URI Signing for MPEG-DASH

Kent

-----Original Message-----
From: CDNi [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Tuesday, December 02, 2014 4:58 AM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] Liaison Statement on URI Signing for MPEG-DASH

Hi Ben,

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: zondag 30 november 2014 12:39
To: Brandenburg, R. (Ray) van
Cc: Matt Caulfield (mcaulfie); Francois Le Faucher; [email-masked]
Subject: Re: [CDNi] Liaison Statement on URI Signing for MPEG-DASH

Ray,

See inline...

Ray

Ben