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

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 14 December 2012 10:34 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 1EF4A21F874B; Fri, 14 Dec 2012 02:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.466
X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=0.134, 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 9Ieg5SZQe7IJ; Fri, 14 Dec 2012 02:34:10 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF921F8746; Fri, 14 Dec 2012 02:34:09 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so2624398lbk.31 for <multiple recipients>; Fri, 14 Dec 2012 02:34:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xTIPvcDY0NQOmgPtOLC3JlODV7L3cPJqFuTQsLWHFdk=; b=cfw212J3D3WQvXecZ0jMY+ODtvft2iyZ1b9jqIPk/llT3ak3Av2Z0B1V0vNkwWEurC l7U4dfWN1KtOIojdmMHZj8nVgqe+EXXGEpU9nQ7HYOj6KVEN8YLmVte2C2+tibujMQTl kT94TuI0Xf17i70zphwisqeCvlPao3MdiY09u3rfJ+nWku/Qo0cj+8ksPswVV/FBkofw PE14NG4qYEI2W/af4jT56Z5nQER9XPQWWmqOK5N0oIwefiIDM1CFPUv37tEYph5ySHjv NH4EN44YgFn3LllQkgOOpTHGgOO4Z+dFaABSHRp5BR/vVBV5qY3+/f2qcO62tpZhup+2 fl5Q==
Received: by with SMTP id o11mr2140035lbc.98.1355481248884; Fri, 14 Dec 2012 02:34:08 -0800 (PST)
Received: from [] (bzq-79-179-146-198.red.bezeqint.net. []) by mx.google.com with ESMTPS id v6sm1718441lbf.11.2012. (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 02:34:07 -0800 (PST)
Message-ID: <50CB009A.80908@gmail.com>
Date: Fri, 14 Dec 2012 12:34:02 +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, The IESG <iesg@ietf.org>
References: <4FBFAE5F.8010305@gmail.com>
In-Reply-To: <4FBFAE5F.8010305@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir review of draft-ietf-6renum-enterprise-04
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: Fri, 14 Dec 2012 10:34:11 -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.

This document reviews best practices in renumbering IPv6 enterprise 

I apologize for my belated review, and hope it is still useful to the 
authors and document reviewers.


The Security Considerations section appears appropriate for this type of 
document. I do not see any issues that should block the document from 


- 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.