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

Vízdal Aleš <ales.vizdal@t-mobile.cz> Wed, 19 February 2014 15:59 UTC

Return-Path: <ales.vizdal@t-mobile.cz>
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 563C61A01DE; Wed, 19 Feb 2014 07:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, 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 kTAMAU10a4j1; Wed, 19 Feb 2014 07:59:09 -0800 (PST)
Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 313E61A0203; Wed, 19 Feb 2014 07:59:06 -0800 (PST)
From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= <ales.vizdal@t-mobile.cz>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Date: Wed, 19 Feb 2014 16:59:00 +0100
Thread-Topic: SecDir review of draft-ietf-v6ops-64share-09
Thread-Index: Ac8tij/XPzJsJTlMR62q6PmDAXIG9QAAEOwg
Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA3256BC44@SRVHKE02.rdm.cz>
References: <4FBFAE5F.8010305@gmail.com> <5304D298.7050101@gmail.com>
In-Reply-To: <5304D298.7050101@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-loop: 2
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forwarded
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/B1LS-mYXbSDaLcxp5R8eAUqRPxs
X-Mailman-Approved-At: Wed, 19 Feb 2014 09:26:35 -0800
Cc: "draft-ietf-v6ops-64share.all@tools.ietf.org" <draft-ietf-v6ops-64share.all@tools.ietf.org>, "iesg@ietf.org" <iesg@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: Wed, 19 Feb 2014 15:59:12 -0000

Dear Yaron,

Many thanks for your review.

> -----Original Message-----
> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
> Sent: Wednesday, February 19, 2014 4:50 PM
> To: secdir@ietf.org; draft-ietf-v6ops-
> 64share.all@tools.ietf.org; iesg@ietf.org
> Subject: SecDir review of draft-ietf-v6ops-64share-09
> 
> 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 non-normative.
> 
> 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.

> - 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.
 
> Thanks,
>       Yaron

Cheers,
Ales