[secdir] SecDir review of draft-ietf-v6ops-64share-09

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 19 February 2014 15:49 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id DA8C91A040F; Wed, 19 Feb 2014 07:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nFb4yDpd4SA7; Wed, 19 Feb 2014 07:49:52 -0800 (PST)
Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D4E9D1A032A; Wed, 19 Feb 2014 07:49:51 -0800 (PST)
Received: by mail-ee0-f48.google.com with SMTP id t10so322976eei.7 for <multiple recipients>; Wed, 19 Feb 2014 07:49:47 -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=DQegKVzEXDuHj3SXDd/z9Yh2r/o1snbJTEgSrtRxS88=; b=Tty3X94HF2HQDbNuLTgMHwf2QLl82nTzGaqx9gH+l4EujzkGvZ21d56yp4UapNMCs5 JmfEnlDFCGkyLsBsfSf84jxdc4Om8BLPz0vcnVIm8zAmlSa+BxZ4h0nyfr/66ANFoVwY Fz66nbHJTDq73FuPrcxJmqXOqCEZHTh21Pay/sPIyJ8k5kuCvuSnDTFeIlN0+W9p6iTB CJFxm43SWrdr+Vfv1h99LpGHoXeH9IxT8OQQ8WfBSbMGVe5g8kfBcrrNffUcXzgLCRxN YSy0xTfLB/81ARPgZzex7ZTMhatC8Kj35MoEwWF7u8ROqhrz4TiJuxVQnFbe3+pWoY2m th0w==
X-Received: by with SMTP id l41mr1781787eey.114.1392824987751; Wed, 19 Feb 2014 07:49:47 -0800 (PST)
Received: from [] (89-139-136-195.bb.netvision.net.il. []) by mx.google.com with ESMTPSA id m9sm2141715eeh.3.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 07:49:46 -0800 (PST)
Message-ID: <5304D298.7050101@gmail.com>
Date: Wed, 19 Feb 2014 17:49:44 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: secdir@ietf.org, draft-ietf-v6ops-64share.all@tools.ietf.org, iesg@ietf.org
References: <4FBFAE5F.8010305@gmail.com>
In-Reply-To: <4FBFAE5F.8010305@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qMyzETpAItcL7OiSvCEx9sXOYc4
Subject: [secdir] SecDir review of draft-ietf-v6ops-64share-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 19 Feb 2014 15:49:57 -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 describes two options of providing hosts behind a 3GPP UE 
(e.g., cellular router) with an IPv6 network prefix, in networks that do 
not support IPv6 prefix delegation. The document is explicitly 


The document is ready to progress.


- I don't understand why the first scenario (sec. 4.2) is even useful, 
i.e. why allocate the /64 to the LAN (and not just settle for a 
link-local prefix) when the UE does not have an address on the 3GPP 
link, and so cannot route traffic to the Internet?

- Despite the non-normative status of the document, I think the security 
considerations deserve stronger wording. I suggest to replace "shall be 
considered" by "SHOULD be applied".

- I would suggest that the security considerations also mention the 
privacy implications of having a (typically) small number of devices, 
all within a single unchanging network prefix. I *believe* this is 
behind the discussion of RFC 4941 is Sec. 4.3, but I would rather have 
the threat spelled out.