Re: [AVT] question on draft-mattsson-srtp-store-and-forward-00.txt

["Dan Wing" <dwing at cisco.com>]

> -----Original Message-----
> From: Rolf Blom J [mailto:rolf.j.blom at ericsson.com] 
> Sent: Tuesday, July 29, 2008 11:09 AM
> To: Dan Wing; David McGrew
> Cc: AVT
> Subject: RE: [AVT] question on 
> draft-mattsson-srtp-store-and-forward-00.txt
> 
> Hello,
> 
> We see 2 main reasons why it is not possible to use simple 
> retransmission of an SRTP stream in a general Store & Forward 
> scenario. 
> 
> 1) Using simple retransmission of the SRTP stream would only 
> give end-to-end protection but no transport protection 
> (hop-by-hop and would thus comply with the assumed trust model.b
>
> 2) It would not be possible to perform playback functions 
> like rewind and fast forward (random seek operations). As we 
> understand this is the reason for the changes in the 
> draft-wing-avt-dtls-srtp-key-transport-02 (removal of similar 
> technique).

draft-mattsson-srtp-store-and-forward says that the fast forward 
/ rewind difficulty is resolved by allowing the storage device
(voicemail server) to re-construct the SRTP header.

I'll let Dave Oran (who co-chairs SPEECHSC) why SPEECSH found
a problem with storing and forwarding RTP.  However, it is my 
understanding that SPEECSH found the problem with *RTP*.  If
my understanding is correct, the proposal in 
draft-mattsson-srtp-store-and-forward would suffer the same
fate -- because the problem is with RTP (not SRTP).

-d


> /Rolf and John
> 
> 
> 
> -----Original Message-----
> From: Dan Wing [mailto:dwing at cisco.com] 
> Sent: den 29 juli 2008 01:49
> To: 'David McGrew'; John Mattsson; Fredrik Lindholm; Yi 
> Cheng; Rolf Blom J; Mats Näslund; Karl Norrman
> Cc: 'AVT'
> Subject: RE: [AVT] question on 
> draft-mattsson-srtp-store-and-forward-00.txt
> 
>  
> 
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of 
> > David McGrew
> > Sent: Monday, July 28, 2008 8:21 PM
> > To: john.mattsson at ericsson.com;
> > fredrik.lindholm at ericsson.com; yi.cheng at ericsson.com; Rolf Blom J 
> > (KI/EAB); "Mats Näslund (KI/EAB)"; Karl Norrman ((KI/EAB))
> > Cc: AVT
> > Subject: [AVT] question on
> > draft-mattsson-srtp-store-and-forward-00.txt
> > 
> > Hello,
> > 
> > Section 3.2.1 says that "The answering machine, acting as a 
> streaming 
> > server when sending the data to the callee, will not use the exact 
> > same RTP headers on the outgoing SRTP traffic as was used on the 
> > incoming SRTP traffic. SRTP as specified in [RFC3711] will 
> not work in 
> > this case, since parts of the RTP header is input to the 
> encryption/ 
> > authentication transforms."
> > 
> > However, some parts of the RTP header would need to be stored along 
> > with the payloads.  Since the answering machine is storing 
> ciphertext 
> > payloads in this case, it would need to store and play back the RTP 
> > timestamp field, since otherwise the answering machine could not 
> > effectively determine what values to put into this field.  The same 
> > considerations would probably apply to the PT field.
> > 
> > Since some parts of the header necessarily need to be 
> stored as part 
> > of the solution, why not store the entire header, then 
> replay the SRTP
> > session from the answering machine exactly as it was sent to it?    
> > This is a simple solution that avoids the need for RTP endpoints to 
> > implement new SRTP transforms and options.  It can be 
> implemented by 
> > the answering machine's RTP/SRTP stack, without any effect on 
> > signaling or any need for explicit support in any other RTP/SRTP 
> > stack.
> 
> A technical similar to that was described in Section 3.4 of
> draft-wing-avt-dtls-srtp-key-transport-01
> <http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-trans
> port-01#section-
> 3.4>, but I pulled it in the most recent version because in 
> Philadelphia Dave Oran pointed out that SPEECHSC found that 
> such audio storage didn't work well (for RTP), and thus would 
> not work well for SRTP.  I am curious if 
> draft-mattsson-srtp-store-and-forward uncovered a new 
> solution that doesn't bump into the problems SPEECHSC found 
> (but I wasn't curious enough to ask at the microphone today).
> 
> -d
> 

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt