Re: [5gangip] Identifier size

[Robert Moskowitz <[e-mail]>]

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
>
>
>
>> On Feb 1, 2018, at 2:18 PM, Robert Moskowitz <[e-mail] 
>> <mailto:[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] 
>>> <mailto:[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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/5gangip
>