Add support of encryption of RTP Header Extentions

[fluffy]

No description provided.

[kristiankielhofner]

I use a proprietary testing platform (Ixia) that makes extensive use of RTP header extensions and I'd like to use it with various projects that use libsrtp.

I see there hasn't been any follow-up or progress on this. I'm not a C programmer but is there anything I can do to help add support for RTP header extensions?

[jfigus]

Do you know which RTP header extensions are used by Ixia? Are they
proprietary, or does it use standards-based extensions? Does Ixia
follow the RFC 3550 limitation of one extension per packet? Or is it
using RFC 5285 that allows multiple extensions?

On 10/30/2013 03:28 PM, Kristian Kielhofner wrote:

I use a proprietary testing platform (Ixia) that makes extensive use
of RTP header extensions and I'd like to use it with various projects
that use libsrtp.

I see there hasn't been any follow-up or progress on this. I'm not a C
programmer but is there anything I can do to help add support for RTP
header extensions?

—
Reply to this email directly or view it on GitHub
#14 (comment).

[kristiankielhofner]

Unfortunately I don't have much experience with RTP header extensions either. This is what Wireshark says:

Real-Time Transport Protocol
[Stream setup by SDP (frame 3)]
[Setup frame: 3]
[Setup Method: SDP]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...1 .... = Extension: True
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: ITU-T G.711 PCMU (0)
Sequence number: 24714
[Extended sequence number: 90250]
Timestamp: 8128
Synchronization Source identifier: 0x8170a7d0 (2171643856)
Defined by profile: 17408
Extension length: 2
Header extensions
Header extension: 106
Header extension: 428099064
SRTP Encrypted Payload: 49473757013d6e6c12f730f65f91d5a3f313b7bf95aa3c61...

[jfigus]

I don't know the full history on why support for header extensions was never added. One concern is the header extensions are not encrypted. This may result in leaking information about the session. The RTP application developer may not be aware of the security ramifications associated with the data they choose to include in the extension.

If you're willing to help test, we could pull a branch to experiment with header extension support. Having not looked at this in detail, it's difficult to estimate how much work is required to support this. I suspect there's not a lot of code to write. But testing it properly will take more effort.

Any chance you can provide the pcap file so I can load this into wireshark myself?

[JonathanLennox]

Unencrypted (but authenticated) header extensions, as defined in RFC 3711, work.

RFC 6904 encrypted header extensions aren't currently supported. Adding support for them wouldn't be very difficult; the trickiest thing would be defining a sensible API for them, since you need to configure which header extension elements are encrypted and which ones aren't.

However, RFC 6904 only defines encryption of RFC 5285-style header extensions. Looking at Kristian's wireshark capture, it doesn't look like he's using RFC 5285 header extensions -- his "defined by profile" field is 17408 (0x4400 hex), whereas for RFC 5285 header extensions it should either be either 48862 (0xBEDE hex) for the one-byte-header form, or else in the range 4096-4111 (0x1000 - 0x100F hex) for the two-byte header form.

On Oct 30, 2013, at 4:33 PM, John Foley <notifications@github.commailto:notifications@github.com>
wrote:

I don't know the full history on why support for header extensions was never added. One concern is the header extensions are not encrypted. This may result in leaking information about the session. The RTP application developer may not be aware of the security ramifications associated with the data they choose to include in the extension.

If you're willing to help test, we could pull a branch to experiment with header extension support. Having not looked at this in detail, it's difficult to estimate how much work is required to support this. I suspect there's not a lot of code to write. But testing it properly will take more effort.

Any chance you can provide the pcap file so I can load this into wireshark myself?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-27436337.

[jfigus]

Thanks for the background information, this is very helpful. However, I'm confused with the Ixia issue. Is Ixia using libsrtp to generate SRTP traffic? My initial assumption was Ixia was simply generating RTP traffic, with the RTP->SRTP encapsulation occurring somewhere on the network. But if unencrypted header extensions are currently working today in libsrtp, this implies Ixia is using libsrtp to generate the SRTP traffic itself or there's a bug. Maybe krisk84 can provide some more detail on the Ixia configuration and network topology.

[kristiankielhofner]

I can provide the full capture via e-mail:

http://mailhide.recaptcha.net/d?k=012PZI4sbQlTnxcLg8649zCg==&c=lHrNvWa_qu8TLUyBRphs6qxY7lGznwRwYBvT5nho-jQ=

The Ixia is generating the SRTP stream natively using some unknown/proprietary implementation. The tshark packet detail I provided is from the Ixia SRTP stream towards FreeSWITCH (latest master). I'm unable to tell if FreeSWITCH decodes the received SRTP packets but the outbound SRTP stream (from FreeSWITCH to Ixia) reports "SRTP protection failed with code 8" on the FreeSWITCH console (code here):

http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_rtp.c?hb=true#to5795

FreeSWITCH currently uses a fairly old version of libsrtp so (for kicks) I updated it to a current checkout of the feature-openssl branch and applied this patch:

https://codereview.chromium.org/21094005/

In this configuration FreeSWITCH now reports "SRTP protection failed with code 2". If it helps I'm compiling against OpenSSL 1.0.1e.

Plain RTP streams between FreeSWITCH and the Ixia work perfectly. If it helps, I'm using IxLoad and this load module:

