[secdir] draft-ietf-bess-multicast-damping-04 SECDIR Review

Donald Eastlake <d3e3e3@gmail.com> Wed, 27 April 2016 18:24 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D67312DBA9; Wed, 27 Apr 2016 11:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id B4VhghwJJue6; Wed, 27 Apr 2016 11:24:48 -0700 (PDT)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 603AD12DBA6; Wed, 27 Apr 2016 11:24:48 -0700 (PDT)
Received: by mail-ob0-x234.google.com with SMTP id bg3so27060180obb.1; Wed, 27 Apr 2016 11:24:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=wV9+p9wVPXKySSRWcSUVwgewl9vp3G/WG+q68mm3CaY=; b=s8prsxg8PXfVSKxYSscGcA8DNO6nyzyl8vftD65+J/jsHZgcZuRlAUoNY5tzO4SPw5 viUB+uuAxbm8MFkc+ipOT6nU8xxjhVxcy1NiAGPMPMJGcLf27Gnc+kcciAtYHcyA5Nuh 75sTTIlb0mBqLy1GViA/hESelbjisJdXoLlQg76H6Epv6R9UKXPcLFPtI87P6sbO5nUP bojLhSohMtiRyxcdSGhdeqVLrWvB5hv7GTOeeH7RLZhUtltC3gvSRgcad4fpR2YF81MY DJ9SJxrTQZ8HPTK8WXQSYmkOKAWadgfU7wPrnwcSzoV1aTQ6k+yJsH+NXSThwkG91IVW Q+NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=wV9+p9wVPXKySSRWcSUVwgewl9vp3G/WG+q68mm3CaY=; b=JFq6ubxUGQ2wIEMr7z1XQIWnvggPmC/XWgXysgZBc9Hjjq2plKqgB57Rsp+ZRvt7V0 4KowcmkN2vpPLCoo3xqJiLgJY/fRFkw9+fYxSPB4SuZ+hNWIRy+DjHUZLdQeua5A3WNJ 43QUBPD+h2kXSX3P2+2RIFEEjZe9L9kNrD4pfac7pXK8HE8ayAw95haj5xiJtXw5Yt2Z im2k3yo9wEb+0XzfGdCu/XFjwBdEEfm56Jb1zUJS1MYSzercoNq+/S7oCCqoFKoYYD/D SyZu5sFp9mbVPs4kYBFYmJIJPVPLfdpV8Zzs5gokcvgiKl7c+TjvimFMBnJZfjPMbXDW wy1g==
X-Gm-Message-State: AOPr4FXc7jOQUl4kctj7ymMADsmRJVjr/NA3xsRIKOdL1jlXiOT8yPz52qx6ZO9CEIhh6JpotDBs0jF24HktqQ==
X-Received: by with SMTP id dx6mr4414989oeb.5.1461781487531; Wed, 27 Apr 2016 11:24:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 27 Apr 2016 11:24:32 -0700 (PDT)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 27 Apr 2016 14:24:32 -0400
Message-ID: <CAF4+nEGuRSm0zQCj44TEAu3h7KbbXj+MiOQqgJ7c4sHMKHooLw@mail.gmail.com>
To: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-bess-multicast-damping.all@ietf.org
Content-Type: multipart/alternative; boundary="089e0115f2a04dc21905317b86fd"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/trs7NHNiYWSuYQgzIGubl8ODgkw>
Cc: "secdir@ietf.org" <secdir@ietf.org>
Subject: [secdir] draft-ietf-bess-multicast-damping-04 SECDIR Review
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 27 Apr 2016 18:24:50 -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.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

This document describes procedures for damping multicast virtual private
network routing state changes to control the effect, particularly the
control plane load, of the churn due to the dynamic multicast group
membership in customer sites.


Overall, I think it is ready with nits but my confidence in that assessment
is not very high.

The feature specified in this document is aimed at limiting one type of
denial of service, or at least at interference to some users by others:
denial or interference due to excessive control plane traffic due to a high
rate of multicast group membership change. Still, it makes me a bit queasy
that the document has not one word, even by reference, about security for
the setting or changing of the parameters used at a node in the damping
algorithm. I suppose it is reasonable that it doesn't talk about how any of
the control messages involved are protected or authenticated since the
document is just about suppressing such messages...

The Security Considerations section has a reasonable discussion of how and
to what extent the mechanisms specified provide the services claimed.

Page 15, Section 9 (Security Considerations), 1st paragraph starting on
this page: There are a number of things wrong with the following sentence:

          Note well that the two
   mechanism may interact: state for which Prune has been requested may
   still remain taken into account for some time if damping has been
   triggered and hence result in otherwise acceptable new state from
   being successfully created.

I would guess it should be "result in preventing otherwise" or should end
with "state not being successfully created". Here is a suggested

          The two mechanisms may interact as follows: if damping has

   been triggered, state for which Prune has been requested may remain

   and still be taken into account for some time resulting in an

   otherwise acceptable new state not being created.


This document is very heavy with acronymic jargon with no expansion or
definition in this document. However, most of it is defined in other RFCs
that are referenced.

Although I am willing to accept that it is just a matter of style, this
document has lots of extra words that add nothing but verbosity. Things
that could be completely dropped with no loss, like starting a sentence
with "Additionally, it is worth nothing that ...". If it wasn't worth
noting, it presumably wouldn't be in the document.

Page 4, Section 3, 3rd paragraph: "...this technique will allow to meet the
goals..." -> "...this technique will meet the goals..."

Page 12, Section 7.2: "More specifically it is RECOMMENDED to complement
the existing ... (e.g. MRIB states): ..." -> "Complementing the existing
... (e.g. MRIB states) is RECOMMENDED: ..."

Page 13, Section 7.3, 2nd paragraph: What does "dimentioning" mean? Also
"...state churn to go beyond what..." -> "...state churn going beyond

Page 14, Section 9, 3rd paragraph: The word "shall" is used. While not
capitalized, this word sounds quite mandatory to me but it is not used in a
mandatory requirement context... I suggest "shall rely upon" -> "relies on".

Page 15, near the top: "should rely upon already" -> "should use already"

Finally, while I understand that others have a different opinion, I find it
objectionable that not a single first page author is willing to list a
telephone number of any sort in the Authors' Addresses section. To my mind,
this sort of corner cutting does not speak well for the document.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA