Re: [AVT] SRTP store-and-forward

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

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.
 
>Ok, though I don't know how the midbox would know what RTCP packets are
>relevant in all cases, especially if they're RTCP sub-packets that are
>defined after the midbox is written/updated.
 
This is a general problem for store-and-forward of RTP and not specific
to SRTP SaF. You are right in that the middlebox cannot know which RTCP
packets are relevant in all future cases and might need to be updated. I
think that a simple policy were the middlebox forwards the information
it knows should be forwarded e2e (e.g. synch info) and the information
it does not recognize (e.g. RTCP APP) goes a long way.
 
>>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.
 
>RTCP is protected end-to-end normally, not hop-to-hop (excluding B2BUAs
-
>perhaps you're assuming a B2BUA, but then RTP isn't end-to-end
protected
>either).  And I'm confused (probably by not reading the recent versions
of
>this): why are you assuming that the midbox is trusted?  And if it's
>trusted, why are you not decrypting the message, then re-encrypting for
>playback, avoiding the entirety (or most of it) of the need for this
>draft?
 
>I'd assumed SRTP Store-and-forward was supposed to assume a lack of
trust
>in the box doing the storing, beyond that it would do the forwarding
when
>asked.  I.e. allow a message to be stored on an insecure server in a
>secure manner; avoiding the possibility that the contents could be
>snooped or modified.  (Obviously they could be deleted or truncated.)
 
The middlebox is exactly as you say only trusted to do the forwarding
when asked (including unmodified synchronization info). We call this
semi-trusted in the draft. If the middlebox is totally untrusted it
would be meaningless to use for anything. We do not trust the middlebox
with cleartext data.
 
>>Most of what can be achieved by messing with the synchronization could

>>be done by not forwarding chosen packets.
 
>Simple refutation: set the current NTP time via RTCP for the one stream
>to be 20 years in the future.  The user will probably hear the audio
and
>see no video (or a still image); or the other way around, depending on
>how the client works.  (Some very dumb clients might ignore this.)  
>Alternate refutation: cause the NTP time to jump around (forward and
>backwards); this could cause all sorts of nasty effects depending on
>the client.
 
I agree, the middlebox could cause the the NTP time to jump around. The
semi-trusted middlebox is however trusted to forward the packets without
modifing them.
 
>>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.
 
>You can do that, but then you lose the ability to leverage all the
tools
>that understand audio/video streams; it no longer is an extension to
>existing abilities, but a new, separate tool for messages.
 
>The question is: what is the reason(s) for SRTP usage, and how does
that
>map to the usecase you're trying to handle here (storing messages)?
Who
>are you protecting against; what level of interference needs to be
overcome?
 
The main thing that we are protecting is the confidentiality of the
data. If you look at the use cases described in the drafts, I think you
will agree that in these use cases it is reasonable to assume that the
middleboxes are what we call semi-trusted. If one absolutely needs to
use a middlebox which is not trusted to not modify the synchronization
info and if modification of the synchronization info is seen as an
unacceptable risk, one might be limited to a smaller set of formats and
tools.

/ John Mattsson