Subject: Re: [5gangip] Identifier size

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Feb 2018 09:27:38 +0100 (CET)

On Wed, 31 Jan 2018, Behcet Sarikaya wrote:

> So my question is the identifier in identifier - locator separation equal
> to the interface id in RFC 8200?

It's hard to follow the discussions here. Can't we just just agree that 
whatever solution we come up with, the device that connects needs to get a 
full usable /64 worth of addresses and then we work from there with the 
proposals?

I'd set this as a hard requirement, we can't go back into handing fewer 
adresses to the device than we have done the past 10 years in 3GPP style 
networks.

So any proposal that doesn't fulfil this requirement doesn't need to even 
be presented. I think that'd be a good clarification for everyone.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Thu, 1 Feb 2018 08:42:55 +0000

Dear Dino,
one reason for addressing the UE in an end-to-end manner is also to enable multiple links via different access technologies to provide the connectivity.
Such heterogeneous multi-path approach is important for 5G IMO.
Best Regards
Dirk 
-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Mittwoch, 31. Januar 2018 23:21
To: [email-masked]
Cc: Tom Herbert <[email-masked]>; [email-masked]; David Allan I <[email-masked]>; 5GANGIP <[email-masked]>
Subject: Re: [5gangip] [Ila] Identifier size

> On Wed, Jan 31, 2018 at 4:12 PM, Dino Farinacci <[email-masked]> wrote:
> > My bad,  statement below should be end-system and correspondents would need to be directly attached to TRs  in order to use all 128 bits of an IPv6 address field as a crypto assigned EID.
> 
> Right, my reference was when LISP ran on the UE.
> 
> We are interested in LISP running on UE.

Why? The question isn’t why the interest in LISP but why the overlay in the UE?

Dino

> 
> Behcet
> When it ran in the network, the RLOCs would be the xTRs in the network. And the EIDs on the UE could still be loopback or one of the SLAAC addresses. It doesn’t matter which ones, even if provider-assigned, because those addresses, used as EIDs wouldn’t have to be advertised into the non-PA assigned attachment carriers.
> 
> Dino
> 
> >
> > Cheers
> > D
> >
> > -----Original Message-----
> > From: 5gangip [mailto:[email-masked]] On Behalf Of David 
> > Allan I
> > Sent: Wednesday, January 31, 2018 1:18 PM
> > To: Dino Farinacci <[email-masked]>; Tom Herbert 
> > <[email-masked]>
> > Cc: 5GANGIP <[email-masked]>; Behcet Sarikaya <[email-masked]>; 
> > [email-masked]
> > Subject: Re: [5gangip] [Ila] Identifier size
> >
> > For my edification, that would only be true if the end system was directly attached to the TR.  Addressing would need to conform to established norms if that was not the case. Correct?
> >
> > Rgds
> > Dave
> >
> > -----Original Message-----
> > From: 5gangip [mailto:[email-masked]] On Behalf Of Dino 
> > Farinacci
> > Sent: Wednesday, January 31, 2018 10:11 AM
> > To: Tom Herbert <[email-masked]>
> > Cc: 5GANGIP <[email-masked]>; Behcet Sarikaya <[email-masked]>; 
> > [email-masked]
> > Subject: Re: [5gangip] [Ila] Identifier size
> >
> > For LISP, you can assign an EID to the loopback interface, all 128-bits. And then the interface addresses that are either statically conifgured or learned by SLAAC are 128-bit RLOCs.
> >
> > You can assign multiple EIDs to the loopback interface, be them crypto-EIDs or not, or a combination of either.
> >
> > If ILA (or ILNP) useds 64-bit identifiers, those can be regsitered to the LISP mapping system and return 128-bit RLOCs. Or for that matter, return any size you want. To be used by how any data-plane wants to use the addresses.
> >
> > Dino
> >
> >> On Jan 31, 2018, at 9:12 AM, Tom Herbert <[email-masked]> wrote:
> >>
> >>
> >>
> >> On Wed, Jan 31, 2018 at 8:27 AM, Behcet Sarikaya <[email-masked]> wrote:
> >> Hi Tom, all,
> >>
> >> I changed this tread to identifier size issue.
> >>
> >> What is the motivation for crypto-graphic identifiers?  Is the idea to give each device a master identifier and then it can use the a crypto graphic function to independently create its own unique identifiers for use in communications. That would be good for address per connection and 80 bits might be doable in ILA.
> >>
> >> 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?
> >>
> >> No, it's not. This is where one of the problems with identifier locator address split arises. SLAAC performs /64 address assignments. This is assigning a  subnet to a device with the expectation that IIDs in the subnet (lower 64 bits) are assigned by the device receiving the assignment,  Many mobile providers use SLAAC to assign /64 to UEs. This is in contrast to using DHCPv6 to get singleton addresses. The IID space is used by the UE for assigning addresses to downstream devices (like in tethering) as well randomizing address for local binding as a means to mitigate address scanning attacks (address scanning was used in WannaCry attack). In this sort of address assignment it's the upper sixty-four bits that identify the mobile device, the identifier for identifier/locator split would be derived from the upper sixty-four bits.
> >>
> >> Sixty-four bits isn't enough to encode both a locator and identifier, but I think a level of indirection will work. This is my description of that:
> >>
> >> A device may be assigned a /64 address via SLAAC as is common in many provider networks. In this scenario, the low order sixty-four bits contains IIDs arbitrarily assigned by devices for its purposes; so these bits cannot be used as an identifier in ILA. The alternative to support /64 prefix assignment is to encode an identifier in the upper sixty-four bits. Since only a subset of bits are available, a level of indirection is used so that  when ILA transformed the upper sixty four bits contains both a locator and an index into a locator (ILA-N) specific table. The entry in the table provides the original sixty-four bit prefix so that ILA to SIR transformation can be done.
> >>
> >> 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?
> >>
> >> In ILA, identifiers need to be unique with an ILA domain. Normally, this will mean it is unique with one SIR prefix. That is analogous to an IID being unique within a subnet.
> >>
> >> Tom
> >>
> >> _______________________________________________
> >> ila mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ila
> >
> > _______________________________________________
> > 5gangip mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/5gangip
> >
> > _______________________________________________
> > 5gangip mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/5gangip
> 
> 

