Skip to main content

Last Call Review of draft-ietf-karp-bfd-analysis-04
review-ietf-karp-bfd-analysis-04-secdir-lc-weiler-2014-08-21-00

Request Review of draft-ietf-karp-bfd-analysis
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-08-19
Requested 2014-07-17
Authors Manav Bhatia , Dacheng Zhang , Mahesh Jethanandani
I-D last updated 2014-08-21
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 Samuel Weiler
State Completed
Request Last Call review on draft-ietf-karp-bfd-analysis by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 08)
Result Has issues
Completed 2014-08-21
review-ietf-karp-bfd-analysis-04-secdir-lc-weiler-2014-08-21-00
(Doc scheduled for telechat this week.)



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.







Summary: I'm not seeing anything that's grossly incorrect, but I 


wonder if this doc is taking the right approach.






The security consideration section acknowledges that increasing the 


length of the sequence number or connecting the sequence numbers to 


clock time could reduce the risk of replay attacks as, presumably, 


could moving to the "meticulous" approaches that require an increasing 


sequence number (and recomputation) at every packet, at the possible 


cost of needing special hardware or having to increase the time 


between BFD packets.  These seem like simpler fixes that adding a new 


hash algorithm, which is what the doc ultimately suggests, and I 


wonder if adding GMAC is really needed.






One thing that's not explicitly discussed, and which I would like to 


see, is a general analysis of algorithm agility - how hard is it to 


add a new algorithm?  The doc says that BFD has no key rollover 


mechanism - I suspect that adding that and algorithm agility are more 


important, in the long run, than just adding a stronger hash 


algorithm.  (Which isn't to say that we even need to improve those, 


just that they may be more important.)






I'm also somewhat skeptical of the premise that BFD needs to use 


algorithms that match the routing algorithm strength:




   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.  BFD therefore needs
   to match the routing protocols in its strength of algorithm.



Are the attack models of the two really aligned?  Do the keying models 


for both suggest that one or the other could cope with weaker 


algorithms?  Can one be more easily rekeyed, thus making it easier to 


cope with weaker algorithms?




Lastly, RFC5880 (the BFD spec) says:
   An attacker who is in complete control of the link between the
   systems can easily drop all BFD packets but forward everything else
   (causing the link to be falsely declared down), or forward only the
   BFD packets but nothing else (causing the link to be falsely
   declared up).  This attack cannot be prevented by BFD.



Given that, does it make sense to go to this pain to replace MD5 and 


SHA1?




-- Sam