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

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 20 February 2014 08:47 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1801A003D for <secdir@ietfa.amsl.com>; Thu, 20 Feb 2014 00:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 IWqaMvPPSq57 for <secdir@ietfa.amsl.com>; Thu, 20 Feb 2014 00:47:27 -0800 (PST)
Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CA01A1A0037 for <secdir@ietf.org>; Thu, 20 Feb 2014 00:47:26 -0800 (PST)
Received: by mail-ee0-f42.google.com with SMTP id b15so775227eek.15 for <secdir@ietf.org>; Thu, 20 Feb 2014 00:47:22 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e3r2vV5bSyl00VOlHuguNufL36TOIV8Rm6nhn3fenyQ=; b=KPiZN+5tBqsPXh6iEhzSTTq9u/b3lHJ/41Jq49BIQBxf/WyKGh8ZbTsaFjNaFtAPn0 Fr8U9zg7IIoH7XclVC4iFfgqmr/fN8K7xpbLrwgpARKkadMzL8TOHJHmW197qs/uILVR 9V2oCyQK1wFrCnhAHYVH1B0khFtJ2XYR67ypVjHju5O1QTtRfRp/ZTGUzz5JClo5MknZ iWGMCtn4tnJaqmMcpyib25hc768GFSlp4NbxvHKNTx/2iaAIQcEeaZOqkLeKv+/3OFXw DiD8RPBycWKjTeKFhr6v04Z2XGnpPWt0OKKosEDZ2mT75IPONHVUUsmt8oTDJ2mvYENQ /4Iw==
X-Received: by 10.15.54.65 with SMTP id s41mr611571eew.100.1392886042546; Thu, 20 Feb 2014 00:47:22 -0800 (PST)
Received: from [10.2.0.16] (89-139-136-195.bb.netvision.net.il. [89.139.136.195]) by mx.google.com with ESMTPSA id f45sm11019886eeg.5.2014.02.20.00.47.21 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 00:47:22 -0800 (PST)
Message-ID: <5305C118.5040507@gmail.com>
Date: Thu, 20 Feb 2014 10:47:20 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Vízdal Aleš <ales.vizdal@t-mobile.cz>
References: <4FBFAE5F.8010305@gmail.com> <5304D298.7050101@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA3256BC44@SRVHKE02.rdm.cz>
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCDA3256BC44@SRVHKE02.rdm.cz>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ch_Z5Li3R_BCebDn8s6pj2mIx-s
Cc: "draft-ietf-v6ops-64share.all@tools.ietf.org" <draft-ietf-v6ops-64share.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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: Thu, 20 Feb 2014 08:47:28 -0000

[Dropped IESG]

Hi Ales, please see below.

Thanks,
	Yaron

On 02/19/2014 05:59 PM, Vízdal Aleš wrote:
> Dear Yaron,
>
> Many thanks for your review.
>
>> -----Original Message-----
>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]

[...]

>> Summary
>>
>> The document is ready to progress.
>>
>> Details
>>
>> - 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?
>
> This scenario is discussing a case where the 3GPP interface assigned
> GUA prefix will be moved to the LAN link, the 3GPP link will still
> be LLA numbered.

So can Internet traffic from the LAN be routed through the 3GPP link in 
this case? It looks funny to me to have a default route with an LLA.

If this is a small independent network with no Internet routing, you 
don't really need a GUA prefix.

>
>> - 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".
>
> OK, we will consider it.
>
>> - 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.
>
> OK, the lifetime of a prefix is bound to the lifetime of the network
> attach (context), once the device (UE) re-attaches a new prefix will
> be assigned by the network. This solution shall be understood as
> an interim one bridging the gap till DHCP-PD will be widely available.

This "interim" period can be a few years, and in the meantime we have a 
large privacy issue here. Does the provider normally enforce periodic 
reassignment of the network prefix? Otherwise I can see prefixes 
remaining valid for months (for small routers of course, not for phones).

>
>> Thanks,
>>        Yaron
>
> Cheers,
> Ales
>