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

Marc Binderberger <marc@sniff.de> Sun, 31 August 2014 18:44 UTC

Return-Path: <marc@sniff.de>
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 65FDA1A8AD6; Sun, 31 Aug 2014 11:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level:
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 vVn_jfuiXOTz; Sun, 31 Aug 2014 11:44:07 -0700 (PDT)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0930D1A8AD1; Sun, 31 Aug 2014 11:44:07 -0700 (PDT)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 8FE4F2AA0F; Sun, 31 Aug 2014 18:44:03 +0000 (GMT)
Date: Sun, 31 Aug 2014 11:44:09 -0700
From: Marc Binderberger <marc@sniff.de>
To: Simon Josefsson <simon@josefsson.org>, Nobo Akiya (nobo) <nobo@cisco.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>
Message-ID: <20140831114409097014.277d3630@sniff.de>
In-Reply-To: <20140830170942319588.ce02d0f5@cisco.com>
References: <20140830170942319588.ce02d0f5@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.15
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/t_X_9k5JBRlsxkDdqr4HAdReeIw
X-Mailman-Approved-At: Tue, 02 Sep 2014 08:01:24 -0700
Cc: draft-ietf-bfd-intervals.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Fwd: 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 18:44:09 -0000

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