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

Magnus Nyström <magnusn@gmail.com> Mon, 10 June 2013 14:56 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8B421F86CA; Mon, 10 Jun 2013 07:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbATUZG4z2aO; Mon, 10 Jun 2013 07:56:42 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0440A21F940D; Mon, 10 Jun 2013 07:56:36 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id q56so5026207wes.3 for <multiple recipients>; Mon, 10 Jun 2013 07:56:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oQgAr7SDuqpZtYQlkF+L/RjN84fvSNdmeze7mvnHZjY=; b=qwkYH7Rrkx0YkGODPMEuDafv6VbTBB2778IoP7lqxrNDIO4d20sxM2/tVYXC/za2/B e9uMuuH54Hy0Kcz09j+ULyDC3n0WvHQJhIxWBRqybiM1fpaP+MmSHFpso58XK8KqOhgq 8MGwuJhSaf/qRl+OCitpWbHrR1Ck1sDP3D6gECXEz6JlXBYzSJ5vltTJ0+clFAc9gTEC vstrxvbkjxNZv19G+t52QIbPg1y14Yai9XWYWS/Bcd7z0jV5yzjikfsN6lxrve1or+an TdOo0vApJ5YYQsxgtKO1/h6/K/5u6yPXHOffWgDKgPps7ocFXRhL760ozK6RewfXhVs5 gJEQ==
MIME-Version: 1.0
X-Received: by 10.180.105.231 with SMTP id gp7mr4894739wib.23.1370876195775; Mon, 10 Jun 2013 07:56:35 -0700 (PDT)
Received: by 10.180.163.168 with HTTP; Mon, 10 Jun 2013 07:56:35 -0700 (PDT)
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940D12D493@xmb-aln-x01.cisco.com>
References: <CADajj4ZpeOL07XDHoB-rRxunu=fkV_ZJunXqSGZ9rmBGuoKM=g@mail.gmail.com> <C15918F2FCDA0243A7C919DA7C4BE9940D12D493@xmb-aln-x01.cisco.com>
Date: Mon, 10 Jun 2013 07:56:35 -0700
Message-ID: <CADajj4bi-STUPmB0U6ps3ksSVYG3Br4hBdFj1K9MQVXz9GhLfQ@mail.gmail.com>
From: Magnus Nyström <magnusn@gmail.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Content-Type: multipart/alternative; boundary="f46d0442881aae2ca704decdfc99"
Cc: "<draft-ietf-avtcore-6222bis@tools.ietf.org>" <draft-ietf-avtcore-6222bis@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-6222bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 14:56:45 -0000

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) <abegen@cisco.com>wrote:

>
> On Jun 10, 2013, at 9:37 AM, Magnus Nyström <magnusn@gmail.com> 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.
> >
> > 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?
>
> 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.
>
> >
> > Thanks,
> > -- Magnus
>
>


-- 
-- Magnus