Port Mapping between Unicast and Multicast RTP Sessions
draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02

[Ballot discuss]
Overall I like this document and what its trying to do.

The max token size is 1024 bits - right? If so, that would not be enough to allow use of many public key encryption schemes and would also prevent inclusion of more complex data within a token (e.g. additional client or session attributes). I can understand that you might not want that now but it seems a bit arbitrary to limit token size like that. Did (or would) the WG consider a two byte length field?

[Ballot comment]
I don't object to this document being published, but I must say for someone outside of the area, this is rather dense and difficult to comprehend. In particular, getting through section 3 is nearly impossible without a lot of forward-reference looking. It took me reading through all of sections 4 and 5 to finally figure out (a) that the Token is simply a server-generated hash of the client's IP address, a time-to-live, and some random data generated by the client (section 3 says that "The Token is essentially an opaque encapsulation", and I have no idea what that is supposed to mean); and (b) that the client is told of the Token's expiration when it requests the Token. I would really like that first part of section 3 to lay out the basic principles in easier to understand language.

[Ballot comment]
One comment from Ari Keränen who helped me with some of the reviews:

Section 7.2. says "The use of SDP for the port mapping solution normatively requires the support for [...] Multiplexing RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761]".

Isn't this a requirement for the whole mechanism (if RTP and RTCP are used on the same ports as defined in section 3), not just with SDP? Perhaps the RFC5761 requirements should already be mentioned in section 3?

[Ballot comment]
(1)  s/If there is no NAT devices/If there are no NAT devices/

(2) p20 says:  key-id || hash-alg (client-ip | nonce | abs-expiration) but since you're recommending HMAC-SHA1 that should be mac-alg rather than hash-alg.

(3) Since the client controls all the inputs to the recommended HMAC calculation, except the expiration time, which may be guessable, it really had better not be the case that that same secret key is used for something else that could get fooled if presented with a token. This is perhaps an unlikely cross-protocol attack (though with manual key management, perhaps not that unlikely) but I'd suggest a sentence in the security considerations saying servers MUST NOT use the same secret from the recommended scheme for other purposes.

[Ballot discuss]
Overall I like this document and what its trying to do.

The max token size is 1024 bits - right? If so, that would not be enough to allow use of many public key encryption schemes and would also prevent inclusion of more complex data within a token (e.g. additional client or session attributes). I can understand that you might not want that now but it seems a bit arbitrary to limit token size like that. Did (or would) the WG consider a two byte length field?

[Ballot discuss]
#1) Section 5 contains the following text:

  An example way for constructing Tokens is to perform HMAC-SHA1
  [RFC2104] on the concatenated values of the information listed above.
  The HMAC key needs to be at least 160 bits long, and generated using
  a cryptographically secure random source [RFC4086].  While HMAC-SHA1
  is the RECOMMENDED procedure, implementations might adopt different
  approaches.

The paragraph starts off saying HMAC-SHA1 is an example.  It then later says it's the recommended way.  It would be much clearer if the paragraph said initially that HMAC-SHA1 is the recommended approach. And, then maybe spin "needs to be" as "MUST be": if HMAC-SHA1 is used then the HMAC key MUST be 160 bits long, and generated using ...

[Ballot discuss]
#1) Section 5 contains the following text:

  An example way for constructing Tokens is to perform HMAC-SHA1
  [RFC2104] on the concatenated values of the information listed above.
  The HMAC key needs to be at least 160 bits long, and generated using
  a cryptographically secure random source [RFC4086].  While HMAC-SHA1
  is the RECOMMENDED procedure, implementations might adopt different
  approaches.

The points: 1) The paragraph starts off saying HMAC-SHA1 is an example.  It then later says it's the recommended way.  It would be much clearer if the paragraph said initially that HMAC-SHA1 is the recommended approach. And, then maybe spin "needs to be" as "MUST be": if HMAC-SHA1 is used then the HMAC key MUST be 160 bits long...

IANA understands that, upon approval of this document, there are four
actions that need to be completed.

First, in the SDP attribute registry for Media level only attributes
("att-field (media level only)" located in the Session Description
Protocol (SDP) Parameters registry at:

http://www.iana.org/assignments/sdp-parameters

a new registration will be added as follows:

SDP Name: portmapping-req
Reference: [ RFC-to-be ]

Second, in the RTCP Control Packet types sub-registry of the Real-Time
Transport Protocol (RTP) Parameters registry located at:

http://www.iana.org/assignments/rtp-parameters

the following RTCP Control Packet type will be registered:

Value: tbd
Abbreviation: TOKEN
Name: Port Mapping
Reference: [ RFC-to-be ]

Third, IANA is to establish a new sub-registry for the sub-message type
(SMT) values to be used with the TOKEN packet type. The registry is
called the "SMT Values for TOKEN Packet Type Registry." The rule to be
used to manage this registry is IETF Review. The new registry is to be
located in:

http://www.iana.org/assignments/rtp-parameters

The initial registrations in this registry are:

Value Name Reference
----- -------------------------------------------------- -------------
0 Reserved [ RFC-to-be ]
1 Port Mapping Request [ RFC-to-be ]
2 Port Mapping Response [ RFC-to-be ]
3 Token Verification Request [ RFC-to-be ]
4 Token Verification Failure [ RFC-to-be ]
5-30 Unassigned IETF Review
31 Reserved [ RFC-to-be ]

Fourth, in the RAMS Response Code Space Registry located in:

http://www.iana.org/assignments/rtp-parameters

a new Response Code will be registered as follows:

Code: 405
Description: Invalid Token
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Port Mapping Between Unicast and Multicast RTP Sessions) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'Port Mapping Between Unicast and Multicast RTP Sessions'
  as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-03-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Roni Even. I have reviewed the document, and
believe it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document is the result of an effort done by key WG members in order to
address a problem encountered in RAMS (Rapid Acquisition for RTP) which was
recognized as a general problem that requires a solution. The current
approach reflects that consensus in the WG. It went through two Working
Group last calls and people had enough time to review it. The document
shepherd feels comfortable with the review it got.

Note that the document started at AVT and was at -11 revision before it was
moved to the new AVTCore WG.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No Concerns

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document has strong consensus for key members of the AVT/AVTCore WGs.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No

(1.g) Has the Document Shepherd personally verified that the

document satisfies all ID nits?(See the Checklist and idnits
).Boilerplate checks are not enough;
this check needs to be thorough. Has the document met all formal review
criteria it needs to, such as the MIB Doctor, media type and URI type
reviews?

The idnits tool reports a comment which is not correct about the latest
version of draft-ietf-avt-rapid-acquisition-for-rtp which is 17 and not 16.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split. There is a normative reference to
draft-ietf-avt-rtp-cnames which is in the RFC Editor queue.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA consideration section exists and is inline with the body of the
document.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

No such sections

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

"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 or packet
amplification attacks that could be used to cause one or more RTP
packets to be sent to a victim client."

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

There was a discussion if to use a token or cookie for the solution. The
initial solution was based on a cookie but after a technical discussion in
IETF78 and mailing list call for consensus the token based solution was
selected. There was a consensus to use this approach.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

The document shepherd is not aware of current implementations but the
vendors of RAMS solution will support