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

[Antoine FRESSANCOURT <[e-mail]>]

Hello,

See comments inline

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


Hi,

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

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

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

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.

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

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.

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

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.

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

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

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

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?

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

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