Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 07 January 2016 15:47 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781201A9009 for <v6ops@ietfa.amsl.com>; Thu, 7 Jan 2016 07:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 7QekQPacafgz for <v6ops@ietfa.amsl.com>; Thu, 7 Jan 2016 07:47:44 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34611A8FD6 for <v6ops@ietf.org>; Thu, 7 Jan 2016 07:47:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07FlhXb047102; Thu, 7 Jan 2016 08:47:43 -0700
Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07Fldka047062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 08:47:40 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.35]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 07:47:39 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "VAN DE VELDE, Gunter (Gunter)" <gunter.van_de_velde@alcatel-lucent.com>, "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" <draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org>
Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host
Thread-Index: AQHRRrIFI13RUsgT4kOKL/Th7Sw3uJ7vFi6A///VyTCAAW6RgP//3BOw
Date: Thu, 07 Jan 2016 15:47:39 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com>
References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <CAKD1Yr3RY1oUtQnN675djc22f7B1Fhx0Ntsmr9rmZVEqmygRDg@mail.gmail.com> <D2B2F846.63BCC%evyncke@cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> <E0AC9F63-5C23-4E79-8B5F-63E3168AE162@alcatel-lucent.com>
In-Reply-To: <E0AC9F63-5C23-4E79-8B5F-63E3168AE162@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/8tKH9B_Xn1pQea4NRE_9nnOP-6I>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2016 15:47:45 -0000

Hi Gunter,

OK, so you are saying that the MAC address of the UE is used as the UE identifier.
But, both link-local and MAC addresses can be readily spoofed by an attacker,
either to steal the service of the legitimate node or to deny service to the
legitimate node. In order to avoid that, the UE would have to have some form
of identifier that cannot be spoofed, or sign its messages using a certificate
provisioned by the service provider - even though captive portal is being
used to authenticate the user.

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: VAN DE VELDE, Gunter (Gunter) [mailto:gunter.van_de_velde@alcatel-lucent.com]
> Sent: Thursday, January 07, 2016 1:51 AM
> To: Templin, Fred L; draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
> Cc: v6ops@ietf.org WG
> Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host
> 
> 
> Hi Fred,
> 
> 
> The WLAN-GW should not care about overlap here, there is a split horizon function and the wlan-gw should be able to handle
> overlapping IPs. Link-local address may be stored to e.g. use when sending RA, but it should not be used as a key, that is the role of
> the MAC address. So as long as MAC addresses don't overlap there should not be a problem distinguishing UEs.
> 
> 
> That being said, it would be unlikely to happen since link-local addresses in a WiFi context are mostly EUI-64 based and thus encode
> the MAC address which as stated should be unique.
> 
> Kind Regards,
> G/
> 
> 
> 
> 
> 
> 
> On 06/01/16 21:01, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
> 
> >I have what I hope will be a simple question: what if two or more UEs configure
> >identical IPv6 link-local addresses - will the WLAN-GW be able to tell them apart?
> >Asked another way, what kind of unique node identifier does the WLAN-GW
> >expect each UE to provide in the initial RS?
> >
> >Thanks - Fred
> >fred.l.templin@boeing.com