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

Tony,

Thanks for the explanations.

I'm not disputing that you can make practically anything work in a private 
network. As I heard the late Dave Sincoskie say in an IAB discussion of the
Internet as it was in about 1994, "just buy an ****ing big CAM and you can
make anything work." Nor am I disputing that aircraft present an especially
hard case of mobility. (Isn't that why cell phones are mainly forbidden
on planes?)

But at Internet scale, we just can't do that. Routing prefixes need
to aggregate. This isn't an aesthetic consideration; it's fundamental
to why we have enough IPv6 prefixes to last for hundreds of years,
and why the backbone routers are able to keep up with growth.

If the first step is using the well-known IPv6 address to map to
a c/o address for mobility, why does the non-topological identfier
need to be in the prefix? The natural place for non-topological
bits in IPv6 is in the Interface Identifier.

Regards
   Brian Carpenter

On 17-Nov-20 12:17, Tony Whyman wrote:
> 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
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
> 