Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

From: Toerless Eckert <[email-masked]>
Date: Tue, 1 Mar 2022 17:41:59 +0100

Eliot, *:

Thanks for the historic reference to IEN19!

IEN19 defines that "an address indicates *where* it is". But in the
Internet, my rfc4291 subnet prefix is injected into Internet BGP,
so that (part of the IPv6) address does not tell me nada, zilch,zip
about *it*'s location. Only the routing system knows the location.

Maybe IEN19 was written with E.164 routing as its core reference, where
i guess (at least back then), the actual location of *it* was
indeed fixed by the physical point of attachment, and the dynamic
routing system only allowed to plot more than one path to *it*.

And of course, the other part of the rfc4291 address is already
called (interface) interface, so it too isn't indicating, where
*it* is. I am obviously using elecrtromagnetic broadcast via
a WiFi AP or a yellow ethernet to locate *it*, not the address.

Did we (e.g.: through locator/identifier split effort or other)
ever came up with some cross-technology consistent terminology for the
nature of an address, such as whether or how we decide if/what is
a locator and/or identifier (or any other name-calling for addresses) ?

For example: The use of locator/identifier in RFC6830 (LISP) i think is,
to use the White Knight's terminology, only what an address is
called by an xTR (or the LISP instance) but nothing more: It does not
defining what the nature of the locator or identifier addresses are.

So maybe there is no such thing as "are" unless we start having self-aware
addresses. Maybe we should only think about what (the parts of)
addresses "is called" by specific entities using them such as the network
routing subsystems address registries or APIs into the forwarding layer.

Cheers
    Toerless

On Tue, Jan 25, 2022 at 08:46:13AM +0100, Eliot Lear wrote:
> The orthodoxy here is the seminal work of Shoch[1]. And of course there's
> Saltzer et al.[2]  The assumptions being made today by different players are
> indeed all over the map.  Routing is a function of the network.  Or is it? 
> Privacy is something the endpoint must manage.  Or is it?  So I like your
> approach for discussion.
> 
> Eliot
> 
> [1] http://www.postel.org/ien/txt/ien19.txt
> [2] http://web.mit.edu/Saltzer/www/publications/endtoend/endtoendA4.pdf

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 1 Mar 2022 20:22:09 +0100

NAT IMHO has been vilified for a lot of bad instances of NAT from the past.
Now unfortunately, the term is identified with evil only, so maybe we should
find a better term for what IMHO are really useful/beneficial instances.
Maybe "address rewrite".

Non-evil address rewrite IMHO is per-flow-stateless as for example used in IP
with the various SIIT variants.

There are various interesting benficial scenarios for stateless address rewrite, such as 
(but not limited to):

a) the ability to eliminate the need for a single global address plan which eliminates
a lot of administrative work for many type of private networks
b) the ability to build light-weight embedded equipment with hard-burned "generic" addresses -
c) Host stack address stability
d) Traffic steering

a), b), d) are example use-cases for which i've also looked into my FA-IINAS draft
and its address rewrite functions.

https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/

Cheers
   Toerlss

