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

[Colin Perkins <[e-mail]>]

Ali,

On 8 Dec 2010, at 02:15, [e-mail] wrote:
> 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.


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/