[secdir] SecDir review of draft-ietf-6man-rfc1981bis-06

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Mon, 17 April 2017 13:21 UTC

Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAA412ECA3; Mon, 17 Apr 2017 06:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3pW3ZNGnT9a; Mon, 17 Apr 2017 06:21:21 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A7412ECA1; Mon, 17 Apr 2017 06:21:21 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id q78so29560579vke.3; Mon, 17 Apr 2017 06:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=H+bbnpXbz7d/dLLaUQcxc8b3YtRHjeHuFWy21Oi21yg=; b=BC7lsUgZmykw71w9p5uFB2T3Op/XlC29ycmkIhsB1XMMaswiqtn66JZQP5vYqgQQLs 4RzHtMxQ+NM3CO1lA7NKA5sbzbGnwRamDLWVqRhhg/aDjt8yCRsHK9k+klM4BRl+DNuk /y5YrmLe3svAdwWJUsyAw9VAFLchI5THXveMuanPBKqb4RRpD4f8dwM19/T06U81HCG6 JwhQgQaR1cmLmyQDgZP6H2G+tPlNmIXrkKrYtxWnuIUmB36QpugAGruDr9EL05XhOaT+ t/MkZ5zAVVBlmebu4auVTU5yU2urlX9leR7lADoXLbHre2NQ0uFGpmePXWEmOFiGUf1E 5jpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=H+bbnpXbz7d/dLLaUQcxc8b3YtRHjeHuFWy21Oi21yg=; b=hMKP0/SKnUiNyWts/iC1SKT0uajY1qXrsGC6e0bnHF/3CfBzD+oTeg/llP5YgcQyEv amJ6Ce43O9zN3JPjeVMja0wl9imH/KqmxJI/HP+A32b5rMc6WIVRgae6iDx2HZBmnWqC tBbOJEpv/g1zJ6zvgjN3fJGhUdJvFO1ljY+CYnZSeswlg7ROVhVfSYusD9/WaHno+5nw fwcYo8ImggW6+9uAzWyRG+xHkvPGb9Zwg3KvpBnvJVVAHboboMqqBWRFNFPqf4/XvjPR jKkDscyCdpjcAELPCVIzzql6CPup5/LIBsjjB7y9v5Lr4dl5m8nM8geT6ryUr9JYSXgd bqoQ==
X-Gm-Message-State: AN3rC/7JqmtfTVYSlYSYTVCu0AFcGQdpgNb4KUlXANdi6bBjSepVp+bp 9WJRX4GCMH1n9KyQj6DXPIOVOZQyUM6R
X-Received: by 10.31.128.4 with SMTP id b4mr606267vkd.88.1492435280372; Mon, 17 Apr 2017 06:21:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.80.17 with HTTP; Mon, 17 Apr 2017 06:21:20 -0700 (PDT)
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Mon, 17 Apr 2017 09:21:20 -0400
Message-ID: <CAGL6ep+W33u81eKahPTXypX1A=sObD_=g0cXg-sALoT6JdFfAw@mail.gmail.com>
To: draft-ietf-6man-rfc1981bis@ietf.org, secdir@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary=001a1142a312bca8c6054d5caaaa
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/TSP93gEx0QW9WDOHUK3X3ipGiMk>
Subject: [secdir] SecDir review of draft-ietf-6man-rfc1981bis-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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, 17 Apr 2017 13:21:24 -0000

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 with issues


The Security Considerations section describes the possible implications of
a malicious party sending false ICMPv6 Packet Too Big messages and
reasonable ways to mitigate their impact.

The section also discusses the implication of filtering valid ICMPv6
Packet Too Big messages, which is one of the limitation of this mechanism,
and points to a more robust alternative.


Issues
======

Issue 1 - The Security Considerations section, page 14:

The first paragraph is discussing the case of malicious party stopping a
victim from receiving legitimate Packet Too Big messages. The second
paragraph is discussing the filtering of such packets and implies the
potential implication of "black holing".

It seems to me that in both of these use cases "black holing" is possible,
and should be clearly stated as such.


Issue 2 - Section 4, 5th paragraph:

Should the term "near future" be clearly defined here?


Nits
====

Page 6, first paragraph:
Drop the "to" before the word "appear"

Regards,
 Rifaat