[secdir] SecDir review of draft-ietf-pim-group-rp-mapping-08

Vincent Roca <vincent.roca@inrialpes.fr> Tue, 04 January 2011 14:56 UTC

Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1EBB3A6C57; Tue, 4 Jan 2011 06:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSf6N5HnUU85; Tue, 4 Jan 2011 06:56:53 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 47AC83A6BA5; Tue, 4 Jan 2011 06:56:53 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.60,272,1291590000"; d="scan'208";a="71761123"
Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 04 Jan 2011 15:58:59 +0100
Message-ID: <4D2335B2.9030803@inrialpes.fr>
Date: Tue, 04 Jan 2011 15:58:58 +0100
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-pim-group-rp-mapping.all@tools.ietf.org
Subject: [secdir] SecDir review of draft-ietf-pim-group-rp-mapping-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 04 Jan 2011 14:56:55 -0000

Hello,

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.

The current security consideration section is extremely limited.
I understand that the additional risks introduced by the current
specification are limited. I also understand that securing PIM is a
problem by itself, that is well beyond the goals of this section
(e.g. it is currently being considered in the KARP WG).

However I'd appreciate if the authors can improve the current section:

** clarify that the main risk is the fact different RPs be selected for the
same group. Is there anything else? E.g. can forged control messages
lead PIM routers to point to a non existing RP for some (all?) groups
which would cause a DoS? (I have no idea if this is feasible or not, it's
just an example).

** the following sentence is ambiguous.
   "The updated algorithm will not completely prevent the possibility of
    different routers selecting different group-to-rp mappings for the
    same group."
It suggests (but does not say explicitly) that the updated algorithm
reduces the possibility of selecting different RP for the same group.
Is it the case?

** the last sentence is the key sentence and it MUST be developed.
What does:
"if various mechanisms [...] are secure and consistent across the network"
mean? You don't have to give answers (as I said it's a problem by itself
that deserved a specific WG to be created). However you can give a
few pointers, and illustrate with a simple attack that can make the
choice incoherent across the network, etc.

I hope these comments are useful.
Regards,

    Vincent

---
Two typos:

* section 2: "Wherever this term in used in this document..." -> "is"

* section 6: it is said (bullets 5, 6 and 7):
        *  If there is only one entry available then that is selected as 
Group-to-RP mapping.
I suggest: "... then that entry is selected..."