[spring] Secdir last call review of draft-ietf-spring-srv6-network-programming-17

Brian Weis via Datatracker <noreply@ietf.org> Thu, 27 August 2020 03:14 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: spring@ietf.org
Delivered-To: spring@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D91233A0CA7; Wed, 26 Aug 2020 20:14:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Brian Weis via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: draft-ietf-spring-srv6-network-programming.all@ietf.org, spring@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159849805983.7699.460089427690333419@ietfa.amsl.com>
Reply-To: Brian Weis <bew.stds@gmail.com>
Date: Wed, 26 Aug 2020 20:14:19 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/2GH4J44hB46ihCnKLIt1RTP8gOw>
Subject: [spring] Secdir last call review of draft-ietf-spring-srv6-network-programming-17
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2020 03:14:20 -0000

Reviewer: Brian Weis
Review result: Has Nits

This document is titled “SRv6 Network Programming”, which is attention
grabbing. It fleshes out how Segment Routing routes IPv6 packets by Segment ID
(SID), as well as defining the format of a SID for IPv6. The Introduction
states, “An ingress node steers a packet through an ordered list of
instructions, called segments.” When one considers this statement along with
the document title, it’s apparent that network devices are indeed being given
“instructions” in the programming sense, where each “instruction” is encoded in
an IPv6 address.

An “instruction” (i.e., SRv6 SID) comprises a locator (which is used to route
to a particular network device), and also directs the network device acting as
the locator how to process the IPv6 packet. With the help of an IPv6 Segment
Routing Header (SRH) header, a series of “instructions” can source route a
packet through the network, where each network device acting as a locator
learns how to handle the packet before possibly sending it on to the next SID
(if any).

The encoding of an IPv6 address as an SRv6 SID includes a locator, a code
indicating a certain function, and optionally arguments to that function. An
initial set of codes (and their associated algorithms) is defined in this
document. Most of the codes describe how the egress router should decapsulate
the packet, with might include defining  which routing table the receiving
router should look up after decapsulation.

The Security Considerations section points to the Security Considerations of
the architecture document and the SRH document. Both documents focus on the
fact that SRv6 is intended to be used within a single domain (e.g., provider
network) and discuss routing mitigations such as filtering external traffic
appropriately. They seem to assume that the boundaries of the domain itself are
inviolate such that the domain boundary devices are not subverted, and that
there are no bad actors within the domain. These are common assumptions for
service provider networks where Segment Routing is intended to be deployed.

However, it cannot be certain that all networks deploying Service Routing to be
free of bad actors, and there will certainly be some benefit to a bad actor
changing “instructions” encoded in IPv6 addresses. Perhaps there is opportunity
for mischief in changing the routing table argument in an End.DT46, for
example. Also, as other SRv6 functions are defined (e.g., packet inspection
functions), it would be important to ensure that those SIDs are not modified to
avoid or decrease the quality of those inspection functions.

The SRH document does describe an HMAC TLV that is intended to mitigate these
kinds of attacks. Since neither of the referenced documents Security
Considerations mention it, it would be a good idea to describe here that there
are threats to changing SIDs, and point out how to mitigate them with the HMAC
TLV.

Also, if I’m not mistaken, when there is just one SID then it is placed in the
IPv6 DA and there is no SRH header or HMAC TLV. This is a general problem with
ensuring that the DA on packets are not changed in transit, and one could use
IPsec to mitigate that issue. It’s probably worthwhile mentioning something
like that.