Re: [Ila] Identifier size

Tom Herbert <tom@herbertland.com> Wed, 31 January 2018 17:13 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46B813184D for <ila@ietfa.amsl.com>; Wed, 31 Jan 2018 09:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 pygI93zFjtRF for <ila@ietfa.amsl.com>; Wed, 31 Jan 2018 09:13:45 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B3D131982 for <ila@ietf.org>; Wed, 31 Jan 2018 09:12:40 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id n188so4294280qkn.11 for <ila@ietf.org>; Wed, 31 Jan 2018 09:12:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6eNwH4wmOq4Hyb3JLCuYQg4cbkq2GfHgyXTPAJbWviE=; b=jMkPlHReWVga0p8fQN0bL8EZ9nFCWq4eZfnJiisUSi7fp3r+7o+z6IT2NdRpzsvf69 mNN7SDJXMf6Aq8lbdMcD96Lyu/TvUTzx3cekLFZGcb/V1QCZGAlCyELsjPfzAZAZskZw xyzFHpQGFr9yecJJDSsJ300nfRFDdl/6yv3+3oR0pSjKV9tl9+/1iXcuftt3Z4eJhLG4 +S2z6SPYKkp9JK1eiGz97Jcigu7ZhE4UpxqKaeaEg8F7RbwGZIk3lC94kj4EIWYmFqXZ 6o7FXJY4hM+diHa43U6jjAEWU/l/3BbrXitsIgozVdER8DFhZ+593f8N0hDvglVqb/yW RvCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6eNwH4wmOq4Hyb3JLCuYQg4cbkq2GfHgyXTPAJbWviE=; b=NOhU7AcDUAkAXZjrrNtmbxborKqlcUoctoXB1p90AM86SFcX+tTKPiScg8t7glSlj5 AZX0pOKJ3FQZ+ldTLXdQXcw590fAv2phgqjVzlZp3pDbbY2zYJQS5o/A4MtOUnsCAOwG 5kBoQ4j2OB8R2Aw0wFwU6UwgfluGpHu1qX2gnyWOyUu48lkGx8koKfO6uKX9Ih9TSaZ6 hEiLrFdxptOlMB2589nLNLMXqB0D7fHS6ZJAfajsJYFmx7TcKkXWI97TP6gV5CYrWIOl H10zPfiz/4LW39scMqC00hWrzdcl0ZaVsnqyJMJoTko2APEEUTZc+Ylf7FxYYHi5OEHC CPdA==
X-Gm-Message-State: AKwxyte1lxnwKZDH6pnY2fvA9bQT+Godh3ElTOg832i4D85iL5jHlqrI FVO1T0pbjwP6APkxKFiURiRbHxuSqWPKRveSEzvYyQ==
X-Google-Smtp-Source: AH8x224fdc8aefrbfChwOksNldAHF41OA1VewJXBgqE8+bF17cZkOWcT6/9BLKUlV4gydGRYg4xwXXYqBUOuuNjlPio=
X-Received: by 10.55.15.169 with SMTP id 41mr6831687qkp.91.1517418759426; Wed, 31 Jan 2018 09:12:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.56.229 with HTTP; Wed, 31 Jan 2018 09:12:39 -0800 (PST)
In-Reply-To: <CAC8QAcfTg_osQe4HGF8w-j_w_=2rwUv9-j=M-NhKyV7GVMxFPQ@mail.gmail.com>
References: <CAC8QAcfTg_osQe4HGF8w-j_w_=2rwUv9-j=M-NhKyV7GVMxFPQ@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 31 Jan 2018 09:12:39 -0800
Message-ID: <CALx6S35zOpTDEP2VJB2NcoDXMQrG9KF20xFqaZhfv=vqAayrUg@mail.gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: 5GANGIP <5gangip@ietf.org>, ila@ietf.org
Content-Type: multipart/alternative; boundary="001a11473f3e21b3050564159618"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/_ZiZBg0-drA0oIBpk22mpjT-wP0>
Subject: Re: [Ila] Identifier size
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jan 2018 17:13:48 -0000

On Wed, Jan 31, 2018 at 8:27 AM, Behcet Sarikaya <sarikaya2012@gmail.com>
wrote:

> Hi Tom, all,
>
> I changed this tread to identifier size issue.
>
> What is the motivation for crypto-graphic identifiers?  Is the idea to
give each device a master identifier and then it can use the a crypto
graphic function to independently create its own unique identifiers for use
in communications. That would be good for address per connection and 80
bits might be doable in ILA.

Saleem pointed out that:
>
> ILNPv6 will not work with more than 64 bits in the NID, and that is consistent
> with RFC8200/STD86 (which refers to RFC4291, for the use of a 64 bit ID).
>
>
> So my question is the identifier in identifier - locator separation equal
> to the interface id in RFC 8200?
>
> No, it's not. This is where one of the problems with identifier locator
address split arises. SLAAC performs /64 address assignments. This is
assigning a  subnet to a device with the expectation that IIDs in the
subnet (lower 64 bits) are assigned by the device receiving the
assignment,  Many mobile providers use SLAAC to assign /64 to UEs. This is
in contrast to using DHCPv6 to get singleton addresses. The IID space is
used by the UE for assigning addresses to downstream devices (like in
tethering) as well randomizing address for local binding as a means to
mitigate address scanning attacks (address scanning was used in WannaCry
attack). In this sort of address assignment it's the upper sixty-four bits
that identify the mobile device, the identifier for identifier/locator
split would be derived from the upper sixty-four bits.

Sixty-four bits isn't enough to encode both a locator and identifier, but I
think a level of indirection will work. This is my description of that:

A device may be assigned a /64 address via SLAAC as is common in many
provider networks. In this scenario, the low order sixty-four bits contains
IIDs arbitrarily assigned by devices for its purposes; so these bits cannot
be used as an identifier in ILA. The alternative to support /64 prefix
assignment is to encode an identifier in the upper sixty-four bits. Since
only a subset of bits are available, a level of indirection is used so that
 when ILA transformed the upper sixty four bits contains both a locator and
an index into a locator (ILA-N) specific table. The entry in the table
provides the original sixty-four bit prefix so that ILA to SIR
transformation can be done.

If yes, then what happens if the UE has more than one interfaces?
>
> This makes it the uniqueness of the IID and the identifier is the same
> problem?
>
> In ILA, identifiers need to be unique with an ILA domain. Normally, this
will mean it is unique with one SIR prefix. That is analogous to an IID
being unique within a subnet.

Tom