Re: [secdir] Review of draft-ietf-bfd-vxlan-09

Jeffrey Haas <> Tue, 10 December 2019 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC891120100; Tue, 10 Dec 2019 07:48:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fDpsOrzNksSC; Tue, 10 Dec 2019 07:48:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7B2E2120045; Tue, 10 Dec 2019 07:48:01 -0800 (PST)
Received: by (Postfix, from userid 1001) id 370731E2F6; Tue, 10 Dec 2019 10:52:22 -0500 (EST)
Date: Tue, 10 Dec 2019 10:52:21 -0500
From: Jeffrey Haas <>
To: "Shawn M. Emery" <>
Cc:, secdir <>, Shawn Emery <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Dec 2019 15:48:03 -0000


On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote:
> Reviewer: Shawn M. Emery
> Review result: Ready with nits


> 1. Relating to privacy:
> I believe that this section [security considerations] should also document
> the security impact of deploying BFD on VXLANs for monitoring tunnel
> traffic.
> Which additional information, if any, can now be obtained with BFD usage?

BFD protects transport between two systems and, in the profile envisaged in
this document, does not typically involve itself in protecting user-managed
endpoints.  (In such circumstances, they might consider standard RFC
5880/5881 BFD as a user-provisioned mechanism.)

The traffic for this mechanism is thus between two systems at the tunnel
level and only covers the information necessary to permit the BFD protocol
to execute, including any BFD security mechanisms that may be applied to
that session.  There are thus no end user privacy considerations for this

> 2. Editorial:
> Echo BFD is out of scope for the document, but does not describe the
> reason for this or why state this at all?

This is covered by RFC 5880 section 5.  Similar to most other IETF
documents, when documenting extensions and we do not conflict with the base
behavior, we don't try to copy and paste the motivations as it waters down
the normative text.  (If we were IEEE, we'd reissue the entire suite every
time we touched something...)

Our preference is to leave it alone.

At best, we could say "See RFC 5880, section 5."

-- Jeff