SRTP midterm review

Hi Su,

I had a chance to test your work today. I have setup an
OpenSER  
server and 2 sip-communicator clients on Linux.
I have tested various scenario:

- 2 clients with usingSRTP set to true,
- 2 clients with using SRTP set to false,
- 1 client with usingSRTP set to true, the other client set
to false,
- 1 "normal" client (ie without your patch) with
one client with  
usingSRTP set to false
- 1 "normal" client (ie without your patch) with
one client with  
usingSRTP set to true

and I could get the expected result for each scenario (noise
with  
asymetric nodes, perfect sound with symetric nodes) 
Furthermore,  
I did not notice any bad exceptions, that's a very great job
Su!

During the tests, looking at the Wireshark dump, I could not
make any  
difference between RTP and SRTP packets. Looking at the RFC,
it looks  
like the header is the same, only the payload is encrypted.
Am I right?

Regarding the code itself, I'd have some questions:
- the usingSRTP field is currently defined in the code as
true or  
false for all remote clients. I guess that in the future,
when we can  
have a key management protocol, SRTP will be used
dynamically  
according to the remote client (if it supports or not SRTP),
right? I  
mean, the scenario where I'll use SRTP with remote client A,
but only  
RTP with remote client B will be possible? From what I saw,
your  
implementation design seems to allow that case, do you
confirm?

- If possible, I'd like you to start writing your
implementation  
report. Writing reports is not the greatest part of the job,
so it's  
better to start early and complete it from time to time.
Especially,  
that would be great if you could start with a class diagram
of your  
design. That would help us and other people to have a good 

understanding of how your classes are interconnected between
them.

- Could you also update your roadmap on http://www.sip- 
communicator.org/index.php/Development/RoadmapSuBing
? Maybe you could add a "last update" field in it,
it'll help me to  
know if it has changed since the last time I checked it. If
you could  
make a brief summary on this ML about what is currently
implemented,  
and what are your short-term next steps, that would be
great.

Thanks again,
Romain


On 2007/07/22, at 20:19, Bing Su wrote:

> Hi Romain,
>
> No problem.  I've
merged my change with the latest code from cvs.
>
> The attached files are:
> 1. "sc-srtp-impl-v0.2.patch" patch file
created by eclipse.
> 2. "sc-srtp-impl-v0.2.src.zip" complete
modified source files. Use
> this if the path doesn't work for you. You can simply
overwrite the
> existing files.
> 3. "build.xml" Modified build.xml.
> 4. "bcprov-jdk14-137.jar" latest bouncycastle
jar file for jdk1.4.
> Manifest folder removed, because it will cause wired
class not found
> problem.
>
> And, there are several ways to test:
> 1. If you have Asterisk installed, dial 500 for
"demo" context
> (Provided by default installation). Then you will hear
only noise,
> because Asterisk doesn't know we are using SRTP, its
RTP packets are
> mis-interpreted.
>
> 2. Register with OpenSER. I've setup a private OpenSER
server and run
> SRTP enabled SC on two PCs, then made call with each
other. In this
> way, we can hear normal voices.
>
> 3. Make "self call". Yes, SC is able to call
itself. If you
have
> only one machine, you can register your SC with
OpenSER, and call your
> own registerd Request URI. Your SC will appear having
incoming call,
> after clicking the answer button, you will have a
"loopback" call set
> up. Then, you can hear your own voice.
>
> In order to enable/disable SRTP feature, please change
the usingSRTP
> variable defined in CallSessionImpl.
>
> If you have any problem, please let me know. 
>
> Best wishes,
> Su
>>
>> <sc-srtp-impl-v0.2.patch><sc-srtp-impl- 
>>
v0.2.src.zip><build.xml><bcprov-jdk14-137.jar>
;

-- 
Romain KUNTZ
kuntzlsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Let me just jump in here , pls see
my comments inline.

Regards,
Werner

Romain KUNTZ wrote:
> Hi Su,
> 
> I had a chance to test your work today. I have setup an
OpenSER server
> and 2 sip-communicator clients on Linux.
> I have tested various scenario:
> 
> - 2 clients with usingSRTP set to true,
> - 2 clients with using SRTP set to false,
> - 1 client with usingSRTP set to true, the other client
set to false,
> - 1 "normal" client (ie without your patch)
with one client with
> usingSRTP set to false
> - 1 "normal" client (ie without your patch)
with one client with
> usingSRTP set to true
> 
> and I could get the expected result for each scenario
(noise with
> asymetric nodes, perfect sound with symetric nodes)