_______________________________________________
5gangip mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/5gangip

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Feb 2018 18:53:02 +0900

On Thu, Feb 1, 2018 at 5:27 PM, Mikael Abrahamsson <[email-masked]> wrote:
>
> Can't we just just agree that whatever solution we come up with, the
> device that connects needs to get a full usable /64 worth of addresses and
> then we work from there with the proposals?
>

What he said. Thank you :-)

---

From: Tom Herbert <[email-masked]>
Date: Thu, 1 Feb 2018 08:15:21 -0800

On Thu, Feb 1, 2018 at 12:27 AM, Mikael Abrahamsson <[email-masked]>
wrote:

> Mikael,

Interface identifier and identifier in idloc are not equivalent. The idloc
identifier identifies the node that has location. In the case of a /64
assignment, the upper sixty-four bits identify the device with a location
and hence the idloc identifier needs to be derived from that. The IID
portion is irrelevant to identifier/locator it belongs to the same node and
move along with the device. So the mapping in idloc is from upper sixty
four bits to locator.

The privacy concern with a /64 assignment is that it becomes a persistent
identifier in addresses of a device and hence likely a user. If two flows
are captured by some third party and have the same high order sixty-four
bits then they are likely to be sourced from the same device and hence same
user. This leads to the addressing privacy exploits such as the one I
described earlier.

> I would take that as a requirement. However, I don't believe /64
assignment is sufficient to ensure privacy.

Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Feb 2018 17:28:31 +0100 (CET)

> assignment is sufficient to ensure privacy.

So what is your proposal to solve the problems you describe?

My hard requirement is that the node has 2^64 addresses available for its 
use because I don't like regressions.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 1 Feb 2018 08:50:40 -0800

On Thu, Feb 1, 2018 at 8:28 AM, Mikael Abrahamsson <[email-masked]> wrote:

