[secdir] SecDir review of draft-weil-shared-transition-space-request-03

Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 22 August 2011 21:16 UTC

Return-Path: <yaronf.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 BFBAD21F8B7E; Mon, 22 Aug 2011 14:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bXkC8KjW81X; Mon, 22 Aug 2011 14:16:38 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id B61D821F8B70; Mon, 22 Aug 2011 14:16:37 -0700 (PDT)
Received: by wwe5 with SMTP id 5so2521944wwe.1 for <multiple recipients>; Mon, 22 Aug 2011 14:17:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=DSkvl38cE3LIpxmpnPDF+WEVq8OnMNhBCET8KAeM9K4=; b=ZjdDldgyUXWmd/E09jkVLe85bNpx+t10TzLf1mVzLED7SuqKAdQ3EQopdasgiQ5fJa 3ScEa9fPLYsh8gBTh4g9lon1VF2WS7UYJcP+cy2Kh9TjeV/CiAFSz/LFy+1MGJBS0zrn 1rmp1M3sdpZNNjIHqCeMO0VRYxHxssyt3Cvf0=
Received: by 10.216.166.136 with SMTP id g8mr2348177wel.24.1314047861528; Mon, 22 Aug 2011 14:17:41 -0700 (PDT)
Received: from [10.0.0.3] (bzq-79-181-242-252.red.bezeqint.net [79.181.242.252]) by mx.google.com with ESMTPS id fm9sm5148626wbb.44.2011.08.22.14.17.38 (version=SSLv3 cipher=OTHER); Mon, 22 Aug 2011 14:17:40 -0700 (PDT)
Message-ID: <4E52C76D.30204@gmail.com>
Date: Tue, 23 Aug 2011 00:17:33 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: secdir@ietf.org, draft-weil-shared-transition-space-request.all@tools.ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir review of draft-weil-shared-transition-space-request-03
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: Mon, 22 Aug 2011 21:16:38 -0000

[Sorry if you receive this message twice. Please respond to this address.]

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

Security considerations are missing and should be added.

Details

A number of objections were raised on the main IETF mailing list. Not 
being an expert on IPv6 transition strategies, I will not opine on the 
value of the proposed address space. However from the point of view of 
security, the draft needs to be improved.

For motivation, the draft refers to a "problem statement" draft, 
draft-bdgks-arin-shared-transition-space. Looking at the security 
considerations in draft-bdgks, it is clear that the current document 
should say much more than "this is not a protocol; there are no security 
implications," as it currently does. I'm afraid I disagree on both 
counts: this is indeed a protocol (it defines who is allowed to use 
these addresses and for what purpose, and it *should* specify how this 
can be enforced), and there are clear security implications: you don't 
want people outside the ISP's network (or the ISP's own customers, for 
that matter) to spoof tunnel termination points.

Following up on draft-bdgks, the current document should at least advise 
on (and better yet, mandate solutions for) "best practices associated 
with the use of this space, including considerations relating to 
filtering, routing, etc.".

Thanks,
     Yaron