Subject: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

From: "Roni Even" <[email-masked]>
Date: Sun, 9 Nov 2014 11:51:58 +0200

Hi guys,

I read the document and was wondering which of the topologies in
draft-ietf-avtcore-rtp-topologies-update-04 is used here (figure 3). Is it
the selective forward middlebox. It will be good to either use the same
terminology or if it is a different topology define it in the topology
draft.

As for the sequence number, when using example in figure 3 , each RTP stream
received (from the same SSRC) may have a gap in the sequence number or the
receiver may report a loss for a stream switched out by the midlebox? Any
requirement here?

Thanks

Roni Even

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Nov 2014 10:05:16 -1000

The RTP header fields that need to be modified by an SFU depend on the architecture and transport mode used, but this can include the sequence number (if SST-SS transport is used), PT, SSRC (if the SFU allocates its own SSRCs), CSRC field (some SFUs do use this if the allocate their own SSRCs). Any of these changes result in the need to recalculate the MIC and can also require the SFU to decrypt and reencrypt, depending on the cipher suite in use. 

If the payload is encrypted end-to-end then the hop-by-hop cipher suite might only require authentication, but then we are presented with another set of issues the draft does not discuss:

1. The SFU no longer has access to the payload fields it needs to make a forwarding decision. This could be potentially solved by copying some or all of those fields to an RTP header extension, as advocated in the following drafts:
https://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext
https://tools.ietf.org/html/draft-avtext-berger-framemarking

Note however that these extensions may need to support not only forwarding but also robustness features beyond NACK/RTX or hop-by-hop FEC. As an example, it would be useful to consider how an SFU receiving an SLI, PLI or RPSI feedback message can respond.

2. The SFU no longer has the keys to generate payloads required to inform end points of layer drops and other codec configuration changes.  One could attempt to provide this functionality in RTCP (e.g. TMMBN = 0 for PAUSED) but this may only work for some transport modes (e.g. SST-MS so that an SSRC can be used to identify a paused layer) and may not be a good enough substitute. 

Looking at all the potential implications on the architecture it seems to me that we are looking at an iceberg here where there are a lot of issues hidden under the surface. There is also more than one potential goal that might be worth focussing on. For example, today SFUs are typically designed for only a single codec whereas SVC technology (or at least temporal scalability) is becoming mainstream so the ability to build generic multi-codec SFUs is desirable. So even if the SFU is trusted with the keys to decrypt the payload there are reasons why not having to parse the payload would be desirable.

> On Nov 8, 2014, at 11:52 PM, Roni Even <[email-masked]> wrote:
> 
> Hi guys,
> I read the document and was wondering which of the topologies in draft-ietf-avtcore-rtp-topologies-update-04 is used here (figure 3). Is it the selective forward middlebox. It will be good to either use the same terminology or if it is a different topology define it in the topology draft.
> 
> As for the sequence number, when using example in figure 3 , each RTP stream received (from the same SSRC) may have a gap in the sequence number or the receiver may report a loss for a stream switched out by the midlebox? Any requirement here?
> 
>  
> 
> Thanks
> 
> Roni Even
> 
>  
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Jonathan Lennox <[email-masked]>
Date: Sun, 9 Nov 2014 23:33:18 +0000

On Nov 9, 2014, at 10:05 AM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

I agree with all these points.  Another point is that if a middlebox can change SSRCs and sequence numbers, that means the end-to-end keystream can’t depend on those (as it does for all current SRTP encryption modes).

One possible solution to some of these issues might be to have the end-to-end crypto transform not cover the entire RTP payload, but instead leave some prefix of the payload (the payload header, loosely defined) only protected hop-by-hop, so the SFE can read and modify it.  (This is somewhat analogous to ISMAcryp selective encryption.) However, exactly how much of the packet would be covered this way would be payload-specific, would need to be tightly coupled to the encoder, could vary on a packet-by-packet basis, and would need to be very precisely specified (payload-by-payload) in order to get useful interoperability.  And even then there are probably some cases it wouldn’t be able to cover, like the ability for an SFU to pull apart or synthesize RED packets for audio.

On Nov 8, 2014, at 11:52 PM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:

Hi guys,

Thanks
Roni Even

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt
<Mail Attachment.txt>_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Nov 2014 16:49:01 -1000

On Nov 9, 2014, at 1:33 PM, Jonathan Lennox <[email-masked]> wrote:
>> And even then there are probably some cases it wouldn’t be able to cover, like the ability for an SFU to pull apart or synthesize RED packets for audio.

[BA] which is a reminder that this impacts audio conferencing as well. It is not possible to mix audio payloads that cannot be decrypted and decoded. With RFC 6464 and endpoint mixing, forwarding can be viable, but forget about transcoding in the middlebox.

---

From: "Nermeen Ismail (nermeen)" <[email-masked]>
Date: Tue, 11 Nov 2014 20:34:45 +0000

PM-07 attempts to capture ,among other things, the sequence number gap requirement during a switch from one media source to another. In order to synchronize the SRTP context either the receiver need to be aware of the source switch and the sequence number associated with the new source need to be updated or the server needs to shield the receiver from such sequence number gaps. In either case the receiver will not be perceiving packet losses during the switch.

Do you think we need to explicitly mention the packet loss issue during a media source switch or do you think that the synchronization of the SRTP context capture it albeit in an implicit way?

nermeen

From: Roni Even <[email-masked]<mailto:[email-masked]>>
Date: Saturday, November 8, 2014 11:51 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

Hi guys,

Thanks
Roni Even

---

From: "Roni Even" <[email-masked]>
Date: Tue, 11 Nov 2014 23:06:44 +0200

Hi Nermeen,

My comment was that this should be discussed in the use case section
(section 5). The proposed  topology should be clear (similar to how a
topology is described in the topologies drafts in term of RTP and RTCP
behavior). Looking at PM-07 it is a very general requirement and is about
security context but what it means depends on the topology in mind.

The topology should be very clear to allow people to offer solutions and to
verify the solution against the topology.  

Roni Even

As individual.

 

From: Nermeen Ismail (nermeen) [mailto:[email-masked]] 
Sent: 11 November, 2014 10:35 PM
To: Roni Even; [email-masked]
Subject: Re: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

PM-07 attempts to capture ,among other things, the sequence number gap
requirement during a switch from one media source to another. In order to
synchronize the SRTP context either the receiver need to be aware of the
source switch and the sequence number associated with the new source need to
be updated or the server needs to shield the receiver from such sequence
number gaps. In either case the receiver will not be perceiving packet
losses during the switch. 

Do you think we need to explicitly mention the packet loss issue during a
media source switch or do you think that the synchronization of the SRTP
context capture it albeit in an implicit way?

nermeen

From: Roni Even <[email-masked]>
Date: Saturday, November 8, 2014 11:51 PM
To: "[email-masked]" <[email-masked]>
Subject: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

Hi guys,

 

Thanks

Roni Even