Skip to main content

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

Yes

(Richard Barnes)

No Objection

(Barry Leiba)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Sean Turner)

Note: This ballot was opened for revision 04 and is now closed.

Richard Barnes Former IESG member
Yes
Yes (for -04) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2013-06-21 for -04) Unknown
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?
Adrian Farrel Former IESG member
No Objection
No Objection (2013-06-26 for -04) Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2013-06-27 for -04) Unknown
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
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2013-06-23 for -04) Unknown
- 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?)
Stewart Bryant Former IESG member
No Objection
No Objection (2013-06-24 for -04) Unknown
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.
Ted Lemon Former IESG member
(was Discuss) No Objection
No Objection (2013-06-27 for -04) Unknown
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.