Re: [secdir] Review of draft-ietf-bfd-vxlan-07
Shawn Emery <shawn.emery@gmail.com> Fri, 07 June 2019 22:31 UTC
Return-Path: <shawn.emery@gmail.com>
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 AA6A4120114; Fri, 7 Jun 2019 15:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2lilEG931FAS; Fri, 7 Jun 2019 15:31:04 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D357C1201D3; Fri, 7 Jun 2019 15:31:03 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id o13so3037766lji.5; Fri, 07 Jun 2019 15:31:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QBjcaJEZF/ZRfuK8pCWRW6yPagMAS7U+hf4nFceMa/U=; b=AtDErEmYP0pvWZ94VFIyQrg07zLlWAsUiucUBMBsXSqvSUa1t+fOmj7ef/y85TxPNn Ksra7deShKkjCuYbe5kxWkQ/Upwj0u4QY1krDBQIbpCScpCpx1QBaVHbKsnsTtd1RT/I pgIvWlu7vF++q+Io3IE4VQ6LbdN0M/VaPI4vHGBEKiHvxXgD6v0GTqANLLdLB3Yb21Ny 6HbVMA8DBCyDSeEZcYHY32aUfvKGNsY84ED8uJ4OSD8ZLRx1ZlODdPhZ5qvgbExwDzNs +2uEiUMRSDifow3AXfx/ZsxJT7uV4ObNa9NAh4DxVyF7l5x6nm2c/2Z0DP4zXk1wXUZl eXSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QBjcaJEZF/ZRfuK8pCWRW6yPagMAS7U+hf4nFceMa/U=; b=BBm0esJ1qUAqktw5DGbHEboa3E6Zo4dO5vfdV7NOXeZ6zz50bqPnB8OQ4OKq+FdL1A bKhai249YMaJ4XFxP5hGkH90VHgQvbkGhAg7kicfz1BTU8Eyp559UyEbXP9+MWMg5ufs zNz+aJch3Vt9lLpSAv/ffNu9Z9hZmhSYKER3z9Vhi0pJktMirPa+G020XG8e+Ep2o4EG +LrtUgLBTdsdJTTD3KAvwY2LRvL4bTK91dAh+/f4b2eEQfIx+8SOaoHWb75Wh1J4vw6q R+l/RHfdp44KFkOEDzq/1lkFVMjxhulwaOPhmDfCA6G/BKx0ccytzPo/cg8xk7smYRpO r2lg==
X-Gm-Message-State: APjAAAUnQ4JjjwkFieNQK6pJYfGlzNeAj2dA5vcRwvESP5kRTiMnwVS2 UbJERYyIrwCL2lH+JIWgXd65FG3nkXmp/660aos=
X-Google-Smtp-Source: APXvYqxdV4mnh7nWJWkZtcvhaKZvkonWF9oboI7jSn5/jAWt52NHR2RQmV7mSAQRBoVXnEMBRY7xjhX+NI73Z9gXmCI=
X-Received: by 2002:a2e:f1a:: with SMTP id 26mr22346104ljp.37.1559946661898; Fri, 07 Jun 2019 15:31:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAChzXmbSUko=KsWbAxTNvWAZjLig=hxhj3yAt-keh-hbbg8w8w@mail.gmail.com> <CA+RyBmVtPGS3O7K3jzXkjXq91OMHSf_LKGBREqDJZzoAMjZ8pg@mail.gmail.com> <20190605212643.GB15506@pfrc.org>
In-Reply-To: <20190605212643.GB15506@pfrc.org>
From: Shawn Emery <shawn.emery@gmail.com>
Date: Fri, 07 Jun 2019 16:30:50 -0600
Message-ID: <CAChzXma04wcp1UR1mVA=MmdiAz+LStihqJXb5YwURXWa1pagKA@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Greg Mirsky <gregimirsky@gmail.com>, secdir@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, Shawn Emery <semery@uccs.edu>
Content-Type: multipart/alternative; boundary="000000000000a6b2f5058ac36201"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/9hAqLh7j9hRkM05hUAW1uY-wsW4>
Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-07
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: Fri, 07 Jun 2019 22:31:08 -0000
Comments begin with SME... On Tue, Jun 4, 2019 at 2:40 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > Hi Shawn, > thank you for the review, clear, directed questions, and helpful > suggestions. Please find answers, notes in-lined and tagged GIM>>. > > Regards, > Greg > > On Fri, May 24, 2019 at 10:45 PM Shawn Emery <shawn.emery@gmail.com> > wrote: > >> Reviewer: Shawn M. Emery >> Review result: Ready with issues >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >> area directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. >> >> This draft specifies usage of the Bidirectional Forwarding Detection >> (BFD) protocol on >> Virtual eXtensible Local Area Network (VXLAN) tunnels. >> >> The security considerations section does exist and discusses the >> introduction of a possible >> DDoS attack due to the requirement of the protocol to set the IP TTL to >> one hop. The prescription >> outlined is to throttle this traffic. The section continues that BFD >> sessions should also have an >> upper limit, but does not give guidance on what is considered reasonable >> to where it would affect >> normal traffic vs. some form of DoS. >> > GIM>> The precise number would depend on many factors and thus we only > recommend to have a knob to control the number of BFD sessions between a > pair of VTEPs. Would the updated recommendation on the control of the > number of concurrent sessions between a pair of VTEP as below address your > concern: > OLD TEXT: > The implementation SHOULD have a reasonable upper bound on the number > of BFD sessions that can be created between the same pair of VTEPs. > NEW TEXT: > If the implementation supports establishing multiple BFD sessions > between the same pair of VTEPs, there SHOULD be a mechanism to control > the maximum number of such session that can be active at the same > time. > SME: Yes, I think that this recommendation helps in resolving the issue. > I believe that this section 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? >> > GIM>> As stated in RFC 5880, BFD is designed to detect failures in the > path between two BFD systems. BFD detects the loss of path continuity > between forwarding engines used by BFD peers that participate in the given > BFD session. As it is defined now, BFD is not used to monitor the tunnel > traffic for possible performance degradation. > SME: OK, I'm fine with the response that no additional information is disclosed that could lead to confidentiality, integrity, or DoS exposure. > >> General comments: >> >> This standards track draft makes a normative reference to the base RFC, >> 7348, which is informational. >> Are there plans of making the base protocol a standards track >> specification? Downward references >> will need to be justified. >> > GIM>> As I understand, it is common practice to introduce to IETF process > a de-facto standard as Informational track document and reference it as the > normative document in a specification on the standard track. The flagged > downref requires manual correction. > SME: OK, I'll let the IESG deal with this aspect of the document. > >> Editorial comments: >> >> NVE is never expanded and not on the RFC Editors Abbreviation List. >> > GIM>> Thank you. Will expand as Network Virtualization Endpoint. > >> >> Echo BFD is out of scope for the document, but does not describe the >> reason for this or why state >> this at all? >> > GIM>> I think that the main reason is that the BFD Echo mode is > underspecified. RFC 5880 defined some of the mechanisms related to the Echo > mode, but more standardization work may be required. > SME: Could you use Jeff's text below to help with why BFD Echo is out of scope for this draft? Thanks, Shawn. -- On Wed, Jun 5, 2019 at 3:25 PM Jeffrey Haas <jhaas@pfrc.org> wrote: > On Tue, Jun 04, 2019 at 01:40:33PM -0700, Greg Mirsky wrote: > > > Echo BFD is out of scope for the document, but does not describe the > > > reason for this or why state > > > this at all? > > > > > GIM>> I think that the main reason is that the BFD Echo mode is > > underspecified. RFC 5880 defined some of the mechanisms related to the > Echo > > mode, but more standardization work may be required. > > Speaking as a BFD chair, this is the relevant observation. BFD Echo is > underspecified to the point where claiming compliance is difficult at best. > In general, it relies on single-hop and the ability to have the remote Echo > client loop the packets. > > This packet loop may not be practical for several encapsulations and thus > is > out of scope for such encapsulations. Whether this is practical for vxlan > today, or in the presence of future extensions to vxlan is left out of > scope > for the core proposal. > > -- Jeff >
- [secdir] Review of draft-ietf-bfd-vxlan-07 Shawn Emery
- Re: [secdir] Review of draft-ietf-bfd-vxlan-07 Greg Mirsky
- Re: [secdir] Review of draft-ietf-bfd-vxlan-07 Jeffrey Haas
- Re: [secdir] Review of draft-ietf-bfd-vxlan-07 Shawn Emery
- Re: [secdir] Review of draft-ietf-bfd-vxlan-07 Jeffrey Haas