Re: [Linphone-developers] [PATCH] zrtp: use session's seq_number for zrtp packets

[Dmitry Monakhov]

On Tue, 06 Nov 2012 15:02:42 +0100, Werner Dittmann <address@hidden> wrote:
> Am 05.11.2012 21:53, schrieb Dmitry Monakhov:
> > 
> > Currently seq_number for zrtp initiated to random value so
> > seq_numbers for rtp and zrtp packets will have different base
> > which is incorrect because other parts expect to receive packets
> > with monolithic seq_numbers.
> 
> It's abosultely ok that ZRTP packet have different seq numbers, acutally
> the ZRTP spec (RFC 6189) requires a random number, see chap 5.
Ohh i've missed that part in rfc6189, But you also use same predefined number in
https://github.com/wernerd/ZRTPCPP/blob/master/clients/ccrtp/ZrtpQueue.cpp

Currently i try to add zrtp to 
libjingle(https://github.com/dmonakhov/libjingle).
By default it use SDES/SRTP encryption, and i have to pick SDES or ZRTP
during negotiation stage, and if ZRTP was chosen it still may fail later so
call will be completely unprotected. 
At the same time Libjingle allow to separate different layer
see 
https://github.com/dmonakhov/libjingle/blob/master/talk/session/media/channel.cc:
OUT:ortp-->mediastream2--->srtp_filter.ProtectRtp()-->NET
IN: NET-->srtp_filter.UnprotectRtp(pkt)--->mediatream2--->ortp
So it is possible to use both negotiation strategies independently:
Let's signalling layer setup encryption via SDES,
later we can try to negotiate zrtp key over existing SDES/SRTP trunc.
Later if zrtp negotiations succeed we may disable SDES, or continue
in double encryption mode (crazy people will love that) 
I test this approach and it works quite well with one exception,
established SDES/SRTP session expect to see monolithic seq_numbers
according to rfc3711:3.3.2

With my patch zrtp negotiation works fine over SRTP trunc.
What do you think about that approach?

> 
> ZRTP just uses the same port numbers to send/receive its packets. ZRTP
> is an own protocol and ZRTP packets shall be filtered by the receiving 
> software
> and handed over to the ZRTP software and then discarded after ZRTP processing.
> ZRTP packets are _not_ RTP packets and should never be treated as such.
> 
> Werner
> 
> 
> > Let's use common session.rtp.snd_seq counter. ASAIU it is safe to
> > modify counter w/o locking from zrtp callback because it is called
> > from sender context.
> > 
> > Signed-off-by: Dmitry Monakhov <address@hidden>
> > ---
> >  src/zrtp.c |    4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/src/zrtp.c b/src/zrtp.c
> > index bb653cd..3a35876 100644
> > --- a/src/zrtp.c
> > +++ b/src/zrtp.c
> > @@ -50,7 +50,6 @@ struct _OrtpZrtpContext{
> >     RtpSession *session;
> >     uint32_t timerWillTriggerAt;
> >     uint16_t last_recv_zrtp_seq_number;
> > -   uint16_t last_sent_zrtp_seq_number;
> >     srtp_t srtpSend;
> >     srtp_t srtpRecv;
> >     zrtp_Callbacks zrtp_cb;
> > @@ -197,7 +196,7 @@ static int32_t ozrtp_sendDataZRTP (ZrtpContext* ctx, 
> > const uint8_t* data, const
> >     uint8_t *buffer8=(uint8_t*)buffer32;
> >     uint16_t *buffer16=(uint16_t*)buffer32;
> >  
> > -   uint16_t seqNumber=userData->last_sent_zrtp_seq_number++;
> > +   uint16_t seqNumber=session->rtp.snd_seq++;
> >  
> >     *buffer8 = 0x10;
> >     buffer8[1]=0;
> > @@ -769,7 +768,6 @@ static OrtpZrtpContext* createUserData(ZrtpContext 
> > *context) {
> >     userData->zrtpContext=context;
> >     userData->timerWillTriggerAt=0;
> >     userData->last_recv_zrtp_seq_number=0;
> > -   userData->last_sent_zrtp_seq_number=rand()+1; // INT_MAX+1 (signed)
> >  
> >     userData->srtpRecv=NULL;
> >     userData->srtpSend=NULL;
> > 
> 
> 
> -- 
> ----------------------------------------------
> Werner Dittmann    address@hidden
> Tel +49 176 993 462 95
> PGP key: 82EF5E8B
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/linphone-developers