[secdir] Secdir early review of draft-ietf-idr-segment-routing-te-policy-18

Vincent Roca via Datatracker <noreply@ietf.org> Mon, 18 July 2022 15:57 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 1D85AC131819; Mon, 18 Jul 2022 08:57:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Vincent Roca via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-idr-segment-routing-te-policy.all@ietf.org, idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165815985911.41588.4687011809090979175@ietfa.amsl.com>
Reply-To: Vincent Roca <vincent.roca@inria.fr>
Date: Mon, 18 Jul 2022 08:57:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/NtawBFAsAZAXkH-FiwGc5rebzX4>
Subject: [secdir] Secdir early review of draft-ietf-idr-segment-routing-te-policy-18
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 18 Jul 2022 15:57:39 -0000

Reviewer: Vincent Roca
Review result: Ready

Hello,

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.

Summary: Ready

I have no comment regarding the security part. Most issues seem fairly classic
when dealing with BGP peering and the Security Considerations section reminds
it's the responsibility of the network operator to guarranty that traffic is
restricted to trusted domain/nodes. I don't know the domain but it seems
reasonable.

Otherwise, a minor comment.
Section 2.4.1: I suggest being a bit more informative when describing Type and
Length fields (this is the first mention of the packet format): >   o  Type: 12
>   o  Length: 6.

There's no explanation and no unit.
As I understand, 12 is a reserved value for a "Preference Sub-TLV", say it, and
Length is 6 bytes long, encompassing the Flags, RESERVED, and Preference
fields, say that too (at least the 1st time).

Cheers,

Vincent