Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
RFC 6222

[Ballot discuss]
The Gen-ART Review by Suresh Krishnan on 2-Jan-2011 raised an issue
  that needs to be resolved before publication. Section 5, Step 2,
  describes the use of an EUI-64 identifier and how to generate one if
  it does not exist. The procedure for the creation of the EUI-64 from a
  48-bit MAC address is incorrect:

  RFC 4291 describes how to create a *modified* EUI-64 identifier (not a
  EUI-64 identifier) from a MAC address. A MAC address of
  xx:78:90:12:34:56 will be transformed to a modified EUI-64 of
  yy7890FFFE123456, where yy is the value of xx with the u/l bit (bit 6)
  flipped. The IEEE reference for creation of an EUI-64 from a 48-bit
  MAC address (http://standards.ieee.org/develop/regauth/tut/eui64.pdf)
  would result in an EUI-64 of xx7890FFFF123456 for the same MAC address.

  While I recognize that no interoperability issues will result from
  this difference, there may be issues with testing if this is not
  resolved. Therfore, I suggest using the term "modified EUI-64" instead
  of EUI-64 or changing the reference from RFC 4291 to the IEEE
  document.

[Ballot discuss]
This is an updated discuss based on the -04 version.

#1) (this might be nit picking) If you not looking for anything out of the hash alg there's actually three properties that should be in this phrase from Section 6.1:

OLD:

collision-resistant or second-preimage resistant

NEW:

collision-resistant, preimage-resistant, or second-preimage resistant

#2) addressed

[Ballot comment]
I support Sean's discuss: hard-coding SHA-1 is unnecessary and counterproductive.  There is no reason that all
clients need to use the same secure hash algorithm, IMHO.  (For example, two clients using SHA-256 and SHA-512
are no more likely to generate a collision than two clients using SHA-256.)  I suggest "compute a message digest
using a secure hash function (e.g., SHA-256)" would provide the right level of detail for section 5.

A short paragraph should also be added to the security considerations section with appropriate references.  (I think
Sean's discuss has the right list.)

I would also note that the algorithm in section 5 does not *guarantee* uniqueness.  I think your odds of a collision
are one in 2**48 (but check with a real mathematician!).  I note this since the Requirements section states "It is
believed that obtaining uniqueness is an important property ..."

Section 4.2, third bullet:

"After performing the procedure, the significant 96 bits are used ..."

Please specify "most significant" or "least significant"; the latter would be consistent with the preceding bullet.

[Ballot discuss]
#2 was revised based on some side discussions.

#1) Section 5: On the use of SHA-1:  What properties are you looking from the output?  If you require no collisions then SHA-1 is probably a bad idea (see https://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/).  It would be much better to use SHA-256 and truncate it.  And, then point to https://datatracker.ietf.org/doc/draft-eastlake-sha2b/.  Yes it is a dependency but it's in AD Evaluation.

#2) Section 5: Algorithm agility would be really nice here.  Locking yourself in to one hash algorithm isn't a good idea.  If the client is the only entity that is ever going to generate this hash true algorithm agility might not be needed, but you could get it by picking a length you want and then saying that one of the algorithms x, y, or z MUST be used.  That way the implementer can pick on that they're doing in their cipher suite.

[Ballot discuss]
This is a fine document with the laudable goal of improving interoperability, but in one respect I think it is both overly specific and unclear about the requirements it is working to meet.

Section 4.1 states:

  An implementation that wishes to
  discourage this type of third-party monitoring can generate a unique
  RTCP CNAME for each RTP session....

However, a unique identifier does not necessarily discourage third-party monitoring, e.g., incrementing from UniqueID-1 UniqueID-2 might ensure uniqueness but not privacy. I suggest that we provide a reference to RFC 4086 here and recommend that those who desire privacy need to generate identifiers that are not only unique but also random.

This issue is connected to Section 4.2, which mandates one algorithm for long-term identifiers and a different algorithm for short-term identifiers (with seemingly different security properties, since long-term identifiers are 36 octets in length whereas short-term identifiers are only 17 octets in length). Would an implementation that generates a UUID for short-term identifiers violate the spec? If so, why? As long as the short-term identifier is unique, the implementation has met the relevant requirement. (Perhaps there is a further requirement or desire to make the identifier random, as mentioned above, but that is a separate issue.)

[Ballot comment]
Section 4: Need to add "NOT RECOMMENDED" to Section 2.  It's used as a key word and the 2119 errata allow it, but you need to include it as shown in the errata (http://www.rfc-editor.org/errata_search.php?rfc=2119).

Any chance for an example per-session unique identifier?

[Ballot discuss]
Section 5: On the use of SHA-1:  What properties are you looking from the output?  If you require no collisions then SHA-1 is probably a bad idea (see https://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/).  It would be much better to use SHA-256 and truncate it.  And, then point to https://datatracker.ietf.org/doc/draft-eastlake-sha2b/.  Yes it is a dependency but it's in AD Evaluation.

Section 5: Algorithm agility would be really nice here.  Locking yourself in to one hash algorithm isn't a good idea.

[Ballot discuss]
Section 4: Need to add "NOT RECOMMENDED" to Section 2.  It's used as a key word and the 2119 errata allow it, but you need to include it as shown in the errata (http://www.rfc-editor.org/errata_search.php?rfc=2119).

Section 5: On the use of SHA-1:  What properties are you looking from the output?  If you require no collisions then SHA-1 is probably a bad idea (see https://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/).  It would be much better to use SHA-256 and truncate it.  And, then point to https://datatracker.ietf.org/doc/draft-eastlake-sha2b/.  Yes it is a dependency but it's in AD Evaluation.

Section 5: Algorithm agility would be really nice here.  Locking yourself in to one hash algorithm isn't a good idea.

[Ballot comment]
Support Stewart's Discuss since we have observed "clone" equipment with identical MAC addresses in the past. Also, I believe that some h/w exists with configurable MAC addresses.

---

Abstract
s/these/those/

[Ballot discuss]
The Gen-ART Review by Suresh Krishnan on 2-Jan-2011 raised an issue
  that needs to be resolved before publication. Section 5, Step 2,
  describes the use of an EUI-64 identifier and how to generate one if
  it does not exist. The procedure for the creation of the EUI-64 from a
  48-bit MAC address is incorrect:

  RFC 4291 describes how to create a *modified* EUI-64 identifier (not a
  EUI-64 identifier) from a MAC address. A MAC address of
  xx:78:90:12:34:56 will be transformed to a modified EUI-64 of
  yy7890FFFE123456, where yy is the value of xx with the u/l bit (bit 6)
  flipped. The IEEE reference for creation of an EUI-64 from a 48-bit
  MAC address (http://standards.ieee.org/develop/regauth/tut/eui64.pdf)
  would result in an EUI-64 of xx7890FFFF123456 for the same MAC address.

  While I recognize that no interoperability issues will result from
  this difference, there may be issues with testing if this is not
  resolved. Therfore, I suggest using the term "modified EUI-64" instead
  of EUI-64 or changing the reference from RFC 4291 to the IEEE
  document.

[Ballot discuss]
Section 4: Need to add "NOT RECOMMENDED" to Section 2.  It's used as a key word and the 2119 errata allow it, but you need to include it as shown in the errata (http://www.rfc-editor.org/errata_search.php?rfc=2119).

Section 5: On the use of SHA-1:  What properties are you looking from the output?  If you require no collisions then SHA-1 is probably a bad idea (see https://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/).  It would be much better to use SHA-256 and truncate it.  And, then point to https://datatracker.ietf.org/doc/draft-eastlake-sha2b/.  Yes it is a dependency but it's in AD Evaluation.

[Ballot discuss]
I think it would be helpful to the reader to briefly note that whilst the methods described in this document are good enough for most practical purposes they are not technically perfect. Whilst I can see no particular problem in the application described here, these methods may well be re-purposed as convenient  general purpose UID mechanisms.

Specifically when the method described in (5) does not use an EUI-64 there is a non-zero probability of collision, and the method in (4) that uses the MAC address is only as good as the quality procedures and ethics of the hardware manufacturer.

[Ballot comment]
1.
>    After obtaining a identifier by doing (a) or (b),
      the least significant 48 bits are converted to the standard colon-
      separated hexadecimal format, e.g., "00:23:32:af:9b:aa", resulting
      in a 17-octet printable string representation.

It would be good to provide a reference for this 'standard ... format'. RFC 5342 uses a different notation, so arguably there is more than one format used in RFCs.

2. Also from 5342 - here is a reference for EUI-64 which could be added (also answers the COMMENT from Alexey)

[EUI-64]  IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
            Registration Authority", , March 1997.

TSV DIR Review

TSV-DIR Last Call review of "Guidelines for Chosing RTP Control Protocol
(RTCP) Canonical Names (CNAMEs)

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors for their information and to allow them to address any issues
raised. The authors should consider this review together with any other
last-call comments they receive.  Please always cc tsv-dir@ietf.org if you
reply to or forward this review.

Summary: This draft is on the right track, but has open issues described in
the review.

The review below gives my basis for three recommendations:
1. For long-term persistent CNAMEs, differentiate among the UUID "Versions"
in RFC 4122
2. For short-term persistent CNAMEs, allow IPv4-only endpoints to generate a
pseudo-random alternative to their MAC, if desired
3. For per-session CNAMEs, provide some guidance for the random value and
the key, which are currently left underspecified.

Section 3 sets up the major requirement to be met, which is better
uniqueness properties than those of the CNAME generation in RFC 3550.
There's a hint in the last sentence of the section about an additional
requirement to afford privacy support.  This sentence only mentions avoiding
exposure of private addresses.  Avoidance of linkage among RTP streams due
to the use of fixed CNAMEs comes up later.

Section 4 sets up the CNAME types, persistent versus per-session, and within
persistent types, short-term IPv4-only, short-term IPv6-capable, and
long-term.  The methods of generating these CNAMEs are distinct and I
understand from the WG mailing list discussion of their AD review that they
are to be specified as mandatory.  On December 2, Ali wrote to AVT that the
next revision will change language in Section 4 from the existing:

  Other methods, beyond the three methods listed above, are not
  compliant with this specification and SHOULD NOT be used.

To the following:

  It is believed that obtaining uniqueness is an important property that
  requires careful evaluation of the method. This document provides a
  number of methods, for which it is believed that at least one of them
  would meet all deployment scenarios. This document therefore does not
  provide for the implementor to define and select an alternative
  method.

  A future specification might define an alternative method for
  generating RTCP CNAMEs as long as the proposed method has appropriate
  uniqueness, and there is consistency between the methods used for
  multiple RTP sessions that are to be correlated. However, such a
  specification needs to be reviewed and approved before deployment.

The second sentence of the first paragraph could be written better:

  This document provides a number of methods, at least one of which
  should be suitable for all deployment scenarios.

My remaining discussion is about making this statement more true.

First, all the methods should afford some access to privacy support, but as
written, there is little or none for the long-term persistent and the
IPv4-only short-term persistent CNAMEs.

                                    An implementation that wishes to
  discourage this type of third-party monitoring can generate a unique
  RTCP CNAME for each RTP session, or group of related RTP sessions,
  that it joins.  Such a per-session RTCP CNAME cannot be used for
  traffic analysis, and so provides some limited form of privacy

The above statement implies that a long-term persistent CNAME inherently
cannot have privacy support.  It's not necessarily so: if the CNAME doesn't
embed identifying information, observers get connections among multiple
streams but they only don't have a fixed host identity, only a pseudonym.

Specific issues per CNAME method:

1) Long-term persistent CNAMEs are required to be generated by an adaptation
of RFC 4122 UUIDs (the adaptation is to leave off the string "urn:uuid:").
The draft references Section 3 of RFC 4122.  It should reference Section 4
instead because Section 3 does not detail the UUID components.  Moreover, it
would be good for the draft to advise on usage among the four different
versions of UUID that RFC 4122 covers:

+ Version 1: generated from clock + MAC, or + MAC-format random number
+ Version 3: generated from namespace:name
+ Version 4: generated from "truly random or pseudo-random number"
+ Version 5: generated from hash of namespace:name

There needs to be some guidance because the use of the UUID Versions 3/5,
derived from namespace:name, has the same problem with non-uniqueness of
FQDNs as the RFC 3550 FQDN-based CNAMEs.  Perhaps this document should
advise against using 3/5.  In addition, right now the draft is silent on
mitigating identity exposure, but it could offer some guidance towards using
the variant of Version 1 that does not expose the MAC or towards using
Version 4.

2) Short-term persistent CNAMEs  are allowed to use a pseudo-randomly
generated RFC 4941 IPv6 privacy address if the device is IPv6-capable, but
are required to exposetheir MACs if the device is IPv4-only.  Why not allow
IPv4-only endpoints to to generate pseudo-random MACs using the
specification of doing so provided for the Version 1 variant in RFC 4122?

3) Per-session CNAMEs are generated using SHA1-HMAC over the concatenation
of the initially-used SSRC, the source and destination addresses and ports,
and "a randomly generated value".  RFC 4086 is given as a reference for the
randomly generated value.  I think an implementer would like to know how
many bytes of randomly generated value should be used; this doesn't come out
clearly from reading RFC 4086. Further, what are the requirements for the
key for HMAC here?  In reading RFC 2104, the reference for HMAC, I end up
with some ideas about the key length, but not about how long/where I can use
the same key or whether there are problematic keys - to mention two
questions that come to mind.  Keying would not normally be easy to
under-specify this way because a security application would call for some
keying details, but in this application there is no security use for the
keys.  Either it would be good to add some guidance or perhaps SHA1-HMAC
could be replaced with an "insecure hash."  Thoughts about this have arisen
from re-reading EKR's SAAG talk from IETF 73:

www.ietf.org/proceedings/08nov/slides/saag-0.pdf

With best regards to all,

Allison
mankin@psg.com / allison.mankin@gmail.com / allison.mankin@jhuapl.edu

[Ballot comment]
5.  Procedure to Generate a Unique Identifier

  2.  Obtain an EUI-64 identifier from the system running this

I think this needs an Informative reference to a document which explains what is EUI-64.

      algorithm.  If an EUI-64 does not exist, one can be created from
      a 48-bit MAC address as specified in [RFC4291].  If an EUI-64
      cannot be obtained or created, a suitably unique identifier,
      local to the node, should be used (e.g., system serial number).

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:  (Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)) to Proposed Standard


The IESG has received a request from the Audio/Video Transport WG (avt)
to consider the following document:
- 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names
  (CNAMEs)'
  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 2010-12-14. 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-avt-rtp-cnames/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-cnames/

Shepherd writeup for draft-ietf-avt-rtp-cnames-02 " Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" as
proposed standard.

  (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 for this document is Keith Drage.

The document shepherd has reviewed the document and believes it is ready for
forwarding to the IESG for publication.

Document history:

- draft-begen-avt-rtp-cnames-00 was submitted 14th April 2010 and
expires 16th October 2011;
- draft-begen-avt-rtp-cnames-01 was submitted 5th May 2010 and
expires 6th November 2011;
- draft-begen-avt-rtp-cnames-02 was submitted 24th May 2010 and
expires 25th November 2011;
- draft-ietf-avt-rtp-cnames-00 was submitted 17th June 2010 and
expires 19th December 2011;
- draft-ietf-avt-rtp-cnames-01 was submitted 26th August 2010 and
expires 27th February 2011;
- draft-ietf-avt-rtp-cnames-01 was submitted 10th November 2010
and expires 14th May 2011;

Call for adoption of baseline as WG item was made 4th June 2010 and
acceptance declared 16th June 2010.

Working group last call was initiated on -00 version on 4th August 2010
for completion 25th August 2010 as proposed standard. Reviews were
received from Jonathan Lennox and Keith Drage.

Prior to working group last call,.comments had been received from Qin
Wu, Dan Wing, Colin Perkins, and Peter Musgrave.

  (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 has been adequately reviewed (see 1a above). This is a very simple
document and numerous substantial comments would not be expected.

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

There are no such concerns from the document shepherd.

  (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.

There are no concerns from the document shepherd from this perspective with the
document.

No IPR disclosures have been made against this document.

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

From a reviewing perspective, the interest in this specific document has been
relatively small, but it forms an essential part of draft-ietf-avt-rapid-
acquisition-for-rtp which has been well and substantially reviewed. It
is assumed that the interested parties in that document have also reviewed this
document.

  (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 appeals or areas of conflict or discontent have been identified.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/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?

Version 2.12.05 of ID nits identifies no issues.

No other formal reviews outside of the AVT working group are perceived as
necessary for this document.

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

The document does split normative and informative references. All the normative
references have been reviewed and are correctly allocated as normative
references. None of these normative references constitute a down reference.

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

There are no IANA considerations required in this document. It creates no new
values of any parameter.

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

There is no formal language in the document.

  (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.
    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?
    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 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.  This memo updates these guidelines to
allow endpoints to choose unique RTCP CNAMEs.

The document achieved consensus in the AVT working group.