[secdir] Secdir last call review of draft-ietf-trill-p2mp-bfd-07
Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 28 December 2017 14:54 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0481412D949; Thu, 28 Dec 2017 06:54:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: secdir@ietf.org
Cc: draft-ietf-trill-p2mp-bfd.all@ietf.org, ietf@ietf.org, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151447284096.3404.9799585674492282627@ietfa.amsl.com>
Date: Thu, 28 Dec 2017 06:54:01 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ZMmWM8DqrTJRa-8QXIeF4_rDQew>
Subject: [secdir] Secdir last call review of draft-ietf-trill-p2mp-bfd-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Dec 2017 14:54:01 -0000
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: "...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.
- [secdir] Secdir last call review of draft-ietf-tr… Stephen Farrell
- Re: [secdir] Secdir last call review of draft-iet… Donald Eastlake
- Re: [secdir] Secdir last call review of draft-iet… Stephen Farrell