[secdir] SecDir repeat review of draft-ietf-6renum-enterprise-05

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 03 January 2013 10:43 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7941621F8518 for <secdir@ietfa.amsl.com>; Thu, 3 Jan 2013 02:43:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.556
X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ScjiYoaWRsHO for <secdir@ietfa.amsl.com>; Thu, 3 Jan 2013 02:43:48 -0800 (PST)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9146421F8B0F for <secdir@ietf.org>; Thu, 3 Jan 2013 02:43:47 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id fe20so7667429lab.1 for <secdir@ietf.org>; Thu, 03 Jan 2013 02:43:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YE5M5gBF9mIKqnLBEdDfo1tytazqIictLBdM3HwY194=; b=tu7ptsKHWzsD4NjgXRmQsZs44eqnVmPYrhRQqs4oOHvbjGfeP/5U7A6xRQNs90I0jV 5ZJ4rditNdeHGmBXg9b1e7mGT0ESdb2AvogvWcXU2q+DEgCCG+nsQGsPM+xaF/jQKytZ UG66Crm6sQIJQuoMIvx2oyU7FBVuM9Ley0j0KzcxTzE+1OdmQN9+gDMWjFm4aLxrObXi mXheN4Onir/7abms6OHd2R92PmZ+YLfY8hn1PVeLSnr8mEE4kRjclXxw/RI7e3nQgiK3 rBcj7HNfoJOktlSN0o7v/m/L5jOZ68OFhzJzGAVdv7AC2XYm6pHLUmlOtikF6IuN6E3T +i7g==
X-Received: by with SMTP id l15mr19204613lbo.5.1357209826378; Thu, 03 Jan 2013 02:43:46 -0800 (PST)
Received: from [] (85-250-110-45.bb.netvision.net.il. []) by mx.google.com with ESMTPS id sj3sm18259074lab.2.2013. (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 02:43:44 -0800 (PST)
Message-ID: <50E560DD.8050506@gmail.com>
Date: Thu, 03 Jan 2013 12:43:41 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-6renum-enterprise.all@tools.ietf.org
References: <4FBFAE5F.8010305@gmail.com> <50CB009A.80908@gmail.com>
In-Reply-To: <50CB009A.80908@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir repeat review of draft-ietf-6renum-enterprise-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 03 Jan 2013 10:43:48 -0000


version -05 of the draft responds to all the concerns I had with -04. I 
have no additional comments.


On 12/14/2012 12:34 PM, Yaron Sheffer 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.
> This document reviews best practices in renumbering IPv6 enterprise
> networks.
> I apologize for my belated review, and hope it is still useful to the
> authors and document reviewers.
> Summary
> The Security Considerations section appears appropriate for this type of
> document. I do not see any issues that should block the document from
> advancing.
> Details
> - Usage of FQDN: I don't understand why RFC 5996 (IKEv2) is cited, I
> suspect this is a typo. Otherwise, please clarify.
> - The "Security" subsection of 4.1 overlaps with the Security
> Considerations section, and I would recommend to consolidate them.
> - 4.1, "Miscellaneous": I accept the recommendation to use FQDNs instead
> of IP addresses. But saying "connections can survive" implies to me that
> live TCP connections will survive an IP renumbering event, which is not
> the case. I would say "connectivity to the remote side can survive"
> instead.
> - 4.3: RFC 2230 is mentioned as a way to deal with naming of IPsec
> endpoints. I am not aware of current implementations of this RFC (in
> fact it is not even mentioned in the current IPsec Roadmap document, RFC
> 6071). Moreover, there is community consensus that IPsec should not be
> used in the absence of a key management protocol. And IKE/IKEv2
> certainly supports naming/identifying endpoints by FQDN.
> - The Security Considerations are sufficient IMO. The first point (using
> renumbering to escape blacklisting) is appropriate in the context, even
> if per Martin Stiemerling's comment, this strategy may not be very
> effective. This is not a recommendation on how to bypass blacklisting,
> just a description of a potential vulnerability.
> Thanks,
>       Yaron