Last Call Review of draft-ietf-trill-p2mp-bfd-07

Request Review of draft-ietf-trill-p2mp-bfd
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-01-08
Requested 2017-12-18
Authors Mingui Zhang, Juniper Networks, Vengada Govindan
Draft last updated 2017-12-28
Completed reviews Rtgdir Early review of -04 by Carlos Pignataro (diff)
Opsdir Last Call review of -07 by Shwetha Bhandari (diff)
Genart Last Call review of -06 by Meral Shirazipour (diff)
Secdir Last Call review of -07 by Stephen Farrell (diff)
Genart Telechat review of -08 by Meral Shirazipour (diff)
Assignment Reviewer Stephen Farrell
State Completed
Review review-ietf-trill-p2mp-bfd-07-secdir-lc-farrell-2017-12-28
Reviewed rev. 07 (document currently at 09)
Review result Has Issues
Review completed: 2017-12-28


Mostly this draft is just bookkeeping so BFD can use trill's P2MP 

I think there is one issue to consider, though since I've not read all the 
referenced documents in detail, I'm open to correction as to whether or
not this is a real issue.

IIRC, BFD has some pretty crappy "authentication" schemes, such as 
allowing a cleartext password, and not using HMAC when doing keyed
hashes. That's been justified by performance and implementation 
requirements for BFD. (Not that I ever found those justifications that
satisfactory myself:-) I don't think TRILL has the same issues in  
that (again IIRC) TRILL doesn't define such "dodgy" schemes, so that 
leads me to wonder if this text is really correct/wise:

"...there is little reason to use the [RFC7978] security mechanisms at 
this time..."

I'd have thought that avoiding the more-dodgy BFD mechanisms would 
be a reason for using TRILL authentication mechanisms. 

In addition, it's not clear (to me) from the draft if the security 
assumptions made for BFD still hold in the environments where
TRILL is likely to be used. If not, then that'd be another reason to
argue that  TRILL authentication ought be used.