Subject: [Perc] Review of needed information for inner security

From: Magnus Westerlund <[email-masked]>
Date: Thu, 8 Oct 2015 11:18:09 +0000

Hi,

John, Mats and I have spent some time reviewing what information we see
as needed for the RTP payload security, hence called inner security. We
also in the end have a proposal for how to include that information.

So we have considered the three topologies that are relevant for PERC.
These three as named in
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update/:

1. Relay - Transport Translator (Section 3.5.1)
2. Media Switching Mixer (Section 3.6.2)
3. Selective Forwarding Middlebox (Section 3.7)

First we look how the SSRCs are handled by these middleboxes. This is
important as it affects how one can track the media streams flowing
through the system.

So the Relay (1) performs no manipulation on the RTP level. Thus, a
packet being sent will arrive at the receiver except for transport
losses. This results in constant SSRCs end to end between sender and
receiver.

The Media Switching Mixer (2) has some important properties. As the
SSRCs used towards the receiver from the RTP mixer (MDD) is task/role
based, rather than related to original source, the inner security
context identification can't be made based on the SSRC, rather an
additional field has to be used. It is important to note that the
sequence of payloads for this stream is created by switching between the
available incoming streams. At any given point in time one specific
stream of inner payloads are forwarded for each task/role. Which it is can be changed at almost
any point. The CSRC would be the normal method for identifying the
original media contributor in a non PERC context. In a PERC context it
seems reasonable to also use CSRC. Especially, as there can't be any
media mixing due to the protected inner payloads, there can only be one
CSRC for any payload. So in this case the SSRC has no relation to the
media sources, and instead it is CSRC (or equivalent) that would have a
relation with the media source.

The SFM (3) although selectively forwarding media, it does have a one to one
handling of SSRCs, one SSRC arriving at a SFM will have its own SSRC
going out. Note that remapping may occur so that incoming and outgoing
SSRC is different.

The remapping of SSRC could occur also in the switching RTP mixer,
although it is not a recommended behaviour.

What was discussed last design team meeting was the view that we want to
enable the remapping of SSRC when needed. It is a simple way of dealing
with SSRC collisions in SFMs for example. However, one need to be aware
of the potential downside. First, by allowing re-mapping we don't have a
global stable identifier towards the originating end-point and its
identification of the media stream. This is something that at least on a
higher layer is needed to prevent substitution attacks, where the MDD
attempts to replace one endpoint's media streams with another endpoints
stream.

We also note that if end-to-end protected RTCP messages are used, not
having a global coordinated SSRC space within a conference, there will
be identification issues, and likely some other id space would be needed.

The next RTP header field that we considered was the RTP sequence
number. At the sender side, the RTP sequence number will be directly
related to the inner payload. However, that relation is not retained
across an MDD. An RTP switching mixer, will create an RTP sequence
number solely related to the out going created stream. As that is a
switched combined stream the corresponding inner sequence number will
jump back and forth at each switch, and the relative offset will change
with each switch.

For the SFM the outer RTP sequence number for an outgoing stream will be
counting the inner payloads selected to be sent (forwarded). Thus, the
offset changes at each time a decision to forward or not forward is made.

The Payload Type field is dependent on the signalling, and likely have
local assignment only. Each joining endpoint will negotiate common sets
of payload types with the signaling server representing the conference.
However, the signalling server when using offer/answer not force an
endpoint to use a particular PT field value to represent a commonly used
codec configuration. Thus, PT rewriting will occur at the MDDs,
independently of the topology.

The RTP marker bit is actually a field owned by the payload format, and
thus are tightly connected to the inner payload. We see that this field
is not possible to modify by the MDD, instead it should be included part
of the payload's integrity protected data.

The padding flag is tightly connected to the inner payload and should

not be modified by the MDD, instead it should be included part

of the payload's integrity protected data.

The Timestamp field also relates to the presentation timeline for the
outgoing stream. Here there is a difference between the SFM, which
maintains the original senders timeline, and the RTP switching mixer
that needs to create its outgoing streams timeline in a consistent way.
This requires rewriting the timestamp, but maintain the inter spacing
between media frames within the inner payload.

Proposal for how to structure information
-----------------------------------------
Our proposal for how the above information should be handled and
maintained are the following.

The inner payload's crypto context is looked up based on the CSRC if
that field is present (for RTP switching mixers), else the SSRC.