On Fri, Jan 28, 2022 at 12:48:59PM +0100, Alexandre Petrescu wrote:
> Sorry, I  take advantage of this valuable public conversation between
> you to mention a point that might be related.
> 
> Le 25/01/2022 à 20:30, Geoff Huston a écrit :
> > [...] various judgemental observations (Like "NAT is evil”, “NBATs break
> > stuff”, etc,) feel free, but they are your constructions, not mine. The
> > issue for me is not judgments of “good” or “bad”, but simply to explore,
> > without overtones of judgement, exactly what an IP
> > address represents in today’s Internet. [...]
> 
> Without jugding, and without thinking others might judge, i.e. to
> qualify as 'good' or 'bad'.
> 
> I do think there might be value in questioning whether there might be
> something inherent in the IP addressing system which might lead to less
> positive consequences.  It is a question on the cause-to-effect dynamics.
> 
> What in the IP addressing system makes it possible that NAT has been
> designed and used largely?  Lack of space in v4 - ok - but is there
> anything more to that problem, now that IPv6 solves the space size
> problem?  Is the fact that NAT kind of probably protection is helping?
> 
> For example, if the IP addressing system had variable length addresses
> (instead of fixed length) - would that make the translation process of
> NAT be unacceptably long, and hence no NAT would be feasible?
> 
> Other than that, what other characteristic of the IP addressing system
> might have an impact on the existence of NATs?
> 
> What other characteristic of the IP addressing system has no impact at
> all on the existence of NATs?  I.e. one could change that characteristic
> but NATs would still be designed.
> 
> Other than NAT and IP addresses, there are other aspects of the current
> Internet addressing that are less desirable.
> 
> For example: the open Internet and its open addressing system leads to a
> need of privacy respecting for the individual; which is good.  At the
> same time, the new privacy rules are not making everyone happy.  Some
> times it goes to large extents.  For example, some addresses of web
> sites are not visible to others _because_ of that privacy ruling.  Not
> all websites in all countries accept to abide to the privacy rules of
> other countries.  Such websites refuse to abide and block access altogether.
> 
> That situation is clearly against the openness of access in the Internet.
> 
> It is not a matter of paying money or not to access data.  Even if one
> pays one is still not given access because one is situated in a country
> of a particular privacy ruling.
> 
> It is a strange situation in which the ruling of privacy is not
> accepted.  Those sites who do not accept to deliver data according to
> the privacy rules do so not because they dont agree with a general
> principle of privacy, but because they dont agree with that particular
> ruling (GDPR in this case) of privacy.
> 
> What is at fault for that situation?
> 
> Is there something in the Internet addressing system at higher layer
> (above IP) that might be qualified as being a little bit in error for
> that lack of access?
> 
> For example, if the 'cookies' used by HTTP involved host names (host
> names are also a sort of addresses) whose structure was agreed locally,
> then there would be more positive view of the generally negative view of
> 'tracking'.  For example, a locally agreed way to identify people is
> generally accepted (license plates, faces, more) but a universal way of
> identification (hostname containing 'Windows' characteristics) might be
> less accepted.
> 
> Alex
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

-- 
---
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 1 Mar 2022 11:54:35 -0800

> defining what the nature of the locator or identifier addresses are.

An identifier (i.e. EID) typically is static (can be dynamcially assigned) and is used by the transport layer and not routable by the underlay. A locator (i.e. RLOC) is an address, according to the definition that everyone understands today, is used in the outer header encapsulation and is routable by the underlay.

It is that simple, even though I made the description lengthy to be a bit more complete on their usage.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Mar 2022 07:33:28 +0100

> It is that simple, even though I made the description lengthy to be a bit more complete on their usage.

Thanks. Not contradicting what i claimed... I think.

My point was specifically that the LISP locator helps LISP to "locate" another
xTR, but that is different from whether or not the locator by the nature
of its address structure helps the underlay to locate the entity (xTR) that the
address is assigned to (xTR). So the name 'locator' is 'just' a good
name for what LISP calls/uses the address for, not for how the under
itself would maybe call the address or use the address for. 

Cheers
    Toerless

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 3 Mar 2022 09:28:23 -0800

> Thanks. Not contradicting what i claimed... I think.

You think right.

> xTR, but that is different from whether or not the locator by the nature

Yes, where the EID is close to or the EID/RLOC are co-located in the same system.

> itself would maybe call the address or use the address for. 

Well the locator you put in an outer header destination address is called/used/assign to whatever the rules of the underlay are. If the underlay is ethernet, then its a 6-byte address where the high-order 3 bytes is an organizational ID, just to cite an example.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 4 Mar 2022 12:39:52 +0100

> Well the locator you put in an outer header destination address is called/used/assign to whatever the rules of the underlay are. If the underlay is ethernet, then its a 6-byte address where the hig…

Indeed.

I have not seen an answer to the question i posed earlier in the thread:
 whether and if so what general (not technology specific) definition of locator
and identifier the IETF may have. But i have seen a lot of confusion about
it and people shying away from using these terms.

If (as i think) we do not have a commonly applicable definition of locator/identifier 
(beyond its use in indivdual technologies like LISP), then i think this is because
folks who tried to apply these terms (incorrectly) may have failed to
see the difference between what an address is and what someone (like an
application) calls it (/uses it for). In that respect the reference to
the White Knight in IEN19 is very helpful to remember.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 4 Mar 2022 14:39:17 -0500

