Re: [Linphone-developers] [PATCH] [PING..] zrtp: use session's seq_number for zrtp pack

[Dmitry Monakhov]

On Tue, 06 Nov 2012 20:55:57 +0400, Dmitry Monakhov <address@hidden> wrote:
> 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?
Werner, you are known as a zrtp guru. Can you please give an advice
Is it possible to avoid strict implementation RFC6189:ch5
in order to provide an ability of zrtp negotiation over SRTP trunc?
As soon as i understand Phill Zimmermann does not consider that
use-case(or i've just missed that).
> 
> > 
> > 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
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/linphone-developers