[karp] draft-ietf-karp-bfd-analysis-00 comments

Jeffrey Haas <jhaas@pfrc.org> Wed, 08 May 2013 17:54 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 10F8D21F8ECB for <karp@ietfa.amsl.com>; Wed, 8 May 2013 10:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id p7XbHxryGToJ for <karp@ietfa.amsl.com>; Wed, 8 May 2013 10:54:12 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org []) by ietfa.amsl.com (Postfix) with ESMTP id 5888321F91CB for <karp@ietf.org>; Wed, 8 May 2013 10:54:11 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id D5482C25D; Wed, 8 May 2013 13:54:10 -0400 (EDT)
Date: Wed, 8 May 2013 13:54:10 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: karp@ietf.org
Message-ID: <20130508175410.GF12732@pfrc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [karp] draft-ietf-karp-bfd-analysis-00 comments
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 May 2013 17:54:17 -0000

I've just read the current version of draft-ietf-karp-bfd-analysis.  I have
one comment and one question:

The draft correctly identifies the potential security implications of
predictable BFD session discriminator values.  The following text in 
RFC 5880 attempts to cover this issue:


      The local discriminator for this BFD session, used to uniquely
      identify it.  It MUST be unique across all BFD sessions on this
      system, and nonzero.  It SHOULD be set to a random (but still
      unique) value to improve security.  The value is otherwise outside
      the scope of this specification.

Obviously implementations may make choices that are problematic from a
replay standpoint, but I don't believe there is anything to really cover in
a new BFD document.  Do the authors believe otherwise, or is this primarily
pointing out "you know better, don't do that!"

It should also be noted that we have two I-Ds as WG documents that cover the
other issues noted in this draft: draft-ietf-bfd-hmac-sha and

Presuming my analysis of the above is correct (an admonition to do the right
thing), this document appears of reasonable quality.  Is there an intent to
last call it sometime soon?

-- Jeff