Download RTP Real-Time Transport Protocol

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

TCP congestion control wikipedia , lookup

Distributed firewall wikipedia , lookup

Computer security wikipedia , lookup

Lag wikipedia , lookup

Net bias wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Remote Desktop Services wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Internet protocol suite wikipedia , lookup

Cross-site scripting wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

RapidIO wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Serial digital interface wikipedia , lookup

IEEE 1355 wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Deep packet inspection wikipedia , lookup

Quality of service wikipedia , lookup

UniPro protocol stack wikipedia , lookup

Real-Time Messaging Protocol wikipedia , lookup

Transcript
RTP
Real-Time Transport Protocol
Patrick Burke
Craig Webb
Outline
•
•
•
•
•
•
•
Introduction
RTP Network Stack
Design Goals
2 Protocols in 1
RTP Packet Format
RTCP Packet Format
Vulnerabilities
Intro / What is RTP?
• RFC 3550/3551 (obsoletes RFC 1889/1890)
• End-to-end delivery for real-time data
– Video/audio conferencing
– Simulations
– VOIP
• Provides functions to support loss, out-oforder, jitter, source/payload identification,
rate control
RTP Network Stack
• Closely coupled with the transport layer
(usually UDP)
Design Goals / What it does...
•
•
•
•
•
•
•
Lightweight - specification and implementation
Flexible - provide mechanism, don’t dictate algorithms
Protocol-neutral - UDP/IP, ST-II, IPX...
Scalable - unicast, multicast 2 to O(107)
Separate data and control - RTP / RTCP
Separate packets for different media types
Support for encryption
Design Goals / What it doesn’t do...
• Ensure timely delivery
• Ensure quality-of-service
• Prevent out-of-order delivery
Provides mechanisms for detecting/measuring these but relies
on Transport layer and/or Application. Example: Relies on
UDP checksum service.
Separate data and control
(Two protocols - consecutive UDP ports)
• RTP
– encapsulates data
– adds sequencing, timestamp, source identification
• RTCP (RTP Control Protocol)
– provides control information
– QoS feedback
RTP packet header
RTP packet header
•
•
•
•
Version - currently 2
Padding - used in encryption
Extension - used in some implementations
CSRC count - number of contributing source indentifiers (maximum of
15)
• Marker - significant events, defined by implementation (i.e. frame
boundaries)
• Payload type - audio/video encoding method
• SSRC - synchronization source, randomly generated at start of session
(no 2 SSRC within the same RTP session can have the same identifier)
RTP Packet Header
• Sequence number
–
–
–
–
Initial value is random,
Increment by 1 each RTP packet sent
Loss detection
Out-of-order detection
• Timestamp
– Used for synchronization
– Allows for QoS feedback (jitter calculations)
– Rate adaptation
RTP mixers and translators
• Mixer
– several media streams to one new stream
– becomes the new SSRC
• Translator
– converts data encoding
RTCP packet types
• SR - sender report, transmission and reception statistics
from active members
• RR - receiver report, reception statistics from non-active
members
• SDES - source description items, CNAME (user@host)
plus any other pertinent info
• BYE - end of participation
• APP - application-specific functions
RTCP packet
• Each RTCP packet begins with a fixed part followed by
structured elements of variable length (must end on a 32
bit boundary).
• Stackable within 1 UDP packet.
RTCP packet
• Periodically sent from:
– Transmitting terminal to receiving terminal
– Receiving terminal to transmitting terminal
• Main functions are:
– Rate control
– Membership identification
– QoS tracking
Issues and Vulnerabilities
• Theoretical Vulnerabilities
• Security Philosophy
• Documented Vulnerabilities
Theoretical Vulnerabilities
• RTP is a relative new-comer
– RFC 1889 approved in 1996
– RFC 3550 approved in 2003
• Functionally identical with 1880
• Updates to rules and algorithms governing how the
protocol is to be used
• Widely used, but few documented
exploitations documented to date
Theoretical Vulnerabilities
• Theoretically vulnerable to common
transportation-layer weaknesses:
– Denial of Service
• SSRC assumption by unauthorized user
• Packet injection
• Fake content inserted before real
– QoS Bandwidth Attack
– Embedded encryption breakable
• Sometimes KEY transmitted in the clear
Security Philosophy
• Network “attacks” hard to recognize without
specific knowledge of application
– Targeted communication is high-speed
• Audio/Visual Communicaiton
• Multicast Communication
• Authentication & Encryption, where required, are
implemented at lower layers
– RTCP statistics are available to help
– “Physician, heal thyself”
Documented Vulnerabilities
• Total of 24 patents found referencing RTP
– Only 2 directly relate to RTP
• 6,856,613 – Throttling audio packets to processing
capacity
• 6,728,265 – Controlling frame transmission rate
– Remainder merely mention RTP as a
recommended or suggested transport method
Documented Vulnerabilities
• Only 3 documented CERT vulnerabilities
– VU#460350 – Apple Quicktime Streaming
Server
• There is an error in the way Quicktime parses
“DESCRIBE requests containing specially crafted
User-Agent fields. An attacker could exploit this
vulnerability by sending a DESCRIBE request with
an overly large User-Agent field.”
– Legitimate users would be blocked from streamed content
• Apple released a patch for this condition
Documented Vulnerabilities
• CERT vulnerabilities (continued)
– VU#148564 – Apple Quicktime Streaming
Server
• Includes a utility called MP3Broadcaster which
contains an integer overflow which may be
exploited to cause a DoS attack.
• No practical solution known by CERT
• Must be prevented by disabling unauthenticated
remote broadcasts
Documented Vulnerabilities
• CERT vulnerabilities (continued)
– VU#934932 – RealNetworks Helix Universal
Server 9
• Contains buffer overflow protection in two plug-in
modules which has allowed remote attackers to
execute arbitrary code causing the Server to crash
• No practical solution known by CERT
• Must be prevented by removing the associated plugins: vsrcplin and vsrc3260
References
• http://www/cs/columbia.edu/~hgs/rtp/faq.html
• http://www.kb.cert.org/vuls
• Kurose & Ross, Computer Networking, 2003
Questions
• What is the main purpose of RTP?
– End-to-end delivery for real-time data
• Video/audio conferencing
• Simulations
• VOIP
• What is the purpose of RTCP?
– Provide RTP control information and QoS
feedback
Questions
• Why does RTP rely on the applications to
provide security measures?
– Targeted communication is high-speed
(Audio/Visual and Multicast) making
recognition of an attack without specific
application knowledge difficult.