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

Simon Josefsson <simon@josefsson.org> Sun, 31 August 2014 19:37 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 1F8591A8BB1; Sun, 31 Aug 2014 12:37:59 -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 QK2VAoWQrYIo; Sun, 31 Aug 2014 12:37:57 -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 32D201A8AFE; Sun, 31 Aug 2014 12:37:56 -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 s7VJbkBq015489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 31 Aug 2014 21:37:47 +0200
Date: Sun, 31 Aug 2014 21:37:44 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Marc Binderberger <marc@sniff.de>
Message-ID: <20140831213744.3dc0fcff@latte.josefsson.org>
In-Reply-To: <20140831114409097014.277d3630@sniff.de>
References: <20140830170942319588.ce02d0f5@cisco.com> <20140831114409097014.277d3630@sniff.de>
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_//xecfQgaLUvA68XLklujD7P"; 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/n7wE5NR28-9zUPSY9Dk9smzMAOY
Cc: Gregory Mirsky <gregory.mirsky@ericsson.com>, "Nobo Akiya (nobo)" <nobo@cisco.com>, draft-ietf-bfd-intervals.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [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: Sun, 31 Aug 2014 19:37:59 -0000

Thanks for response.  If the standards track issue has already been
discussed by authors and WG, then I'm happy -- I just wanted to bring it
up in case it hadn't already been discussed.

/Simon

You wrote:

> Hello Simon,
> 
> thanks for the review!
> 
> Let me start with the simple part:
> 
> > 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.
> >	[...]
> 
> Good point. In fact a not-yet-published updated draft contains your
> first example already; I will add your other suggestions as well.
> 
> 
> > 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.
> 
> This was discussed in the BFD workgroup and the consensus was the set
> of "Common Intervals" should be more a guideline for developers and
> not a strict requirement. I personally think the availability of the
> document to the public, including customers, will create enough
> momentum for implementers to read this.
> 
> Appendix B is on the border, IMHO. The underlying mechanism is still
> the same Poll sequence as defined in RFC5880, we just clarify how to
> apply it in a multi-step convergence. And yes, RFC5880 has a "gap" in
> assuming the convergence takes only one poll sequence. Again the
> workgroup seems to be fine to have this additional information
> informal.
> 
> 
> > 2) The document refers to RFC 2119 keywords (which are meaningless
> > for non-standards track documents)
> 
> you have a point but as we use this one SHOULD I thought it's good to
> have this reference.
> 
> 
> >                                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'?
> 
> We moved away from MUST to SHOULD when we decided the draft should
> have an informal status. I reduced it to the one SHOULD in section 3
> as this is the only section that spells out a technical requirement;
> the other sections explain the problem and the solution idea, which
> is why I used normal English "should", "may", "recommend" for these
> sections.
> 
> Kind of: getting the readers attention in section 3 as these
> paragraphs need to be read more carefully. 
> 
> 
> Let me incorporate your proposed changes and I send you a diff to
> check I do address your comments properly.
> 
> 
> Again thanks for the review!
> 
> Best regards,
> Nobo, Greg & Marc
> 
> 
> 
> > 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