Problems and Requirements of Source Address Spoofing in Integrated Space and Terrestrial Networks
Tsinghua UniversityBeijing 100084Chinajuneliu@tsinghua.edu.cnTsinghua UniversityBeijing 100084Chinalihewu@cernet.edu.cnTsinghua UniversityBeijing 100084Chinaty-zhang20@mails.tsinghua.edu.cnTsinghua UniversityBeijing 100084Chinawuqian@cernet.edu.cn
General
Internet Area Working GroupSAVIThis document presents the detailed analysis about the problems and requirements of dealing with the threat
of source address spoofing in Integrated Space and Terrestrial Networks (ISTN). First, characteristics of ISTN that cause DDos
are identified. Secondly, it analyzes the major reasons why existing terrestrial source address validation mechanism
does not fit well for ISTN. Then, it outlines the major requirements for improvement on source
address validation mechanism for ISTN.IntroductionMega-constellations of low-earth-orbit (LEO) satellites, such as Starlink ,
Kuiper and OneWeb serve the area that the terrestrial networks cannot
reach . LEO satellites have advantage of wide
coverage and low delay .LEO mega-constellations have Inter Satellite Links (ISLs) ,which enable traditional attacks extend
from one-hop in satellite communication environment to the whole satellite networks. Also, LEO’s
attributes, such as open access environment, limited Resources and dynamic topology, enable
severe security threats. These security threats yield diverse challenges on existing network security design.By analyzing security events occurred recently, we realized that typical LEO threats are Source Address Spoofing.
This memo outlines the major problems and requirements for improvement on source address validation mechanism in ISTN.TerminologyLEO: Low Earth OrbitGEO: Geostationary Earth OrbitLSN: LEO Satellite NetworksISL: Inter-satellite LinksGS: Ground StationSAVA: Source Address Validation ArchitectureSAVI: Source Address Validation ImprovementsDHCP: Dynamic Host Configure ProtocolSLACC: Stateless Address AutoconfigurationDNS: Domain Name SystemDDoS: Distributed Denial-of-Service AttacksCDN: Content Delivery NetworkVulnerable Characteristics of ISTN A satellite constellation is composed of one or more satellite shells. Each shell is
organized by a large number of satellites distributed around the earth according to
certain design strategies to ensure cooperative performance. Kepler elements can be
used to describe the orbit of a satellite. Usually, satellites with an orbital altitude
of 400-2000 km are called LEO satellites, and satellites with an orbital altitude of
2000-36000 km are MEO satellites. GEO is a satellite in geosynchronous orbit, with an
altitude of about 36000 km from the earth. Satellites in different orbits have their
own characteristics . Table 1 exemplifies typical mega constellations in operation.
Typical-mega-constellations.
Constellation
Altitude (km)
Number of orbits
Number of satellite per orbit
Starlink
550
72
22
1110
32
50
1130
8
50
1275
5
75
1325
6
75
Kuiper
590
28
28
610
36
36
630
34
34
Telesat
1015
27
13
1325
40
33
Inter-Satellite Links (ISLs)Comparing with previous satellite communication systems,ene of the most obvious feature of the
mega constellation is the use of inter-satellite links. ISL can reduce the delay of satellite
network and improve network capacity by avoiding the ping-pong phenomenon and reducing the occupation
of the link between the ground station (GS) and the satellite. Although ISL is not used in the
initial stage of Starlink deployment, it is still an important part of the future satellite network.
Since the launch on September 14, 2021, the satellite version of Starlink has been upgraded to V1.5, and the load of inter satellite laser link is increased . As of April 22, 2022, V1.5 satellites have been launched 13 times in total, and the proportion of in orbit Starlink satellites supporting ISL is rising rapidly.
The performance of trans-oceanic routes in networks with and without ISL is discussed
in . The conclusion is that ISL always have lower delay than ground relay.
The most typical configuration is to equip each satellite with four ISLs, which are respectively
used to link the front and rear satellites in the same orbit and the two satellites in adjacent
orbits . In fact, ISL does not need to be restricted by grid topology.
It has become a new problem to design ISL configuration to maximize network bandwidth and minimize latency .Open Access EnvironmentAs transmission medium used by satellites, wireless microwave or laser channel, has inferior
transmission quality comparing to wired channel. Moreover, the communication between satellites and
GSs will be affected by weather, atmospheric conditions, signal attenuation. The transmission channel
can be disturbed easily due to the open environment. In addition, the position description information,
such as orbit of the satellite, is public. Therefore the motion can be accurately predicted through
calculation . This will increase the possibility of premeditated attack.
Moreover, due to the global movement of the satellite, the majority of its cycle is in an uncontrolled
environment, facing a large number of malicious hosts and users distributed all over the world.Dynamic NetworksDue to the extremely fast speed of LEO satellites relative to the ground, it has short-lived coverage
for terrestrial users (less than 3 minutes). What's more, under the minmax connection principle,
a handover occurs in an average of about 40 seconds . The frequent handover
between user terminals and LEO satellites will cause inevitable frequent updating of the IP address.Limited ResourcesDue to the limitation of rocket capacity, cost and manufacturing technology, satellite design will be
subject to many restrictions. The processors on satellites also have worse performance than that of the
terrestrial equipment. Up-to-date onboard processor have a CPU frequency ranging from 100MHz to 500MHz,
much lower than commercial processors. In particular, typical performance of spatial processor are as follows. The Cobham GR740 is
a 65 nm CPU with a 32-bit quad-core architecture that operates at 250 MHz with estimated power dissipation
of under 1.5 W. The BAE Systems RAD5545 is a 45 nm CPU with a 64-bit quad-core architecture
that operates at 466 MHz with estimated power dissipation of under 20 W. The Boeing Maestro is
a 90 nm CPU with a 64-bit 49-core architecture that operates at 350 MHz with estimated power dissipation
of under 22.2 W. A space-grade 32 nm CPU HPSC with 64-bit dual quad-core architecture is
considered that is currently being developed by Boeing, which is estimated to operate at 500 MHz with
power dissipation of under 10 W.Threat from Source Address SpoofingThe report shows that attacks occur increasingly in satellite systems. In 2019,
attacks on satellite systems increased 255 percent. Some hackers begun to attack the satellite constellations,
rather than the previous ones on satellite monomers. DDoS attacks against satellite networks have
feature of low-cost and low-detectability. And by congesting of the target link, or exploiting some
vulnerable characteristics, the satellite networks are as vulnerable to DDoS attacks as terrestrial
networks . In the past, the attacks on satellite communication systems, such as eavesdropping, interference and
frequency blocking mainly occur in the physical layer. The use of the ISL in ISTN increases
the vulnerability of network layer and above. The attack object expands from satellite monomer to satellite network, and the attack method evolves from physical layer to higher layer.DDoS attack is one of the most common attack
in network layer. Cisco predicts that the number of DDoS attacks will increase to 154 million worldwide
in 2023 . Through the query and test of DNS services in 62000 autonomous domains around
the world, it is found that more than half of the networks are in danger of being DDoS attacked
because they do not validate the source address of packets . Due to limited computing resource, lack of traceability, and exposure to the uncontrolled environment,
source address spoofing attacks in ISTN are more severe than that in the terrestrial network. Existing Solutions and Failure AnalysisMany measures have been actually deployed on the Internet to resist DDoS attacks, but they are difficult to adapt to the new features of mega-constellations and can not work as effectively as in terrestrial networks. Professional firewall: identify and isolate the traffic according to some characteristics of the traffic to prevent malicious traffic from entering the network. Such firewalls are usually additional hardware, and their weight and volume greatly increase the cost of satellite launch. In addition, the energy consumption required for its high performance is also unbearable for satellites. Scrubbing center: transfer the flow to the scrubbing center, filter and scrub it, and then return the normal flow to the original server. Traffic will occupy a lot of link bandwidth in the process of leading out and returning, increase the probability of congestion and occupy the traffic of normal users. In addition, due to the need to transfer to the scrubbing center, this operation will bring additional detour delay depending on the deployment location of the scrubbing center. Equipment upgrade: upgrade the server, gateway and other equipment to improve the tolerance of large traffic. Once launched, the satellite will continue to move at a high speed in space, and it is difficult to upgrade its hardware in the future. Therefore, its bandwidth and processing speed, which are heavily dependent on the performance indicators of the hardware, can basically be considered as non scalable. Source address validation: filter address spoofing packets and locate malicious users in the network through the traceability of source address . In the terrestrial network, source address validation mechanisms such as SAVI have been deployed and proved effective to a certain extent. SAVI is an endogenous security mechanism at the protocol level and has little dependence on hardware. It is one of the most promising solutions to be transplanted to the ISTN scenario. However, due to the vulnerable characteristics of satellite constellations described in 3.2, 3.3 and 3.4, SAVI mechanism cannot be used directly in ISTN. Problems of Source Address Spoofing in ISTN Understand The Necessity of Onboard Source Address Validation The most effective deployment scheme of SAVI is to deploy on the first hop switching device. In the
traditional satellite communication system, the satellite adopts "bent-pipe-only" model, that is,
satellites only relay terrestrial users' radio signals to the fixed ground stations without ISLs or routing.
As ground station location is fixed, the storage location of anchor binding information is fixed accordingly.
Therefore, the SAVI mechanism can take effect stably at a low cost in terrestrial networks. ISTN is in a dilemma of vast global traffic and limited ground stations. If the
"bent-pipe-only" model is adopted, all traffic on the network will converge to the thimbleful of ground stations.
This will generate traffic convergence, resulting in bottlenecks and a sharp decline in network performance.
That explains why ISLs are put on the Starlink agenda and routers are the most expected device in the network
infrastructure. Further, in such a network structure, the source address validation mechanisms are naturally deployed on satellites. The source address validation scenario for mega constellations is shown in Figure 1. It is divided into ground
segment and satellite segment. The ground segment includes user terminal, authentication server and ground gateway,
and is connected to the Internet through ground gateway. The space segment consists of satellites in the satellite
Internet (support SAVI and ISL). However, in today's time-varying topology LEO satellite networks, SAVI mechanism faces the problem that the
anchor binding information stored on the satellite is no longer stable. The router in satellites moves at a high speed,
therefore the mobility mechanism in the terrestrial network is no longer effective. There are two possible terms of settlement as follows.
Each has its respective unacceptable weaknesses. Signaling Storm and Service InterruptionReauthentication in ISTN contains the following steps according to its network composition:1. Considering the resource limitation and information security of satellites, the authentication server
(such as RADIUS Server) storing user identity information needs to be accessed after reaching the GS through the ISL, 2. The LEO satellite initially accessed by the user terminal acts as an authenticator to initiate an identity
authentication request to the authentication server and assign an address to the user terminal, 3. As LEO satellites keep moving at a high-speed relative to ground, user terminals need to switch access to satellites every dozens of seconds, 4. After the handover, the user needs to find a new satellite as the access point and perform the reauthentication and rebinding process to access the network. A. Signaling Storm First, the user sends the authentication request to the NCC on the ground through the network for reauthentication
process. This process requires multiple signaling interactions between the user and the access satellite, between
the access satellite and the NCC. Secondly, the authenticated user executes the address configuration process to
obtain the trusted address. In this process, multiple signaling interactions with specific servers or satellites
will also occur according to the address configuration mechanism. From the perspective of the whole network,
a large amount of users need to perform reauthentication at every moment, and each reauthentication contains a
large amount of signaling. Therefore, as shown in Figure 2, if the number of users rises to 97000 under the
scale of Starlink phase I, signaling storm occurs, which not only occupies the link bandwidth, but also generates
the bottlenecks of NCC and cause bad deterioration of network performance. B. Service InterruptionThe legitimacy of user identity and the authenticity of address are the premise of realizing the function
of upper layer protocol. During the period from the handover to the successful rebinding, the user cannot use
the services at the network layer or above. This will cause interruption of the user's ongoing business.
Users need to wait until the completion of the reauthentication process. This seriously affects user experience.Delay Deterioration and Bandwidth OccupationTunnel forwarding in ISTN contains the following steps according to its network composition:1. After disconnecting from the access satellite, the user forwards the data traffic to the satellite where the
anchor binding information is located through the tunnel instead of reauthenticate or rebind, 2. After receiving the data packet, the satellite with anchor binding information unpacks it to obtain the user's
original data packet, and then validates its source address.A. Delay DeteriorationSince source address validation is required before the packet is forwarded, it needs to be forwarded to the satellite
where the anchor binding information is located, and then routed after validation. This causes traffic detour and
additional delay. Moreover, due to the periodicity of satellite movement, after disconnecting from the user,
the satellite will gradually move away from the user in half a cycle, and even on the other side of the earth in the
worst case. It can be seen from Figure 3 and Figure 4 that the number of hops and time delay from the user are
gradually increasing in the first half of the satellite cycle as the satellite brings the anchor binding information moves away. The introduction of such a large additional delay has completely suppressed the low delay advantage of mega constellations.B. Capacity DeteriorationFrom the end-to-end perspective, the detour of data traffic causes delay. From the network perspective, the detour of data
traffic causes additional ISLs to be used. Compared with the shortest path, tunnel forwarding needs to pass through more ISLs
when delivering the same amount of end-to-end traffic, therefore occupying more bandwidth. The reduction of ISL bandwidth leads
to the decline of the overall network capacity.Requirements for Improvement on Source Address Validation for ISTN In order to implement source address validation mechanism in ISTN, the following requirements for improvement should be made:Scalability A reasonable source address validation mechanism should be able to deploy as many satellites and user nodes as possible in
ISTN. With the continuous development of constellation and user scale, the handover may occur more frequently, which increases the pressure on the processing capacity of the mechanism. The mechanism should ensure that the network performance indicators such as delay and bandwidth do not deteriorate significantly, so as to support the long-term development of the network and users. A possible focus is that the signalling interaction process involved in source address validation should avoid bottleneck nodes caused by traffic aggregation in each link.Lightweight Due to on-board resources are very limited, source address validation mechanism should be lightweight. At present,
more and more Internet services, such as Content Delivery Network (CDN) , are expected to be extended to satellites.
As a basic security support function, the source address validation mechanism should occupy less satellite resources and can be deployed under the limitation of existing satellite resources. Reduce the computing power and memory capacity required by the mechanism, so as to leave more available resources for upper layer services and applications..Functional IntegrityThe deployment of ISTN is a long-term work. A mega-constellation will require continuous launch and iterative version. A reasonable source address validation mechanism should be designed to ensure that its functional integrity is not limited by the current deployment completion of the constellation. The mechanism should include the processing of incremental deployment of newly launched and deployed satellites, such as database synchronization.Transparency to UsersThe handover of the physical layer will undoubtedly lead to the interruption of all upper layer services. The source address validation mechanism should be organically combined with the user re access related operations as much as possible to reduce additional operations, so as to ensure the transparency of the physical handover to the user. The goal is to make users unaware when handover at the bottom and running the source address validation mechanism. The delay sensitive Internet services at the top, such as video, conference and game services, can maintain continuity and the advantages of low delay and high bandwidth provided by ISTN.Cost stabilityThe operations involved in source address validation will inevitably bring a certain amount of cost. In order to limit the cost to a controllable range, it should be decoupled from the deployment location of the ground station and the real-time location of the initial access satellite. It has been proved in experiments that if the rebinding process after handover needs to visit the ground station or the initial satellite, it will introduce great volatility to the cost.AcknowledgementsIANA ConsiderationsThis memo includes no request to IANA.ReferencesNormative ReferencesA Source Address Validation Architecture (SAVA) Testbed and Deployment ExperienceBecause the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. This memo defines an Experimental Protocol for the Internet community.Source Address Validation Improvement (SAVI) FrameworkSource Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.Source Address Validation Improvement (SAVI) Solution for DHCPThis document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods ScenarioIn networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods.Informative ReferencesGearing up for the 21st century space raceBehind closed doors: A network tale of spoofing, intrusion, and false dns securityA Synergic Architecture for Content Distribution in Integrated Satellite and Terrestrial NetworksDelay is not an option: Low latency routing in spaceNetworking in heaven as on earthAnalysis of LEO, MEO, and GEO Global Mobile Satellite Systems in the Presence of Interference and FadingGLOBAL DDoS THREAT REPORTCisco Annual Internet Report (2018–2023) White PaperNTTDPCOM 6G White PaperITU 6G visionSurrey 6G visionIn-orbit Computing: An Outlandish thought Experiment?Distirbuted denial of sevrice attack and the zombie ant effectGR740: Rad-Hard Quadcore LEON4FT System-on-ChipQuadcore Radiation-Hardened System-on-Chip Power Architecture ProcessorImplementation of Kernels on the Maestro ProcessorValidation of SGP4 and IS-GPS-200D Against GPS Precision EphemeridesUsing ground relays for low-latency wide-area routing in megaconstellationsInternetworking with satellite constellationsNetwork topology design at 27,000 km/hourICARUS: Attacking low Earth orbit satellite networksStarlink Block v1.5 High Performance Spaceflight Computing (HPSC) Processor ChipletStarlinkKuiperOneWeb