search

moq-wg / moq-transport

draft-ietf-moq-transport
Other
87 stars 22 forks source link

relay modifying payload #216

Closed gwendalsimon closed 9 months ago

gwendalsimon commented 1 year ago

Line 234 and line 598: “A relay MUST NOT combine, split, or otherwise modify object payloads.” I would argue against this statement. It is sometimes a good idea to let the edge (relay) modify the payload of the object. For example, it is possible to embed a watermark on the video content at the edge by applying some slight changes on the (compressed and encrypted) payload. More generally edge processing can preserve the scalability (only one version of the object is sent to the relay) while enabling personalization.

Besides, the formulation at Line 773 “payload SHOULD NOT be processed by a relay” is not consistent. Imho it would be a better formulation.

hardie commented 1 year ago

Hi Gwendal,

Note that the proposed action will not work if the relay does not have the keys for the object and that this use case is specified in the charter:

Media content may be end-to-end encrypted in certain use cases, where the "end-to-end" keys are available to media sources and consumers, but not relays.

On Tue, Jun 20, 2023 at 7:37 AM Gwendal Simon @.***> wrote:

Line 234 and line 598: “A relay MUST NOT combine, split, or otherwise modify object payloads.” I would argue against this statement. It is sometimes a good idea to let the edge (relay) modify the payload of the object. For example, it is possible to embed a watermark on the video content at the edge by applying some slight changes on the (compressed and encrypted) payload. More generally edge processing can preserve the scalability (only one version of the object is sent to the relay) while enabling personalization.

Besides, the formulation at Line 773 “payload SHOULD NOT be processed by a relay” is not consistent. Imho it would be a better formulation.

— Reply to this email directly, view it on GitHub https://github.com/moq-wg/moq-transport/issues/216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKVXZET4RHGPDSCYES7IQDXMFAKPANCNFSM6AAAAAAZMZOHSI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

gwendalsimon commented 1 year ago

Hi Hardie,

It is possible to modify the payload even if the relay does not have the encryption keys.

For example, in edge-embedded watermark (which applies to DASH/HLS today but it could apply on MoQ as well in the future), some metadata are produced in the video headend to indicate which bytes of the payload should be modified. This metadata takes into account the encryption. The relay extracts the metadata and modifies the payload without decrypting/re-encrypting the content.

More generally, it is up to the relay to not introduce mess in the content. I don't really understand why we would need to specifically forbid any action on the payload in MoQ.

wilaw commented 1 year ago

I'm actually coming around to agreeing with Gendal on this one. The normative statement that "A relay MUST NOT combine, split, or otherwise modify object payloads." was derived from a desire to ensure that relays in 3rd party network could be trusted to transmit but not modify the content. This trust enables reliable scale through CDNs, which was the feature that the authors were seeking. However there are use-cases in which a content distributor may legitimately want a trusted relay network to modify or substitute the content on their behalf - watermarking and per-session encryption being two of them.

Since these features a critical to modern media delivery, we need to allow for them in moq-transport. Therefore we should relax the normative relay requirement to one of these two options:

A relay MUST NOT combine, split, or otherwise modify object payloads unless it is executing a distribution function on behalf of the content distributor.

or

A relay SHOULD NOT combine, split, or otherwise modify object payloads.

hardie commented 1 year ago

On Thu, Jun 22, 2023 at 10:41 PM Will Law @.***> wrote:

I'm actually coming around to agreeing with Gendal on this one. The normative statement that "A relay MUST NOT combine, split, or otherwise modify object payloads." was derived from a desire to ensure that relays in 3rd party network could be trusted to transmit but not modify the content. This trust enables reliable scale through CDNs, which was the feature that the authors were seeking. However there are use-cases in which a content distributor may legitimately want a trusted relay network to modify or substitute the content on their behalf - watermarking and per-session encryption being two of them.

Since these features a critical to modern media delivery, we need to allow for them in moq-transport. Therefore we should relax the normative relay requirement to one of these two options:

A relay MUST NOT combine, split, or otherwise modify object payloads unless it is executing a distribution function on behalf of the content distributor.

Individual contributor hat on:

I don't think this makes a sufficient distinction--any relay is "executing a distribution function on behalf of the content distributor".