The inner crypto context includes the necessary key (called transport
key below) and other crypto
information. To prevent attacks we also need a identifier for this
particular inner media stream. For this we want to have two parts, one
part identifying the endpoint, and another identifying the media stream.
The endpoint identifier can either be globally unique and assigned by
the master key server, thus enabling a compact field scaled to planned
maximum participation in a conference. Alternatively if significant
longer randomly picked. An endpoint id assigned by the master key server
seems preferable as that enables mapping between the endpoint id and
other identifiers meant for humans. The stream id is managed by the endpoint. We
foresee that these two IDs are carried by EKT to establish this context.
The field lengths can be configurable and the used values provided in
the key-management protocol for the EKT master key. Thus enabling that
most conference to use 1 + 1 byte enabling 256 endpoints which each can
have 256 streams. Sufficient for most use cases, and for those use cases
that requires more participants or streams one can use longer fields
within the conference.

The Inner Payload gets an explicit sequence number. We propose 32 bits
that counts the number of sent packets using a specific transport key
used to protect this inner payload. It is part of the inner payload to
keep these close, and minimize the overhead. Using an RTP header
extension will in many case have more overhead.

We foresee that PERC systems will perform transport re-keying quite
frequently, that is why 32-bits will be sufficient, and if that is on
its way to wrap, the sending end-point will have to rekey its transport
key for this media stream. We note that 32-bits are sufficient also for
really high bit-rates. At 3 Gbps using 1200 bytes of payload one need to
rekey approximately every 3 hours. Using 24 bits would result in
rekeying every 53 seconds for this case.

To ensure that replay protection is present, and to prevent MDD reordering
of packets, one will need to have a sequence number also for the used
transport key. That way when one starts using a new transport key, one
can reset the inner payload sequence number, thus enabling long lived
sessions.

For the cases where one wants to prevent joining and leaving participant
to decrypt media prior or after joining and leaving respectively then we
forsee the need for master key rekeying. Also that needs to be tracked,
to prevent replay attacks. Thus also on this level one needs to have a
associated sequence number with the master key. When one
starts using a new master transport key, the transport key sequence
number is reset.

The inner payload identification will thus basically be
"Master_Key_seq_nr : Transport_Key_Seq_nr : Inner_Payload_Seq_nr". The
first two will determined through the key management protocol and EKT.
Enabling the receiver to determine if a payload is less recent then the
latest received one. This enables one to have a short window for
accepting older packets to deal with re-order events thus preventing
replays. We note that the MDD will be able to delay packets. Thus when
switching back to a source select any point between the previous sent
and the latest received by the MDD, as the point of continuing
transmission. We likely need to discuss if that is a sufficient level of
protection. We need to deal with expected levels of transport delay.

To summarize our proposal:

As part of the inner RTP payload for a particular media stream:
- Explicit 32-bit sequence number
- Use CSRC/SSRC for context lookup on packet reception.

Use EKT for context population per media stream of the following
information:

-   Endpoint ID + Endpoint specific stream ID

-   Transport key used to protect payload

-   Transport key sequence number

Stream specific context also contain:
Highest seen inner payload identifier "Master Sequence nr : Transport
Sequence nr. : Packet Sequence nr" and replay window.

Key-management for EKT master key
- EKT Master key
- Master Key sequence number
- Field lengths for Endpoint Id and Endpoint Stream ID
- Endpoint ID

IV includes:
- Endpoint ID + Endpoint specific stream ID
- Master_Key_seq_nr : Transport_Key_Seq_nr : Inner_Payload_Seq_nr
e2e integrity protected information

- padding flag

- marker bit

- payload + padding + pad count (also encrypted)

- IV (only Inner_Payload_Seq_nr sent in each packet)

Looking forward to feedback on this.

Cheers

Magnus Westerlund
John Mattson
Mats Näslund

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 8 Oct 2015 13:14:39 +0000

On Oct 8, 2015, at 7:18 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:

This is certainly true for video, but is it true for audio?

There are other ways to detect talkspurt start for audio if the MDD can’t modify the marker bit (e.g., CSRC switch for a media switching mixer) but it’s new behavior.

