Re: [5gangip] Identifier size

[Robert Moskowitz <[e-mail]>]

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] <mailto:[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
>     <https://www.ietf.org/internet-drafts/draft-hspab-5gangip-atticps-00.txt>
>     > Status:
>     > https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/
>     <https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/>
>     > Htmlized:
>     https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00
>     <https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00>
>     > Htmlized:
>     >
>     https://datatracker.ietf.org/doc/html/draft-hspab-5gangip-atticps-00
>     <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 <http://tools.ietf.org>.
>     >
>     > The IETF Secretariat
>     >
>     >
>     >
>     > _______________________________________________
>     > 5gangip mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/5gangip
>     <https://www.ietf.org/mailman/listinfo/5gangip>
>     >
>
>
>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip