[secdir] SecDir review of draft-ietf-pim-explicit-rpf-vector-07

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Thu, 17 December 2015 20:51 UTC

Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500C71B30AB; Thu, 17 Dec 2015 12:51:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMDKo2O1agnz; Thu, 17 Dec 2015 12:51:50 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAC21B30AA; Thu, 17 Dec 2015 12:51:49 -0800 (PST)
Received: by mail-ig0-x231.google.com with SMTP id m11so20892169igk.1; Thu, 17 Dec 2015 12:51:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=055iH9P17ZUq8qdjVRfYRZ6PsfWQs4zMuU69CZZNYiA=; b=ImqpElWo/+xFchueouk0/F8ImuMdVIAxcw8YgncGJpAARiwOd5NiJlkKf7CY5wUZQj thyAkOMmd5GErh3ZDpRe2MXvp0+Att8N0VbPbH2qwiQeNfUNRXlquUxFUgj+6aIedCrm Ianns0hIq1Rv1Wq2I9lpF2jC+UjohzkfF7OPTIIKTqE4ifR4DGbGnqU87TYPZYCtfIyl nCRFXfr4f3cgjVFmNbbD2kB7PO+JQElyzgeaGyuPO5111cOgyhJ+Bi8hlLOIecgeq+q6 BkqrVRvyPp3vJAgu2B/DBX/DcubAqzf4jdkR6GG2oP28/dAOVT91cRFHM5R2T41b0LZr jlow==
MIME-Version: 1.0
X-Received: by 10.50.18.114 with SMTP id v18mr6095148igd.34.1450385509303; Thu, 17 Dec 2015 12:51:49 -0800 (PST)
Received: by 10.107.147.6 with HTTP; Thu, 17 Dec 2015 12:51:49 -0800 (PST)
Date: Thu, 17 Dec 2015 15:51:49 -0500
Message-ID: <CAGL6epKLFyJyR1sfvj8xW1ekX0eA5aV4AM33U6SkPoF+hxv6qw@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-pim-explicit-rpf-vector.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="047d7b41840311cb0a05271e3140"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/V11HoS_WsrgKJgU0p1xVVCSHsGI>
Subject: [secdir] SecDir review of draft-ietf-pim-explicit-rpf-vector-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Dec 2015 20:51:51 -0000

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 Security Consideration section points to the security consideration
of the ietf-pim-rfc4601bis document, which seems reasonable as this
document
adds new attribute to the existing PIM Join message.


The document then states the following:
"In order to minimize the risk of a malicious node injecting an incorrect
Explicit RPF vector stack, it should be used within a single management
domain."

You might want to elaborate a bit on how does a single management domain
help minimize this risk.


Also, the security consideration section in ietf-pim-rfc4601bis document
discusses the impact of a forget Join message and its implication on the
multicast traffic. You might want to add some text to explain if this new
attribute, defined in this document, changes the implication of a forged
Join message or not; if it does, you might want to explain how.

Regards,
 Rifaat