[Sis-csi] Communications Endpoints

[Keith Scott]

Probably not complete, but here's my  initial cut at where communications
endpoints (at application, transport, and network) might show up in the
cislunar architecture.
 
Communications endpoints:
    Astronauts in space suites (EVA from CEV or landed base)
    NASA flight controllers
    CEV
    Launch vehicles
    Cargo vehicles
    Astronauts' families
    News services
    NASA data archive facility
    Scientists
    Lander(s)
    Rover(s)
 
I propose that there are a number of different things that may affect where
the endpoints of communication are, and that in many cases these things can
be 'mixed-&-matched'.  What's below is the 'vanilla' end-to-end IP scenario,
and a list of modifications to it.  This could also be structured around the
common issues (below) with the 'mix&match snap-ins' organized as approaches
to solving the individual issues.

Not complete in that some of thissues (security, QoS) aren't yet folded into
all of the approaches.

		--keith
 
--------------------
Issues to be addressed:
 
Security: We postulate that authentication and access control will be
required before IP packets are allowed onto a space link.  Without these
capabilities, the possibility of a denial-of-service attack against space
assets is unacceptably high.
 
Encryption (as separate from authentication/access control): will end users
be allowed to encrypt traffic?  What provisions for privacy will be
required?  How does this interact with security (above) and application
layer (content) filtering, below?
 
Mobility: Space assets may attach to the terrestrial Internet though some
number of ground stations.  Terrestrial endpoints that want to route data to
space must send packets towards the correct ground station.  While normal IP
routing could in principle take care of this (provided the correct ground
station started advertising the space IP addresses in routing protocol
updates at the right times), in practice the time required for IP routing
tables to converge is too long to make this a viable alternative if
short-to-moderate length passes are to be supported.
 
Quality of Service (QoS): It is likely that QoS will be required, especially
for criticality-of-life and mission-critical voice.  If possible we want an
architecture that can provide a very high probability of delivering
'special' traffic, with the understandings that the volume of this traffic
will be low (and smaller than the smallest link it must traverse) and that
it is allowed to displace other traffic.
 
Application Layer (content) filtering: Is it a good idea to allow
scientists, and others who might be authorized to communicate with endpoints
in space, free reign to do so?  What if a scientist's instrument on a rover
can use enough power to run the batteries down so that the thing freezes
while sitting in shadow if he forgets to turn it off?  What if I'm allowed
to send stuff to the rover, and I accidentally type in the wrong port # for
my UDP packet?  Can I cause the rover to do a backflip?  Application layer
filtering would provide a way to inspect commands (all traffic, really)
before they are uplinked.
 
Transport Layer Performance: TCP performance can be poor over high
bandwidth*delay links.  This of course trickles up to affect
application-layer performance as well.
 
Heterogeneous network layers: Do we allow for the possibility of
heterogeneous network layers (like a scientist running IPv4 from his/her
palm pilot because it just doesn't _do_ IPv6 talking to an IPv6-enabled
cislunar achitecture)?  NAT?
 
Space Link Termination: currently, many space links are not terminated at
ground stations, but rather are extended over some portion of the
terrestrial infrastructure via Space Link Extensions (SLE).  What are the
advantages / disadvantages of terminating the space links at the ground
stations and going immediately into routed IP?
 
-------------------
 
===============================
========== Approaches ===========
===============================
 
End-to-End IP [vanilla IP]
In a 'pure' end-to-end IP scenario, the space network is simply an extension
of the terrestrial Internet.  Groundstations act as IP routers, and IP
packets flow uninterrupted between participants.  Security devices may
provide authentication and access control, but these security devices must
be placed at appropriate places (one per G/S, e.g.).
 
Deployment Issues: Terminate space links in ground stations; route IP
packets in/out of ground stations.
 
Advantages: Conceptually simple -- extend the terrestrial Internet over the
space links.
 
Disadvantages:  Security would be complex to implement (lots of security
devices (one per ground station?), need to synchronize policy among them).
TCP performance may suffer over high BW*Delay paths.  IP requires the
existence of contemporaneous end-to-end paths.  No QoS guarantees for data
in the terrestrial internet.  Chance of data loss (and need for
retransmission) of data that made it across the space link and gets lost in
the terrestrial network.  Mobility support is required (space assets may
communicate with any of several ground stations -- ground assets need to
know to which ground station to send data).  Mobility support can be
provided by IP Mobility (MobileIP, IPv4) or IPv6 mobility.  Requires that
the same version of IP be supported end-to-end.
 
=================
 
Route all space traffic through a control center? [Control center
concentrator]
With this option, all traffic to/from space is routed through a control
center.  This can be achieved, e.g. by having the control center advertise
the 'space' addresses to the terrestrial internet.  This has the advantage
of allowing centralized security such as authentication and access control.
Using this mechanism, IP packets still flow end-to-end between participants;
there is no provision for the control center to do application-layer
filtering of data (the control center doesn't get to look a the contents of
the IP packets).
 
Deployment Issues: 
 
Advantages: Allows centralized security mechanisms.  Can address mobility by
changing routes at control center (and maybe tunneling through terrestrial
infrastructure, from control center to the appropriate G/S).
 
Disadvantages: Control center becomes a single point of failure.  No ability
to do command verification.  No QoS guarantees for data in the terrestrial
internet (see above).  TCP performance may suffer over high BW*Delay paths.
Requires contemporaneous end-to-end data paths for IP.  No QoS guarantees in
public network(s).
 
=================
 
Application-layer processing. [content filtering]
Application layer processing would allow for inspection of the contents of
IP packets, in order to provide access control _to_specific_commands_.
 
Deployment Issues: Can be deployed in a 'vanilla IP' scenario (with
application-layer processing at each ground station, e.g.) or in a control
center concentrator scenario.
 
Advantages: provides a mechanism to do command inspection/verification (keep
the PI from turning on his 1000W instrument and draining the battery that
was needed to run the heaters).
 
Disadvantages: Inspection of commands will require deep-packet inspection,
probably termination of the transport layer connection.
 
=================
 
Transport Layer Proxies [PEPs]: PEPs are network devices that improve
transport layer performance through some means.  There are a number of
different types of TCP PEPs that range from manipulating the data/ack stream
to 'split-connection' PEPs that terminate TCP connections.  Generally, PEPs
need to be able to see, and usually manipulate, transport layer headers.
 
Advantages: PEPs can dramatically increase transport layer performance.
 
Disadvantages: PEPs introduce state into the network.  PEPs may place
constraints on traffic patters, such as: once a transport connection starts
out going through a PEP, it must continue that way until it is terminated.
 
 
==========  END =====