http://www.ixiacom.com/products/xcellon/xcellon_ultra_np_load_module/index.php

Hopefully this helps clarify my situation. Thank you all for your responses!

[jfigus]

Do you know if Ixia is encrypting the RTP header extension? Looking at
the Chromium patch that you applied to libsrtp, it returns error code 2
if it's unable to parse the extension header. If the header extension
is encrypted, this may explain why you're seeing error code 2. The
Chromium patch wouldn't derive the correct length of the header extension.

It would be interesting to see the result of this test w/o the Chromium
patch applied. It may revert back to the old error code 8.

Is there any way to disable encryption of the RTP header extension on
Ixia? It would be interesting to see the test result if you can do this.

On 10/30/2013 07:03 PM, Kristian Kielhofner wrote:

I can provide the full capture via e-mail:

http://mailhide.recaptcha.net/d?k=012PZI4sbQlTnxcLg8649zCg==&c=lHrNvWa_qu8TLUyBRphs6qxY7lGznwRwYBvT5nho-jQ=

The Ixia is generating the SRTP stream natively using some
unknown/proprietary implementation. The tshark packet detail I
provided is from the Ixia SRTP stream towards FreeSWITCH (latest
master). I'm unable to tell if FreeSWITCH decodes the received SRTP
packets but the outbound SRTP stream (from FreeSWITCH to Ixia) reports
"SRTP protection failed with code 8" on the FreeSWITCH console (code
here):

http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_rtp.c?hb=true#to5795

FreeSWITCH currently uses a fairly old version of libsrtp so (for
kicks) I updated it to a current checkout of the feature-openssl
branch and applied this patch:

https://codereview.chromium.org/21094005/

In this configuration FreeSWITCH now reports "SRTP protection failed
with code 2". If it helps I'm compiling against OpenSSL 1.0.1e.

Plain RTP streams between FreeSWITCH and the Ixia work perfectly. If
it helps, I'm using IxLoad and this load module:

http://www.ixiacom.com/products/xcellon/xcellon_ultra_np_load_module/index.php

Hopefully this helps clarify my situation. Thank you all for your
responses!

—
Reply to this email directly or view it on GitHub
#14 (comment).

[kristiankielhofner]

I don't know if the Ixia is encrypting the extensions or not but if I re-run the test without SRTP enabled they are different. However, seeing as I have no idea what the extensions are used for this isn't definitive.

I will be able to retry this test tomorrow with the latest libsrtp with FreeSWITCH without the Chromium patch applied.

[jfigus]

Thanks for sending the full wireshark capture. There are a couple of
items that look inconsistent. First, as Jonathan indicated, the Ixia
is sending the value 0x4400 in the "define by profile" field. This
seems to be inconsistent with the RFC. It's possible Ixia has a bug. It
may be worth an inquiry with Ixia about this if you happen to have a
support contract with them.

Second, the header extension values coming from the other device appear
to be in little endian byte order on the wire. For example, the IXIA is
sending:

Defined by profile: 0x4400
Extension length: 0x0002

But the other side is sending:

Defined by profile: 0x0044
Extension length: 0x0200

This results in a 'malformed packet' error in wireshark since it's
decoding an extension length of 512, but the UDP packet length is only
196. I'm not aware that libsrtp modifies the extension header bytes.
This may be a bug in the RTP stack that's using libsrtp.

On 10/30/2013 07:03 PM, Kristian Kielhofner wrote:

I can provide the full capture via e-mail:

http://mailhide.recaptcha.net/d?k=012PZI4sbQlTnxcLg8649zCg==&c=lHrNvWa_qu8TLUyBRphs6qxY7lGznwRwYBvT5nho-jQ=

The Ixia is generating the SRTP stream natively using some
unknown/proprietary implementation. The tshark packet detail I
provided is from the Ixia SRTP stream towards FreeSWITCH (latest
master). I'm unable to tell if FreeSWITCH decodes the received SRTP
packets but the outbound SRTP stream (from FreeSWITCH to Ixia) reports
"SRTP protection failed with code 8" on the FreeSWITCH console (code
here):

http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_rtp.c?hb=true#to5795

FreeSWITCH currently uses a fairly old version of libsrtp so (for
kicks) I updated it to a current checkout of the feature-openssl
branch and applied this patch:

https://codereview.chromium.org/21094005/

In this configuration FreeSWITCH now reports "SRTP protection failed
with code 2". If it helps I'm compiling against OpenSSL 1.0.1e.

Plain RTP streams between FreeSWITCH and the Ixia work perfectly. If
it helps, I'm using IxLoad and this load module:

http://www.ixiacom.com/products/xcellon/xcellon_ultra_np_load_module/index.php

Hopefully this helps clarify my situation. Thank you all for your
responses!

—
Reply to this email directly or view it on GitHub
#14 (comment).

[kristiankielhofner]

Testing today with libsrtp/feature-openssl and without the Chromium patch applied it reverted back to returning error code 8 on srtp_protect.

I will work with FreeSWITCH on the byte swap issues.

[kristiankielhofner]

If anyone is interested it was fixed with this commit:

http://fisheye.freeswitch.org/changelog/freeswitch.git?cs=b0d95efd09d010154a8422c611feb64c64a1e71f

[jfigus]

Closing this issue since it appears to have been fixed in freeswitch.