You mentioned that one of the motivations for letting the MDD rewrite SSRCs was to allow it to handle SSRC collisions, but if the CSRC is the index to the crypto context, we still have a collision problem — and it’s not clear to me that the originators of the colliding SSRC values would always be able to see that there’s a problem. How should this be handled?

I also notice you don’t have any provisions for inner-encryption (end-to-end) header extensions.  I think this is correct — I don’t see any use case for them at present — but do we actually have consensus on this at this point?

—
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 8 Oct 2015 15:44:15 +0200

Den 2015-10-08 kl. 15:14, skrev Jonathan Lennox:
>
>> On Oct 8, 2015, at 7:18 AM, Magnus Westerlund
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:

I would claim so. It is still owned by payload format.

The semantics that this is a good starting point and that you retune 
your jitter buffer at this point that would have to be indicated somehow 
else. The frame marking header extension would be one possibility. Your 
CSRC switch idea below is also a possibility.

>
> There are other ways to detect talkspurt start for audio if the MDD
> can’t modify the marker bit (e.g., CSRC switch for a media switching
> mixer) but it’s new behavior.
>
> You mentioned that one of the motivations for letting the MDD rewrite
> SSRCs was to allow it to handle SSRC collisions, but if the CSRC is the
> index to the crypto context, we still have a collision problem — and
> it’s not clear to me that the originators of the colliding SSRC values
> would always be able to see that there’s a problem. How should this be
> handled?

For an RTP switching mixer that does SSRC rewriting, may also have to 
rewrite the CSRC. I think the point you may be missing is that SSRC/CSRC 
is only used as crypto context reference in the receiver. There are no 
hard binding between the actual SSRC/CSRC value and the crypto context. 
You establish the crypto context based on the EKT packets included in 
the flow. It is basically a soft state binding between the SSRC/CSRC and 
the crypto context. If one fouls this up a new EKT packet can actually 
overwrite the crypto context.

>
> I also notice you don’t have any provisions for inner-encryption
> (end-to-end) header extensions.  I think this is correct — I don’t see
> any use case for them at present — but do we actually have consensus on
> this at this point?

Yes, we should have considered this. However, I think one can make the 
assumption that any E2E header extension would be directly connected 
with the inner payload and be protected using the same crypto context.

Not having run this by John and Mats, but one can create an IV that is 
different from the inner payload by having a extension header flag and 
the header extension ID and use that for protecting the header 
extension. That way one can protect each header extension independently 
and not care about MDD reordering E2E header extensions. This is just a 
quick idea.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 08 Oct 2015 13:36:27 -0500

Magnus,

Thanks for that. I'd like to go through this point by point in the meeting.

For now, I'll just thought out a few thoughts and questions.

Given the focus of perc to provide E2E confidentiality of media, do we even need to authenticate anything in the RTP header E2E? Changes to that information doesn't weaken media confidentiality.

If we assume that, I think work for RTP is very simple.  We merely encrypt the media content using an E2E key.  We then follow normal SRTP procedures to provide HBH integrity (even double-encrypting if we wanted).  That yields a solution following the SRTP spec pretty closely, modulo the inner encryption.

The only to pieces of information that we need to not create a lot of new machinery is the SSRC and SEQ fields.  We could easily put those in either a header extension or payload.  If we insert them always, that inflates each packet by 64 bits.  Periodically, we would need to convey the ROC, but the frequency of that could be limited.  The MDD could modify anything in the header. We retain all properties of SRTP for each hop.

The only special treatment at the receiver is to decrypt the inner media content.  By preserving the SSRC, SEQ and ROC, we can largely reuse what's defined in AES-GCM for RTP. We can also detect replay of packets where a compromised MDD sends data it sent previously since we have the SSRC, SEQ, and ROC.

I think defining the steps following SRTP very closely will help address security concerns.  My only concern is inflating each packet by 64 bits.

In terms of implementation, I would use SRTP to authenticate that packet as usual, then locate contextual information for the inner part in relation to that outer part. That is, the outer SSRC might be associated with many crypto contexts (one for each sender).  A concern, though, is that some complex topologies where, say, A(SSRC=1) and B(SSRC=1) sends media to different MDDs, each of which rewrites the SSRC to 3 and 4, respectively.  Those flows then go to a next hop MDD that rewrites those SSRCs to a new value 5. The receiver might use 5 to process the outer part, but then uses SSRC 1 for the inner part. Problem is, both senders use the same inner SSRC value of 1.

