Telechat Review of draft-ietf-karp-bfd-analysis-06
review-ietf-karp-bfd-analysis-06-opsdir-telechat-taylor-2014-08-25-00

This is a re-review of draft-ietf-karp-bfd-analysis following its update 


to version -06. As before, these comments



were written primarily for the benefit of the operational area directors.



Summary: the update does not address the issue I raised in my previous 


review. That is, that one of the identified requirements identified in 


Section 2 cannot currently be met, and has no follow-up in the rest of 


the document despite the text in the next paragraph promising such 


follow-up. I recommended that the author insert, after the deficient 


requirement, text to to the effect provided by the authors because the 


issue seems to be key to deployment.






Quoting: "Thats because we really dont know how to address this issue. 


And this is one of the reasons why BFD authentication is still not 


deployed in the field."






Given my scrambling of E-mail distribution, this may be because my 


recommendation did not reach the people who should have seen it. 


Apologies if that is so.






Nit: IDNits complains about use of the form "[RFC6518]" rather than "RFC 


6518" in the Abstract.





Original review follows:
=======================



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/