> Use SLAAC to get a /64 to use with application where privacy is not a
concern. Provide DHCPv6 to get single untrackable addresses for
privacy-sensitive or anonymous communications, Identifier locator split
needs to support both models.

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Thu, 1 Feb 2018 17:42:23 +0000

Tom;

On 01 Feb 2018, at 16:50, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Feb 1, 2018 at 8:28 AM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, 1 Feb 2018, Tom Herbert wrote:

My hard requirement is that the node has 2^64 addresses available for its use because I don't like regressions.

Use SLAAC to get a /64 to use with application where privacy is not a concern. Provide DHCPv6 to get single untrackable addresses for privacy-sensitive or anonymous communications, Identifier locator split needs to support both models.

RFC8064 (PS) / RFC7217 (PS) has your second sentence covered, without needing a DHCPv6 server. (Avoids the DHCPv6 server becoming the tracking device.)

As far as I can tell, the options for generating the Identifier value are for an ID/LOC system which conforms to RFC8200 (S) for a /64 Locator are:

- SLAAC: where identity privacy or verifiable identity is not a concern.
- RFC3972 (PS): where a cryptographically-verifiable identity is required.
- RFC8064 (PS): where identity privacy is required.

Possibly, there are other options.

Cheers,
--/Saleem

Tom

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Feb 2018 11:05:42 -0800

> Such heterogeneous multi-path approach is important for 5G IMO.

Right, I knew an answer, I wanted to see what your’s was. Thanks.

Dino

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 1 Feb 2018 17:18:29 -0500

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:
> 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).
>
> Regards,
> On Mon, Jan 29, 2018 at 4:16 PM, Tom Herbert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Jan 29, 2018 at 12:39 PM, Behcet Sarikaya
>     <[email-masked] <mailto:[email-masked]>> 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
>     >
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/5gangip>
>     >
>
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Feb 2018 15:01:40 -0800

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 <[email-masked]> 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:
> 
> 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 Mon, Jan 29, 2018 at 4:16 PM, Tom Herbert <[email-masked]> wrote:
>> <[email-masked]> wrote:
>> > Hi all,
>> > Title:          IP Issues and Associated Gaps in Fifth Generation Wireless
>> > Networks
>> > Htmlized:       https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00
>> > Htmlized:
>> >    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
>> > 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
>> >
>> >
>> >

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 1 Feb 2018 23:22:17 -0500

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:
>> On Feb 1, 2018, at 2:18 PM, Robert Moskowitz <[email-masked] 
>> <mailto:[email-masked]>> 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:
>>
>> Since there will always be collisions, you need some 
>> collision management approach.  The above draft provides one such 
>> approach.
>>
>>> consistent

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Feb 2018 20:37:48 -0800

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 <[email-masked]> 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
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 1 Feb 2018 23:52:35 -0500

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

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 1 Feb 2018 23:59:45 -0500

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Feb 2018 16:36:58 +0100

>> <mailto:[email-masked]>> wrote:
[...]

>> concern. Provide DHCPv6 to get single untrackable addresses

If we want the addresses or prefixes to be untrackable then SLAAC may be 
a recommendation, instead of DHCPv6, but.

Much of the trackability in 4G networks comes from the fact that the 
link to UE is a point-to-point link.  There is a single prefix for this 
ptp link, be it with SLAAC or DHCP.

So my question is whether someone works on making the 5G links to the UE 
be more like shared links like in WiFi.  Many UEs already make the link 
to the network look more like a WiFi link than a ptp link: it has a MAC 
address, etc.  But the PGW still considers it as a ptp link.

Alex

  for
>> privacy-sensitive or anonymous communications, Identifier locator 
>> split needs to support both models.
> 
> RFC8064 (PS) / RFC7217 (PS) has your second sentence covered, without 
> needing a DHCPv6 server. (Avoids the DHCPv6 server becoming the tracking 
> device.)
> 
> As far as I can tell, the options for generating the Identifier value 
> are for an ID/LOC system which conforms to RFC8200 (S) for a /64 Locator 
> are:
>