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

Vízdal Aleš <ales.vizdal@t-mobile.cz> Thu, 20 February 2014 09:55 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 06BD31A0083 for <secdir@ietfa.amsl.com>; Thu, 20 Feb 2014 01:55:38 -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 H9hqbjwUc8Gc for <secdir@ietfa.amsl.com>; Thu, 20 Feb 2014 01:55:35 -0800 (PST)
Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id E554B1A0063 for <secdir@ietf.org>; Thu, 20 Feb 2014 01:55:32 -0800 (PST)
From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= <ales.vizdal@t-mobile.cz>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Date: Thu, 20 Feb 2014 10:55:23 +0100
Thread-Topic: SecDir review of draft-ietf-v6ops-64share-09
Thread-Index: Ac8uGGCXp2OwkdPOQ/uwlLfeYhot7AABtuwA
Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA3256BD0B@SRVHKE02.rdm.cz>
References: <4FBFAE5F.8010305@gmail.com> <5304D298.7050101@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA3256BC44@SRVHKE02.rdm.cz> <5305C118.5040507@gmail.com>
In-Reply-To: <5305C118.5040507@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/Lt0wlVP1IUzU1Z2u-n8LUwVmM4A
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 09:55:38 -0000

Hi Yaron,

Please see inline.

> >> -----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? 

Yes, that's the intention.

>It looks funny to me to have a default route with an LLA.

If you do SLAAC, the on-link router will send you the RA message
whose source IPv6 address will be LLA and will be also used
as the default route. (as per Neighbor Discovery RFC)

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

The use-case is your mobile phone acting as a WiFi access point
for your notebook while travelling or while being at home. There
is a need for GUA for the tethered devices. (IPv4 approach would
be private IPV4+NAT44)

> >> - 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).

You're right, the interim solutions tend to become permanent.

Some networks do, some don't. Please note that the mobile phones
are getting a /64 these days, so the potential privacy issue is
already there, we're just extending the same /64 to a small LAN.

A user may re-load the device to get a new prefix if their network
is not enforcing a new prefix every n hours.

> >> Thanks,
> >>        Yaron

Cheers,
Ales