Furthermore, I
> did not notice any bad exceptions, that's a very great
job Su!
> 
> During the tests, looking at the Wireshark dump, I
could not make any
> difference between RTP and SRTP packets. Looking at the
RFC, it looks
> like the header is the same, only the payload is
encrypted. Am I right?

Correct, its only the Payload. SRTP ist just a
"small" extension on top
of RTP.

> 
> Regarding the code itself, I'd have some questions:
> - the usingSRTP field is currently defined in the code
as true or false
> for all remote clients. I guess that in the future,
when we can have a
> key management protocol, SRTP will be used dynamically
according to the
> remote client (if it supports or not SRTP), right? I
mean, the scenario
> where I'll use SRTP with remote client A, but only RTP
with remote
> client B will be possible? From what I saw, your
implementation design
> seems to allow that case, do you confirm?

I've looked at Su's code, seems pretty ok, some things are
yet missing
though, for example the replay check and as far as I can
remember the
authentication stuff.

Peforming key negotiation is the most important job after a
good SRTP
implementation. This is _the_ part that makes SRTP really
secure - if you
have a weak key negotiation protocol then SRTP wouldn't help
.  I
do
not know about the future roadmaps but this is a necessary
next step to
make it all work and usable.
> 
> - If possible, I'd like you to start writing your
implementation report.
> Writing reports is not the greatest part of the job, so
it's better to
> start early and complete it from time to time.
Especially, that would be
> great if you could start with a class diagram of your
design. That would
> help us and other people to have a good understanding
of how your
> classes are interconnected between them.
> 
> - Could you also update your roadmap on
> http://www.sip-communicator.org/index.php/Dev
elopment/RoadmapSuBing
> ? Maybe you could add a "last update" field
in it, it'll help me to know
> if it has changed since the last time I checked it. If
you could make a
> brief summary on this ML about what is currently
implemented, and what
> are your short-term next steps, that would be great.
> 
> Thanks again,
> Romain
> 
> 
> On 2007/07/22, at 20:19, Bing Su wrote:
> 
>> Hi Romain,
>>
>> No problem.  I've
merged my change with the latest code from cvs.
>>
>> The attached files are:
>> 1. "sc-srtp-impl-v0.2.patch" patch file
created by eclipse.
>> 2. "sc-srtp-impl-v0.2.src.zip" complete
modified source files. Use
>> this if the path doesn't work for you. You can
simply overwrite the
>> existing files.
>> 3. "build.xml" Modified build.xml.
>> 4. "bcprov-jdk14-137.jar" latest
bouncycastle jar file for jdk1.4.
>> Manifest folder removed, because it will cause
wired class not found
>> problem.
>>
>> And, there are several ways to test:
>> 1. If you have Asterisk installed, dial 500 for
"demo" context
>> (Provided by default installation). Then you will
hear only noise,
>> because Asterisk doesn't know we are using SRTP,
its RTP packets are
>> mis-interpreted.
>>
>> 2. Register with OpenSER. I've setup a private
OpenSER server and run
>> SRTP enabled SC on two PCs, then made call with
each other. In this
>> way, we can hear normal voices.
>>
>> 3. Make "self call". Yes, SC is able to
call itself. If you
have
>> only one machine, you can register your SC with
OpenSER, and call your
>> own registerd Request URI. Your SC will appear
having incoming call,
>> after clicking the answer button, you will have a
"loopback" call set
>> up. Then, you can hear your own voice.
>>
>> In order to enable/disable SRTP feature, please
change the usingSRTP
>> variable defined in CallSessionImpl.
>>
>> If you have any problem, please let me know. 
>>
>> Best wishes,
>> Su
>>>
>>>
<sc-srtp-impl-v0.2.patch><sc-srtp-impl-v0.2.src.zip
><build.xml><bcprov-jdk14-137.jar>
>>>
> 
> --Romain KUNTZ
> kuntzlsiit.u-strasbg.fr
> Louis Pasteur University - Networks and Protocols Team
> 
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Romain,

Thank you for your reviewing. My comments inline.

On 7/23/07, Romain KUNTZ <kuntzclarinet.u-strasbg.fr>
wrote:
> Hi Su,
>
> I had a chance to test your work today. I have setup an
OpenSER
> server and 2 sip-communicator clients on Linux.
> I have tested various scenario:
>
> - 2 clients with usingSRTP set to true,
> - 2 clients with using SRTP set to false,
> - 1 client with usingSRTP set to true, the other client
set to false,
> - 1 "normal" client (ie without your patch)
with one client with
> usingSRTP set to false
> - 1 "normal" client (ie without your patch)
with one client with
> usingSRTP set to true
>
> and I could get the expected result for each scenario
(noise with
> asymetric nodes, perfect sound with symetric nodes)

