Re: Extending a /64

[Tony Whyman <[e-mail]>]

On 08/11/2020 14:40, Mark Smith wrote:
> If you're worried about DoS attacks, why are these critical aircraft 
> systems being attached to the public Internet in the first place?
My preference is for a closed network and for air gaps between any 
ground systems directly connected to it and systems connected to the 
public internet. However, it is not feasible to demand this. The ATN is 
a global communications network with no centralised control. There will 
be many different participants e.g. Airlines, ATC Centres, Met Sources, 
Airports and so on. All have some degree of access to the public 
internet and we cannot prevent this. A strategy is needed that accepts 
that there will be points of interconnection with the outside world and 
the ATN and that some egress points may have mis-configured firewalls 
that could enable an attacker to inject packets into the ATN. We have to 
have strength in depth to counter this. Typically, firewalls at every 
interconnection point and the firewall rules need to be as simple as 
possible in order to minimise the risk of mis-configuration or using 
out-of-date information.
>
> A aircraft only public /16 might make firewalling easier for you, it's 
> also a permanent and easy target. DoS attacks can take out firewalls too.
Security through obscurity has its uses, but we should not rely on this.
>
> The RFC4193 ULA address space seems like it would be the right address 
> space for these aircraft critical systems. The ULA address space has 
> been used in electricity smart meter networks I'm familiar with, and 
> they're nearly if not as critical.

You seem to be following the same path that I did when proposing 
alternatives. I tried to propose ULAs earlier this year but got push 
back from those that wanted public internet access for some classes of 
drones. But, if we get blocked by IANA then this is a route we may have 
to go down.

My original point though is that enabling a subnet if > 64 bits is a 
really good idea.

