Subject: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-06.txt

From: [email-masked]
Date: Tue, 07 Dec 2010 18:15:03 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title           : Port Mapping Between Unicast and Multicast RTP Sessions
	Author(s)       : A. Begen, et al.
	Filename        : draft-ietf-avt-ports-for-ucast-mcast-rtp-06.txt
	Pages           : 32
	Date            : 2010-12-07

This document presents a port mapping solution that allows RTP
receivers to choose their own ports for an auxiliary unicast session
in RTP applications using both unicast and multicast services.  The
solution provides protection against denial-of-service attacks that
could be used to cause one or more RTP packets to be sent to a victim
client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-ports-for-ucast-mcast-rtp-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 9 Dec 2010 23:48:09 +0000

Ali,

This update addresses most of my concerns with the -04 version of the draft. The remaining issues are:

> - Section 3.2, 4th bullet on page 8: the discussion of how the token may remain valid for multiple sessions is unclear. It may be clearer to say that the token is valid for that port on the server until its expiration time, irrespective of what that port is used for. Following on from this, would it be appropriate to add a warning that the server port SHOULD NOT be reused for other RTP sessions until the expiration time of the tokens issued?

The first half of this has been addressed, thanks. I didn't spot anything warning that the server port shouldn't be reused when there are unexpired token outstanding: did I just miss it, or is this not important?

> - Section 3.2 is written as an example, but uses RFC 2119 language, and contains many normative requirements. I would suggest that Section 3 be split into two Sections: one giving the motivating example, and another giving normative requirements for use of the port mapping extensions to RTCP.

While Section 3.2 has been split into two parts, I believe this is still an open issue. The new text at the start of Section 3.2.1 is clear, but Section 3.2.2 still normatively refers to the example scenario. I think this port mapping scheme is more generally useful than just in RAMS-like scenarios, so I'd encourage Section 3.2.2 to be updated to be much more generally applicable. The basic normative description of the extensions is included on the last half of page 9 ("The following steps summarise the Token-based solution:") and page 10; page 8 and the first half of page 9 focus on the RAMS example and, while they may be normative for that use case, they aren't necessary for the protocol description.

