Re: [5gangip] Identifier size

[Robert Moskowitz <[e-mail]>]

Further on a 1% probability on other sizes

in a 96 bit ID:    4*10^13
in a 64 bit ID:    6*10^8 (600 million)
in a 48 bit ID:    2.5*10^6 (2.5 million)

These are approximate, but 'in the ball park'.

Bob

On 02/01/2018 11:22 PM, Robert Moskowitz 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
>>
>>
>>
>>> 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
>>
>
>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip