Re: [AVT] SRTP store-and-forward

["John Mattsson" <john.mattsson at ericsson.com>]

>Rolf Blom <rolf.j.blom at ericsson.com> writes:
>>To be able to handle an audio and a video stream using one security 
>>context it is necessary to introduce a mechanism to give them separate

>>protection. We did that with the introduction of the SSS, the SRTP SaF

>>Source. It s also necessary to be able to indicate which e2e security 
>>context that the media is using and thus a CCI, Crypto Context 
>>Identifier is needed. So we believe that what we have presented is 
>>general enough but still is a very thin design providing not more than
what is really needed.
>>
>>Cullen gave an example in which it was essential that what is 
>>forwarded is the complete message that was received by the SaF 
>>middlebox (do not launch the missile!). Even if I believe that such a 
>>message wouldn't be left on an answering machine - it probably should 
>>be delivered directly to eliminate the risk for mistakes - it points
at a possible threat.
>>This threat might perhaps be countered by some RTCP signaling messages

>>e2e. However, in the current draft-naslund-saf-00 we do not provide 
>>e2e integrity protected RTCP. Is this a problem? Should it be added? 
>>Or are there other application layer mechanisms that should be 
>>applied? Note that with an e2e integrity transform and letting PUV be 
>>a counter, it is possible to detect replays and re-orderings at the 
>>application layer. However, it will not guarantee that all packets are
forwarded.
>>Note that the threat discussed is outside the trust model assumed for 
>>SRTP store-and-forward, which assumes a honest but curious SaF
middlebox.

Randell Jesup <rjesup at wgate.com> writes:
>You need to at least include RTCP as well, or synchronization between 
>streams (audio and video) cannot be done. Protecting it would be smart,

>though probably not strictly necessary. (If not protected, someone 
>could mess with the stream sync, possibly tickling bugs in the player 
>or causing one stream or the other to never play, to jump around, or to

>be unintelligible.)

Our intention have always been that the middlebox saves the relevant
parts of RTCP (e.g. SR, APP) and retransmits them to the final receiver.
As RTCP is protected hop-by-hop, the only one that could mess with the
synchronization is the middlebox, which according to our trust model is
trusted not to do so. Most of what can be achieved by messing with the
synchronization could be done by not forwarding chosen packets. We
thought about protecting RTCP e2e but felt that it creates more problems
than it solves. Parts of RTCP should be sent e2e and other parts only
hbh, for RTCP APP, this distinction is application dependant. If there
is a need to protect against a synchronization messing middlebox, the
audio and video should encoded in a format that can be sent in a single
stream.

/John