Hi Stephen, Thanks for your review.
On Thu, Dec 28, 2017 at 9:54 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > Reviewer: Stephen Farrell > Review result: Has Issues > > Mostly this draft is just bookkeeping so BFD can use trill's P2MP > capabilities. > > 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: The BFD standard was adopted in 2010 and does indicate that its keyed SHA1 method is strongest and points designers of future BFD authentication types towards HMAC... > "...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. TRILL essentially clones the IS-IS cryptographic authentication mechanisms which do use HMAC (RFC5310). > 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. It seems to me that perhaps the direction of the recommendation should be flipped so that RFC 7978 authentication is recommended over BFD multipoint authentication. Maybe something like: OLD However, [RFC7978], while it provides both authentication and encryption for point-to- point extended RBridge Channel messages, provides only authentication for multipoint RBridge Channel messages. Thus, there is little reason to use the [RFC7978] security mechanisms at this time. However, it is expected that a future document will provide for group keying; when that occurs, the use of RBridge Channel security will also be able to provide encryption and may be desirable. NEW [RFC7978] provides encryption only for point-to-point extended RBridge Channel messages so its encryption facilities are not applicable to this draft. However [RFC7978] provides stronger authentication than that currently provided in BFD. Thus, there is little reason to use the BFD security mechanisms if [RFC7978] authentication is in use. It is expected that a future TRILL document will provide for group keying; when that occurs, the use of [RFC7978] RBridge Channel security will be able to provide both encryption and authentication. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill