Skip to main content

Problems and Requirements of Source Address Spoofing in Integrated Space and Terrestrial Networks
draft-jliu-istn-savi-requirement-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jun Liu , Hewu Li , Tianyu Zhang , Qian Wu
Last updated 2021-10-25
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jliu-istn-savi-requirement-00
Internet Area Working Group                                       J. Liu
Internet-Draft                                                     H. Li
Intended status: Informational                                  T. Zhang
Expires: 28 April 2022                                             Q. Wu
                                                     Tsinghua University
                                                         25 October 2021

Problems and Requirements of Source Address Spoofing in Integrated Space
                        and Terrestrial Networks
                  draft-jliu-istn-savi-requirement-00

Abstract

   This 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 28 April 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.

Liu, et al.               Expires 28 April 2022                 [Page 1]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Vulnerable Characteristics of ISTN  . . . . . . . . . . . . .   3
     3.1.  Inter-Satellite Links (ISLs)  . . . . . . . . . . . . . .   4
     3.2.  Open Access Environment . . . . . . . . . . . . . . . . .   5
     3.3.  Dynamic Networks  . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Limited Resources . . . . . . . . . . . . . . . . . . . .   5
     3.5.  Threat from Source Address Spoofing . . . . . . . . . . .   6
   4.  Problems of Source Address Spoofing in ISTN . . . . . . . . .   7
     4.1.  Understand The Necessity of Onboard Source Address
           Validation  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Signaling Storm and Service Interruption  . . . . . . . .   8
     4.3.  Delay Deterioration and Bandwidth Occupation  . . . . . .  10
   5.  Requirements for Improvement on Source Address Validation for
           ISTN  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Scalability . . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Lightweight . . . . . . . . . . . . . . . . . . . . . . .  12
     5.3.  Capacity  . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.4.  User Experience . . . . . . . . . . . . . . . . . . . . .  12
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Mega-constellations of low-earth-orbit (LEO) satellites, such as
   Starlink [Starlink], Kuiper [Kuiper] and OneWeb [OneWeb] serve the
   area that the terrestrial networks cannot reach
   [Networking-in-Heaven].  LEO satellites have advantage of wide
   coverage [ITU-6G][Surrey-6G][Nttdocomo-6G] and low delay
   [Low-Latency-in-Space].

Liu, et al.               Expires 28 April 2022                 [Page 2]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   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.

2.  Terminology

   LEO: Low Earth Orbit

   GEO: Geostationary Earth Orbit

   LSN: LEO Satellite Networks

   ISL: Inter-satellite Links

   GS: Ground Station

   SAVA: Source Address Validation Architecture

   SAVI: Source Address Validation Improvements

   DHCP: Dynamic Host Configure Protocol

   SLACC: Stateless Address Autoconfiguration

   DNS: Domain Name System

   DDoS: Distributed Denial-of-Service Attacks

   CDN: Content Delivery Network

3.  Vulnerable 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

Liu, et al.               Expires 28 April 2022                 [Page 3]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   altitude of about 36000 km from the earth.  Satellites in different
   orbits have their own characteristics [LEO-MEO-GEO].  Table 1
   exemplifies typical mega constellations in operation.

    +===============+===============+===========+=====================+
    | Constellation | Altitude (km) | Number of | Number of satellite |
    |               |               |   orbits  |      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         |
    +---------------+---------------+-----------+---------------------+

                   Table 1: Typical-mega-constellations.

3.1.  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.  The first launche of 51 Starlink Block v1.5
   satellites took place in September 2021 [STARLINK-ISL].  The
   performance of trans-oceanic routes in networks with and without ISL
   is discussed in [Ground-Relays].  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 [Internetworking].  In fact, ISL

Liu, et al.               Expires 28 April 2022                 [Page 4]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   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 [Motif].

3.2.  Open Access Environment

   As 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 [GPS-Precision].  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.

3.3.  Dynamic Networks

   Due 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
   [In-Orbit-Computing].  The frequent handover between user terminals
   and LEO satellites will cause inevitable frequent updating of the IP
   address.

3.4.  Limited Resources

   Due 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.

Liu, et al.               Expires 28 April 2022                 [Page 5]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   In particular, typical performance of spatial processor are as
   follows.  The Cobham GR740 [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 [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 [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 [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.

3.5.  Threat from Source Address Spoofing

   The report [GLOBAL-DDoS] 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 [ICARUS].

   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.  DDoS attack [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 [Cisco-Report].  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
   [Dns-Security].

   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.  To
   prevent this kind of attack, the most effective mechanism in
   terrestrial network is to filter the address spoofing packet and
   ensure the traceability of the packet through source address to
   locate the malicious users in the network
   [RFC5210][RFC7039][RFC7513][RFC8074].

Liu, et al.               Expires 28 April 2022                 [Page 6]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   In the terrestrial network, source address validation mechanisms such
   as SAVI have been deployed and proved effective to a certain extent.
   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.

4.  Problems of Source Address Spoofing in ISTN

4.1.  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).

Liu, et al.               Expires 28 April 2022                 [Page 7]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

             +-------------------------------------------+
             | +---------+                   +---------+ |
    Space    | |Satellite|       ISLs        |Satellite| |
    Segment  | |  (SAVI) | <---------------> |  (SAVI) | |
             | +----+----+                   +-----+---+ |
             +------|------------------------------|----+
                    |                              |
             +------|------------------------------|-----+
             | +----+----+  +--------------+   +---+---+ |   +--------+
    Ground   | |   User  |  |Authentication|<->|Gateway|<--->|Internet|
    Segment  | | Terminal|  |    Server    |   |Station| |   +--------+
             | +---------+  +--------------+   +-------+ |
             +-------------------------------------------+

         Figure 1: The source address validation scenario for ISTN.

   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.

4.2.  Signaling Storm and Service Interruption

   Reauthentication 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.

Liu, et al.               Expires 28 April 2022                 [Page 8]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   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.

     Queuing delay
       in NCC (ms)
           |
       10 -|                                    *
           |                                    *
        8 -|                                   *
           |                                  *
        6 -|                                 *
           |                               *
        4 -|                            **
           |                         **
        2 -|                     **
           |*******************
        0 -|-------*-------*-------*-------*-------*------>
           0     20000   40000   60000   80000  100000  Number of users

                     Figure 2: The bottlenecks of NCC.

   B.  Service Interruption

   The 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.

Liu, et al.               Expires 28 April 2022                 [Page 9]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

4.3.  Delay Deterioration and Bandwidth Occupation

   Tunnel 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 Deterioration

   Since 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.

         Number of hops
           from anchor
               |
           35 -|
               |                        **
           30 -|                      *    *
               |                    *        *
           25 -|                  *            *
               |                *                *
           20 -|              *                    *
               |            *                        *
           15 -|          *                            *
               |        *                                *
           10 -|      *
               |    *
            5 -|  *
               |*
            0 -|--------.-------.-------.--------.-------.---->
               0       100     200     300      400     500  Time(s)

Liu, et al.               Expires 28 April 2022                [Page 10]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

           Figure 3: The number of hops from anchor to the user.

       Delay from anchor (ms)
               |
           70 -|
               |                        **
           60 -|                      *    *
               |                    *        *
           50 -|                  *            *
               |                *                *
           40 -|              *                    *
               |            *                        *
           30 -|          *                            *
               |        *                                *
           20 -|      *
               |    *
           10 -|  *
               |*
            0 -|--------.-------.-------.--------.-------.---->
               0       100     200     300      400     500  Time(s)

                Figure 4: The delay from anchor to the user.

   The introduction of such a large additional delay has completely
   suppressed the low delay advantage of mega constellations.

   B.  Capacity Deterioration

   From 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.

5.  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:

Liu, et al.               Expires 28 April 2022                [Page 11]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

5.1.  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, network
   performance indicators such as delay and bandwidth should be
   discussed.  The focus is that there should be no bottleneck node for
   traffic aggregation in source address validation.

5.2.  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) [CDN-ISTN], are
   expected to be extended to satellites.  As a basic security function,
   source address validation mechanism should occupy less satellite
   resource and leave more computing power and memory capacity for upper
   layer services.

5.3.  Capacity

   The deployment of ISTN is a long-term activity with continuous launch
   and incremental deployment.  The design of source address validation
   mechanism should ensure that its functional integrity is not limited
   by the current completion degree of the constellation, and the
   mechanism should be considered as an indispensable part of load on
   the satellite design stage before launch.

5.4.  User Experience

   There should be an attribute that ensures the user to be unaware of
   the underlying physical handover.  The continuous Internet services
   on upper layers, such as video, conference and game services, should
   be able to maintain business continuity as well as low latency and
   high bandwidth provided by ISTN.

6.  Acknowledgements

7.  IANA Considerations

   This memo includes no request to IANA.

8.  References

8.1.  Normative References

Liu, et al.               Expires 28 April 2022                [Page 12]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   [RFC5210]  Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
              "A Source Address Validation Architecture (SAVA) Testbed
              and Deployment Experience", RFC 5210,
              DOI 10.17487/RFC5210, June 2008,
              <https://www.rfc-editor.org/info/rfc5210>.

   [RFC7039]  Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
              "Source Address Validation Improvement (SAVI) Framework",
              RFC 7039, DOI 10.17487/RFC7039, October 2013,
              <https://www.rfc-editor.org/info/rfc7039>.

   [RFC7513]  Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
              Validation Improvement (SAVI) Solution for DHCP",
              RFC 7513, DOI 10.17487/RFC7513, May 2015,
              <https://www.rfc-editor.org/info/rfc7513>.

   [RFC8074]  Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, Ed.,
              "Source Address Validation Improvement (SAVI) for Mixed
              Address Assignment Methods Scenario", RFC 8074,
              DOI 10.17487/RFC8074, February 2017,
              <https://www.rfc-editor.org/info/rfc8074>.

8.2.  Informative References

   [CDN-ISTN] Yang, S., "A Synergic Architecture for Content
              Distribution in Integrated Satellite and Terrestrial
              Networks", 2020.

   [Cisco-Report]
              "Cisco Annual Internet Report (2018–2023) White Paper",
              2018, <https://www.cisco.com/c/en/us/solutions/collateral/
              executive-perspective s/annual-internet-report/white-
              paper-c11-741490.html>.

   [DDoS-Attack]
              Elion, J., "Distirbuted denial of sevrice attack and the
              zombie ant effect", 2000.

   [Dns-Security]
              Deccio, C., "Behind closed doors: A network tale of
              spoofing, intrusion, and false dns security", 2020.

   [GLOBAL-DDoS]
              "GLOBAL DDoS THREAT REPORT", 2019,
              <https://business.blogthinkbig.com%2Fwp-content%2Fuploads%
              2Fsites%2F2%2F2020%2F02%2FGTSA_Etisalat_DDoS_v2.pdf>.

Liu, et al.               Expires 28 April 2022                [Page 13]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   [GPS-Precision]
              Kelso, T., "Validation of SGP4 and IS-GPS-200D Against GPS
              Precision Ephemerides", 2007.

   [GR740]    Hjorth, M., "GR740: Rad-Hard Quadcore LEON4FT System-on-
              Chip", 2017.

   [Ground-Relays]
              Handley, M., "Using ground relays for low-latency wide-
              area routing in megaconstellations", 2019.

   [HPSC]     "High Performance Spaceflight Computing (HPSC) Processor
              Chiplet", 2017.

   [ICARUS]   Giuliari, G., "ICARUS: Attacking low Earth orbit satellite
              networks", 2021.

   [In-Orbit-Computing]
              Bhattacherjee, D., "In-orbit Computing: An Outlandish
              thought Experiment?", 2020.

   [Internetworking]
              Wood, L., "Internetworking with satellite constellations",
              2001.

   [ITU-6G]   "ITU 6G vision", <https://www.itu.int/dms_pub/itu-
              s/opb/itujnl/S-ITUJNL-JFETF.V1I1-2020-P09-PDF-E.pdf>.

   [Kuiper]   "Kuiper", <https://en.wikipedia.org/wiki/Kuiper_Systems>.

   [LEO-MEO-GEO]
              Vatalaro, F., "Analysis of LEO, MEO, and GEO Global Mobile
              Satellite Systems in the Presence of Interference and
              Fading", 1995.

   [Low-Latency-in-Space]
              Handley, M., "Delay is not an option: Low latency routing
              in space", 2018.

   [Maestro]  Suh, J., "Implementation of Kernels on the Maestro
              Processor", 2013.

   [Motif]    Bhattacherjee, D., "Network topology design at 27,000 km/
              hour", 2019.

   [Networking-in-Heaven]
              Klenze, T., "Networking in heaven as on earth", 2020.

Liu, et al.               Expires 28 April 2022                [Page 14]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   [Nttdocomo-6G]
              "NTTDPCOM 6G White Paper",
              <https://www.nttdocomo.co.jp/english/binary/pdf/corporate/
              technology/whitepaper_6g/
              DOCOMO_6G_White_PaperEN_20200124.pdf>.

   [OneWeb]   "OneWeb", <https://en.wikipedia.org/wiki/OneWeb>.

   [RAD5545]  Berger, R., "Quadcore Radiation-Hardened System-on-Chip
              Power Architecture Processor", 2015.

   [Space-Race]
              Bhattacherjee, D., "Gearing up for the 21st century space
              race", 2018.

   [Starlink] "Starlink", <https://en.wikipedia.org/wiki/Starlink>.

   [STARLINK-ISL]
              "Starlink Block v1.5", 2021,
              <https://space.skyrocket.de/doc_sdat/starlink-v1-5.htm>.

   [Surrey-6G]
              "Surrey 6G vision",
              <https://www.surrey.ac.uk/sites/default/files/2020-11/6g-
              wireless-a-new-strategic-vision-paper.pdf>.

Authors' Addresses

   Jun Liu
   Tsinghua University
   Beijing 100084
   China

   Email: juneliu@tsinghua.edu.cn

   Hewu Li
   Tsinghua University
   Beijing 100084
   China

   Email: lihewu@cernet.edu.cn

Liu, et al.               Expires 28 April 2022                [Page 15]
Internet-Draft     ISTN SAVI Problems and Requirements      October 2021

   Tianyu Zhang
   Tsinghua University
   Beijing 100084
   China

   Email: ty-zhang20@mails.tsinghua.edu.cn

   Qian Wu
   Tsinghua University
   Beijing 100084
   China

   Email: wuqian@cernet.edu.cn

Liu, et al.               Expires 28 April 2022                [Page 16]