>
> If you want to provide Internet access on the plane itself, treat that 
> as a separate non-critical problem and a separate network.
Are you talking about the back cabin? This is always a separate problem 
to the front cabin where if you are have internet and rely on it then it 
must be a critical problem.
>
> Regards,
> Mark.
>
> On Mon, 9 Nov 2020, 00:01 Tony Whyman, <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     The problem of the /64 limit came up in ICAO working groups
>     earlier this
>     year when developing a global addressing plan for the ATN/IPS and
>     there
>     would be strong support here for allowing subnet prefixes to go
>     beyond
>     the /64 boundary.
>
>     Our problem is that we wanted to define an addressing plan that
>     uses 39
>     bits to identify each aircraft, allows for a minimum of 4 more
>     bits for
>     subnetting and works within the existing standards. I'll give some
>     background below for those interested in why 39 bits, but the
>     problem is
>     that if you are going to allocate a /64 (deriving from a /60 MNP) to
>     each subnet on an aircraft then you need a /21 as your initial
>     allocation - and this is before you start thinking about other
>     ATN/IPS
>     users such as drones.
>
>     In order to avoid a potential problem getting a sufficient address
>     allocation, we did look at extending into the "other 64 bits" of
>     an IPv6
>     address for subnet IDs, which was looking very "unused". After
>     all, you
>     can only cram in a handful of systems into the avionics bay of
>     even the
>     biggest aircraft and, if you extend the addressing scheme into the
>     back
>     cabin, passengers can only bring on so many mobile phones, tablets
>     and
>     laptops in their hand luggage. 64 bits is an overkill for the host
>     identifier and, if only we could have allocated (e.g.) a /96 for each
>     aircraft subnet, then the problem would just go away.
>
>     In the end, we concluded that we could not bend the existing
>     standards
>     to do this and did not have the desire to push for change. Hence,
>     we are
>     in the process of asking IANA for a /16 for the global civil aviation
>     community. Hopefully we will get this. However, an argument is
>     expected
>     given that the current policies push back against such a large
>     allocation and demand a utilisation efficiency that we will never
>     achieve. However, if we don't get a /16 and the standards stay as
>     they
>     are, then a private address space and NAT at the boundaries may be
>     the
>     only answer - not really what anyone wants.
>
>     I would certainly support raising the existing limit. A hard limit
>     of a
>     /96 would seem to be a good idea to stop ISPs going too far. It's
>     probably also worth noting that perhaps one day every home on the
>     planet
>     may require an IPv6 Prefix. That is perhaps over a billion given the
>     world's population. With densely packed address allocation that still
>     requires 30 or so bits. Once you take into account any kind of
>     geographical sub-allocation then you will need a lot more. A /96
>     would
>     seem to be much easier to live with than a /64.
>
>     Tony Whyman, MWA
>
>     Background
>     -----------------
>
>     For operational reasons, the ATN/IPS address allocation should
>     allow for
>     a common prefix for all aircraft operated by the same airline.
>     Network
>     diagnostics and firewall rules are often cited in support of such a
>     requirement. It is also highly desirable that there should be a
>     common
>     prefix for all airline IPv6 Address Prefixes. Again this is to
>     support
>     simple firewall rules. Resisting DoS attacks is extremely
>     important in
>     our environment and these include firewall rules that prevent packets
>     from external sources being sent to aircraft unless authorised, if
>     only
>     to minimise the risk of overloading limited capacity wireless
>     subnetworks. If every airline and ATC Centre has a different address
>     prefix then managing these rules will be an almost impossible task if
>     they all have unrelated prefixes. A common ICAO prefix is thus highly
>     desirable as are common prefixes for each category of address
>     space user.
>
>     It is believed that 15 bits is the minimum necessary to
>     sub-allocate a
>     prefix to each airline registered with ICAO. This leverages an
>     existing
>     registration scheme and allows for a reasonable degree of growth.
>
>     There are also very good reasons for using the existing ICAO 24-bit
>     aircraft identifier as part of an aircraft''s /60 MNP i.e. to
>     sub-allocate each airline's address space to each of their
>     aircraft. For
>     very good safety reasons, ATC Centre Flight Data Processors need to
>     correlate datalink messages (callsigns and 24-bit), surveillance
>     reports
>     (radar and ADS-B - which also use the 24-bit scheme), voice messages
>     (using callsigns) and Flight Plans. Basically, you don't want to
>     introduce yet another identifier into the mix and the use of
>     overlapping
>     schemes improves confidence in the overall result.
>
>     There is also the small matter of backwards compatibility with the
>     existing ATN/OSI CLNP addressing scheme. This also uses an airline
>     identifier/24-bit approach to address allocation and if we keep to
>     the
>     same address semantics then it becomes feasible to introduce the
>     ATN/IPS
>     with minimum impact on the high certification environment of the
>     Flight
>     Data Processor. Any alternative will cost a lot more and put back
>     deployment for several years.
>
>     So, we really are boxed in and 39 bits + 4 bits for aircraft
>     subnets is
>     the minimum needed for assignment of a /64 to each aircraft subnet.
>     Hence, the need for at least a /21, which ends up as a request for
>     a /16
>     when you add in other users and a desire for nibble boundaries.
>
>     On 08/11/2020 10:25, [e-mail]
>     <mailto:[e-mail]> wrote:
>     > Starting a new thread.
>     >
>     > A problem described in variable-slaac is:
>     >
>     > "It should be possible to extend an end-user network that is
>     only assigned a /64"
>     >
>     > I believe that is a problem worth looking at.
>     > This problem is not only restricted to the mobile access case,
>     think connecting a host with VMs to a link.
>     >
>     > The address delegation to a site problem is intertwined with the
>     autonomous networking problem of the site itself. The IETF
>     solution is DHCPv6 PD + HNCP. The expectation of addressing of a
>     network is that the addresses are long-lived.
>     >
>     > There are many potentional solutions:
>     >
>     > a1) ask the network operator for more address space.
>     > a2) change provider
>     > a3) introduce government regulation
>     > b1) steal the uplink /64 (64share)
>     > b2) steal multiple /64s from uplink
>     > c) overlay. use e.g. LISP to tunnel across the access ISP to
>     connect to an ISP that support multi-homing and larger address space.
>     > d) MultiLink Subnet Routing. I.e. let a single /64 span multiple
>     links. draft-thubert-6man-ipv6-over-wireless,
>     draft-ietf-ipv6-multilink-subnets
>     > e) NAT
>     > f) P2P Ethernet. Hosts are not on the same physical link, so
>     let's stop pretending they are. A consequence of that is that
>     links don't need subnets. Only assign addresses to hosts.
>     draft-troan-6man-p2p-ethernet-00
>     > g) extend the /64 bit boundary. HNCP implementations do /80s I
>     think (forces DHCP for address assignment)
>     >
>     >
>     > Requirements:
>     > R-1: Permissionless. Not require an action on the network operator
>     > R-2: Arbitrary topology
>     > R-3: Long-lived address assignments
>     > R-4: Support bad operational practice: flash renumbering /
>     ephemeral addressing
>     >
>     >
>     > Is there interest to work on this problem?
>     > If so, suggestions for next steps?
>     >
>     > Best regards,
>     > Ole (without any particular hat on)
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
>     >
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>