On 03/29/11 03:00, Ian Hickson wrote:
On Wed, 23 Mar 2011, Harald Alvestrand wrote:
>
> Is there really an advantage to not using SRTP and reusing the RTP
> format for the data messages?
Could you elaborate on how (S)RTP would be used for this? I'm all in
favour of defering as much of this to existing protocols as possible, but
RTP seemed like massive overkill for sending game status packets.
If "data" was defined as an RTP codec ("application/packets?"), SRTP
could be applied to the packets.
It would impose a 12-byte header in front of the packet and the
recommended authentication tag at the end, but would ensure that we
could use exactly the same procedure for key exchange, multiplexing of
multiple data streams on the same channel using SSRC, and procedures for
identifying the stream in SDP (if we continue to use SDP) - I believe
SDP implicitly assumes that all the streams it describes are RTP streams.
I've been told that defining RTP packetization formats for a codec needs
to be done carefully, so I don't think this is a full specification, but
it seems that the overhead of doing so is on the same order of magnitude
as the currently proposed solution, and the security properties then
become very similar to the properties for media streams.
