[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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).
/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-transport-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