[sip-comm-dev] [GSoC] SRTP midterm review


#1

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) :slight_smile: 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. :slight_smile: 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.:slight_smile: 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. :slight_smile:

Best wishes,
Su

<sc-srtp-impl-v0.2.patch><sc-srtp-impl-v0.2.src.zip><build.xml><bcprov-jdk14-137.jar>

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

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) :slight_smile: 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/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. :slight_smile: 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.:slight_smile: 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. :slight_smile:

Best wishes,
Su

<sc-srtp-impl-v0.2.patch><sc-srtp-impl-v0.2.src.zip><build.xml><bcprov-jdk14-137.jar>

--Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Romain,

Thank you for your reviewing. My comments inline.

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) :slight_smile: Furthermore,
I did not notice any bad exceptions, that's a very great job Su!

Oh, you certainly did a lot of tests. :wink:
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.:slight_smile:

- 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

···

On 7/23/07, Romain KUNTZ <kuntz@clarinet.u-strasbg.fr> wrote:

Thanks again,
Romain

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

> Hi Romain,
>
> No problem. :slight_smile: 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.:slight_smile: 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. :slight_smile:
>
> Best wishes,
> Su
>>
>> <sc-srtp-impl-v0.2.patch><sc-srtp-impl-
>> v0.2.src.zip><build.xml><bcprov-jdk14-137.jar>

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Werner,

Thank you for your review, this is highly appreciated as I am for from being an SRTP expert.

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.

Ok, good to know.

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.

GSoC is not over yet :wink: Those items are in the development roadmap for GSoC.

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.

I also guess that without a key negotiation protocol we can forget about interop with other clients, so this is something we'd like to have in the future.

Within GSoC, we'd like to make a survey of existing key management protocols and pick up one (or is there a specific one for SRTP? SRTP RFC does not define it). But implementation may or not be done within GSoC, that will depend on the available time.

Cheers,

···

On 2007/07/23, at 20:50, Werner Dittmann wrote:
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Su,

pls see my comments inline. Thanks

Regards,
Werner

Bing Su wrote:

Hi Romain,

Thank you for your reviewing. My comments inline.

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) :slight_smile: Furthermore,
I did not notice any bad exceptions, that's a very great job Su!

Oh, you certainly did a lot of tests. :wink:
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.

what does that mean "you didn't see a difference between encrypted
and plain payload when looking at it with wireshark"? Usually there is a
noticable difference - for example if you use G.711 codec you usually
see a sort of regular patterns in unencrypted mode, but complete random
data in encrypted mode if you look at the packet on the line - between
the two clients that do SRTP. Only the headers are not different in encrypted
cersus unencrypted mode.

SRTP does not modify the RTP headers in any way, only the payload (after
the header data) and adds (optionally) some bytes for authentication _after_
the payload data.

Look at this example: this is a typical G.711 RTP packet that contains some
noise (not speech). The RTP packet header starts at 0x2a (the 0x80 byte),
payload starts at offset 0x36:

