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

[Behcet Sarikaya <[e-mail]>]

On Tue, Nov 17, 2020 at 12:36 PM Templin (US), Fred L <
[e-mail]> wrote:

> “Host routes” is a correct analogy, yes, with the only difference being
> that the routes
>
> will be /60 and not /128. Instead of host routes, an expression I have
> used is “scalable
>
> deaggregation”, since BGP is capable of handling millions of de-aggregated
> routes as
>
> long as routing churn is kept in balance. The global Internet is already
> proof that BGP
>
> scales well under those conditions, and the BGP topology I have specified
> in this
>
> document is far simpler and far less prone to BGP update storms.
>
>
>

Yes, MNP is Mobile Node Prefix (?) so you keep/60 prefixes of each node in
the routing table and leave the detail of handling them to BGP.

This is what I referred to as "good technique" below.

Behcet

> Fred
>
>
>
> *From:* Behcet Sarikaya [mailto:[e-mail]]
> *Sent:* Tuesday, November 17, 2020 9:48 AM
> *To:* Templin (US), Fred L <[e-mail]>
> *Cc:* Brian E Carpenter <[e-mail]>; Tony Whyman <
> [e-mail]>; Joel M. Halpern <[e-mail]>;
> [e-mail]
> *Subject:* Re: [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 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
> --------------------------------------------------------------------
>
>