1 / 6

SDP Security Descriptions for Media Streams

This draft proposes a framework for establishing secure media streams by sending security descriptions, ciphers, keys, etc. in SDP. It includes changes such as removing support for multicast and multipoint SRTP sessions, addressing SIP forking, and clarifying negotiation parameters.

eshaffer
Download Presentation

SDP Security Descriptions for Media Streams

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SDP Security Descriptions for Media Streams draft-ietf-mmusic-sdescriptions-03.txt March 3, 2004 Flemming Andreasen (fandreas@cisco.com) Mark Baugher (mbaugher@cisco.com) Dan Wing (dwing@cisco.com)

  2. Purpose • Establish secure media streams by sending security descriptions with ciphers, keys, etc. in SDP • Divided into core frameworkand an SRTP-specific part: • High-level Operation and parameter definition • Use with Offer/Answer • Use outside Offer/Answer • Grammar

  3. Overview of Changes • Removed support for multicast and multipoint SRTP sessions • Point-to-point media streams only • SIP forking addressed via workaround • Turn multipoint into multiple point-to-point instead. • Removed SRC parameter • SSRC, SEQ and ROC no longer signaled • ROC must always be zero when joining a session • Send and receive keys now required to be unique to avoid two-time pad problem during SSRC collissions.

  4. Overview of Changes, cont. • Expanded on rules for creating and removing crypto contexts • Added new “tag” parameter for offer/answer • Clarified whether each parameter is negotiated or declarative in offer/answer • Modified IANA registry structure • Incorporated various other review comments received

  5. Minor Issue - Address Change • Scenario: • A has performed initial offer/answer exchange • Crypto context established • A performs a subsequent offer/answer exchange and receives a new media stream destination address • Issue: • Cannot assume new destination address has access to old crypto context ROC value • Solution: • Need to either reset ROC (to zero) or use new SSRC whenever destination address changes (IP or port) • Note that ROC is not an issue for all types of ciphers

  6. Next Steps • Ready for WGLC

More Related