Subject: Re: [MMUSIC] RTSP: dest_addr in the response

From: "Mike Severa" <[email-masked]>
Date: Mon, 3 Nov 2008 09:48:16 -0800

I am guessing the goal is for a server always to echo the dest_addr parameter specfied by the client, i.e., never to allow something like
 
C - > S:  ... dest_addr="192.1.2.3:4567"
 
S - > C:  ... dest_addr=":4567"
 
Even though a SHOULD here might imply that this is legal (and as long as the latter were not part of a 463 error response, the implied semantics would be that the server processed the request and will deliver the RTP to the requested host).
 
Note, C.2.2 specifies echoing for dest_attr in a way which I believe other text in the body of the RFC implies, however it is in the context of a specific use case there so its not clear how generally applicable that is intended to be. Is that echoing specified somewhere else that I missed, or is C.2.2 sufficient to disallow something like above (even if logic should be enough..) ?
 
thanks,
 
Mike

________________________________

From: [email-masked] on behalf of Magnus Westerlund
Sent: Fri 31.10.2008 03:00
To: HAAS Christian
Cc: [email-masked]
Subject: Re: [MMUSIC] RTSP: dest_addr in the response

HAAS Christian skrev:
> Hello;
>
> From: Behalf Of Rémi Denis-Courmont
>>> Responses to request including the Transport header with a dest_addr
>>> parameter SHALL include the full destination address that is actually
>>> used by the server.
>> I don't really care. I think this informations is of no use to the
>> client anyway.
>
> I also see this of little use for the client -- at most it could verify that
> the IP is actually his own.
> But I'd suggest it to be good practice (SHOULD) to return the full address
> for debugging/tracing.
>

Okay, I was thinking for the same purpose of debugging and verifying
that the server see something that you think are correct. I don't see
any security risks here thus I was thinking of forcing this with a SHALL
for more usability. But I can write a SHOULD also.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Nov 2008 19:19:15 +0100

Mike Severa skrev:
> I am guessing the goal is for a server always to echo the dest_addr
> parameter specfied by the client, i.e., never to allow something like
>  
> Even though a SHOULD here might imply that this is legal (and as long as
> the latter were not part of a 463 error response, the implied semantics
> would be that the server processed the request and will deliver the RTP
> to the requested host).
>  
> Note, C.2.2 specifies echoing for dest_attr in a way which I believe
> other text in the body of the RFC implies, however it is in the context
> of a specific use case there so its not clear how generally applicable
> that is intended to be. Is that echoing specified somewhere else that I
> missed, or is C.2.2 sufficient to disallow something like above (even if
> logic should be enough..) ?
>  

I think we have several things here to consider. First of all is that
the text tries to be protocol agnostic, while it is easy to think about
RTP over UDP. Secondly, I agree that the above really shouldn't happen
unless the protocol really needs it to happen. Which isn't likely.

I suggest to add the following sentence after the SHOULD sentence:

The server MUST NOT remove address information present already in the
request when responding unless the protocol requires it.

Solves it?

Cheers

Magnus Westerlund

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 4 Nov 2008 09:30:45 +0200

On Friday 31 October 2008 09:51:44 ext HAAS Christian, you wrote:
> I also see this of little use for the client -- at most it could verify
> that the IP is actually his own.

Now that you mention it, it would allow immediately detecting NAT error 
scenarios, instead of waiting for some implementation-specific timeout.

Should the client also not be required to include the address? Then the server 
will reject the query (in the common case) if it does not match the remote 
address of the control connection.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "HAAS Christian" <[email-masked]>
Date: Tue, 4 Nov 2008 09:44:11 +0100

Hello!

From: Rémi Denis-Courmont [mailto:[email-masked]] 
> > [...]
> [...]
> Should the client also not be required to include the address?
> Then the server will reject the query (in the common case) if it
> does not match the remote address of the control connection.

As currently discussed in the other thread, the client might be required to
always include the destination address;
Yet I would not go that far as to bind the (unicast) media destination 1:1 to
the controlling client.

Regards,
ch
____________________________________________________
Christian Haas
Team DIVOS, Software Engineer
FREQUENTIS AG

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 - 8353
Mobile   +43-664-60 850 - 8353
Fax       +43-1-811 50 - 77 8353
Web      www.frequentis.com
E-Mail    [email-masked]
 
Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600
____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 4 Nov 2008 10:56:07 +0200

On Tuesday 04 November 2008 10:44:11 ext HAAS Christian, you wrote:
> Yet I would not go that far as to bind the (unicast) media destination 1:1
> to the controlling client.

For RTP/AVP/UDP;unicast, I fail to see an alternative that would not turn the 
RTSP server into a DDoS proxy. Except in a walled garden trusted network.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Nov 2008 16:21:14 +0100

> RTSP server into a DDoS proxy. Except in a walled garden trusted network.

Okay, there are several reasons why this is not always required.

For X/Y/TCP when the client is active there is no requirement to provide
the dest_addr, i.e. TCP source address as this is learned when
connecting. Considering that TCP many times is used when there is
middleboxes present knowing the address the server sees is commonly not
possible. Thus not requiring this make things work. Security
implications are minimal due to TCP 3-way handshake.

For RTP/AVP/UDP the reason to exclude the address is similar. You are
going to hope the middlebox is port preserving and uses the same IP
address for all flows, including between TCP and UDP. Thus leave IP
address out of the dest_addr and let the server use the one from the TCP
connection. Security is the same as above as RTSP TCP connection is used
for address determination.

I agree that no destination address without a mechanism that ensures the
return routability at least to the client is very dangerous. But I think
these cases are covered in the security discussion around the
destination header.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic