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

Bob Hinden <bob.hinden@gmail.com> Mon, 17 April 2017 16:22 UTC

Return-Path: <bob.hinden@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 C4EB91315AD; Mon, 17 Apr 2017 09:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 7bD7RZKe_7fC; Mon, 17 Apr 2017 09:22:47 -0700 (PDT)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 7F8FB1315E8; Mon, 17 Apr 2017 09:22:29 -0700 (PDT)
Received: by mail-wm0-x241.google.com with SMTP id d79so9706773wmi.2; Mon, 17 Apr 2017 09:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oSSiGpHTat+CnYzWAaKqQ/D8oD82ixPbZiSupKFmeuY=; b=A2FqYX7mV/CHKumHlJbTNhAQyFMBODDYnzvfoPJsB1HDObfIiac0GhbDXl5Fbdmj4p I14YP8wkYUntsLT0wTYwtmhOrSOx4XCNh+kIhsrDL2EhWPN9MSiU/IGfDg/CotPS/kDW nOjw+lVOVMP1E37u0rF/C+hjOscCTtO/OQmDpLX3hU4FJGXbnj4AsuRIGxDTh1M4VAUF npGszWCEsqOKoFEYnKNYnGCdvv0P5AOGaT+kYCJZR2ei6AfiGpH8EDQ6tLmFKp8H3DGm feGjz8rwSAZ89uNpj1KYKsPdfNreUSBkmZoZxs5zNt624GTM+omETt+iSWAibujQfAUX 6pEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oSSiGpHTat+CnYzWAaKqQ/D8oD82ixPbZiSupKFmeuY=; b=IlTW4LnL1PVjNCrFen/3PfNaCyLlGPTpj9/1O4hn3ZkLuaIVUuGxemPtGgGx6qdLtK qifVQPH/7SYl6TIU8oUGikxG3IrhJSbaN5ancLAmvxtbvuLju9dqwIZ8MOp9IEGrQ8W5 IquAU8GS13DL83zM8dOah9exb/SIQKXH41zuGnaRQxIKpZofwPqL/K6oDDtLxNZlSvRP DmMwRXrcVH7op3RxN6ZLwsMKyAS30ig4c/pNhqkqHyl/npdwKZOmZ4/ncW9UIhcVYAkC XG+4s6++92/ViGm0CCwbuaB76rEABrqN1N0Zftd5PQsSQX/M5cU+r7Of5RU0qHpb8+I4 FIQA==
X-Gm-Message-State: AN3rC/5cbraOEzVjdlqvzfkz0jeyBa3/fuCm8Ls65kFu/DEjJ/e1AKNt T6kr11jJHthWol2I8XQ=
X-Received: by 10.28.20.85 with SMTP id 82mr9711119wmu.59.1492446148055; Mon, 17 Apr 2017 09:22:28 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:7138:5797:ecde:70ca? ([2601:647:4d01:db10:7138:5797:ecde:70ca]) by smtp.gmail.com with ESMTPSA id z84sm11036148wmh.27.2017.04.17.09.22.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 09:22:26 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <BAC2B14B-1A12-4EB3-B510-C374AB29D4F4@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_9AC639EE-E2DF-4F5C-B64B-0CCB72297B54"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 17 Apr 2017 09:22:20 -0700
In-Reply-To: <CAGL6ep+W33u81eKahPTXypX1A=sObD_=g0cXg-sALoT6JdFfAw@mail.gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, draft-ietf-6man-rfc1981bis@ietf.org, secdir@ietf.org, IESG <iesg@ietf.org>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
References: <CAGL6ep+W33u81eKahPTXypX1A=sObD_=g0cXg-sALoT6JdFfAw@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/9X6zZQ0R9PdefOJ7tDaGoIjM6Xc>
Subject: Re: [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 16:22:49 -0000

Rafaat,

Thanks for the review.  Comments below.

Bob

> On Apr 17, 2017, at 6:21 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
> 
> 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.

How about if I add the following after the two indented paragraphs describing the attacks:

   Both of these attacks can cause a black hole connections, that is, the
   TCP three-way handshake completes correctly but the connection hangs
   when data is transferred.


> 
> 
> Issue 2 - Section 4, 5th paragraph:
> 
> Should the term "near future" be clearly defined here?

I think the text is clear given the sentences that follow.  The text is trying not to be too descriptive given that implementations will differ.   It could say things like “quickly” “as soon as possible”, etc., but I think that’s all about the same.

> 
> 
> Nits
> ====
> 
> Page 6, first paragraph:
> Drop the "to" before the word “appear"

Thanks, will fix.


> 
> Regards,
>  Rifaat
> 
>