Skip to main content

Last Call Review of draft-ietf-karp-bfd-analysis-04
review-ietf-karp-bfd-analysis-04-opsdir-lc-taylor-2014-08-08-00

Request Review of draft-ietf-karp-bfd-analysis
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-08-12
Requested 2014-07-30
Authors Manav Bhatia , Dacheng Zhang , Mahesh Jethanandani
I-D last updated 2014-08-08
Completed reviews Genart Last Call review of -04 by Scott W. Brim (diff)
Genart Telechat review of -06 by Scott W. Brim (diff)
Secdir Last Call review of -04 by Samuel Weiler (diff)
Opsdir Last Call review of -04 by Tom Taylor (diff)
Opsdir Telechat review of -06 by Tom Taylor (diff)
Assignment Reviewer Tom Taylor
State Completed
Request Last Call review on draft-ietf-karp-bfd-analysis by Ops Directorate Assigned
Reviewed revision 04 (document currently at 08)
Result Has issues
Completed 2014-08-08
review-ietf-karp-bfd-analysis-04-opsdir-lc-taylor-2014-08-08-00
Oops, sent to wrong list.


-------- Original Message --------
Subject: Last Call review of draft-ietf-karp-bfd-analysis-05
Date: Thu, 07 Aug 2014 14:14:42 -0400
From: Tom Taylor <tom.taylor.stds at gmail.com>


To: Gen Art <gen-art at ietf.org>, 


draft-ietf-karp-bfd-analysis-05 at tools.ietf.org




I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
 These comments were written primarily for the benefit of the
operational area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: this document is almost ready to publish as an Informational
document with a minor issue and editorial suggestions.

Minor issue: Section 2 identifies vulnerability to DoS attacks as a gap,
but there is no follow-up in the rest of the document.

Editorial: in the middle paragraph of Section 1, change "require" to
"allow".

OLD
   Moving the routing protocols to a stronger
   algorithm while using weaker algorithm for BFD would require the
   attacker to bring down BFD in order to bring down the routing
   protocol.

NEW
   Moving the routing protocols to a stronger
   algorithm while using weaker algorithm for BFD would *allow* the
   attacker to bring down BFD in order to bring down the routing
   protocol.



Editorial: I have trouble parsing the first sentence of the fourth
paragraph of Section 3. It currently reads:

   Note that when using authentication mechanisms, BFD requests the
   sequence of a received BFD packets drops with a limited range (3*
   Detection time multiplier).

Do you mean to say that BFD requests retransmission of BFD packets that
were received but dropped, and whose sequence numbers lie in a limited
range (3* Detection time multiplier)?


Editorial: same paragraph, next sentence, drop the "of":

OLD

(3 times of the detect interval of the session)

NEW

(3 times the detect interval of the session)



Editorial: next paragraph, third sentence:

OLD

   If a node will randomly select a new discriminator
   for a new session and use authentication mechanism to secure the
   control packets, inter-session replay attacks can be mitigated to
   some extent.

NEW

   If a node randomly selects a new discriminator
   for a new session and uses an authentication mechanism to secure the
   control packets, inter-session replay attacks can be mitigated to
   some extent.


Editorial: same paragraph, fourth line from bottom: s/reasons/reason/


Editorial: Section 4, third paragraph: s/elaborately/carefully/


Editorial: Section 6, second paragraph: s/relative effective/relatively
effective/