I'm worried that we'll have the same issue with using the CSRC field as you've described it for the same reason.  Or, do you think this can be avoided somehow?  (Given even more hops, I'm feeling skeptical.)

The positive aspect is we have similar thinking on inner/outer.  We just have to be careful to ensure that inner crypto context will not be confused with another and that, to the extent possible, we minimize changes to SRTP.

Inner "uniqueness" is one motivation for our current proposal, though I appreciate folks want to change the SSRCs.  That nonetheless complicates things a lot.

Anyway, I'd love to go through some slides on the call.  I think that's going to be more helpful in exchanging ideas on this.

Paul

-------- Original Message --------
From: Magnus Westerlund <[email-masked]>
Sent: October 8, 2015 6:18:09 AM CDT
To: "[email-masked]" <[email-masked]>
Cc: "Mats Näslund" <[email-masked]>, John Mattsson <[email-masked]>
Subject: [Perc] Review of needed information for inner security

Hi,

IV includes:

- padding flag

- marker bit

Cheers

Magnus Westerlund
John Mattson
Mats Näslund

------------------------------------------------------------------------

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 9 Oct 2015 11:52:52 +1100

On 8/10/2015 10:18 PM, Magnus Westerlund wrote:
> enable the remapping of SSRC when needed.
>
Is there a PERC design team now established? Did that get notified to 
the WG list?

Christian

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 8 Oct 2015 20:24:11 -0700

Hello Christan

  Yes. there was one design meeting held with attendees who had volunteered
during IETF 93.  My apologies if I missed your name.

The next design meeting will be on 10/12 , 10 AM EST. I will be sending out
the meeting details to the list to ensure we don't miss anyone.

Thanks
Suhas

On Thu, Oct 8, 2015 at 5:52 PM, Christian Groves <
[email-masked]> wrote:

>> Is there a PERC design team now established? Did that get notified to the
> WG list?
>
> Christian
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 11 Oct 2015 09:18:04 +0000

John,

>Yes “inner ID uniqueness” is a must, even if ID collisions do not lead 
>to two time pads (EKT and random SRTP master keys fixes this). Just as 
>your analysis above shows, random 32-bit SSRCs are in many scenarios to 
>short to give uniqueness. As stated, we therefore suggest that the Key 
>Management Function assigns an “Endpoint ID” when endpoint requests the 
>"e2e key”. This is something the KMF would do internally anyway. In our 
>proposal, SSRC/CSRC would not be used for e2e protection, they would 
>only be used as an context identifier for the receiver. This leads to 
>the requirement that SSRC/CSRC must be unique for the receiver and that 
>several senders using the same SSRC/CSRC is fine (as in your example). 
>Our current understanding is that this would give a e2e ID solution 
>with no changes to RTP SSRC handling, no packet overhead (except when 
>CSRC is used), Inner ID uniqueness, and the possibility to map e2e 
>identities to more human readable names.

I think you're likely right.  With the approach we were taking, each 
endpoint would need to be assigned a unique SSRC (versus simply 
selecting one at random).  There is already an RFC for that to signal it 
in SDP -- I think.  JL wrote that, so perhaps he can tell me if it's not 
suitable for this application.

So long as the endpoints have that unique value -- whatever it is -- to 
construct the IV, then I think that eases my concerns over manipulating 
the SSRC by the MDD.

Paul

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 12 Oct 2015 07:29:14 -0600

> On Oct 8, 2015, at 5:18 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
>  

I agree with above and let me summarize as requirements are the MDD can optionally modify

SSRC, Seq_no, PT, timestamp, CC, CSRC

But can not modify: (M) Marker, (P) Padding. 

I'm never clear on the many different meanings the M bit has been used for so bit harder for me to decide but we can figure that out and ditto for padding but what you are proposing sounds like it would work for me. 

We should probably make sure we know what we want for V, X,

I would propose V is that as a future extensibility we might allow V to modified by MDD but I don't really care. 

I think the X bit we need to be modified by MDD so that it can insert things like mixer to client levels. 

> Proposal for how to structure information

I view this as for the E3E, we need to be able to find all the bits that are used in normal E2E crypto from some new place in the packet. I'm fine with finding the original SSRC in CSRC. 

> Looking forward to feedback on this.

