Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt

From: [email-masked]
Date: Mon, 08 Jul 2013 14:29:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.

	Title           : Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
	Author(s)       : Ali Begen
                          Colin Perkins
                          Dan Wing
                          Eric Rescorla
	Filename        : draft-ietf-avtcore-6222bis-05.txt
	Pages           : 10
	Date            : 2013-07-08

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 9 Jul 2013 10:10:32 +0200

WG,

This document has just been in IESG review and the authors has discussed
with the IESG. One discuss raised was the implications of the MAC based
generation of short-term persistent CNAMES. The conclusion in that
discussion was to remove that option and rely only on random names in
that case.

I wanted to inform the WG about this significant change and give you a
chance to react to this change before the document is approved. You will
have one week to react.

The details can be seen in this diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-05

Cheers

Magnus Westerlund

On 2013-07-08 23:29, [email-masked] wrote:
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 9 Jul 2013 15:38:32 +0000

No comment on removing option a), but later in the document I did note the sentence:

"This	value MUST be at least 96 bits and MAY be up to 512 bits."

To me "MAY defines an option, and therefore this appears to be stating that the upper limit is optional, whereas I believe you are stating:

"This	value MUST be at least 96 bits and MUST be less than 512 bits."

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Magnus Westerlund
> Sent: 09 July 2013 09:11
> To: [email-masked]
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt
> 
> WG,
>

---

From: Dan Wing <[email-masked]>
Date: Tue, 9 Jul 2013 19:15:03 -0700

> "This	value MUST be at least 96 bits and MUST be less than 512 bits."

RFC4096 ("Randomness Requirements for Security") has as its longest output 512 bits, and that document is what we cite for generating the random value.  A value longer than 512 bits is permitted, and would not cause interoperability problems; it just needs to fit into the CNAME space, which has a maximum size of 255 octets of ASCII characters.  If there is need to specify the maximum length to conform to RFC3550's CNAME length limit, that maximum would be 255 octets * 3 / 4 = 191.25 octets (the 3/4 is to for binary to BASE64 encoding, the .25 octets gets into nuance of BASE64 encoding, I don't want to worry about BASE64 encoders).  But that is a limit of CNAME encoding in RFC3550.  I propose draft-ietf-avtcore-6222bis just say "The value MUST be at least 96 bits" and not worry about the maximum -- CNAME already has a maximum due to its 255 octet length.

-d

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 10 Jul 2013 14:11:42 +0000

If that applies then I agree.

I might suggest an informative statement indicating that the maximum length is fixed by RFC 3550.

Keith

> From: Dan Wing [mailto:[email-masked]]
> Sent: 10 July 2013 03:15
> To: DRAGE, Keith (Keith)
> Cc: Magnus Westerlund; [email-masked]
> > To me "MAY defines an option, and therefore this appears to be stating
> that the upper limit is optional, whereas I believe you are stating:
> >
> RFC4096 ("Randomness Requirements for Security") has as its longest output
> 512 bits, and that document is what we cite for generating the random
> value.  A value longer than 512 bits is permitted, and would not cause
> interoperability problems; it just needs to fit into the CNAME space,
> which has a maximum size of 255 octets of ASCII characters.  If there is
> need to specify the maximum length to conform to RFC3550's CNAME length
> limit, that maximum would be 255 octets * 3 / 4 = 191.25 octets (the 3/4
> is to for binary to BASE64 encoding, the .25 octets gets into nuance of
> BASE64 encoding, I don't want to worry about BASE64 encoders).  But that
> is a limit of CNAME encoding in RFC3550.  I propose draft-ietf-avtcore-
> 6222bis just say "The value MUST be at least 96 bits" and not worry about
> the maximum -- CNAME already has a maximum due to its 255 octet length.
> 
> -d
> 
> 
> 
> >
> > Regards
> >
> > Keith
> >
> >>> This draft is a work item of the Audio/Video Transport Core
> Maintenance
> >> Working Group of the IETF.
> >>>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 10 Jul 2013 10:56:22 -0700

> chance to react to this change before the document is approved. You will

I've read the changes and they look fine to me.

---

From: Kevin Gross <[email-masked]>
Date: Mon, 15 Jul 2013 11:10:08 -0600

Yes, this is a significant change. It appears to imply that a cryptographic
PRNG is required in every RTP device and things will be more difficult for
3rd party network performance monitoring systems.

Although there is discussion in the draft downplaying these issues, there
are RTP applications that won't otherwise require a CPRNG and there are
applications where ease of monitoring is more important than security.

What was the reason given for wanting to remove the MAC option?

If we go with this, I suggest an editorial pass to reduce repetition in the
last two bullets in section 4.2 and clean up references to "multiple",
"several" as there are now only two methods recommended for generating
CNAMEs. Let me know if you need any help with this.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 15 Jul 2013 17:26:04 +0000

MAC addresses are not unique anymore, so cannot be reliably used for cname generation.

On Jul 15, 2013, at 10:10 AM, Kevin Gross <[email-masked]> wrote:

> Yes, this is a significant change. It appears to imply that a cryptographic PRNG is required in every RTP device and things will be more difficult for 3rd party network performance monitoring systems.
> 
> Although there is discussion in the draft downplaying these issues, there are RTP applications that won't otherwise require a CPRNG and there are applications where ease of monitoring is more important than security.
> 
> If we go with this, I suggest an editorial pass to reduce repetition in the last two bullets in section 4.2 and clean up references to "multiple", "several" as there are now only two methods recommended for generating CNAMEs. Let me know if you need any help with this.
> 
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com, www.X192.org
> 
> 
> On Tue, Jul 9, 2013 at 2:10 AM, Magnus Westerlund <[email-masked]> wrote:
> WG,
>

---

From: Kevin Gross <[email-masked]>
Date: Mon, 15 Jul 2013 14:48:41 -0600

I've done quick research on this issue and it is real and I'm surprised it
has not been more disruptive. MAC addresses have been assumed by many to be
globally unique for a long time.

Sorry if this has already been discussed somewhere, but it seems harsh to
remove MAC-based CNAMEs entirely. They can be used safely in many
environments and there at least two motivations for doing so. Can we demote
MAC-based CNAMEs to NOT RECOMMENDED instead?

There are other instances in the draft where we describe how previous
recommendations were found to be lacking. How about we add something to the
draft to explain why MAC-based CNAMEs are no longer permitted/recommended.
I'm willing to help with this.

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Mon, Jul 15, 2013 at 11:26 AM, Ali C. Begen (abegen) <[email-masked]>wrote:

> > Yes, this is a significant change. It appears to imply that a
> cryptographic PRNG is required in every RTP device and things will be more
> difficult for 3rd party network performance monitoring systems.
> >
> > Although there is discussion in the draft downplaying these issues,
> there are RTP applications that won't otherwise require a CPRNG and there
> are applications where ease of monitoring is more important than security.
> >
> > If we go with this, I suggest an editorial pass to reduce repetition in
> the last two bullets in section 4.2 and clean up references to "multiple",
> Maintenance Working Group of the IETF.
> > >