Changes between Initial Version and Version 1 of Ticket #2018


Ignore:
Timestamp:
Jun 3, 2017 9:19:51 AM (8 years ago)
Author:
nanang
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #2018 – Description

    initial v1  
    44 
    55==== Specification ==== 
    6  - SDES (the only SRTP keying mechanism currently available in PJMEDIA) and DTLS-SRTP may coexist in run-time, any of them may be disabled (via run-time or compile-time). 
     6 - SDES (the only SRTP keying mechanism currently available in PJMEDIA) and DTLS-SRTP may coexist, any of them may be disabled (at run-time or compile-time). 
    77 - As currently best effort media encryption via SDP capability negotiation is not supported yet, it should be configurable which SRTP keying method to be used in generating offer. And for generating answer, it should detect and use the keying method used by the offer. 
    88 - Support DTLS-SRTP handshake before SDP answer is sent/received. 
    … …  
    1818#define PJMEDIA_SRTP_HAS_DTLS 1 
    1919    }}} 
     20    To disable DTLS-SRTP, just set macro {{{PJMEDIA_SRTP_HAS_DTLS}}} to 0 (by default it is currently disabled). To disable SDES, set macro {{{PJMEDIA_SRTP_HAS_SDES}}} to 0 (by default it is currently enabled). 
     21 
    2022 1. Build PJSIP with [wiki:TLS TLS enabled] using OpenSSL backend. 
    2123 
    … …  
    3335}}} 
    3436 
     37To enable only one keying method at run-time, just set {{{keying_count}}} to 1 and {{{keying[0]}}} to the preferred keying method from the same PJSUA callback, e.g: 
     38{{{ 
     39void on_create_media_transport_srtp(pjsua_call_id call_id, 
     40                                    unsigned media_idx, 
     41                                    pjmedia_srtp_setting *srtp_opt) 
     42{ 
     43    srtp_opt->keying_count = 1; 
     44    srtp_opt->keying[0] = PJMEDIA_SRTP_KEYING_DTLS_SRTP; /* enable only DTLS-SRTP */ 
     45} 
     46}}} 
     47 
     48 
    3549==== Limitation ==== 
    3650This ticket will only implement the core part of DTLS-SRTP, i.e: SRTP key negotiation via DTLS, while DTLS-SRTP itself also depends on other features that we haven't supported yet: 
    37  - SIP signaling integrity protection, provided via: 
    38    - SIP Identity, specified by [https://tools.ietf.org/html/rfc4474 RFC4474] and [https://tools.ietf.org/html/rfc4916 RFC4916], only Authentication Service is needed. 
    39    - S/MIME, specified by [https://tools.ietf.org/html/rfc3261#section-23 RFC3261 section 23]. 
    40    - SIPS, actually we already support this, but as SIPS can't guarantee that all proxies are trusted, the security provided by SIPS is considered weaker. 
    41  - Best effort media encryption via SDP capability negotiation, to offer media channel with multiple configurations (e.g: offering SRTP but also accept plain RTP), this seems to be a [https://tools.ietf.org/html/rfc5763#section-6.11 MUST]. 
     51 1. SIP signaling integrity protection, this may be provided by any of these extensions: 
     52   1. SIP Identity, specified by [https://tools.ietf.org/html/rfc4474 RFC4474] and [https://tools.ietf.org/html/rfc4916 RFC4916], only Authentication Service is needed. 
     53   2. S/MIME, specified by [https://tools.ietf.org/html/rfc3261#section-23 RFC3261 section 23]. 
     54   3. SIPS, actually we already support this, but as SIPS can't guarantee that all proxies are trusted, the security provided by SIPS is considered weaker. 
     55 1. Best effort media encryption via SDP capability negotiation, to offer media channel with multiple configurations (e.g: offering SRTP but also accept plain RTP), this seems to be a [https://tools.ietf.org/html/rfc5763#section-6.11 MUST]. 
     56 
     57==== Behavior change ==== 
     58 1. Media transport UDP can now be attached multiple times, any old attachment will be silently replaced by the latest. This change is done because DTLS nego needs to access the real transport (UDP/ICE) before stream is created (or SDP nego is completed). After SDP nego is completed, stream will invoke media transport {{{attach()}}} again. 
     59 2. Media transport UDP & ICE is equipped with auto-switching RTP/RTCP target address to the address it receives RTP/RTCP from, and there is probation period (i.e: 10 packets) before switching to the new target address, during this probation period all packets from the candidate target address will be discarded. Now those packets will be no longer discarded as long as we have not received any packet from the current known source address (if any). Without this change, any incoming 'TLS hello' will be discarded until probation period is reached or SDP answer is received (which tell us about remote RTP address). 
     60 
    4261 
    4362==== Reference ====