Re: [5gangip] Identifier size

[Robert Moskowitz <[e-mail]>]

1.4*10^18

1% at 1.7*10^17
.1% at 5.6*10^16

*I* would not bet a design on even a .1% collision probability.  I AM 
including a collision management feature.

Bob

On 02/01/2018 11:37 PM, Dino Farinacci wrote:
> But I’d bet on 50% probability with a 120-bit identifier. But, as you say, we are old guys.  ;-)
>
> Dino
>
>> On Feb 1, 2018, at 8:22 PM, Robert Moskowitz <[e-mail]> wrote:
>>
>> This is the wrong way to look at it.  What is the 1% probability of a collision.  At that point, a collision is going to happen.  The 50% probability is a sure bet thing.
>>
>> In a possible population of 2^128, the probability of a collision reaches 1% when the population reaches
>>
>> 2.7*10^18
>>
>> This is a big number, but nowhere like what it takes to reach a 50% collision probability.
>>
>> But this thread was on a MUCH smaller size Identifier.  You have to run the numbers and if the probability is even 0.1%, you better include a collision management piece.
>>
>> Bob
>>
>> On 02/01/2018 06:01 PM, Dino Farinacci wrote:
>>> I keep this on my desktop, just for frequent reference. UUIDs are 128 bits.
>>>
>>> Dino
>>>
>>> <PastedGraphic-2.png>
>>>
>>>> On Feb 1, 2018, at 2:18 PM, Robert Moskowitz <[e-mail]> wrote:
>>>>
>>>> Behcet,
>>>>
>>>> I was really sick with the flu and a secondary infection all of January and am only now trying to cut through the backlog.  Us older guys got to watch it...
>>>>
>>>> Anyway a comment about length of Identifier.  i have a bit of experience on considering how long to make an Identifier.   For some recent examples on this and the best estimation equation on the probability of collisions, please see:
>>>>
>>>> draft-moskowitz-hierarchical-hip
>>>>
>>>> Since there will always be collisions, you need some collision management approach.  The above draft provides one such approach.
>>>>
>>>> Just sharing a bit of my study into consequences on choosing an Identifier length.
>>>>
>>>> I may get through the various responses on this original post still this week...
>>>>
>>>> Oh, and I have an Excel sheet that makes using the formula easy; just ask for it.
>>>>
>>>> Bob
>>>>
>>>> On 01/31/2018 11:27 AM, Behcet Sarikaya wrote:
>>>>> Hi Tom, all,
>>>>>
>>>>> I changed this tread to identifier size issue.
>>>>>
>>>>> 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?
>>>>>
>>>>> 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?
>>>>>
>>>>> Regards,
>>>>> Behcet
>>>>> On Mon, Jan 29, 2018 at 4:16 PM, Tom Herbert <[e-mail]> wrote:
>>>>> On Mon, Jan 29, 2018 at 12:39 PM, Behcet Sarikaya
>>>>> <[e-mail]> wrote:
>>>>>> Hi all,
>>>>>> Dirk and I submitted this PS draft.
>>>>>> We need this to be discussed and improved. Please read and comment.
>>>>> Hi Behcet,
>>>>>
>>>>> Thanks for posting the draft. A few comments...
>>>>>
>>>>> "However it can be argued that it is difficult to derive globally
>>>>> unique identifiers only using 64 bits.  So it is better to use longer
>>>>> identifiers, e.g. 80 bits or longer"
>>>>>
>>>>> Can you elaborate on this?
>>>>>
>>>>> I think the Privacy issues should be it's own section.
>>>>> Identifier/locator has both pitfalls and give opportunities to improve
>>>>> privacy.
>>>>>
>>>>> "The use of identifiers unique for each user brings privacy issues. If
>>>>> the identifier is stolen then your traffic can be unlawfully tracked,
>>>>> there could be serious implications of it."
>>>>>
>>>>> This is true today when devices have address or assigned a single /64.
>>>>> One alternative is gives users thousands or millions of addresses
>>>>> (identifier). Identifier/locator split should facilitate that. Note
>>>>> that this effect is already provided by NAT since every connection
>>>>> through a NAT is translated to non-trackable address/port. NAT has
>>>>> some law enforcement agencies freaking out because of its strong
>>>>> (inadvertent) privacy!
>>>>>
>>>>> "Privacy of identifiers is especially an issue for a UE communication
>>>>> with a server like Google, Facebook, LinkedIn, etc."
>>>>>
>>>>> You might want to mention that simple identifier rotation [RFC4914] is
>>>>> not enough these days..
>>>>>
>>>>> "Privacy issue can be mitigated only if Id-Loc system has proxy mode
>>>>> of operation.  In proxy mode, user traffic is intercepted by a proxy.
>>>>> Proxy node which could be placed at the subnet router or site border
>>>>> router.  The router tunnels the traffic to the server.  In the process
>>>>> UE identifier becomes hidden and this hopefully removes privacy
>>>>> issues."
>>>>>
>>>>> I'm not sure what this means. Multiple identifiers per deivce should
>>>>> address the privacy issue, Maybe a proxy would have the same effect?
>>>>>
>>>>> "5G specific identifiers can also used to deal with privacy issues.
>>>>> IMSI is known to be 64 bit and unique for each UE.  IMSI should not be
>>>>> exposed to any entities.  It is like 64-identifier.  Instead
>>>>> identifiers like 5G-GUTI can be used"
>>>>>
>>>>> I think this is two levels. An identifier in IP identifies a node for
>>>>> the purpose of being the endpoint of the communication. Something like
>>>>> IMSI identifies a specific device (and hence user). In the best case
>>>>> scenario, IP identifiers don't reveal the identity of users and they
>>>>> can be made externally visible. IMSI is by its nature sensitive
>>>>> information and only visible in a trusted domain. A mapping system
>>>>> will need to map identifiers to identities (like an IMSI) so the
>>>>> system needs to be secured.
>>>>>
>>>>> A big item missing in this section is locator security. Fine grained
>>>>> locators used in cellular system could be used to infer the
>>>>> geo-location of devices and hence users, thus enabling stalkers
>>>>> everywhere.  So locators need restricted visibility somehow..
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>> Also we are soliciting co-authors, please let us know.
>>>>>>
>>>>>> Regards,
>>>>>> Dirk & Behcet
>>>>>>
>>>>>>
>>>>>> A new version of I-D, draft-hspab-5gangip-atticps-00.txt
>>>>>> has been successfully submitted by Behcet Sarikaya and posted to the
>>>>>> IETF repository.
>>>>>>
>>>>>> Name:           draft-hspab-5gangip-atticps
>>>>>> Revision:       00
>>>>>> Title:          IP Issues and Associated Gaps in Fifth Generation Wireless
>>>>>> Networks
>>>>>> Document date:  2018-01-28
>>>>>> Group:          Individual Submission
>>>>>> Pages:          7
>>>>>> URL:
>>>>>> https://www.ietf.org/internet-drafts/draft-hspab-5gangip-atticps-00.txt
>>>>>> Status:
>>>>>> https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/
>>>>>> Htmlized:       https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00
>>>>>> Htmlized:
>>>>>> https://datatracker.ietf.org/doc/html/draft-hspab-5gangip-atticps-00
>>>>>>
>>>>>>
>>>>>> Abstract:
>>>>>>     This document attempts to make the case for new work that need to be
>>>>>>     developed to be used among various virtualized functions and the end
>>>>>>     user which may be moving.  First a set of use cases on tunneling,
>>>>>>     charging, mobility anchors are developed and then the steps of
>>>>>>     proposed new work is described next.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of submission
>>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>>
>>>>>> The IETF Secretariat
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 5gangip mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 5gangip mailing list
>>>>>
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>> _______________________________________________
>>>> 5gangip mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/5gangip