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

From: Simon Josefsson <[email-masked]>
Date: Sat, 30 Aug 2014 22:56:15 +0200

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

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 31 Aug 2014 21:37:44 +0200

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]
> > (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
> 
> 
> 
> > 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]