Furthermore,
> I did not notice any bad exceptions, that's a very
great job Su!
>
Oh, you certainly did a lot of tests. 
I didn't try linux environment. But it worked, I think this
is because the
transformation of RTP packet is not os-dependent.

> During the tests, looking at the Wireshark dump, I
could not make any
> difference between RTP and SRTP packets. Looking at the
RFC, it looks
> like the header is the same, only the payload is
encrypted. Am I right?
Yes, headers are not encrypted. I also used Wireshark to
monitor the packets.
But I can't tell the difference between encrypted and plain
payload using my
eye.

>
> Regarding the code itself, I'd have some questions:
> - the usingSRTP field is currently defined in the code
as true or
> false for all remote clients. I guess that in the
future, when we can
> have a key management protocol, SRTP will be used
dynamically
> according to the remote client (if it supports or not
SRTP), right? I
> mean, the scenario where I'll use SRTP with remote
client A, but only
> RTP with remote client B will be possible? From what I
saw, your
> implementation design seems to allow that case, do you
confirm?
Yes of course. This is how it should be.
If at last we use TLS based SIP protocol to negotiate SRTP
keys, then whether
shall we enable SRTP feature is determined at SDP
negotiation period, which is
handle internally by CallSessionImpl.
If we use other mechanisms, then we will probably add some
methods
such as SetSRTPPolicy() to CallSession.

>
> - If possible, I'd like you to start writing your
implementation
> report. Writing reports is not the greatest part of the
job, so it's
> better to start early and complete it from time to
time. Especially,
> that would be great if you could start with a class
diagram of your
> design. That would help us and other people to have a
good
> understanding of how your classes are interconnected
between them.\
Of course, there is a lot of UML reverse engineering tools
for Java.
Creating a class diagram will not be hard.

>
> - Could you also update your roadmap on http://www.sip-
> communicator.org/index.php/Development/RoadmapSuBing
> ? Maybe you could add a "last update" field
in it, it'll help me to
> know if it has changed since the last time I checked
it. If you could
> make a brief summary on this ML about what is currently
implemented,
> and what are your short-term next steps, that would be
great.
Sure. Fow now I will continue to code a little bit more.
Especially
the authentication part. And get this done at the end of the
week.

Best regards,
Su

>
> Thanks again,
> Romain
>
>
> On 2007/07/22, at 20:19, Bing Su wrote:
>
> > Hi Romain,
> >
> > No problem.  I've
merged my change with the latest code from cvs.
> >
> > The attached files are:
> > 1. "sc-srtp-impl-v0.2.patch" patch file
created by eclipse.
> > 2. "sc-srtp-impl-v0.2.src.zip" complete
modified source files. Use
> > this if the path doesn't work for you. You can
simply overwrite the
> > existing files.
> > 3. "build.xml" Modified build.xml.
> > 4. "bcprov-jdk14-137.jar" latest
bouncycastle jar file for jdk1.4.
> > Manifest folder removed, because it will cause
wired class not found
> > problem.
> >
> > And, there are several ways to test:
> > 1. If you have Asterisk installed, dial 500 for
"demo" context
> > (Provided by default installation). Then you will
hear only noise,
> > because Asterisk doesn't know we are using SRTP,
its RTP packets are
> > mis-interpreted.
> >
> > 2. Register with OpenSER. I've setup a private
OpenSER server and run
> > SRTP enabled SC on two PCs, then made call with
each other. In this
> > way, we can hear normal voices.
> >
> > 3. Make "self call". Yes, SC is able to
call itself. If you
have
> > only one machine, you can register your SC with
OpenSER, and call your
> > own registerd Request URI. Your SC will appear
having incoming call,
> > after clicking the answer button, you will have a
"loopback" call set
> > up. Then, you can hear your own voice.
> >
> > In order to enable/disable SRTP feature, please
change the usingSRTP
> > variable defined in CallSessionImpl.
> >
> > If you have any problem, please let me know. 
> >
> > Best wishes,
> > Su
> >>
> >>
<sc-srtp-impl-v0.2.patch><sc-srtp-impl-
> >>
v0.2.src.zip><build.xml><bcprov-jdk14-137.jar>
;
>
> --
> Romain KUNTZ
> kuntzlsiit.u-strasbg.fr
> Louis Pasteur University - Networks and Protocols Team
>
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net