Re: [CDNi] New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has

["Brandenburg, R. (Ray) van" <[e-mail]>]

Hi Kevin,

> The only purpose for the STT, then, is to tell the server the preferred conveyance for subsequent tokens, in the case that it doesn't match the conveyance in the request?  But that is already dictated in section 5?

Correct. The main reason I added STT was for future extensibility. Imagine another document would specify a different transport mechanism (e.g. a DASH-specific one) with STT=2. That document might still use the cross-domain redirection mechanism specified in 5.2 or something similar. In that case, when the CDN receives an incoming Signed Token, it needs to know whether to send it as a Cookie (STT=1), or via some other mechanism (STT=2). I guess you’re right that since the new document would override/update/extend section 5/6, STT doesn’t necessarily need to be defined by draft-brandenburg-cdni-for-has, but could be defined by this new document.

Ray

From: "[e-mail]" <[e-mail]>
Date: Friday 8 July 2016 at 22:53
To: Ray van Brandenburg <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has

Hi Ray,

> New STT values are expected to update sections 5 and 6. The reason the STT value is made explicit in the token as well is to allow implementations that have received the Token in some other fashion (e.g. through the cross-domain redirection scenario in section 5.2), to be aware of the target transport mechanism.

I guess by issue is that: in order to read the STT value in the token, the server would need to have already found the token via the process in section 6.  In the non-cross-domain case, the server should just use whatever conveyance was used in the request (query string, uri path, cookie, etc.)?  The only purpose for the STT, then, is to tell the server the preferred conveyance for subsequent tokens, in the case that it doesn't match the conveyance in the request?  But that is already dictated in section 5?  If section 5 says use a cookie, unless you're redirecting, then use query string (or uri path), then we don't really need STT?

thanx.

--  Kevin J. Ma


From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
Sent: Friday, July 08, 2016 8:24 AM
To: Kevin Ma J; [e-mail]
Subject: Re: New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has

Hi Kevin,

Thanks for the review! Please see my comments inline.

Ray

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday 5 July 2016 at 23:43
To: Ray van Brandenburg <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has

Hi Ray,

  (As an individual) I finally found some time to read through the updated draft.  Some comments and questions below.

thanx!

--  Kevin J. Ma

- section 4.1, step 3.E: What if the user pauses, or there is an ad inserted, and the token expires?  Understood that it's probably up to the media player to handle that case, but would they need to go back to the CP to get a new valid manifest URL?  Which would have a token that is valid for the chunks as well?

It’s up to the media player to make sure it refreshes the token, either before or after it (although the former might be easier). On way to do that would be to send an HTTP HEAD request for an arbitrary segment to the CDN. Note that this does assume that the media player is aware of the approximate validity time of a token. In practice this is something that could be communicated in a manifest file, such as a DASH MPD. It’s one of the topics for which it might be worth considering sending in a liaison to MPEG, if the WG should decide to adopt this work.

What I would like to do in a next iteration of this document is to add a sentence along the lines of ‘Upon receiving an HTTP HEAD request, a CDN SHOULD validate the incoming Signed Token and generate a new one in the same way as it would do for an HTTP GET’.

- section 4.1, steps 9, 11.B, 11.E, 12.B, and 12.F, section 7.1 step 1, section 7.2 steps 3.A.d and 3.B.d, and section 7.4 steps 10.A.2, 10.A.5, 10.B.2, and 10.B.6: Should the UPC be percent-encoded?  And should CIP be encrypted?

Correct. This version of draft-brandenburg-cdni-uri-signing-for-has hasn’t yet been brought in line with the most recent version of draft-ietf-cdni-uri-signing, where percent-encoding of the UPC was introduced. In the same way, CIP should be encrypted. I’ll fix this in the next iteration.

- section 4.1, steps 9, 11.B, 11.E, 12.B, 12.F, section 5.2, and section 7.1 step 1: If the token is only good for segments, but is attached to the manifest request, does that mean that there is no signature validation on the manifest request?  In the 2xx non-redirect case, would you expect a v1 manifest signature be in the query string and a separate v2 chunk signature be in the cookie?

Maybe the document should be clearer on this. My intention was that Signed Tokens should be used for both manifest and segment requests, especially given that the 200 OK for the initial manifest will contain the first Signed Token. In other words, the UPC should be chosen in a way that both the manifest location and the segment location is covered by the UPC.

- section 4.1, step 10, sections 5/6, and section 7.4 step 9: Seems like a chicken and egg problem.  The STT says that the token is in the cookie, but the STT is in the token that's inside the cookie.  Does the initial token always have to be in a token?  Should the initial token always be in the query string to be compatible with v1, since the VER=2 is also inside the token inside the cookie?  From the client perspective, should only subsequent tokens be in the cookie?  From the CDN perspective, unless passed in the metadata, how will the CDN know where to look for the token, or does it always check everywhere?  If the process is to always check the query string first and the cookie second, do we even need STT?  New STT values are going to require and update to the procedure in section 6, as well as registration of new STT values?

New STT values are expected to update sections 5 and 6. The reason the STT value is made explicit in the token as well is to allow implementations that have received the Token in some other fashion (e.g. through the cross-domain redirection scenario in section 5.2), to be aware of the target transport mechanism.

- section 5.2: The v1 draft also supports token as a path parameter; is that intentionally omitted here?

The primary reason it’s not here is that this draft predates the latest version of draft-ietf-cdni-uri-signing where support for path parmeter was introduced. However, I need to give it some thought whether it makes sense to support that scenario here as well, given that the main reason for using path parameters in v1 would be cases where you don’t have segment-level authentication as defined in this draft.


- section 7.1 steps 2 and 3: I would expect that v2 would have a new GenericMetadata ptype (MI.UriSigning.v2?) and that ptype would tell the dCDN what it should expect in the token?  It would be nice if the draft could define v2 such that it supported both VER=1 and VER=2, so that the MI.UriSigning.v2 metadata could be a superset of information needed to process all known token types, and make the token processing a runtime decision?

I like that. I need to delve into the Metadata aspects of v1 again to see exactly how we could achieve such a thing. Maybe something to discuss in Berlin.

- section 7.4, general: This draft removes the "Note that re-signing a URI MUST..." text from the v1 draft(section 3.1).  Since this is about resigning, I think the text about maintaning the same values should be added here, specifically for KID/KID_NUM, HMAC, and DSA.

Good point.


- Do you have an idea as to what additional registries, metadata, and/or logging fields will be needed?  Will the new ptype just be MI.UriSigning.v2?

To be completely honest, I haven’t given the Metadata aspects a lot of thought yet. I’ll come back to you on that one.

Thanks again!

Ray


From: CDNi [mailto:[e-mail]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Friday, June 10, 2016 11:34 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [CDNi] New version (and IPR statement) of draft-brandenburg-cdni-uri-signing-for-has

Hi all,

As you might have seen, I’ve recently uploaded a new version of draft-brandenburg-cdni-uri-signing-for-has (-03).

https://tools.ietf.org/html/draft-brandenburg-cdni-uri-signing-for-has-03

What is important to note is that KPN has updated it’s IPR statement on this document to be in line with the IPR statements that have been filed on other CDNI documents (i.e. “Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers”). Hopefully this clears up the lengthy IPR discussion we’ve been having around this document so that we can focus on the technical aspects again.

Looking forward to your feedback,
Ray

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.