This is inventing a new security scheme for the HBH. My questions is first can we just use SRTP for HBH? Any reason it would not work?  It seems to me that it will work and if it does, then I get a bit antsy about it inventing something new will have any significant advantages.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 12 Oct 2015 07:33:25 -0600

> frequently,

for systems that rekey on participants joining or leaving that seems likely, but I think we also need to support systems that do not do and have one key for the whole session

---

From: "Roni Even" <[email-masked]>
Date: Mon, 12 Oct 2015 17:09:05 +0300

Hi,
Quick question about finding the original SSRC in the CSRC, what will happen
if going through cascaded media switching mixers? 

Roni

-----Original Message-----
From: Perc [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: Monday, October 12, 2015 4:29 PM
To: Magnus Westerlund
Cc: [email-masked]; Mats Näslund; John Mattsson
Subject: Re: [Perc] Review of needed information for inner security

> John, Mats and I have spent some time reviewing what information we 
> see as needed for the RTP payload security, hence called inner 
> security. We also in the end have a proposal for how to include that
information.
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update/:
>  
> 1. Relay - Transport Translator (Section 3.5.1) 2. Media Switching 
> Mixer (Section 3.6.2) 3. Selective Forwarding Middlebox (Section 3.7)
>  
> sequence of payloads for this stream is created by switching between 
> the available incoming streams. At any given point in time one 
> specific stream of inner payloads are forwarded for each task/role. 
> Which it is can be changed at almost any point. The CSRC would be the 
> normal method for identifying the original media contributor in a non 
> PERC context. In a PERC context it seems reasonable to also use CSRC. 
> Especially, as there can't be any media mixing due to the protected 
> inner payloads, there can only be one CSRC for any payload. So in this 
> case the SSRC has no relation to the media sources, and instead it is 
> CSRC (or equivalent) that would have a relation with the media source.
>  
> The SFM (3) although selectively forwarding media, it does have a one 
> to one handling of SSRCs, one SSRC arriving at a SFM will have its own 
> SSRC going out. Note that remapping may occur so that incoming and 
> outgoing SSRC is different.
>  
> What was discussed last design team meeting was the view that we want 
> to enable the remapping of SSRC when needed. It is a simple way of 
> dealing with SSRC collisions in SFMs for example. However, one need to 
> be aware of the potential downside. First, by allowing re-mapping we 
> don't have a global stable identifier towards the originating 
> end-point and its identification of the media stream. This is 
> something that at least on a higher layer is needed to prevent 
> substitution attacks, where the MDD attempts to replace one endpoint's 
> media streams with another endpoints stream.
>  
> jump back and forth at each switch, and the relative offset will 
> change with each switch.
>  
> For the SFM the outer RTP sequence number for an outgoing stream will 
> be counting the inner payloads selected to be sent (forwarded). Thus, 
> the offset changes at each time a decision to forward or not forward is
made.
> local assignment only. Each joining endpoint will negotiate common 
> sets of payload types with the signaling server representing the
conference.
> endpoint to use a particular PT field value to represent a commonly 
> used codec configuration. Thus, PT rewriting will occur at the MDDs, 
> The RTP marker bit is actually a field owned by the payload format, 
> and thus are tightly connected to the inner payload. We see that this 
> field is not possible to modify by the MDD, instead it should be 
> included part of the payload's integrity protected data.
>  
> not be modified by the MDD, instead it should be included part of the 
> payload's integrity protected data.
>  

I agree with above and let me summarize as requirements are the MDD can
optionally modify

I'm never clear on the many different meanings the M bit has been used for
so bit harder for me to decide but we can figure that out and ditto for
padding but what you are proposing sounds like it would work for me. 

I would propose V is that as a future extensibility we might allow V to
modified by MDD but I don't really care. 

I think the X bit we need to be modified by MDD so that it can insert things
like mixer to client levels. 

> Proposal for how to structure information

I view this as for the E3E, we need to be able to find all the bits that are
used in normal E2E crypto from some new place in the packet. I'm fine with
finding the original SSRC in CSRC. 

> key below) and other crypto information. To prevent attacks we also 
> need a identifier for this particular inner media stream. For this we 
> want to have two parts, one part identifying the endpoint, and another 
> identifying the media stream.
> longer randomly picked. An endpoint id assigned by the master key 
> server seems preferable as that enables mapping between the endpoint 
> id and other identifiers meant for humans. The stream id is managed by 
> the endpoint. We foresee that these two IDs are carried by EKT to
establish this context.
> most conference to use 1 + 1 byte enabling 256 endpoints which each 
> can have 256 streams. Sufficient for most use cases, and for those use 
> cases that requires more participants or streams one can use longer 
> fields within the conference.
>  
> its way to wrap, the sending end-point will have to rekey its 
> transport key for this media stream. We note that 32-bits are 
> sufficient also for really high bit-rates. At 3 Gbps using 1200 bytes 
> of payload one need to rekey approximately every 3 hours. Using 24 
> bits would result in rekeying every 53 seconds for this case.
>  
> To ensure that replay protection is present, and to prevent MDD 
> reordering of packets, one will need to have a sequence number also 
> for the used transport key. That way when one starts using a new 
> transport key, one can reset the inner payload sequence number, thus 
> enabling long lived sessions.
>  
> For the cases where one wants to prevent joining and leaving 
> participant to decrypt media prior or after joining and leaving 
> respectively then we forsee the need for master key rekeying. Also 
> that needs to be tracked, to prevent replay attacks. Thus also on this 
> level one needs to have a associated sequence number with the master 
> key. When one starts using a new master transport key, the transport 
> key sequence number is reset.
>  
> Enabling the receiver to determine if a payload is less recent then 
> the latest received one. This enables one to have a short window for 
> transmission. We likely need to discuss if that is a sufficient level 
> of protection. We need to deal with expected levels of transport delay.
>  
>  
> - Master_Key_seq_nr : Transport_Key_Seq_nr : Inner_Payload_Seq_nr e2e 
> integrity protected information
> - padding flag
> - marker bit

