Re: [5gangip] Identifier size

[Dino Farinacci <[e-mail]>]

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]> 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