[secdir] Secdir last call review of draft-ietf-pim-3810bis-10

Valery Smyslov via Datatracker <noreply@ietf.org> Wed, 29 May 2024 08:43 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 862E5C14F6F6; Wed, 29 May 2024 01:43:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Valery Smyslov via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171697222753.27354.8958461284461061682@ietfa.amsl.com>
Date: Wed, 29 May 2024 01:43:47 -0700
Message-ID-Hash: JCM6M7N5XPN5T5QECPTMWO23GZA6NE7N
X-Message-ID-Hash: JCM6M7N5XPN5T5QECPTMWO23GZA6NE7N
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-pim-3810bis.all@ietf.org, last-call@ietf.org, pim@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Valery Smyslov <valery@smyslov.net>
Subject: [secdir] Secdir last call review of draft-ietf-pim-3810bis-10
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/0I992zJ5wxG41sj2fZ3GgPJMkHA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Reviewer: Valery Smyslov
Review result: Has Issues

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.

THe document describes the Multicast Listener Discovery protocol version 2
(MLDv2) for IPv6. This protocol allows IPv6 routers to discover the presence of
multicast listeners on directly attached links, and to discover which multicast
addresses are of interest to these listeners. The draft is well written and
easy to understand. There are few issues though, that relate to security of the
protocol.

I think that the Security Consideration section should be expanded and be
rewritten in a more structural way. In particular, it should be mentioned that
the protocol lacks any cryptographic protection, thus its messages are not
authenticated, provide no confidentiality and can be replayed. Then I would
discuss the consequences of each of these deficiencies.

The lack of replay protection seems to have no effect on the protocol security,
because it is (at least it should be) designed so that it tolerates IP packets
duplication (correct me if I'm wrong, I read the protocol itself briefly, but
this was my impression).

The lack of authentication leads to possible message forgery. The corresponding
attacks are described in the draft, however, I'm not sure taht the list is
complete. For example, it seems to me that forged Current State Report message
from a malicious node may report a lot number of faked listening multicast
addresses, aiming to consume router's resources (a kind of DoS attack).

The lack of confidentiality is not discussed in the draft. In fact, it leads to
privacy issues - any passive attacker on the local link can learn what
multicast addresses other nodes are listen to, which may be quite sensitive
information.