[secdir] Secdir review of draft-ietf-bfd-intervals-03

Simon Josefsson <simon@josefsson.org> Sat, 30 August 2014 20:56 UTC

Return-Path: <simon@josefsson.org>
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 3B4181A0AF0; Sat, 30 Aug 2014 13:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
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 sx0kWDvfB7XW; Sat, 30 Aug 2014 13:56:29 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B091A0AED; Sat, 30 Aug 2014 13:56:28 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7UKuH46007724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Aug 2014 22:56:19 +0200
Date: Sat, 30 Aug 2014 22:56:15 +0200
From: Simon Josefsson <simon@josefsson.org>
To: secdir@ietf.org, draft-ietf-bfd-intervals.all@tools.ietf.org, iesg@ietf.org
Message-ID: <20140830225615.786868b0@latte.josefsson.org>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
OpenPGP: id=54265e8c; url=http://josefsson.org/54265e8c.txt
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="PGP-SHA256"; boundary="Sig_/Nw8OQi74uXYENv=dxpFCqUF"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.4 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2kz_1WLPEHpBZK14x8mYb4jomd8
Subject: [secdir] Secdir review of draft-ietf-bfd-intervals-03
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: <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: Sat, 30 Aug 2014 20:56:31 -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.

This document describe how a flaw in BFD negotiation that can lead to
peers failing to agree on a transmission interval can be mitigated by
having nodes follow certain conventions.

I see no security considerations at all related to this document, and
the Security Considerations section adequately reference RFC 5880.

Other comments:

1) Why is this document Informational?  Not being involved in this area
at all, it seems to me that the negotiation flaw is serious enough to
warrant 'Updates: 5880' to make sure implementers/deployers read this
document.

2) The document refers to RFC 2119 keywords (which are meaningless for
non-standards track documents) but the only use of that (that I could
find) is in the second paragraph of section 3 which says SHOULD about
something that I interpret as being required elsewhere and merely
repeated for illustration and background.  Section 1 reads 'This
document proposes a set of interval values that should be supported by
all implementations.' -- I suspect this ought to be SHOULD (or
even MUST) instead of 'should'?

3) Pretty please expand the acronym BFD the first time it is is used.
Section 1 "Introduction" starts with 'The standard [RFC5880]
describes...' and I suggest 'The Bidirectional Forwarding Detection
(BFD) standard [RFC5880] describes...' instead.  The abstract
starts with 'BFD' and I suggest 'Bidirectional Forwarding Detection
(BFD)'.  Maybe the document title should be changed too, it is now
'Common Interval Support in BFD'. 'Common Interval Support in
Bidirectional Forwarding Detection (BFD)' or maybe 'Common Interval
Support for the Bidirectional Forwarding Detection (BFD) Protocol'?

/Simon