I do not believe the community has an agreed definition of identifier or 
locator.  We do have some relatively common usage for locator.  As far 
as I know there is no fully acurate and written down definition even for 
that.

Note also that while Dino likes LISP for lots of things (for good 
reason), the LISP working group has been working to move the LISP RFCs 
to Proposed Standard with descriptions of usage that are for particular 
use case (not limited domains, but specific uses).  While originally 
developed to address Internet-Wide scaling problems, that is NOT what 
the PS documents cover.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Mar 2022 08:57:36 +1300

Toerless,

I believe the closest we ever got to agreed definitions was in the
IRTF RFC 6115:

    6.   A "locator" is a structured topology-dependent name that is not
         used for node identification and is not a path.  Two related
         meanings are current, depending on the class of things being
         named:

         1.  The topology-dependent name of a node's interface.

         2.  The topology-dependent name of a single subnetwork OR
             topology-dependent name of a group of related subnetworks
             that share a single aggregate.  An IP routing prefix is a
             current example of the latter.

    7.   An "identifier" is a topology-independent name for a logical
         node.  Depending upon instantiation, a "logical node" might be a
         single physical device, a cluster of devices acting as a single
         node, or a single virtual partition of a single physical device.
         An OSI End System Identifier (ESID) is an example of an
         identifier.  A Fully Qualified Domain Name (FQDN) that precisely
         names one logical node is another example.  (Note well that not
         all FQDNs meet this definition.)

Regards
    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 6 Mar 2022 22:05:16 +0100

On Fri, Mar 04, 2022 at 02:39:17PM -0500, Joel M. Halpern wrote:
> locator.  We do have some relatively common usage for locator.  As far as I
> know there is no fully acurate and written down definition even for that.

Thanks for reconfirming. I just became a fan of the white knight approach,
because it removes the need for any absolute truth.

> Note also that while Dino likes LISP for lots of things (for good reason),
> the LISP working group has been working to move the LISP RFCs to Proposed
> Standard with descriptions of usage that are for particular use case (not
> limited domains, but specific uses).  While originally developed to address
> Internet-Wide scaling problems, that is NOT what the PS documents cover.

Yes. I think we will have to wait for even Tony's proposed prefix improvement work
to not suffice, but instead for the Internet Core/ABSR routers to finally
not scale anymore before enough operators would come back asking for 
architectural improvements. But i think even before that happens, one could offer
maybe some partial deployments of LISP as a service to tier-2++ smaller
ISPs who want to multihome to more than one Internet uplink provider but
still not carry the whole BGP routing table. But i have no good idea of
where the operational pressure points are these days that could lead to such
incremental evolution from the edge.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Jens Finkhaeuser <[email-masked]>
Date: Mon, 07 Mar 2022 09:12:18 +0000

Hi,

I'm new on the list - I'll just jump in, I suppose. I'm working on a couple of R&D projects on drone communications, where most participants tend to invent a different wheel from people here. Part of my being here is trying to bridge that gap a bit.

I largely like the RFC 6115 definition, as it is also compatible with the URI/URL definitions more people might be used to. That should help with adoption.

I've been reading up on LISP-MN and/or LISP+ALT (that's on a different list, I know), and am currently unsure that these proposals fully meet the needs of drones. I'll have to understand the proposals better.

The addressing related point here is IMHO the RFC 6115 definition for identifiers may be more suitable for drone uses than the LISP-MN proposal treats EIDs: drones must carry static identifiers for authentication of control handover, while the EID assignment in the proposal reads to me as slightly more dynamic (though not as dynamic as RLOC assignment).

Hope that helps,
Jens

---

From: Antoine FRESSANCOURT <[email-masked]>
Date: Mon, 7 Mar 2022 11:14:53 +0000

Hello,

Reading the ISP-MN draft, it seems to me that EIDs are identifiers, not locators, even if they take the form of IPvX addresses (By the way, this is a perfect example of the Locator - identifier ambiguity of IP, highlighted in Mobile IP discussions). The text of the draft mentions that they change infrequently and besides they are irrelevant from a topological perspective with regards to where the drone is roaming. The RLOC is an address, and I think it has relevance from a topological perspective if it can be used to point to the antenna / access point to which the drone is attached.

