[secdir] Secdir last call review of draft-ietf-grow-bmp-adj-rib-out-06

Catherine Meadows via Datatracker <noreply@ietf.org> Fri, 02 August 2019 20:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0902212018B; Fri, 2 Aug 2019 13:19:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Catherine Meadows via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: grow@ietf.org, draft-ietf-grow-bmp-adj-rib-out.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Message-ID: <156477714899.20990.10992539485582022650@ietfa.amsl.com>
Date: Fri, 02 Aug 2019 13:19:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/EfDiEUc_IH2xTc2-rZX02DKuTU0>
Subject: [secdir] Secdir last call review of draft-ietf-grow-bmp-adj-rib-out-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Aug 2019 20:19:09 -0000

Reviewer: Catherine Meadows
Review result: Not Ready

This draft describes describes a modification of BGP Monitoring Protocol to
allow it access to the Adj-RIB-Out Routing Information Bases.  It already has
access to the  Adj-RIB-In.  According to  RFC4271  these are defined as
follows: ”The Adj-RIBs-In contains unprocessed routing information that has
been advertised to the local BGP speaker by its peers"   and "The Adj-RIBs-Out
contains the routes for advertisement to specific peers by means of the local
speaker’s UPDATE messages.”   The procedure by which BMP sends  Adj-RIBS-Out is
similar to  that which by which it sends Adj-RIBS-In.

The Security Considerations Section consists of the following statement:

It is not believed that this document adds any additional security

This is not enough.  First, you need to say additional security considerations
beyond what.  This can best be done by referencing one or more RFCs.  In this
case it would be RFC 7854, and perhaps RFC 4271.  e.g.

This document does not add any  additional security considerations beyond those
already covered RFC 7854.

Secondly, you need to say why it doesn’t introduce any new security
considerations.  In both Adj-RIBS-In and Out cases the information sent is
routing information.  Would there be any new security considerations involved
in sharing routing information sent in UPDATE messages vs. advertisements?  If
not, why not?