Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
draft-ietf-avtcore-6222bis-06

[Ballot comment]
The discussion of third-party monitoring in 4.1 is uncomfortable. It seems to be encouraging application developers to add hooks to make third-party monitoring easier, which would be great if we thought that this was only going to be used for performance measurement. But of course it can also be used for tracking endpoints through a firewall, or in the presence of temporary IP addresses.

It's hard to see how this text adds value. What was the working group's motivation for including this text?

In 4.2, regarding short-term persistent RTCP names, the document says "In either case, the procedure is performed once per initialization of the software," which contradicts the point made in 4.1 about the purpose of these short-term persistent identifiers and the advice that they are not needed for unrelated streams. It seems to me that you could make this better by saying "at least once" to allow for the possibility that they would cycle more frequently.

The following was a DISCUSS.  Based on Dan Wing's agreement to remove the recommendation to use MAC addresses (see email), I am clearing the DISCUSS.  The above comments have not, as far as I know, been addressed, but were not intended to be blocking.

Using the MAC address of the device for short-term persistent identifiers seems like a privacy problem.

6.2 speaks to this point, but the proposed mitigation assumes that the problem is that an eavesdropper would gain information about the identity of the endpoint using the persistent identifier. In fact, the more likely problem is that the other endpoint would gain that information.

I am not the IESG expert on privacy, so I may be making more out of this than is warranted, but I'd really like to see some additional review of the privacy implications of this before it goes out. I assume such review has not occurred because I see no mention of this issue in the security considerations section. Please let me know if I am mistaken.

You could clear this DISCUSS either by not using the MAC address, by explaining the working group's rationale for why this isn't a problem in a way that is convincing, or by getting someone with more expertise on the subject than I to review it and explain why it isn't an issue, or by implementing whatever mitigation they suggest. To be honest, given the set of names I see as authors of this document, I assume I am missing something, so please don't hesitate to point out what that is.

[Ballot comment]
Let me double-check something regarding the CNAME length
  "To locally produce a unique identifier, we simply generate a
  cryptographically pseudorandom value as described in [RFC4086].  This
  value MUST be at least 96 bits but MAY be longer."
What is the max length? While quickly browsing through RFC 3550, I could not find it.
Why is this important? For management: if we need to access the information via a MIB, NETCONF, IPFIX, ... we need the max length.
I was unable to tell
1. what is the max CNAME length?
2. if the CNAME max length changed compared to RFC 3550

btw, "we" in IETF specifications is not ideal.

Editorial:
  In Section 6.5.1 of the RTP specification, [RFC3550], there are a
  number of recommendations for choosing a unique RTCP CNAME for an RTP
  endpoint. 

The first link "Section 6.5.1" is wrong. It goes to RFC 6222

[Ballot discuss]
Using the MAC address of the device for short-term persistent identifiers seems like a privacy problem.

6.2 speaks to this point, but the proposed mitigation assumes that the problem is that an eavesdropper would gain information about the identity of the endpoint using the persistent identifier. In fact, the more likely problem is that the other endpoint would gain that information.

I am not the IESG expert on privacy, so I may be making more out of this than is warranted, but I'd really like to see some additional review of the privacy implications of this before it goes out. I assume such review has not occurred because I see no mention of this issue in the security considerations section. Please let me know if I am mistaken.

You could clear this DISCUSS either by not using the MAC address, by explaining the working group's rationale for why this isn't a problem in a way that is convincing, or by getting someone with more expertise on the subject than I to review it and explain why it isn't an issue, or by implementing whatever mitigation they suggest. To be honest, given the set of names I see as authors of this document, I assume I am missing something, so please don't hesitate to point out what that is.

[Ballot comment]
The discussion of third-party monitoring in 4.1 is uncomfortable. It seems to be encouraging application developers to add hooks to make third-party monitoring easier, which would be great if we thought that this was only going to be used for performance measurement. But of course it can also be used for tracking endpoints through a firewall, or in the presence of temporary IP addresses.

It's hard to see how this text adds value. What was the working group's motivation for including this text?

In 4.2, regarding short-term persistent RTCP names, the document says "In either case, the procedure is performed once per initialization of the software," which contradicts the point made in 4.1 about the purpose of these short-term persistent identifiers and the advice that they are not needed for unrelated streams. It seems to me that you could make this better by saying "at least once" to allow for the possibility that they would cycle more frequently.

[Ballot comment]
Like Stewart, I am a little surprised that the algorithm described here
is probablistic given that the failure of a previous solution to
guarantee uniqueness is cited as a major motivation for this work.

Given the contradiction implicit in "probably unique", I think that this
document should refresh the readers' minds (even if only by reference)
about the consequences of non-unique choice and how such situations are
resolved.  For example, if the consequence is that there is an extra
protocol exchange to force resolution, then that is one thing.  But if
the protocol will completely fail to work, that is something quite
different.

But I have no objection to the publication of this document.

[Ballot comment]
I have no objection to this being published, but I am slightly disappointed that the proposal is for a probabilistic scheme rather  than a deterministic scheme, which surely must be feasible.

[Ballot comment]

