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

[Behcet Sarikaya <[e-mail]>]

On Mon, Nov 16, 2020 at 2:43 PM Templin (US), Fred L <
[e-mail]> wrote:

> Brian,
>
> > -----Original Message-----
> > From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> > Sent: Monday, November 16, 2020 12:21 PM
> > To: Tony Whyman <[e-mail]>; Joel M. Halpern <
> [e-mail]>; [e-mail]
> > Subject: [EXTERNAL] Why this is broken [was Re: Extending a /64]
> >
> > This message was sent from outside of Boeing. Please do not click links
> or open attachments unless you recognize the sender and
> > know that the content is safe.
> >
> >
> > On 17-Nov-20 04:26, Tony Whyman wrote:
> > > On 16/11/2020 14:50, Joel M. Halpern wrote:
> > >> Tony, why are you embedding the 39 bit airplane ID into the IPv6
> > >> address.  That seems to be the fundamental thing that then has you
> > >> need very short prefixes, and doing other difficult operations.
> > >>
> > >> And if the answer is "ICAO said so", then we have a problem of really
> > >> smart aviation engineers doing network engineering.
> > >>
> > >> Yours,
> > >> Joel
> > >
> > > Perhaps the best way to answer this question is to look at the
> alternative.
> > >
> > > 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 actually works; the routing system is described here:
>
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/
>
> The MNPs do not need to be topologically-fixed, because the nodes are
> mobile at all times and frequently change their topological attachments.
> True, the MNPs are non-aggregateable but that just means there will be
> one prefix per mobile node represented in the BGP routing system, and
> we have shown how BGP can handle lots of MNPs as long as the amount
> of churn can be minimized.
>
>

Actually what Fred is saying here is that they use host routes.
So each airplane since it is moving  constantly changing networks they
don't change its address, these are what Fred calls MNP.
So they keep so many host routes in their routing table.

It is how they handle their routing table given these so many extra entries
in it.
I think they developed some good techniques to handle it.

Behcet

> This is so badly conceived that I suggest an IETF liaison statement to
> > ICAO may be needed.
>
> We have  a liaison statement that could be expanded on if necessary.
> But, I don't see the problem since we already have this working well.
>
> > 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.
> >
> > 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.
>
> The ATN/IPS will be a secured network with no connections to the Internet
> and open only to authorized users. An enterprise network for civil
> aviation,
> if you will. Unauthorized users will not have access to the network, and
> even
> for authorized users the multi-layered security services will ensure
> secured
> communications.
>
> Fred
>
> > 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
> > > --------------------------------------------------------------------
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>