This is inventing a new security scheme for the HBH. My questions is first
can we just use SRTP for HBH? Any reason it would not work?  It seems to me
that it will work and if it does, then I get a bit antsy about it inventing
something new will have any significant advantages.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 12 Oct 2015 14:34:36 +0000

On Oct 11, 2015, at 5:18 AM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:

John,

Yes “inner ID uniqueness” is a must, even if ID collisions do not lead to two time pads (EKT and random SRTP master keys fixes this). Just as your analysis above shows, random 32-bit SSRCs are in many scenarios to short to give uniqueness. As stated, we therefore suggest that the Key Management Function assigns an “Endpoint ID” when endpoint requests the "e2e key”. This is something the KMF would do internally anyway. In our proposal, SSRC/CSRC would not be used for e2e protection, they would only be used as an context identifier for the receiver. This leads to the requirement that SSRC/CSRC must be unique for the receiver and that several senders using the same SSRC/CSRC is fine (as in your example). Our current understanding is that this would give a e2e ID solution with no changes to RTP SSRC handling, no packet overhead (except when CSRC is used), Inner ID uniqueness, and the possibility to map e2e identities to more human readable names.

I think you're likely right.  With the approach we were taking, each endpoint would need to be assigned a unique SSRC (versus simply selecting one at random).  There is already an RFC for that to signal it in SDP -- I think.  JL wrote that, so perhaps he can tell me if it's not suitable for this application.

If you mean RFC 5576, it’s a mechanism for endpoints to declaratively indicate what SSRC values they’ll be using, not to provide a way for one end of an offer/answer exchange to preemptively assign an SSRC to the other.

In principle I suppose an MDD could send an offer listing every SSRC currently used in the session, so the endpoint could avoid re-using them, but this would have scaling issues in large and dynamic conferences, and still be subject to collisions when two endpoints join a conference simultaneously.

So long as the endpoints have that unique value -- whatever it is -- to construct the IV, then I think that eases my concerns over manipulating the SSRC by the MDD.

---

From: John Mattsson <[email-masked]>
Date: Sat, 10 Oct 2015 12:04:51 +0000

>Thanks for that. I'd like to go through this point by point in the meeting.

Good, lets discuss on the next PERC Design Meeting on Monday.

>The only to pieces of information that we need to not create a lot of new machinery is the SSRC and SEQ fields.

Totally agree on an RTP level, these are RTP fields and PERC should not do any changes to RTP. But changes will be needed to SRTP, EKT, and DTLS/DTLS-SRTP (if used for e2e key management). Here we need to discuss how to to achieve the best overall solution with regards to security, performance, features, and complexity.

