IETF Logo Mail Archive

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

"Shawn M. Emery" <semery@uccs.edu> Tue, 10 December 2019 21:36 UTC

Return-Path: <semery@uccs.edu>
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 8CA77120019; Tue, 10 Dec 2019 13:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.488
X-Spam-Level:
X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 fcyAu0U31h6L; Tue, 10 Dec 2019 13:36:49 -0800 (PST)
Received: from exchange.uccs.edu (uccs-ex1.uccs.edu [128.198.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E702C120005; Tue, 10 Dec 2019 13:36:48 -0800 (PST)
Received: from mail-ed1-f49.google.com (209.85.208.49) by UCCS-EX1.uccs.edu (128.198.1.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 10 Dec 2019 14:36:46 -0700
Received: by mail-ed1-f49.google.com with SMTP id cy15so17369524edb.4; Tue, 10 Dec 2019 13:36:46 -0800 (PST)
X-Gm-Message-State: APjAAAXj7NJKR03UI8jxIERlocxBuXMg0dW8W9rH1n7DuoWQuCHhvswg HFCh18YF0zLhJcJfX9J7gHT1y1CN2pJVg4QwCQg=
X-Google-Smtp-Source: APXvYqzoVQn3bFL6gdvs4Cua/mGOYgS1Yt1g4g+hpevP/nKSbgIG54JSR+nmvnApINro6oEj15lvzhQjwUWiwODMFZ0=
X-Received: by 2002:a50:fa87:: with SMTP id w7mr42506594edr.0.1576013805546; Tue, 10 Dec 2019 13:36:45 -0800 (PST)
MIME-Version: 1.0
References: <CAChzXmaj-fBb5D8EPy7C4nU0mO0+yPGux51-Xxvu22oyUVh4Ag@mail.gmail.com> <20191210155221.GB29250@pfrc.org>
In-Reply-To: <20191210155221.GB29250@pfrc.org>
From: "Shawn M. Emery" <semery@uccs.edu>
Date: Tue, 10 Dec 2019 14:36:34 -0700
X-Gmail-Original-Message-ID: <CAChzXmaPh1Z23yOwig1ToJOp7ye6b0W3pcmk5_qPzHV9es6yUg@mail.gmail.com>
Message-ID: <CAChzXmaPh1Z23yOwig1ToJOp7ye6b0W3pcmk5_qPzHV9es6yUg@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: draft-ietf-bfd-vxlan.all@ietf.org, secdir <secdir@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000a75430599604faa"
X-Originating-IP: [209.85.208.49]
X-ClientProxiedBy: UCCS-EX3.uccs.edu (128.198.1.103) To UCCS-EX1.uccs.edu (128.198.1.101)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/BRy1upX2MQCiMU6ESPalCJ3QIEo>
X-Mailman-Approved-At: Tue, 10 Dec 2019 13:38:19 -0800
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 21:36:52 -0000

Hi Jeff,

Comments begin with SME...

On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas <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.


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

Shawn.
--

v2.23.0 | Report a Bug | By Email