Re: [Ila] [5gangip] Identifier size

On Wed, Jan 31, 2018 at 4:12 PM, Dino Farinacci <farinacci@gmail.com> 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
> >
> > -----Original Message-----
> > From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of David
> Allan I
> > Sent: Wednesday, January 31, 2018 1:18 PM
> > To: Dino Farinacci <farinacci@gmail.com>; Tom Herbert <
> tom@herbertland.com>
> > Cc: 5GANGIP <5gangip@ietf.org>; Behcet Sarikaya <sarikaya@ieee.org>;
> ila@ietf.org
> > 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:5gangip-bounces@ietf.org] On Behalf Of Dino
> Farinacci
> > Sent: Wednesday, January 31, 2018 10:11 AM
> > To: Tom Herbert <tom@herbertland.com>
> > Cc: 5GANGIP <5gangip@ietf.org>; Behcet Sarikaya <sarikaya@ieee.org>;
> ila@ietf.org
> > 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 <tom@herbertland.com> wrote:
> >>
> >>
> >>
> >> On Wed, Jan 31, 2018 at 8:27 AM, Behcet Sarikaya <
> sarikaya2012@gmail.com> 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
> >> ila@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ila
> >
> > _______________________________________________
> > 5gangip mailing list
> > 5gangip@ietf.org
> > https://www.ietf.org/mailman/listinfo/5gangip
> >
> > _______________________________________________
> > 5gangip mailing list
> > 5gangip@ietf.org
> > https://www.ietf.org/mailman/listinfo/5gangip
>
>