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

Jeffrey Haas <jhaas@pfrc.org> Tue, 10 December 2019 22:00 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BE912018D; Tue, 10 Dec 2019 14:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FEH_0dbj9GY; Tue, 10 Dec 2019 14:00:21 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0591201E0; Tue, 10 Dec 2019 14:00:21 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 31C6A1E2F5; Tue, 10 Dec 2019 17:04:41 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF64ECE6-53AF-4B85-8DCF-A7A40A32449F"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CAChzXmaPh1Z23yOwig1ToJOp7ye6b0W3pcmk5_qPzHV9es6yUg@mail.gmail.com>
Date: Tue, 10 Dec 2019 17:00:18 -0500
Cc: draft-ietf-bfd-vxlan.all@ietf.org, secdir <secdir@ietf.org>
Message-Id: <F812C328-E0AF-40CC-B552-11E88969A35E@pfrc.org>
References: <CAChzXmaj-fBb5D8EPy7C4nU0mO0+yPGux51-Xxvu22oyUVh4Ag@mail.gmail.com> <20191210155221.GB29250@pfrc.org> <CAChzXmaPh1Z23yOwig1ToJOp7ye6b0W3pcmk5_qPzHV9es6yUg@mail.gmail.com>
To: "Shawn M. Emery" <semery@uccs.edu>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/tnyXjMA9ya2N4KQZMOhgNUEbbbg>
Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 10 Dec 2019 22:00:24 -0000

Shawn,

The fundamental issue you're running into is you don't implement bfd for vxlan without also implementing base BFD (RFC 5880).  IETF specs don't typically try to spell out all considerations from the base specification in each extension.  And yes, it's a common criticism of IETF documents vs. other SDO docs such as IEEE or ITU-T.

Given this [see below]

> On Dec 10, 2019, at 4:36 PM, Shawn M. Emery <semery@uccs.edu>; wrote:
> 
> Hi Jeff,
> 
> Comments begin with SME...
> 
> On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org>> wrote:
> Shawn,
> 
> 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
> mechanism.
> 
> SME: This was not clear to me when reading the draft and think that the text above would help in defending that there are no privacy concerns that this specification introduces.

Adding in these considerations in an extension document to base BFD seems weird.

>  
> > 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."
> 
> SME: This was also not clear to me, as my initial investigation did not lead me to this text.

Understood.  But again, spelling out all such considerations from the base document in the extension document isn't very IETF.

My request would be to review RFC 5880 and see if you come to the same conclusions.

-- Jeff

> 
> Shawn.
> --