Subject: Re: [CDNi] New Liaison Statement, "Liaison Statement to IETF on URI signing"

From: Kevin Ma J <[email-masked]>
Date: Thu, 10 Dec 2015 18:56:25 +0000

Hi Ben/All,

  (as a chair) I was preparing a liaison response and going back through the list discussions, and (as an individual) I had a clarifying question about the token refresh (which is now only part of Ray's individual draft):

> With a token that changes after a variable number of segments, the CDN now needs to keep state about how many times it has seen the token already and needs to co-ordinate that state across the CDN in case some of the requests go to different surrogates, etc.

  When we say "state" here, are we talking about session state?  Would it need anything more than a new metadata variable that says "the CDN SHOULD only generate a new token if the current token is less than X seconds away from expiring", where X is an integer value conveyed in the metadata?

  And wrt notifying the client of the value of X, I think that would be out-of-scope for CDNI?

thanx!

--  Kevin J. Ma

From: CDNi [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Wednesday, November 04, 2015 1:12 PM
To: c^
Cc: Content Delivery Networks Interconnection Discussion List; Watanabe Shinji
Subject: Re: [CDNi] New Liaison Statement, "Liaison Statement to IETF on URI signing"

Craig,

On 3 Nov 2015, at 12:21, c^ <[email-masked]<mailto:[email-masked]>> wrote:

Cookie use also creates other dependencies when using MSE such as crossdomain/CORS which can be problematic in certain deployments.
Query string based is more portable...
But not without its own set of issues. There is no single answer here IMO. BTW I wasn’t trying to suggest that MPEG avoid query parameters and use cookies instead but to ponder whether they’d considered cookies as part of the solution space as if it was considered and discounted I’d be interested in what led to that choice.

WRT generating tokens being 'cheap'; consider the flash crowds associated with news events on live streams. Token generation in these circumstance is very different to the moderate peak:mean in on-demand video workflows.
Sure but such flash crowds put stress on the whole delivery chain and I highly suspect that the overhead of generating tokens will not be the weakest link that causes a flash crowd to impact a streaming service.

The trade off being an extended time limited token being 'good enough'…
That was part of my point. If one has the option to create a long lived single token and one has the option to chain tokens on each request then I’m struggling to understand what benefit there is to having a third option that is somewhere in the middle.

I can go into some of these considerations further off list…
I’d certainly be interested in discussing this stuff more either on or off list.

Ben

CraigT
--
c%5e
On 3 Nov 2015 20:20, "Ben Niven-Jenkins" <[email-masked]<mailto:[email-masked]>> wrote:
Ray,

I wouldn't signal to the CDN whether it should expect the token in a cookie or a query param, if it was me I'd spec it so the CDN has to support both and a rule for which of cookie or query param to use if both are present.

Ben

> On 3 Nov 2015, at 08:58, Brandenburg, R. (Ray) van <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi all,
>
> I've added my comments below.
>
> Ray
>
>
>
>> On 03/11/15 08:53, "CDNi on behalf of Ben Niven-Jenkins" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>>
>> Colleagues,
>>
>> My 2p (¥3.7) inline
>>
>>
>>> On 3 Nov 2015, at 04:12, Liaison Statement Management Tool <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Title: Liaison Statement to IETF on URI signing
>>>
>>> Body: At the 113th MPEG meeting MPEG experts took note of the new draft "URI Signing for HTTP Adaptive Streaming". This document specifically addresses the use case of segmented content in the context of URI Signing. MPEG experts progressed regarding the integration of URI Signing extension for segmented content in MPEG DASH. In discussion we had several comments and observations that MPEG experts would like to share with the IETF CDNI working group. MPEG welcome comments and feedback on the reported progress.
>>>
>>> Integrated workflow
>>> MPEG experts reached consensus on recommending the following steps for the integration of URI Signing extension for segmented content and client authentication and authorisation scheme (Example of such a scheme is the Online Multimedia Authorization Protocol (OMAP) publicly available online).
>>>
>>> 1.    The service provider choses a given client authentication and authorisation scheme to protect the access to the MPD. The application around the DASH client takes care of implementing the protocol in order to successfully receive the MPD.
>>> 2.    The initial segment access token is provided either in the HTTP response of the MPD or within the MPD itself.
>>> 3.    The MPD contains appropriate instructions which signal to the DASH client where the segment access token must be extracted from, e.g. either from HTTP header of segment responses. In addition, this signalling instructs the DASH client to insert this segment token back in segment requests as a query string parameter. Note that MPEG included this generic mechanism of transparent parameter passing in an ongoing amendment of MPEG DASH part 1. This document should reach publication in the course of 2016.
>>
>> I wonder if MPEG also considered setting the token in a cookie, e.g. on the MPD response? For the situations where it works* it’s a better option than query parameters IMO and means the client doesn’t have to do anything special to have the token inserted on every request as the HTTP stack will do that as part of HTTP.
>>
>> *cookies don’t work in all environments, e.g. blockers on browsers or clients where the player has an independent cookie jar to the rest of the app/browser but if you’re going to do something like insert the token into the request using special client handling anyway, you could do the same for a cookie and have the benefit of only having to do it once rather than once per segment.
>
> Agreed.
>
> My feeling is you'd want both a cookie-based as well as a query parameter-based solution. The cookie-based version for legacy clients, and a query-based version in cases where cookie's don't work. In the uri-signing-for-HAS draft I've added a flag to allow the CDN/CSP to communicate which mechanism should be applied.
>
>>
>>> 4.    The segment access token is not meant to be validated by the authorization provider but solely by the CDN to guarantee an easily scalable and stateless validation. To this end, MPEG experts acknowledged the need of a parameter functionally equivalent to the Path Pattern defined in the URI Signing for HTTP Adaptive Streaming. As a result, the URI Signing for HTTP Adaptive Streaming seems to fulfil the identified requirements and will be considered for further work.
>>>
>>>
>>> Furthermore, here are comments from MPEG experts on the URI Signing for HTTP Adaptive Streaming draft.
>>>
>>> Long-term tokens (into sentences)
>>> Some DASH services may use long-term tokens to request segments, where long-term typically means couple of hours to several days. In this scenario, additional tokens (not URI Signed Token) are sent along to enforce client authentication. As a result, refreshing the URI Signed Token at every request may seem superfluous. MPEG experts would like to know the opinion of the IETF CDNI working group on this scenario and whether the validation mechanism could be adapted, e.g. by signalling when the CDN must regenerate a new URI Signed Token.
>>
>> A single token can be given a long expiry time so I’m not completely certain what the MPEG use case is. That provides a long time in which a token could be passed to someone else, which drove the idea of changing the token from the CDN side on every segment which reduces the exposure time to the minimum possible. It seems that what MPEG is asking for is the ability to tune the exposure time.
>>
>> IMO it sounds a nice knob to have in theory, but I’m wondering why someone would actually tune it in practice. Generating tokens is pretty cheap, it’s basically a single call to a SHA hash function. I think it also increases the implementation complexity significantly. With a long use single token or with re-writing the token on every segment the CDN can process each request independently. With a token that changes after a variable number of segments, the CDN now needs to keep state about how many times it has seen the token already and needs to co-ordinate that state across the CDN in case some of the requests go to different surrogates, etc.
>>
>> It sounds like a lot of complexity for little real benefit IMO.
>
> Fully agree.
>
> (One way to implement it would be to have some sort of Expiration Time Threshold to indicate when the CDN should refresh the token, but that would result in all kinds of issues, such as effectively having variable token lengths which will cause issues in cases of prolonged pause)
>
>>
>>> Name collision
>>> MPEG experts understand that the name URISigningPackage, as a query string, as an HTTP header parameter or in a cookie, constitutes a normative aspect of the URI Signing specification. MPEG experts would like to know whether the IETF CDNI working group has decided the appropriate approach to prevent name collision.
>
> The current base URI signing spec already allows overriding the URISigningPackage query string parameter based on e.g. Metadata. In case of DASH, and clients having to know this name, I think the best solution would be to just convey it in the MPD.
>
>>>
>>> Consecutive tokens
>>> According to the URI Signing for HTTP Adaptive Streaming draft, the server may issue multiple tokens and delivered them in consecutive HTTP requests. It does not seem that there is a dependency between the tokens. Could IETF expert confirm that a token issued at time t does not invalidate a token issued prior to time t ?
>>
>> In the 3 token implementations I am familiar with tokens are completely independent and a token issued at time t does not invalidate a token issued prior to time t.
>
> Agreed. Apart from having to keep and synchronise state across nodes, I don't see how you could even implement it.
>
>>
>> Ben
>>
>>>
>>>
>>> MPEG kindly asks the IETF CDNI working group to consider the above observations and welcome further collaboration on this topic.
>>>
>>>
>>>
>>> Our future meetings:
>>> -    DASH Ad-hoc meetings, 21 February 2016, San Diego, CA
>>> -    The 114th MPEG meeting, 22 - 26 February 2016, San Diego, CA
>>>
>>>
>>> Attachments:
>>>
>>>  29n153811
>>>  https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-1.doc
>>>
>>>  29n153811 htm
>>>  https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-2.htm
>>>
>>> _______________________________________________
>>> CDNi mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/cdni
>>
>> _______________________________________________
>> CDNi mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/cdni
> 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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 14 Dec 2015 16:58:06 +0000

Hi Kevin,

> On 10 Dec 2015, at 18:56, Kevin Ma J <[email-masked]> wrote:
> 
> Hi Ben/All,
>  
>   When we say "state" here, are we talking about session state?

I’m not sure if it would count as session state. If a CDN needs to know how many times it has seen a token, it needs to store information across requests (count of times it has seen the token). It’s that storage of information across requests that I mean by state.

>   Would it need anything more than a new metadata variable that says "the CDN SHOULD only generate a new token if the current token is less than X seconds away from expiring", where X is an integer value conveyed in the metadata?

That would remove the need to maintain state but might introduce other effects depending on the use case, e.g. if X is too short maybe the token expires before the client presents it to the CDN again.

I’m sure it could be made to work if X was selected with care but I’m still unconvinced of how much it is really needed, i.e. how many use cases require the CDN to refresh the token periodically but where a period of “every request” would be detrimental/a perceivable overhead?
 
>   And wrt notifying the client of the value of X, I think that would be out-of-scope for CDNI?

I’d assume the client doesn’t need to know the value of X, it just makes requests like it would normally does it not?

Ben

> On 3 Nov 2015, at 12:21, c^ <[email-masked] <mailto:[email-masked]>> wrote:
>  
> On 3 Nov 2015 20:20, "Ben Niven-Jenkins" <[email-masked] <mailto:[email-masked]>> wrote:
> Ray,
> 
> > On 3 Nov 2015, at 08:58, Brandenburg, R. (Ray) van <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi all,
> >
> >> On 03/11/15 08:53, "CDNi on behalf of Ben Niven-Jenkins" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Colleagues,
> >>
> >> My 2p (¥3.7) inline
> >>
> >>
> >>> On 3 Nov 2015, at 04:12, Liaison Statement Management Tool <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>>  https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-1.doc <https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-1.doc>
> >>>
> >>>  29n153811 htm
> >>>  https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-2.htm <https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-2.htm>
> >>>
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/cdni <https://www.ietf.org/mailman/listinfo/cdni>
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/cdni <https://www.ietf.org/mailman/listinfo/cdni>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cdni <https://www.ietf.org/mailman/listinfo/cdni>

---

From: Kevin Ma J <[email-masked]>
Date: Mon, 14 Dec 2015 17:21:28 +0000

Hi Ben,

> I’m sure it could be made to work if X was selected with care but I’m still unconvinced of how much it is really needed, i.e. how many use cases require the CDN to refresh the token periodically bu…

  I agree with you about both needing to tune X, and not necessarily needing delayed token regeneration; I was just considering the alternative to maintaining state.

> I’d assume the client doesn’t need to know the value of X, it just makes requests like it would normally does it not?

  Ray had brought up the use case of a long pause, during which I assume there was to be some type of background process that does HEAD/Range requests to periodically get a new token.  Personally, I don't think this is a strong use case, but regardless, the interface between client and CDN/CSP is out-of-scope for CDNI, so I don't see us specifying a way to convey that information.

thanx!

--  Kevin J. Ma

From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Monday, December 14, 2015 11:58 AM
To: Kevin Ma J
Cc: c^; Content Delivery Networks Interconnection Discussion List; Watanabe Shinji
Subject: Re: [CDNi] New Liaison Statement, "Liaison Statement to IETF on URI signing"

Hi Kevin,

On 10 Dec 2015, at 18:56, Kevin Ma J <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ben/All,

Ben

thanx!

--  Kevin J. Ma

Craig,

Ben

CraigT

Ben