0000 00 16 3e 7c 32 03 00 16 17 8e 38 65 08 00 45 00 ..>|2.....8e..E.
0010 00 c8 00 00 40 00 40 11 f0 aa c0 a8 64 01 c0 a8 ....@.@.....d...
0020 64 28 1f 40 78 28 00 b4 f4 8c 80 88 42 55 64 28 d(.@x(......BUd(
0030 10 cb 34 c2 90 f9 63 6c 60 6f 62 6c 60 6d 6c 6c ..4...cl`obl`mll
0040 62 62 62 63 6c 62 63 6c 62 6c 62 62 62 6d 6d 62 bbbclbclblbbbmmb
0050 62 6c 6d 62 6d 62 6c 63 62 62 6d 6d 6c 62 62 6c blmbmblcbbmmlbbl
0060 6d 6d 60 6d 62 6d 63 6c 62 6d 62 62 63 6f 62 6d mm`mbmclbmbbcobm
0070 62 6c 62 62 62 6d 6c 63 6d 6c 63 6c 63 62 6f 63 blbbbmlcmlclcboc
0080 62 6d 62 62 62 6d 6f 62 6d 62 62 62 6d 63 6c 62 bmbbbmobmbbbmclb
0090 6d 6d 62 6d 6d 6c 62 62 6c 62 62 6d 6d 6d 6d 6d mmbmmlbblbbmmmmm
00a0 62 62 6c 6d 6d 62 63 6d 63 6c 63 69 63 6c 62 6d bblmmbcmclciclbm
00b0 6d 6d 62 62 6d 62 6c 62 63 62 62 6d 62 6d 62 6d mmbbmblbcbbmbmbm
00c0 62 62 6d 63 6d 62 6d 62 6f 6d 62 63 6c 63 6d 62 bbmcmbmbombclcmb
00d0 6c 63 62 6d 62 62 lcbmbb

Here a G.711 packet with similar noise, but encrypted with SRTP. The RTP header
starts at 0x2a (the 0x80 byte), the payload looks completely random because
it is encrypted, payload starts at offset 0x36:

0000 00 16 3e 7c 32 03 00 16 17 8e 38 65 08 00 45 00 ..>|2.....8e..E.
0010 00 cc 00 00 40 00 40 11 f0 a6 c0 a8 64 01 c0 a8 ....@.@.....d...
0020 64 28 1f 40 78 28 00 b8 56 45 80 08 42 56 64 28 d(.@x(..VE..BVd(
0030 18 eb 34 c2 90 f9 ce e9 c5 7f c2 7a f2 7e 2b 6d ..4........z.~+m
0040 1a 58 54 70 1b 39 ef 32 ac 67 61 fe 06 92 2a 7c .XTp.9.2.ga...*|
0050 97 98 f6 a2 82 9d 94 6e 2e 90 ed 26 99 69 29 d4 .......n...&.i).
0060 83 39 e9 da 2a 49 a7 8d 96 7f ca 1e 82 49 0b 4c .9..*I.......I.L
0070 00 aa b4 29 eb 00 74 6b 67 10 24 24 b3 8e 80 c5 ...)..tkg.$$....
0080 81 40 e9 8a 2f ff 3d 2c 53 8f 1c 08 cd 40 9e 51 .@../.=,S....@.Q
0090 53 b9 18 52 ae 50 ae 25 4d da 71 1c 1a 61 a3 ce S..R.P.%M.q..a..
00a0 ba 7f 28 c1 84 5b 55 43 d5 69 7a 90 5f e6 6b ec ..(..[UC.iz._.k.
00b0 32 7f a7 b1 21 af 5e a2 63 d4 95 5b d8 5b ef 31 2...!.^.c..[.[.1
00c0 48 22 a0 ef c6 0e c7 aa 64 62 e7 dd 58 19 a7 69 H"......db..X..i
00d0 ca a1 17 c0 ca 26 a8 30 0b 8c .....&.0..

Both packets are from the same session, the first packet before switching to
SRTP, i.e. plain payload, the second packet after key negotiation and switching
to SRTP. Look at offset 0x32 in both packets: its the same SSRC, the
sequence number increased from 16981 (0x4255) to 16932 (0x4256). In between
was key negotiation with ZRTP (not shown here).

If you look at the timestamp at both packets (starting at offset 0x2e)
you see the values 1680347339 (0x642810cb) and 1680349419 (0x642818eb).
G.711 payload is 160 bytes and the client sends a packet every 20ms.
Thus the key negotiation took 260ms on my system with two parallel running
clients on an AMD Athlon 64 X2 (dual core system):
1680349419 - 1680347339 = 2080 bytes, divided by 160 = 13, times 20ms = 260ms
(the attributes of the G.711 codec are: 160 bytes for every 20ms, in total
8000 bytes for one second -> 64.000 bits per second)

···

On 7/23/07, Romain KUNTZ <kuntz@clarinet.u-strasbg.fr> wrote:

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.:slight_smile:

- 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. :slight_smile: 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.:slight_smile: 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. :slight_smile:
>
> Best wishes,
> Su
>>
>> <sc-srtp-impl-v0.2.patch><sc-srtp-impl-
>> v0.2.src.zip><build.xml><bcprov-jdk14-137.jar>

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Werner,

It seems Romain has already answered your question.
I just want to say thank you. :slight_smile:
Your comments are always valuable.
Without your help, I will have much more trouble with SRTP.

Best regards,
Su

···

On 7/24/07, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

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) :slight_smile: 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/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. :slight_smile: 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.:slight_smile: 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. :slight_smile:
>>
>> Best wishes,
>> Su
>>>
>>> <sc-srtp-impl-v0.2.patch><sc-srtp-impl-v0.2.src.zip><build.xml><bcprov-jdk14-137.jar>
>>>
>
> --Romain KUNTZ
> kuntz@lsiit.u-strasbg.fr
> Louis Pasteur University - Networks and Protocols Team
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Su,

Oh, you certainly did a lot of tests. :wink:
I didn't try linux environment. But it worked, I think this is because the
transformation of RTP packet is not os-dependent.

I guess you are working on the Windows OS?
I didn't have a chance to test on MacOSX yet, I'll try to do so in the near future. But as you said your code is os-independant, so I don't think it's needed to test it under multiple OSes. If you keep on using Windows on your side, and me testing on Linux on my side, that's enough at the moment.

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.

Ok I see.

Of course, there is a lot of UML reverse engineering tools for Java.
Creating a class diagram will not be hard.:slight_smile:

Ah yes, I did not think about such tool.

- 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.

Great! Then I'll contact you by IM next week to briefly summarize your activities and define together August's roadmap.

Cheers,

···

On 2007/07/24, at 20:00, Bing Su wrote:
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net