[secdir] Secdir last call review of draft-ietf-dmm-srv6-mobile-uplane-21

Stephen Farrell via Datatracker <noreply@ietf.org> Sat, 05 November 2022 17:47 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 F1B95C14CE3A; Sat, 5 Nov 2022 10:47:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: dmm@ietf.org, draft-ietf-dmm-srv6-mobile-uplane.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.20.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166767044098.30659.4793177681477368157@ietfa.amsl.com>
Reply-To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Sat, 05 Nov 2022 10:47:20 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jgAWwA4f1V8MhicyV3P-6gLxYBQ>
Subject: [secdir] Secdir last call review of draft-ietf-dmm-srv6-mobile-uplane-21
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: Sat, 05 Nov 2022 17:47:21 -0000

Reviewer: Stephen Farrell
Review result: Has Issues

This is a relatively minor issue, but worth fixing. This draft is aiming for
standards-track. RFC2804 says that we won't standardise lawful intercept
mechanisms, yet the draft specifies in 6.1 that Args.Mob.Session can be used
for that. I'd say best is to just drop that example usage to avoid having to
worry about this.

Otherwise, if one believes the basic security claim of SRv6 (that traffic can
be kept within a "trusted" local n/w) then the security considerations here are
correct that this doesn't add anything new.