- 6552 updates 3550, does this also? I'm just wondering
if the "updated by" metadata for 3550 will be preserved
or mucked up or what. (Others may know all this, but
I don't:-)

- 4.2, 2nd bullet: just a query - is there any need to
consider base64url encoding here? If so it'd be good to
mention since its often a bit of a mess if discovered
later. (I've no idea if these names might be sent in
URLs or web forms.)

- CNAME is a DNS term of art, and the DNS term is
perhaps the more widely known. I think it'd be good to
distinguish those if that's not already done elsewhere.

- For privacy reasons, changing CNAMEs is a fine plan.
However, an equally fine plan might be to chose a CNAME
from a small set so that transport problems are unlikely
but the identifying precision of the value is minimial.
Was this option considered? (To make it concerete just
to help answer the question, say if N unique values were
enough to ensure the probability of a transport problem
could be ignored then why not just pick a random number
between 1 and N, for the smallest acceptable N?)

[Ballot comment]
I'm a Yes, but did have a couple of comments for the authors. Please consider them, along with other comments you may receive.

For those oi us who aren't wizards at security but might still end up implementing this revised algorithm ... in 1.  Introduction

  For a discussion on the linkability of RTCP CNAMES produced by
  [RFC6222], refer to [I-D.rescorla-avtcore-random-cname].

I thought that reference to the draft was pretty important, but https://datatracker.ietf.org/doc/draft-rescorla-avtcore-random-cname/ is currently expired. I know the reference is listed as Informational, so you won't be stuck in REF-HOLD, but I found the discussion of the linking problem to be short, clear and compelling (where "compelling" means you can tell your boss "If we don't update our implementation, people may die").

If the referenced draft really is stalled, perhaps you could include something like the referenced draft's section 2.1 text (with attribution)?

In 3.  Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME

  This document replaces the use of FQDN as an RTCP
  CNAME by alternative mechanisms.

Not to be pedantic, but the same text is in RFC 6222 :-)

Perhaps it needs to be updated for the current draft, to point to RFC 6222?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-avtcore-6222bis-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names
  (CNAMEs)'
  as 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 2013-06-11. 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.

Abstract


  The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
  persistent transport-level identifier for an RTP endpoint.  While the
  Synchronization Source (SSRC) identifier of an RTP endpoint may
  change if a collision is detected or when the RTP application is
  restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
  endpoints can be uniquely identified and associated with their RTP
  media streams.

  For proper functionality, RTCP CNAMEs should be unique within the
  participants of an RTP session.  However, the existing guidelines for
  choosing the RTCP CNAME provided in the RTP standard are insufficient
  to achieve this uniqueness.  RFC 6222 was published to update those
  guidelines to allow endpoints to choose unique RTCP CNAMEs.
  Unfortunately, later investigations showed that some parts of the new
  algorithms were unnecessarily complicated and/or ineffective.  This
  document addresses these concerns and replaces RFC 6222.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ballot/


No IPR declarations have been submitted directly on this I-D.

Writeup for draft-ietf-avtcore-6222bis-03

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This is request to be published as a proposed standard.

This is the appropriate type as it replaces the existing proposed standard in RFC 6222. Which also was appropriate as this specifies a protocol functionality.


(2) 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

  The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
  persistent transport-level identifier for an RTP endpoint.  While the
  Synchronization Source (SSRC) identifier of an RTP endpoint may
  change if a collision is detected or when the RTP application is
  restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
  endpoints can be uniquely identified and associated with their RTP
  media streams.

  For proper functionality, RTCP CNAMEs should be unique within the
  participants of an RTP session.  However, the existing guidelines for
  choosing the RTCP CNAME provided in the RTP standard are insufficient
  to achieve this uniqueness.  RFC 6222 was published to update those
  guidelines to allow endpoints to choose unique RTCP CNAMEs.
  Unfortunately, later investigations showed that some parts of the new
  algorithms were unnecessarily complicated and/or ineffective.  This
  document addresses these concerns and replaces RFC 6222.
 
Working Group Summary

The requirements for this replacement of RFC 6222 came from RTCWEB WG, which identified the linkability and privacy issue of the previous random method. There was strong WG consensus to address this issue. The method of addressing it, using a cryptographic random number generator, was obvious. The main concern in WG last call has been around the clarity of the motivation for the update.


Document Quality

The Shepherd assumes that this will see significant implementation, especially initially in any WebRTC implementations. The document has gotten a fair amount of reviews in the WG last call.

Personnel

  Magnus Westerlund is the Document Shepherd.
  Richard Barnes is the Responsible Area Director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Shepherd has reviewed the document in WG last call and tracked the changes afterwards. For the writeup the chair has reviewed the draft again for each item in the I-D checklist.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

At the originally stated WG last call dead-line the number of reviews where less than minimal. After some prodding a bit more reviews where received. Sufficient to make the shepherd comfortable with publishing this replacement.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No, if anything it would be to verify that the security goals has been meet. That appears clear from the shepherd's point of view so no additional review has been requeted. The Shepherd assumes a sec-dir review will happen to further verify that nothing obvious has been missed.


(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors have confirmed that they are in conformance.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure was present in the database on the 2013-04-24.


(9) 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? 

Their is a fairly wide agreement on doing this update. The people who reviewed or contributed to the details are much more some few individuals.

(10) 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 publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No ID nits found.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No such review has been deemed necessary.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

One of the informative references [I-D.rescorla-avtcore-random-cname] was a motivation for doing this work, and is not intended to be published.

(14) 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 plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Yes, this will obsolete RFC 6222. That is noted in header, abstract and introduction.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document updates possible ways of generating CNAMES. As they are source only options and opaque strings for any receiver their are no
need to register them. Thus no IANA action necesary as noted by IANA consideration section.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No entries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ID-Nits, but no ther formal languages present.