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 >
- [secdir] SecDir review of draft-camarillo-rai-med… Yaron Sheffer
- Re: [secdir] SecDir review of draft-camarillo-rai… Gonzalo Camarillo
- Re: [secdir] SecDir review of draft-camarillo-rai… Gonzalo Camarillo
- [secdir] SecDir review of draft-yegin-pana-encr-a… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-krb-wg-kerbe… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Sean Turner
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Stephen Farrell
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Sam Hartman
- Re: [secdir] SecDir review of draft-ietf-krb-wg-k… Tom Yu
- [secdir] SecDir and AppsDir review of draft-ietf-… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- [secdir] Use of StringPrep/Unicode (was Re: SecDi… Alexey Melnikov
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Black, David
- Re: [secdir] Use of StringPrep/Unicode (was Re: S… Black, David
- Re: [secdir] SecDir and AppsDir review of draft-i… Black, David
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- Re: [secdir] SecDir and AppsDir review of draft-i… Mallikarjun Chadalapaka
- Re: [secdir] SecDir and AppsDir review of draft-i… Alexey Melnikov
- [secdir] SecDir review of draft-ietf-6renum-enter… Yaron Sheffer
- [secdir] SecDir repeat review of draft-ietf-6renu… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-rtgwg-ipfrr-… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-clue-telepre… Yaron Sheffer
- [secdir] SecDir review of draft-ietf-v6ops-64shar… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Vízdal Aleš
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-v6ops-64… Vízdal Aleš