[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.
- [Sidrops] Secdir last call review of draft-ietf-s… Mališa Vučinić via Datatracker