[Live-devel] Transport header VLC client

[Matthew Krenzer]

We have had similar issues in the past multihoming boxes with other
protocols (icmp, radius, and a few others).  In the end the solution has
always been to modify the client to bind outbound requests to a specific
address.  If you know the desired target address at the time of the RTSP
request and the address exists on the box the request comes from (as in
multihoming), you should just ensure the request actually originates
from the desired target address.  

I think as a general rule (not sure here - and assuming bsd sockets), if
you don't bind a socket before calling connect the OS assigns (somewhat
of) a random source udp/tcp port number and chooses as the source
address the  ipaddress of the interface through which it thinks the
packing will go - which is not always the desired source address.

To do otherwise would be, as Ross points out, a potentially large
vulnerability.

Matthew


> -----Original Message-----
> From: live-devel-bounces at ns.live555.com [mailto:live-devel-
> bounces at ns.live555.com] On Behalf Of Ashutosh Dutta
> Sent: Tuesday, February 27, 2007 11:42 PM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] Transport header VLC client
> 
> Ross, thanks for your reply. I agreed with DOS attack part.
> 
> However, in some cases (e.g., multihoming case), the client may like
to
> receive the stream in a specific desired address. Thus having the
> ability to receive at a particular address (interface) is sometimes
> desirable. It is good to know that the RTSP server has some optional
> settings. I guess, one needs to update the RTSP client to get this
> feature.
> 
> Thanks
> Ashutosh
> 
> 
> 
> 
> Ross Finlayson wrote:
> >> I was curious if anybody has experience using transport header in
VLC
> >> client code to designate the address where the server should play
it
> >> stream. This is the example from RTSP RFC 2326bis.
> >>
> >>>  C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
> >>>             CSeq: 302
> >>>             Transport: RTP/AVP;multicast;mode="PLAY",
> >>>                 RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
> >>>                 "192.0.2.5:3457";mode="PLAY"
> >>>
> >>>       S->C: RTSP/2.0 200 OK
> >>>             CSeq: 302
> >>>             Date: 23 Jan 1997 15:35:06 GMT
> >>>             Session: 47112344
> >>>             Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
> >>>             "192.0.2.5:3457";src_addr="192.0.2.224:6256"
> >>>             /"192.0.2.224:6257";mode="PLAY"
> >
> > Note that the "LIVE555 Streaming Media" code does not yet support
> > (for either clients or servers) the RTSP 2.0 proposal (as defined by
> > the "2326bis" Internet Draft).  We currently support only the RTSP
> > 1.0 standard (RFC 2326).  In RTSP 1.0, the parameter that you're
> > referring to is called "destination", not "dest_addr".
> >
> > In any case, our RTSP client implementation (and thus, VLC) does not
> > support this.  Neither does our RTSP server implementation (except
in
> > some normally #ifdef'd out code in "RTSPServer.cpp").  Note that
> > allowing the client to specify the IP address that the server should
> > send has major security implications - it would effectively make
> > possible denial-of-service attacks on innocent third parties - and
so
> > probably no RTSP server anywhere supports this feature by default.
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel