Subject: [5gangip] Identifier size

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 31 Jan 2018 10:27:25 -0600

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

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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 09:12:39 -0800

On Wed, Jan 31, 2018 at 8:27 AM, Behcet Sarikaya <[email-masked]>
wrote:

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

> 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

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 31 Jan 2018 17:30:07 +0000

Just to clarify ... at least for ILNP ...

On 31 Jan 2018, at 16:27, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tom, all,

Saleem pointed out that:

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

It is not *equal* - it uses the same number of bits and occupies the same bits of the IPv6 header, and may have syntactic similarities, but the semantics are different.

Not a problem - the identifier can be used on multiple interfaces, as it is a node identifier not an interface identifier.

This makes it the uniqueness of the IID and the identifier is the same problem?

Not really.

Cheers,
--/Saleem

Regards,
Behcet
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

Hi Behcet,

Tom

> Title:          IP Issues and Associated Gaps in Fifth Generation Wireless
> Networks
> Htmlized:       https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00
> Htmlized:
> 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]>

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 10:11:10 -0800

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

---

From: David Allan I <[email-masked]>
Date: Wed, 31 Jan 2018 21:17:30 +0000

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

Dino

> 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).
> 
>

---

From: David Allan I <[email-masked]>
Date: Wed, 31 Jan 2018 21:25:25 +0000

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. 

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

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

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 14:12:49 -0800

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 31 Jan 2018 16:17:54 -0600

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.

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 14:21:05 -0800

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