Subject: [secdir] Secdir review of draft-ietf-avtcore-6222bis-03

From: Magnus Nyström <[email-masked]>
Date: Sun, 9 Jun 2013 23:37:23 -0700

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

This avtcore document describes a new method for generating unique RTCP
canonical names and obsoletes RFC 6222.
The Security Considerations section seems adequate to me.

(A few side comments:
- RFC 6222 is mentioned in several places (e.g., Section 1, Section 8).
Should it not also be a reference?
- In Section 4.2, it is stated that, if the RTP endpoint is in a
virtualized environment, then the MAC address may not be unique. In such
cases, the host shall use the other presented option for short-term
persistent RTP CNAMEs. I wonder if it in general is possible for an RTCP
endpoint to deterministically determine if its MAC address is unique? It is
not in general possible for a process to detect if it is running in a
virtualized OS.)

Thanks,
-- Magnus

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 10 Jun 2013 13:30:08 +0000

On Jun 10, 2013, at 9:37 AM, Magnus Nyström <[email-masked]> wrote:

> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  

Thanks.

> These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
> This avtcore document describes a new method for generating unique RTCP canonical names and obsoletes RFC 6222.
> 
> - RFC 6222 is mentioned in several places (e.g., Section 1, Section 8). Should it not also be a reference?

I dont think it should as we are not requiring something from 6222. we are simply mentioning it to emphasize what 6222 did and what this document is doing.

> - In Section 4.2, it is stated that, if the RTP endpoint is in a virtualized environment, then the MAC address may not be unique. In such cases, the host shall use the other presented option for short-term persistent RTP CNAMEs. I wonder if it in general is possible for an RTCP endpoint to deterministically determine if its MAC address is unique? It is not in general possible for a process to detect if it is running in a virtualized OS.)

I am not sure about this (i.e., do not know how easy for a program to determine whether it is in a virtual system or not). I think if a program is likely to be in a virtual OS, it can simply default to the other option.

---

From: Magnus Nyström <[email-masked]>
Date: Mon, 10 Jun 2013 07:56:35 -0700

For the first comment, then I think you should remove the [RFC6222] from
the first section because that definitely looks like a reference to me. It
is your call, it has nothing to do with security, but when you refer to
what is done in a different document several times then I would recommend
you to include it at least as an informational reference.

For the second comment, how would a program developer know if his program
is likely to be executed in a virtualized OS? I think today, pretty much
any program could in which case this alternative (the MAC alternative)
looks a bit doubtful to even have in there to me.

Thanks,
/M

On Mon, Jun 10, 2013 at 6:30 AM, Ali C. Begen (abegen) <[email-masked]>wrote:

> > I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
>
> Thanks.
>
> > These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these comments
> just like any other last call comments.
> I dont think it should as we are not requiring something from 6222. we are
> simply mentioning it to emphasize what 6222 did and what this document is
> doing.
>
> I am not sure about this (i.e., do not know how easy for a program to
> determine whether it is in a virtual system or not). I think if a program
> is likely to be in a virtual OS, it can simply default to the other option.
>
> >
> > Thanks,
> > -- Magnus
>
>

-- 
-- Magnus