If I make a comparison with what is happening in 3GPP mobile networks, the ID of the device (drone, sensor, mobile phone, laptop, you name it) is carried by the SIM and appears as an IMSI to the outside (bearing in mind that in theory, the IMSI is a public ID, and a device can have several public IDs attached to the private one carried in the SIM's secure element). This IMSI is used in attachment procedure to get a data channel and an IPvX address that is relevant to the visited network in which the device is roaming / attached. Within this scoep of relevance, the device is supposed to be reachable by means of ARP-like discovery mechanisms (well, it uses a specific network function coupled with a database to perform the discovery, but the goal is the same).

Best regards,

Antoine

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Jens Finkhaeuser
Sent: Monday, March 7, 2022 10:12 AM
To: Brian E Carpenter <[email-masked]>
Cc: Toerless Eckert <[email-masked]>; [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

Hi,

Hope that helps,
Jens

---

From: Jens Finkhaeuser <[email-masked]>
Date: Mon, 07 Mar 2022 12:18:04 +0000

Hi,

> Reading the ISP-MN draft, it seems to me that EIDs are identifiers, not locators, even if they take the form of IPvX addresses (By the way, this is a perfect example of the Locator - identifier ambiguity of IP, highlighted in Mobile IP discussions).

That is also my reading.

> The text of the draft mentions that they change infrequently and besides they are irrelevant from a topological perspective with regards to where the drone is roaming.

Different sections of the draft claim different things; some claim EIDs never change, others talk about multiple EIDs used in different scenarios. I find section 5.1 interesting: "It is anticipated that these EIDs will change infrequently if at all, since the assignment of a LISP-MN's EID is envisioned to be a subscription time event."

Subscription is an undefined term that also appears in LISP+ALT. In the context of drones (not to bombard you with terminology from that area), one could imagine that subscription occurs when loading a mission plan onto a drone prior to departure. But by definition, this then only entails anticipated scenarios, not emergency response situations.

A completely static drone identifier is one thing; EIDs changing rarely is another. Drones may require communications with isolated, private networks, which are outside the scope of LISP+ALT - how subscription should be interpreted here is an interesting topic!

> The RLOC is an address, and I think it has relevance from a topological perspective if it can be used to point to the antenna / access point to which the drone is attached.

Also my understanding.

> If I make a comparison with what is happening in 3GPP mobile networks, the ID of the device (drone, sensor, mobile phone, laptop, you name it) is carried by the SIM and appears as an IMSI to the ou…

I fear that view is somewhat incomplete, though not from a 3GPP perspective.

EASA (at least) regulation require multiple distinct radio technologies for fail over of command & control (C2) links. One way of viewing this is to treat the C2 link as an abstract interface that is dynamically mapped to one of several radios; this multi-link (somewhat distinct from multi-homed, but very similar) approach is currently gaining in popularity, it seems. That in turn implies that a SIM-based identifier at best identifies the link used, not the vehicle itself.

While it is technologically feasible to use the SIM ID in other links and vice versa a WiFi MAC address in 3GPP networks, neither would be their intended purpose.

It is also possible to punt drone identification entirely to a layer above (which is the approach we're currently taking), but that just means we're also implicitly accepting a drone identifier<->link identifier (/ EID) mapping as an additional level of indirection.

In other words, none of this currently covers the kind of identification needs this space has. (There is an aside here I'll spare you on how these identifiers most likely need to be (hashes of) public keys.)

For what it's worth, I am well aware that it's entirely fair to treat these kinds of identifiers as an application layer concern. On the other hand, the applications are almost exclusively concerned with addressing at this level of abstraction. At that moment one has to ask what purpose an EID serves here, unless it is as static as and therefore equivalent to the drone identifier?

I'm not sure if this is the right list to discuss this, though; this is, after all, affecting mostly LISP-MN/LISP+ALT. The general RFC 6115 distinction between identifiers and locators still makes sense, it's more how LISP-MN may or may not interpret identifiers that raises some questions for me. But I suppose that's relevant enough?

Hope that helps,

Jens

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 7 Mar 2022 13:39:39 +0100

Thanks, Brian. Looks like a good reference. Alas a longer read ;-)

Definitions seem to be agreeable. Except that "node" is overloaded across
different RFCs.  We used it instead of router/switch in ANIMA. I guess
i would now use  "logical entity" for what rfc6115 calls logical node.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 7 Mar 2022 13:42:28 +0100

Do IMSI have any structure ?

An E.164 address for example is often a hybrid, where there are country and
even network prefixes, which like routing prefixes can be seen as locators,
whereas the suffix is an identifier...

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Antoine FRESSANCOURT <[email-masked]>
Date: Mon, 7 Mar 2022 13:00:39 +0000

Hello,

See comments inline

From: Jens Finkhaeuser [mailto:[email-masked]]
Sent: Monday, March 7, 2022 1:18 PM
To: Antoine FRESSANCOURT <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Toerless Eckert <[email-masked]>; [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>
Subject: RE: [Int-area] Continuing the addressing discussion: what is an address anyway?

Hi,

On Monday, March 7th, 2022 at 12:14, Antoine FRESSANCOURT [email-masked]<mailto:[email-masked]> wrote:

Hello,

That is also my reading.

Also my understanding.

[AFT] 3GPP provides a method to address this. Indeed, it allows bridging with other link layer technologies, termed “Non-3GPP access networks”. Wi-Fi for instance is seen as such a non-3GPP access technology, on which the 3GPP Authentication, authorization and accounting (AAA) infrastructure can be used.

[AFT] If you consider the identifier for the sole purpose of identification, I don’t see any problem with using this ID to do AAA on any type of access layer technology. For instance, with Wi-Fi, the identity credentials present in the SIM can be used in a RADIUS or DIAMETER authentication and network attachment procedure (This is actually done in several network offloading use cases).

[AFT] In my view, identifiers should not have a layer relevance, otherwise you can consider them as flat addresses. Yet, identifiers have a relevance with regards to the identity provider (the network operator in the SIM card’s case) and how open or willing he is to open APIs used in AAA operations for whichever layer or access technology used.

[AFT] If you are interested in identifiers being hashes of public keys, you might be interested in self-certifying identifiers, used for instance in storage systems.

[AFT] when you look at a “3GPP” architecture diagram, usually the AAA elements are either present at each layer in the architecture or represented as a vertical elements used at each architectural layer (and the lower the layer, the fastest the AAA elements have to operate)

Hope that helps,
Jens

---

From: Antoine FRESSANCOURT <[email-masked]>
Date: Mon, 7 Mar 2022 13:06:29 +0000

Hello,

See inline

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Monday, March 7, 2022 1:42 PM
To: Antoine FRESSANCOURT <[email-masked]>
Cc: Jens Finkhaeuser <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

[AFT] An IMSI is 3 digits Mobile Country Code (MCC) then 3 digits Mobile Network code (MNC) then 10 to 12 digits identifier.

An E.164 address for example is often a hybrid, where there are country and even network prefixes, which like routing prefixes can be seen as locators, whereas the suffix is an identifier...

[AFT] I would argue that this structure is more of a norm to allow the distributed allocation of a unique identifier than something that has a sort of topological relevance. For instance, if you have several national network to network interfaces between operators, the bridge between one mobile network to another can happen at any bridge, thus the MNC part of the IMSI is a bit more of a service address or the identifier of an identity service provider.

Cheers
    Toerless

On Mon, Mar 07, 2022 at 11:14:53AM +0000, Antoine FRESSANCOURT wrote:
> Cc: Toerless Eckert <[email-masked]>; [email-masked]; Dirk Trossen 
> <dirk.trossen=[email-masked]>

--
---
[email-masked]

---

From: Jens Finkhaeuser <[email-masked]>
Date: Mon, 07 Mar 2022 13:15:53 +0000

Hi,

------- Original Message -------

> [AFT] 3GPP provides a method to address this. Indeed, it allows bridging with other link layer technologies, termed “Non-3GPP access networks”. Wi-Fi for instance is seen as such a non-3GPP access…

That seems unlikely when the WiFi network is private.

The main use case for drone is any kind of situation where sending a person is less desirable; very often, these coincide with limited access to the public Internet. AAA concerns here must necessarily cover cases where centralized identity systems are inaccessible. My understanding is that "Non-3GPP access networks" do require this identity system.

It's also worth understanding that while the ground station authenticating the drone is of some interest, it is far more important for the drone to authenticate the ground station - verifying command & control instructions is safety critical, authenticating the drone is more of a DoS protection by comparison.

> [AFT] In my view, identifiers should not have a layer relevance, otherwise you can consider them as flat addresses. Yet, identifiers have a relevance with regards to the identity provider (the netw…

"Flat addresses" is exactly the kind of view of an identifier that's of interest here.

Jens

---

From: Alan DeKok <[email-masked]>
Date: Mon, 7 Mar 2022 08:31:04 -0500

> [AFT] 3GPP provides a method to address this. Indeed, it allows bridging with other link layer technologies, termed “Non-3GPP access networks”. Wi-Fi for instance is seen as such a non-3GPP access…

  As Jens also noted, this is unlikely to happen outside of the commercial / telco / ISP space.  People have been trying to do business-to-business roaming for 25 years.  It hasn't taken off.

  Even WiFi roaming integration has taken decades to get going.  There's now OpenRoaming, which is nice.  But I was trying to get something similar done 15+ years ago, and gave up due to lack of interest and/or perceived value.

> [AFT] If you consider the identifier for the sole purpose of identification, I don’t see any problem with using this ID to do AAA on any type of access layer technology. For instance, with Wi-Fi, t…

  Telcos are moving to anonymous identifiers for privacy issues, especially in the WiFi offload case.

  The only people who need to see the actual identifiers are (a) the end user, and (b) the ISP that the user has a contractual relationship with.

  This process is defined in RFC 7542 (NAI).

  Perhaps this is off-topic for here, but I think it would be very nice to permit roaming for non-corporate entities.  If I visit my friends house, why do I need to go through complex steps to configure WiFi?  He (or his systems) know what the configuration is.  He trusts his systems.  I know him.  He trusts me (at least for WiFi access).  Why is there nothing to "close the loop" ?  Implementing that would require some kind of global addressing scheme.

  Alan DeKok.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 7 Mar 2022 14:32:44 +0100

Thanks, Atoine, inline

> [AFT] I would argue that this structure is more of a norm to allow the distributed allocation of a unique identifier than something that has a sort of topological relevance. For instance, if you ha…

So, when i am roaming from another country, would that carrier not try to connect to
my home carrier by the combination of MCC and MNC ?

That feature to me would make MCC+MNC similar to a routing prefix, right ?

Cheers
    toerless

-- 
---
[email-masked]

---

From: Antoine FRESSANCOURT <[email-masked]>
Date: Mon, 7 Mar 2022 13:46:57 +0000

See inline,

Best regards,

Antoine

-----Original Message-----

So, when i am roaming from another country, would that carrier not try to connect to my home carrier by the combination of MCC and MNC ?

[AFT] The main difference in my view is that in mobile roaming ecosystems, you can't really route a packet to a specific network operator by going through a kind of transit provider that would take all the roaming requests for a single country (or at least this is how I remember things). I miss the possibility to aggregate part of the routing prefixes in IPvX to consider this an addressing scheme. From a topological standpoint, it means that you can't really use a transit intermediate that goes somewhat in the direction of the destination to route roaming traffic (at least in my view).

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 7 Mar 2022 15:03:41 -0800

> The addressing related point here is IMHO the RFC 6115 definition for identifiers may be more suitable for drone uses than the LISP-MN proposal treats EIDs: drones must carry static identifiers for…

It can be dynamic but encouraged to be static, and simpler for management that way.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 7 Mar 2022 15:08:45 -0800

> On Mar 7, 2022, at 4:18 AM, Jens Finkhaeuser <[email-masked]> wrote:
> 

"Subscription time" means the mobile-node manufacture assigns an EID like it would a IMEI. Then it never changes.

> A completely static drone identifier is one thing; EIDs changing rarely is another. Drones may require communications with isolated, private networks, which are outside the scope of LISP+ALT - how…

EIDs need to be unique *within* a mapping system. So you can have multiple mapping systems that use, say 240.0.0.0/4 (for IPv4 EIDs), for static assignment, where the low-order 3 bytes is a random number generated and verify from the mapping system the node uses to be unique.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 7 Mar 2022 15:10:14 -0800

> [AFT] If you are interested in identifiers being hashes of public keys, you might be interested in self-certifying identifiers, used for instance in storage systems.

Check on draft-ietf-lisp-ecdsa-auth for how LISP does "CGAs" for EID assignment.

Dino

---

From: Jens Finkhaeuser <[email-masked]>
Date: Tue, 08 Mar 2022 09:45:34 +0000

Dino,

thank you for this and your other answers!

I can see that it's possible to treat EIDs as sufficiently static to treat them as (stand-ins for) unique identifiers.

I can still (quite easily) construct scenarios with drones where the EID-to-RLOC mapping on a LISP map server is not going to suffice for AAA. I'd gladly discuss this further, but it is increasingly out of scope of the current topic on the distinction between identifiers and locators.

I'm conducting some ongoing research on this more general AAA topic, however. I can see that there is space for a LISP extension at some point to cover such scenarios. That is a highly interesting conclusion in its own right. If you don't mind, I shall reach out to you regarding this in some time, because you appear to be the right person for this!

Jens

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 8 Mar 2022 12:21:51 +0100

Hi Jens,

I'm not sure about your requirements. I think that identifiers for AAA
can be unique and static on their "layer" and do not need to coincide
with network addresses. So if you just want to be sure that you are
talking to the right node, some UUID or public key hash should be fine
for AAA purposes.

However, if you actually want to get to a particular NodeID, no matter
where this node is currently attached to in the underlying network, then
the solution is probably related to the network layer and routing:
you need either need ID-based routing or some ID/Locator split solution
like ILNP or LISP etc. It is also a question of how "self-contained" the
solution should be: on the one hand, one can use overlay solutions for
NodeID to Locator resolution and then use the usual underlay(s) to get
to the locators. On the other hand, every overlay adds complexity,
overhead and is a potential source for inconsistencies.
So if your problem is to get control over a particular drone with a
certain NodeID, ID-based addressing is probably quite beneficial.

Regards,
  Roland

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Mar 2022 12:00:01 -0800

> thank you for this and your other answers!

Anytime.

> I can see that it's possible to treat EIDs as sufficiently static to treat them as (stand-ins for) unique identifiers.

Yes, that is correct.

> I can still (quite easily) construct scenarios with drones where the EID-to-RLOC mapping on a LISP map server is not going to suffice for AAA. I'd gladly discuss this further, but it is increasingl…

If you want to go private, I can discuss with you. 

But note that registration to the mapping system can be signed and verified with PKI so when a requesting EID is authenticated (and authorized) to lookup a destination EID, the map-server can decide if a reply should be returned (map-servers can proxy-reply for Map-Requests).

> I'm conducting some ongoing research on this more general AAA topic, however. I can see that there is space for a LISP extension at some point to cover such scenarios. That is a highly interesting conclusion in its own right. If you 

It is my belief that you don't need other AAA solutions if your mapping system supports access-control and identity verification.

> don't mind, I shall reach out to you regarding this in some time, because you appear to be the right person for this!

Sure, anytime. Thanks.

Dino

---

From: Jens Finkhaeuser <[email-masked]>
Date: Wed, 09 Mar 2022 07:52:26 +0000

Hi Roland!

(And greetings to my former hometown, Karlsruhe!)

> with network addresses.

> (snip)

I agree; this is also the approach we currently take.

The set of requirements for drones is complex, and I have not laid it out well - mostly because this conversation thread is about addressing, while most of the issues I perceive are to do with routing. Of course the two are hard to separate. I also have another use case in mind that is unrelated to drones.

I have been pointed in some interesting directions on this list - thank you all! - and I think at this time it's best that I read through this material carefully. I can then come back, lay out my use cases, and provide some comments on which approach does and does not work so well from their point of view.

That seems a lot better than continuing, because conceptually, the split between identifier and locator as proposed makes a lot of sense to me as well; we're effectively pursuing much the same direction.

Jens

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 4 Mar 2022 13:26:20 -0800

> Note also that while Dino likes LISP for lots of things (for good reason), the LISP working group has been working to move the LISP RFCs to Proposed Standard with descriptions of usage that are for particular use case (not limited domains, but specific uses). While originally developed to address Internet-Wide scaling problems, that is NOT what the PS documents cover.

The defintiions we have in the experimental status RFC 6830 are:

The definitions we have in the Proposed Standard RFC 6830bis are:

Cheers,
Dino