[Sidrops] Secdir last call review of draft-ietf-sidrops-rov-no-rr-03

Mališa Vučinić via Datatracker <noreply@ietf.org> Wed, 03 August 2022 11:01 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C044EC157B4C; Wed, 3 Aug 2022 04:01:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mališa Vučinić via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-sidrops-rov-no-rr.all@ietf.org, last-call@ietf.org, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165952447777.25310.16375289147619891801@ietfa.amsl.com>
Reply-To: Mališa Vučinić <malisa.vucinic@inria.fr>
Date: Wed, 03 Aug 2022 04:01:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Xj49LXudMAMZ5H44RjXPINrnAeU>
Subject: [Sidrops] Secdir last call review of draft-ietf-sidrops-rov-no-rr-03
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2022 11:01:17 -0000

Reviewer: Mališa Vučinić
Review result: Ready

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 is a short, well-written document which describes a mechanism to avoid
Route Refresh due to new RPKI data being available at BGP speakers. The idea is
that the BGP speakers preserve the partial routing data (Adj-RIB-In) in case
Route Origin Validation fails, in order to be able to check it back once the
RPKI data is available. The mechanism improves the previous situation where
some implementations would trigger the Route Refresh upon receiving new RPKI
data.

The Security Considerations section refers to the document references for
considerations. While I am not an expert on BGP, I do not perceive new security
issues with this proposal.