Re: Why this is broken [was Re: Extending a /64]

[Tony Whyman <[e-mail]>]

On 16/11/2020 20:20, Brian E Carpenter wrote:
>
>> Aircraft MNPs are non-topological
> Thank you for that clear statement. Internet routing *is* topological.
> Therefore, you cannot use bits in the routing prefix for non-topological
> information. Therefore, you cannot put 39 magic bits into the routing
> prefix; the Internet doesn't work like that. End of story. Back to the
> drawing board.
>
> This is so badly conceived that I suggest an IETF liaison statement to
> ICAO may be needed.

The basic problem of mobility is that a mobile node must keep the same 
IP Address while it moves its location in an internet. In the ATN, we 
complicate this by making our mobile node a mobile platform with one or 
more onboard subnets, and require that an aircraft can make concurrent 
use of multiple air/ground subnetworks. We can assign an MNP to each 
aircraft, but that cannot be a locator in the normal sense in that it 
does not relate to anything around it at any given time.

In the ATN/OSI, we did try to make the equivalent aircraft address 
prefix routeable by using IDRP as the routing protocol and declaring 
each aircraft to be a routing domain. At least this allowed routes to 
the aircraft to be advertised throughout the ground internet. However, 
this led to obvious scaleability problems (there are mitigation 
strategies but this post is not about them). The distributed routing 
also made it difficult to communicate the very different routing 
policies that the ATC Providers required.

This approach did lead to the semantic equivalent of our "39 magic bits" 
being a routeable address prefix, and there was a limited form of 
aggregation possible from the fact that there was a common airline 
prefix to the aircraft MNP.

In the ATN/IPS we first have a legacy problem - for reasons I keep 
explaining - which make it very difficult to define an MNP that does not 
include an airline identifier and the ICAO 24 bit identifier. However, 
that does not stop us wanting to overcome the scaleability issues and 
routing policy issues that we have with the legacy system.

We are considering various mobility management systems but, in the end, 
they all come back to the same ideas.

1. There is a routable care-of address assigned to each aircraft 
interface to an air/ground subnetwork.

2. The mobility routing problem for routing to an MNP relative IP 
Address is to determine the care-of address of the aircraft interface 
that best matches the routing policy requirements.

3. Forward the packet to the care-of address using normal internet routing.

Here, the MNP is being used as a "name" and the mobility routing problem 
is solved by looking up the care-of address associated with the MNP 
(name). Once the packet gets to the aircraft then the destination 
address becomes a routeable address, etc.

It's not as if this approach is that novel. In LISP, for example, a 
destination IP address (an EID) is used to lookup a corresponding RLOC 
IP address and the packet is then encapsulated and forwarded to the 
RLOC. Once there, the EID is routeable.

So, I really don't see why you are so worked up about the 
identifier/locator duality in an MNP. There is nothing that magic about 
the 39 bits. They are just a unique identifier for the aircraft. Perhaps 
it is because they contain redundant information that you find this 
offensive - but that is primarily a legacy problem which we cannot 
easily walk away from.

Constructive contributions are always welcome and if you want to send a 
liaison statement to ICAO then it should be addressed to the secretary 
of the Communications Panel and for the attention of Working Group I. If 
you want access to the working papers then the usual protocol is to go 
through your national CAA.

>
> There's nothing to stop you putting those 39 bits into the Interface
> Identifier of the aircraft's IPv6 addresses. That would need a slightly
> different version of RFC7217, but would still allow 25 entropy bits.
Possible, but what do you gain? You still need a unique MNP for each 
aircraft. Also, we need the full 64-bits to map to the remaining parts 
of the legacy NSAP Address.
>
> However, you should be aware that IP addresses are intrinsically
> forgeable. I'm not sure I would want to fly on an aircraft whose
> identity might be trivially forged. Also, it would be trivial for
> an attacker to observe that a particular address belongs to a
> particular aircraft.
True, which is why we have end-to-end authentication, authenticated 
logins and continuous peer entity authentication  over each air/ground 
subnetwork, and a trust model under which all routing and MNP/care-of 
address bindings are exchanged on the ground. Personally, I am not a fan 
of "security through obscurity" and prefer to use strong encryption instead.
>
> One more comment below...
>
>> and hence could be densely allocated.
>> However, if you want to go the distance and specify the minimum length
>> identifier then:
>>
>> 1. You need to set up a new registration database for aircraft (in order
>> to assign the new identifier) and one that is global rather than state
>> based - which is the present approach.
>>
>> 2. You need to update the specification for the Aircraft Personality
>> Module and organise the fleet wide upgrade necessary to ensure that
>> every affected aircraft gets a new ICAO global Aircraft Identifier.
>>
>> 3. Safety Authorities will now identify a new hazard potentially
>> resulting from a mis-match between the existing ICAO 24-bit identifier
>> (which still has to be used for radar, ADS-B, TCAS, etc.), and the new
>> airframe identifier.
>>
>> 4. We need to develop procedures and systems for mitigating the new
>> hazard, assuming it is deemed serious enough.
>>
>> 5. The protocol gateways that are planned to avoid having to upgrade the
>> existing ATC Systems in the same timeframe would now have to include a
>> lookup table between the "old" NSAP Addresses and the "new" IPv6 Addresses.
>>
>> 6. The Safety Authority would identify a new hazard resulting from a
>> table configuration/maintenance error and procedures/mitigations would
>> be needed to counter the threat.
>>
>> 7. The address mapping would have to extend to the application protocols.
>>
>> In other words - a lot of negatives each with a potentially large cost
>> attached to them.
>>
>> The next step is to accept that it is worth "wasting" a few more bits
>> and using the existing ICAO 24-bit aircraft identifier instead of some
>> new global aircraft identifier. This avoids issues 1 to 4 above.
>>
>> In order to avoid 5, 6  and 7, we need to have a simple algorithm to
>> convert between aircraft ATN/OSI NSAP Addresses and ATN/IPS IPv6
>> Addresses.
> Are you aware that we already "solved" that in 1996 (https://tools.ietf.org/html/rfc1888), and scrapped it in 2005?
>
> Regards
>     Brian
>
>
>
>> The existing (legacy) NSAP Address format for aircraft
>> addresses starts off with some constant prefix and is then followed by
>> an airline identifier, the ICAO 24-bit identifier, an 8 bit subnet id
>> and a 48-bit End System id (it follows a structure originally proposed
>> by NIST). The last two can be readily combined into a 64-bit host
>> identifier. Indeed, if we based the MNP on the ICAO 24-bit then the only
>> thing stopping a simple algorithm is the missing airline identifier part
>> - this cannot be readily predicted from the ICAO 24-bit identifier
>> without access to the registration database.
>>
>> In order to avoid a lookup table in the protocol gateway, etc. we need
>> to have an airline identifier in the MNP. 15 bits appears to be the
>> minimum we can get away with (in order to avoid a new airline
>> identifier, the proposal is to generate a 15-bit identifier by encoding
>> the existing ICAO three character airline identifier using ITA-2 letter
>> shift). Hence 24 +15 = 39.
>>
>> The industry's network providers also regard embedding an airline
>> identifier in the MNP as highly desirable. It is used in the existing
>> system for diagnostic purposes and firewalls.
>>
>> This is not an "ICAO says so" at all. This is practical engineering to
>> deliver a new system as an evolution from an existing system and with
>> limited budgets. Start with a clean sheet of paper and you could use a
>> lot less that 39 bits. Unfortunately, we do not have that luxury.
>>
>> Tony
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>