> - Section 5 should discuss timings and failure modes. RTCP is not a timely or reliable protocol. What is the expected behaviour if these messages are lost and/or delayed? (e.g., that's the retransmission behaviour).

The text to address this, in Section 4, is good. One addition might be to mandate that the server MUST be prepared to handle duplicate requests and MUST generate the same token in response to a duplicate request, and that the client MUST ignore duplicate responses, to get consistency in how this is handled.

> - Section 5: The RTCP extensions defined here are exchanged in order to setup a unicast session, rather than to provide feedback on an existing session. Accordingly, it's not clear that they should be sent as RTCP Feedback messages. Would it be appropriate to define new RTCP packet types to convey this information, rather than trying to shoehorn this into transport layer feedback packets (this would also avoid the problem of how to set the SSRCs)?

I still believe it would be appropriate to define new RTCP packet types to convey this information, rather than trying to shoehorn these into transport layer feedback packets. 

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 19:49:59 -0800

Hi Colin,

> > - Section 3.2, 4th bullet on page 8: the discussion of how the token may remain valid for multiple sessions is unclear. It may
> be clearer to say that the token is valid for that port on the server until its expiration time, irrespective of what that port is
> used for. Following on from this, would it be appropriate to add a warning that the server port SHOULD NOT be reused for
> other RTP sessions until the expiration time of the tokens issued?
> 
> The first half of this has been addressed, thanks. I didn't spot anything warning that the server port shouldn't be reused when
> there are unexpired token outstanding: did I just miss it, or is this not important?

The unexpired (outstanding) tokens are not important for the server-side ports.
 
> > - Section 3.2 is written as an example, but uses RFC 2119 language, and contains many normative requirements. I would
> suggest that Section 3 be split into two Sections: one giving the motivating example, and another giving normative
> requirements for use of the port mapping extensions to RTCP.
> 
> While Section 3.2 has been split into two parts, I believe this is still an open issue. The new text at the start of Section 3.2.1 is
> clear, but Section 3.2.2 still normatively refers to the example scenario. I think this port mapping scheme is more generally
> useful than just in RAMS-like scenarios, so I'd encourage Section 3.2.2 to be updated to be much more generally applicable.
> The basic normative description of the extensions is included on the last half of page 9 ("The following steps summarise the
> Token-based solution:") and page 10; page 8 and the first half of page 9 focus on the RAMS example and, while they may be
> normative for that use case, they aren't necessary for the protocol description.

OK, I will give another shot. Let me know if -07 version looks good (submitted soon).
 
> > - Section 5 should discuss timings and failure modes. RTCP is not a timely or reliable protocol. What is the expected
> behaviour if these messages are lost and/or delayed? (e.g., that's the retransmission behaviour).
> 
> The text to address this, in Section 4, is good. One addition might be to mandate that the server MUST be prepared to handle
> duplicate requests and MUST generate the same token in response to a duplicate request, and that the client MUST ignore
> duplicate responses, to get consistency in how this is handled.

The server does not really keep any state about the earlier requests. Which means, when a client repeats the request (assuming it will use the same random number and its IP will not change), the server still may not produce the same token since the server could be advancing the expiration time based on the request's arrival time. I don't see a reason why this would be a problem. From operational viewpoint, both are valid tokens. If the client somehow gets two Token responses (which are probably different), it could discard the one expiring sooner, or the other. Does not matter IMO.
 
> > - Section 5: The RTCP extensions defined here are exchanged in order to setup a unicast session, rather than to provide
> feedback on an existing session. Accordingly, it's not clear that they should be sent as RTCP Feedback messages. Would it be
> appropriate to define new RTCP packet types to convey this information, rather than trying to shoehorn this into transport
> layer feedback packets (this would also avoid the problem of how to set the SSRCs)?
> 
> I still believe it would be appropriate to define new RTCP packet types to convey this information, rather than trying to
> shoehorn these into transport layer feedback packets.

This is duly noted. However, I respectfully have to say that we did not do this for RAMS and making such a big change at this stage does not seem like a good idea to me. We are bending some rules but I think we are within a reasonable margin :)

Thanks.
-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Dec 2010 10:37:26 +0100

> This is duly noted. However, I respectfully have to say that we did not do this for RAMS and making such a big change at this stage does not seem like a good idea to me. We are bending some rules b…

The fact that we did not do it for RAMS is a mote question, unless you
are of the view that once you made a misstake you can never do
differently in the future? ;-)

I am also of the opinion that using a new RTCP packet type would be
better here. We can still use AVPF early or immediate transmission modes
etc, only note this in the spec.

Secondly, as you are defining sub types that really show that you should
use its own packet type. I would also note that the messages have quite
different semantics from what we previously have in feedback with the
exception of RAMS then.

I know you want to finish this up. But it appears to me that you haven't
really gotten enough eyes on the proposal until the last month
considering how many different suggestions for improvements you are now
getting. I think we can slow down slightly and actually consider this.
This is a general mechanism that will be used for a potentially large
number of applications and future extensions within RTP. Which is
another difference from RAMS, rams does one thing in one context. Port
mapping is a building block that already is used by at least two
separate mechanism and I expect more in the future. Thus I think we
should ensure that we get it as right as possible.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
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]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Dec 2010 22:47:39 +0000

Hi Ali,

> OK, I will give another shot. Let me know if -07 version looks good (submitted soon).

That's a lot better. I would still clarify in the introduction to section 3.2.2 “are not specific to that particular example” -> “are not specific to that particular example, and can be applied to any scenario where analogous ports can be identified” or similar.

Colin

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 13 Dec 2010 15:04:31 -0800

> That's a lot better. I would still clarify in the introduction to section 3.2.2 “are not specific to that particular example” -> “are
> not specific to that particular example, and can be applied to any scenario where analogous ports can be identified” or
> similar.

Sure. This will show up in -09. I am waiting on Magnus' review that I hope to receive tomorrow.

-acbegen