[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.