Standards Track A. Rao Netscap - RFC Editor

More documents

Recommendations

Info

RFC 2326 Real Time Streaming Protocol April 1998users of the servers. See [H15.3] for HTTP serverrecommendations regarding server logs.Transfer of Sensitive Information:There is no reason to believe that information transferred viaRTSP may be any less sensitive than that normally transmittedvia HTTP. Therefore, all of the precautions regarding theprotection of data privacy and user privacy apply toimplementors of RTSP clients, servers, and proxies. See[H15.4] for further details.Attacks Based On File and Path Names:Though RTSP URLs are opaque handles that do not necessarilyhave file system semantics, it is anticipated that manyimplementations will translate portions of the request URLsdirectly to file system calls. In such cases, file systemsSHOULD follow the precautions outlined in [H15.5], such aschecking for ".." in path components.Personal Information:RTSP clients are often privy to the same information that HTTPclients are (user name, location, etc.) and thus should beequally. See [H15.6] for further recommendations.Privacy Issues Connected to Accept Headers:Since may of the same "Accept" headers exist in RTSP as inHTTP, the same caveats outlined in [H15.7] with regards totheir use should be followed.DNS Spoofing:Presumably, given the longer connection times typicallyassociated to RTSP sessions relative to HTTP sessions, RTSPclient DNS optimizations should be less prevalent.Nonetheless, the recommendations provided in [H15.8] are stillrelevant to any implementation which attempts to rely on aDNS-to-IP mapping to hold beyond a single use of the mapping.Location Headers and Spoofing:If a single server supports multiple organizations that do nottrust one another, then it must check the values of Locationand Content-Location headers in responses that are generatedunder control of said organizations to make sure that they donot attempt to invalidate resources over which they have noauthority. ([H15.9])In addition to the recommendations in the current HTTP specification(RFC 2068 [2], as of this writing), future HTTP specifications mayprovide additional guidance on security issues.Schulzrinne, et. al. Standards Track [Page 74]
RFC 2326 Real Time Streaming Protocol April 1998The following are added considerations for RTSP implementations.Concentrated denial-of-service attack:The protocol offers the opportunity for a remote-controlleddenial-of-service attack. The attacker may initiate trafficflows to one or more IP addresses by specifying them as thedestination in SETUP requests. While the attacker’s IP addressmay be known in this case, this is not always useful inprevention of more attacks or ascertaining the attackersidentity. Thus, an RTSP server SHOULD only allow clientspecifieddestinations for RTSP-initiated traffic flows if theserver has verified the client’s identity, either against adatabase of known users using RTSP authentication mechanisms(preferably digest authentication or stronger), or othersecure means.Session hijacking:Since there is no relation between a transport layerconnection and an RTSP session, it is possible for a maliciousclient to issue requests with random session identifiers whichwould affect unsuspecting clients. The server SHOULD use alarge, random and non-sequential session identifier tominimize the possibility of this kind of attack.Authentication:Servers SHOULD implement both basic and digest [8]authentication. In environments requiring tighter security forthe control messages, the RTSP control stream may beencrypted.Stream issues:RTSP only provides for stream control. Stream delivery issuesare not covered in this section, nor in the rest of this memo.RTSP implementations will most likely rely on other protocolssuch as RTP, IP multicast, RSVP and IGMP, and should addresssecurity considerations brought up in those and otherapplicable specifications.Persistently suspicious behavior:RTSP servers SHOULD return error code 403 (Forbidden) uponreceiving a single instance of behavior which is deemed asecurity risk. RTSP servers SHOULD also be aware of attemptsto probe the server for weaknesses and entry points and MAYarbitrarily disconnect and ignore further requests clientswhich are deemed to be in violation of local security policy.Schulzrinne, et. al. Standards Track [Page 75]
Page 2 and 3:
RFC 2326 Real Time Streaming Protoc
Page 4 and 5:
Page 7:
Page 10 and 11:
Page 12 and 13:
Page 14 and 15:
Page 16 and 17:
Page 18 and 19:
Page 20 and 21:
Page 22 and 23:
Page 24 and 25: RFC 2326 Real Time Streaming Protoc
Page 92: RFC 2326 Real Time Streaming Protoc
show all

Standards Track A. Rao Netscap - RFC Editor

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?