>In terms of implementation, I would use SRTP to authenticate that packet as usual, then locate contextual information for the >inner part in relation to that outer part. That is, the outer SSRC might be associated with many crypto contexts (one for each >sender). A concern, though, is that some complex topologies where, say, A(SSRC=1) and B(SSRC=1) sends media to different >MDDs, each of which rewrites the SSRC to 3 and 4, respectively. Those flows then go to a next hop MDD that rewrites those >SSRCs to a new value 5. The receiver might use 5 to process the outer part, but then uses SSRC 1 for the inner part. Problem is, >both senders use the same inner SSRC value of 1.

>I'm worried that we'll have the same issue with using the CSRC field as you've described it for the same reason. Or, do you think >this can be avoided somehow? (Given even more hops, I'm feeling skeptical.)

>The positive aspect is we have similar thinking on inner/outer. We just have to be careful to ensure that inner crypto context >will not be confused with another and that, to the extent possible, we minimize changes to SRTP.

>Inner "uniqueness" is one motivation for our current proposal, though I appreciate folks want to change the SSRCs. That >nonetheless complicates things a lot.

John

From: "Paul E. Jones" <[email-masked]<mailto:[email-masked]>>
Date: Thursday 8 October 2015 20:36
To: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Mats Näslund <[email-masked]<mailto:[email-masked]>>, John Mattsson2 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Perc] Review of needed information for inner security

Magnus,

Paul

________________________________
From: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>
Sent: October 8, 2015 6:18:09 AM CDT
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Mats Näslund" <[email-masked]<mailto:[email-masked]>>, John Mattsson <[email-masked]<mailto:[email-masked]>>
Subject: [Perc] Review of needed information for inner security

Hi,

IV includes:

- padding flag

- marker bit

Cheers

Magnus Westerlund
John Mattson
Mats Näslund

________________________________

Perc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perc

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2015 11:23:55 +0200

Hi,

I expect that the second MDD to copy the CSRC field from the incoming 
packet to the outgoing to maintain the original. It MUST not use the 
SSRC from the incoming as the value, when the incoming packet has an 
CSRC value, to put in the CSRC field for the outgoing.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2015 11:44:51 +0200

Den 2015-10-12 kl. 15:33, skrev Cullen Jennings:
>> We foresee that PERC systems will perform transport re-keying
>> quite frequently,
>
> for systems that rekey on participants joining or leaving that seems
> likely, but I think we also need to support systems that do not do
> and have one key for the whole session
>

I agree that there will be a set of conferences that don't need the 
protection against a joining endpoint retrospectively decrypt what 
happened prior to it joining.

However, when I say transport key, I really mean the key used the 
end-to-end protection for a specific stream. That is the key we put in 
the inband key-distribution mechanism (EKT). As that must be present and 
capable of handling participants joining, i.e. repeated distribution of 
the key the originating endpoint uses. Thus, performing a rekeying of 
particular stream's key protecting end-to-end will require no 
substantial changes, and it will be a necessary for the higher security 
target. Thus, I assume that EKT will support rekeying.

With that assumption in place, I don't see an issue with using it for 
rekyeing when a end-to-end sequence number wraps. Sure, one probably 
shouldn't need to rekey to frequently, but using every couple of minutes 
for a high-bandwidth flow should have no negative effect.

We derived 32-bits as sufficient based on the highest bit-rate RTP 
payload format that has any bounds, and that is the SMPTE 292M (RFC 
3497) (Yes, raw uncompressed format can go higher) but 3 Bbps appears 
sufficient as a calculation example. Using regular 1500-bytes Ethernet 
with good safety margin we assumed 1200 bytes of payload. That results 
in 312500 packets per second. Using a 32 sequence number would allow it 
to wrap in 13743,9 seconds. So that is clearly sufficient. Using 24 bits 
would wrap it in 53,7 seconds. Which probably works, but a bit short. 
For more modest flows like HQ video at 25 mbps, then the packet rate 
becomes in the order of 2600 packets per second. A 24 bit sequence 
number would last 6450 seconds, i.e. almost 1.8 hours. I note that the 
16-bit sequence number wraps every 25 seconds here.

The idea was really to not have to deal with a ROC in the IV, and 
instead have sufficient amount of bits present in the end-to-end 
sequence number.

Cheers

Magnus Westerlund