As we have discussed before, there are different types of intermediaries. From my perspective the range is from "relay" which is about what it says on the tin (sending things along) to back-to-back client/origin gateways (which have one "side" which are clients that have media keys and use that status to produce transformations, thus becoming new origins on the other "side"). For anything between the two (without the media keys but with a transformation function), I think we have to define the functionality both in terms of requirements (and I don't see anything in draft-ietf-moq-requirements at the moment) and, eventually, as on the wire capabilities. The business arrangements which lead to them are at different layer (8, if I remember the t-shirt).

As an example, it looks to me like per-session encryption from client to intermediary is going to come by default from using QUIC; if you have some other requirements for that encryption, I think we need more than a modification of this text to justify it.

Chair hat on:

Attempting to permit protocol behavior with reference to business arrangements not visible in the protocol has not been a wild success in IETF contexts in the past, and the chances that any such design will attract objections from the IETF security review teams seems to me very high. If the working group decides to go down that path, I will suggest that we get an early security review so that we avoid a late surprise on a design point of this magnitude.

Ted

or

A relay SHOULD NOT combine, split, or otherwise modify object payloads.

— Reply to this email directly, view it on GitHub https://github.com/moq-wg/moq-transport/issues/216#issuecomment-1603351716, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKVXZHMEZJXDWBMAOSEVPLXMS3YPANCNFSM6AAAAAAZMZOHSI . You are receiving this because you commented.Message ID: @.***>

wilaw commented 1 year ago

As an example, it looks to me like per-session encryption from client to intermediary is going to come by default from using QUIC; if you have some other requirements for that encryption, I think we need more than a modification of this text to justify it.

By per-session encryption, I meant an edge relay dynamically applying DRM to clear media segments as it delivers them to a client, using a key that is unique to that particular client. This is a common feature of some HTTP CDNs today. This payload encryption is quite distinct from the transport layer encryption afforded by QUIC.

VMatrix1900 commented 1 year ago

I agree with Ted. The relay as a function does not process the media payload. But it can be co-located with other media-payload-aware processing function(client/producer/transcoder). For example, a CDN node can implement both the relay(media-payload-agnostic forward) function and producer(media-payload-aware processing) function.

kixelated commented 1 year ago

My mental model is that MoQ relays are like QUIC middleboxes. A "relay" MUST NOT combine/split/modify the payloads, much like a router MUST NOT combine/split/modify QUIC packets.

The rationale is that OBJECT boundaries can have semantic meaning to the application. An obvious example is that an application may decide that each frame is an OBJECT. This will break if a relay changes how OBJECTs are fragmented, much like how QUIC will break (short header) if a router decides to split/concatenate UDP packets. And of course, a relay can cause havok if it decides to modify any bytes.

Of course, we must support transcoding and transmuxing that works in conjunction with the application. We could come up with a new name for this processor, but I think it makes more sense to think in terms of layers. It's the difference between a L3 load balancer and an L7 load balancer.

My video and chat application could run on Akamai. By default it would use moq-transport mode, where all OBJECTs are transferred unaltered. I could optionally opt-into on a moq-warp mode and have Akamai add a watermark, although the chat tracks are still in moq-transport mode and MUST NOT be modified.

gwendalsimon commented 1 year ago

Would it be possible to distinguish between

To be honest, I don't see how we can define it...

Yet, in practice, it is often the case that the publisher (or producer) owns not only the origin (QUIC Server) but also the Relay (directly or indirectly). Forcing all relays to be passive brings a restriction to various (present and future) optimizations. It would lead a publisher to implement two separate client-server MoQ sessions (client-relay and relay-origin) just for implementing a simple edge-embedding watermark.

Do you have any strong motivation for forcing all relays to be definitively passive? What if the draft simply omits these sentences?

hardie commented 1 year ago

Hi Gwendal

In my personal opinion, the passive terminology isn't helpful. I think Luke's point is that there are middleboxes that act at the "MoQ transport" layer and they are limited to passing the bits as they get them; we call them relays because that's what the verb "relay" means. You could call them exploders, distribution nodes, or something else as well. Those don't need a lot of coordination with the node creating the objects (there could be several layers of relay between the origin and the one we're currently dealing with)

There are other middleboxes with other roles, but those require more coordination with the publisher. Those middleboxes need more coordination; a middlebox that adds an AI-generated closed caption will need the audio media key, for example.

I don't think anyone is saying that there can't be middleboxes which add watermarks; we're saying that they are not transport relays.

On Wed, Jun 28, 2023 at 10:21 PM Gwendal Simon @.***> wrote:

Would it be possible to distinguish between

  • a "passive relay": who MUST NOT modify object payload, i.e. media-payload-agnostic forward (from @VMatrix19000), i.e. who is a moq-transport relay (from @kixelated https://github.com/kixelated)
  • an "active relay": who MAY modify object payload, i.e. media-payload-aware forward, a moq-warp relay

To be honest, I don't see how we can define it...

Yet, in practice, it is often the case that the publisher (or producer) owns not only the origin (QUIC Server) but also the Relay (directly or indirectly). Forcing all relays to be passive brings a restriction to various (present and future) optimizations. It would lead a publisher to implement two separate client-server MoQ sessions (client-relay and relay-origin) just for implementing a simple edge-embedding watermark.

Do you have any strong motivation for forcing all relays to be definitively passive? What if the draft simply omits these sentences?

— Reply to this email directly, view it on GitHub https://github.com/moq-wg/moq-transport/issues/216#issuecomment-1612121268, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKVXZCLVJ6JIRRZWHP4PZDXNSN4FANCNFSM6AAAAAAZMZOHSI . You are receiving this because you commented.Message ID: @.***>

suhasHere commented 1 year ago

I think, this goes back to us lacking a common agreement on the terminology . I did write up a first version of it in the arch spec here

things that can modify media payload are entities that are trusted to do so ( in the cases of e2e encryption, they are provided the keys or in DRM case, the content key is shared with such an entity)

Thinking in terms of entities and the roles they play from a security architecture perspective has been pretty helpful for defining things and scoping the requirements

here is the relevant section : https://datatracker.ietf.org/doc/html/draft-nandakumar-moq-arch-00#section-2

I would love to develop this further to meet various use-cases, so please share your feedback. thanks

ianswett commented 1 year ago

I believe this is out of scope for the transport draft.

fluffy commented 1 year ago

I think it is fine for a device to receive one track, modify it, and publish a different track. But I don't think we should call that a relay.

I think we should restrict the relays to not looking into the payload. That will help us have a fast scalable design for relays and allow them to work in cases with E2E encryption.

ianswett commented 9 months ago

Objects are identified by a track, Group ID and Object ID, and all copies must be bitwise identical, as specified in #376