Re: [Ccrtp-devel] SRTP proposal for ccRTP

[David Sugar]

Werner Dittman,

secure RTP is very strategic to what I wish to do with GNU ccRTP, in
part because I am doing a lot of development on peer based voip
telephone servers, unlike the spoke-wheel IP-PBX model, which imposes a
man-in-the-middle transcoding tap on any "secure" connections.  So
naturally I am very interested in any development in this area,
especially if there is a relatively complete implementation to work from
that we can already integrate.  Oddly enough I was just talking about
this topic earlier today...

ccrtp does not directly offer higher level session timers, although if
the callback hooks are held in ccrtp, an external application could
still activate them and manage session timing on behalf of the stack.
Or we could add a separate session timer thread into ccrtp that could be
activated and used to manage the timers and callbacks for that purpose.
 Since your ZRTP implimentation is a new derived class that sits on top
of the existing RTP (soon SRTP) framework, it maybe makes sense to add a
separate thread object for session timers as part of the new class.

The overall approach you have implemented seems quite reasonable and
workable.  Should receipt processing for srtp packets be done before
onRTPPacketRecv, or after?  The idea for that particular hook was to be
able to prefilter and perhaps even to proxy unmodified encoded packets.
 This question depends largely on the practicality of proxying srtp.

Federico Pouzols would probably be the person most involved in
integrating new code.  I might add support for a configure option to
optionally disable openssl/srtp if possible since we also do arm builds
of ccrtp for embedded applications, and it could be nice if we have
options to strip down the code easily for those that may need to.

Generally as a GNU package we prefer that copyright assignment is
executed through the FSF.  Please cut and paste the following text into
an email, complete the questionnaire, and send to address@hidden,
address@hidden and address@hidden  You can send the
changes/patches/replacement source files through the public list if you
like and/or directly to me and Federico.

---- Begin Cut and Paste ----
REQUEST:  SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
GNU ccRTP

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]



[Which files have you changed so far, and which new files have you written
so far?]


---- End Cut and Paste ----



Werner Dittmann wrote:
> All,
> 
> during some work on a SIP client project (minisip) I did some stuff
> regarding SRTP and ZRTP (Phil Zimmermann's key exchange protocol). I
> would like to contribute this to the ccRTP implementation.
> 
> The minisip project itself uses GPL/LGPL, the SRTP implementation
> is implemented in C++. I've successfully tested this SRTP against the
> libsrtp implementation (srtp.sourceforge.net/srtp.html, developed by
> Cisco in C and put in open domain).
> 
> Looking at the ccRTP implementation I see that it is fairly easy to
> enhance ccRTP with the C++ SRTP implementation.
> 
> My proposal to add SRTP to ccRTP based on the existing SRTP code:
> 
> New public methods / functions to enable SRTP:
> Add methods to IncomingDataQueue and OutgoindDataQueue to set a
> SRTP crypto context. Each SSRC uses an own crypto context. There
> are different crypto contexts required for incoming and outgoing.
> 
> Outgoing case:
> In methods "putData" "sendImmediate" include a check if a crypto
> context is active (set) for the SSRC. This check will be done after
> the normal RTP packet was set up. If the check is true, process the
> RTP packet for SRTP and perform SRTPprocessing (encryption, add
> authentication tags, etc). Then put the packet in the queue or send
> it immediately. SRTP encrypts the contents only, not the headers
> fields.
> 
> Incoming case:
> Extend the "takeInDataPacket" method to check for an active (set)
> crypto context for the received SSRC. This check would be done after
> the basic validity checks but before the call "onRTPPacketRecv" hook.
> If there is an active crypto context perform SRTP processing (decryption,
> check replay, authenticate, etc.). If it's successful accept the packet
> and handle it like a normal RTP packet.
> 
> I've done the necessary hacking to enhance ccRTP as described.
> Currently the SRTP uses  openSSL as the crypto backend. The overall
> changes to existing ccRTP code  is small, new classes are added, e.g.
> to handle the SRTP crypto conext, perform encryption etc.
> 
> 
> Regarding ZRTP:
> I've implemented PZ's ZRTP protocol in C++ and tested it against the
> original implementation. I'm also in contact with PZ because of the
> interop tests.
> 
> Because ZRTP is a protocol "on top" of RTP/SRTP I would implement a
> ZRTPQueue that inherits from AVPQueue and performs the ZRTP handling.
> ZRTP provides ways to exchange and negotiate keys to setup the
> SRTP crypto context. After this is done, ZRTP is transparent with
> respect to RTP/SRTP handling.
> 
> IMHO this is also somewhat straightforward given the existing C++ ZRTP
> implementation.
> 
> There is one major question that I haven't solved yet: does ccRTP
> provide some functions for "timeout" / timer handling with callback?
> ZRTP requires protocol timers (only one at a time) to trigger resend
> data. Any idea/hint is welcomed here.
> 
> What do you think? How to contribute the code? (after I did the necessary
> tests - of course you will find some test code as well)
> 
> I appreciate any ideas or hints. Don't hesitate to bring up
> questions as well.
> 
> Regards,
> Werner
> 
> 
> _______________________________________________
> Ccrtp-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/ccrtp-devel

dyfet.vcf
Description: Vcard