[RTG-DIR] Rtgdir last call review of draft-ietf-idr-bgpls-srv6-ext-12

Stewart Bryant via Datatracker <noreply@ietf.org> Mon, 28 November 2022 07:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 066B9C1524CC; Sun, 27 Nov 2022 23:32:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stewart Bryant via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-idr-bgpls-srv6-ext.all@ietf.org, idr@ietf.org, last-call@ietf.org, rtg-ads@ietf.org, sec-ads@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166962073801.18346.2098650422227174656@ietfa.amsl.com>
Reply-To: Stewart Bryant <stewart.bryant@gmail.com>
Date: Sun, 27 Nov 2022 23:32:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/Zli0PZPtgzLtIEAhKFTRZGduhz0>
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-bgpls-srv6-ext-12
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2022 07:32:18 -0000

Reviewer: Stewart Bryant
Review result: Has Issues

I apologies for the lateness of this last call review.

The routing technology in this specification seems fine, however I do have
concerns over the network security.

>From the text in the introduction is says: "On similar lines, introducing the
SRv6 related information in BGP-LS allows consumer applications that require
topological visibility to also receive the SRv6 SIDs from nodes across an IGP
domain or even across Autonomous Systems (AS), as required.  This allows
applications to leverage the SRv6 capabilities for network programming."

Then in the security section it says "SR operates within a trusted domain
[RFC8402] and its security considerations also apply to BGP-LS sessions when
carrying SR information."

I am concerned that the exposure of sensitive network information outside the
network as proposed here represents a significant security risk. I am also
concerned that the increased (practically unconstrained) exposure to the threat
of hostile actors.

The "trusted domain" concept which is fundamental to SRv6 is fragile at best.
The scope of the domain and the method of policing are not well described, and
unlike MPLS which successfully operates that model, SRv6 does not have the
advantage of being able to automatically classify external traffic as being of
an alien type. With this specification the domain is expanded from the network
itself to some subset of the applications using the network. It is difficult to
see how the scope and size of the threat to the network is contained in this
operational model and I do not see text that help the operator in that regard.
Applications significantly increase the size of the code base and number of
organizations that can introduce a threat, and by their nature expand the
geographic area of risk in an unconstrained way, perhaps to the full Internet.

I believe that a more complete review of the security model is needed before
this specification is finalised.