NASA MSFC Mission Operations Laboratory MSFC NASA MSFC Mission Operations Laboratory HOSC Payload Ethernet Gateway (HPEG) HOSC Service Supporting IP Access to Payloads

NASA MSFC Mission Operations Laboratory MSFC Page 2 Capabilities  Provides access to ISS payloads using standard network protocols and services  Provides Cadre tools to control/limit access to payloads via user authorization and system controls  Provides Cadre tools to monitor user activity

NASA MSFC Mission Operations Laboratory MSFC Page 3 Definition of Terms  User IP address  The user’s real IP address  Destination IP address  The real IP address of the onboard destination  NAT  Network Address Translation  Ground Node ID  Required by some services as part of the protocol. Currently, only required by CFDP. Uniquely identifies a ground CFDP node. To support static onboard configuration of CFDP, each assigned Ground Node ID will be mapped to a specific Onboard NAT IP address

NASA MSFC Mission Operations Laboratory MSFC Page 4 Definition of Terms  Space Node ID  Required by some services as part of the protocol. Currently, only required by CFDP. Uniquely identifies a payload’s CFDP node.  HPEG Proxy IP address  IP address assigned to the user at run-time to access a specific onboard destination  Dynamic – assigned from address pool when starting an HPEG session with a specific payload

NASA MSFC Mission Operations Laboratory MSFC Page 5 Definition of Terms  HPEG Onboard NAT IP address  IP address allowed by the onboard network  Used for NATing the source address in the user’s IP packets  Dynamic or Static  Dynamic – If user is not authorized for any service that requires a Ground Node ID, address is assigned from address pool when the HPEG Service is started. This address will be used for all subsequent payload sessions.  Static – If user is authorized for a service that requires a Ground Node ID (e.g. CFDP), address is assigned based on the selected Ground Node ID. Users may have more than one Ground Node ID assigned. This address will be used for all subsequent payload sessions.  Protocol  The type of an IP packet  tcp, udp, icmp

NASA MSFC Mission Operations Laboratory MSFC Page 6 Definition of Terms  Service  IP communication method over a particular protocol and an optional port  ssh (tcp/22)  Proxy ARP (ARP – Address Resolution Protocol)  Proxy ARP is the technique in which one host, usually a router, answers ARP requests intended for another machine. By "faking" its identity, the router accepts responsibility for routing packets to the "real" destination. Used by the HPEG Service to route the Proxy IP to the correct login server.

NASA MSFC Mission Operations Laboratory MSFC Page 7 Rules of the Road  HPEG Service is available as a standard ERIS service defined in POIC to Generic User Interface Definition Document, V2-Secured Services (PGUIDD), SSP  Supported by both TReK and EPC  Supports custom applications meeting interfaces defined in the PGUIDD  HPEG service may be started after valid EHS login, role and MOP selection  HPEG only provides the underlying infrastructure to utilize IP services for payload access  Payload Developer (PD) must provide their own service client applications (e.g. ssh client, ping client, etc)  Exception: Both EPC and TReK provide a CFDP client

NASA MSFC Mission Operations Laboratory MSFC Page 8 Rules of the Road  Only HOSC authorized services are allowed  cfdp (udp/4560)  ssh (tcp/22)  rdp (tcp/3389)  https (tcp/443)  ping (icmp)  Network Instruments Observer (HOSC Cadre Only)  tcp/25903  tcp/25901  Each service must be authorized by the HOSC Customer Service Team (CST) prior to use by the end user  Additional services may be allowed and must be coordinated with the HOSC CST

NASA MSFC Mission Operations Laboratory MSFC Page 9 Rules of the Road  HPEG service performs port checking on all forward and return packets  Packets containing unauthorized ports will be dropped with no notification to the user  TCP connections initiated from onboard to the user’s ground station are not supported  Port check will fail since the onboard source port will be random  UDP data from onboard to the user’s ground station is supported only when sent to the currently assigned Onboard NAT IP address on an authorized port

NASA MSFC Mission Operations Laboratory MSFC Page 10 Rules of the Road  If Ground Node ID is required for any of the user’s authorized services on any destination (e.g. CFDP), user must specify a Ground Node ID prior to accessing any payload via HPEG  User will not be allowed payload access until Ground Node ID has been specified  Only one HPEG Service may be started per ground station  A single HPEG Service supports access to all authorized payloads/services  Onboard CFDP Service  PD responsible for delivery and configuration of CFDP node  Payload user must login to payload if reconfiguration is required, e.g., ssh, rdp  TReK provides a CFDP console application available to payloads

NASA MSFC Mission Operations Laboratory MSFC Page 11 Rules of the Road  HOSC is authorized for 8Mb/s output to MCC  Aggregate bandwidth for all users  HOSC Cadre enables/monitors HPEG users  DMC monitors bandwidth usage per user  PRO must enable users prior to HPEG activities  PRO enables the HPEG subsystem  If disabled, payload sessions are terminated  Only scenario, where HPEG terminates sessions  HPEG does not terminate payload sessions during LOS conditions  Depending on protocol/service, connections may survive LOS periods

NASA MSFC Mission Operations Laboratory MSFC Page 12 Packet Routing Example

NASA MSFC Mission Operations Laboratory MSFC Page 13 Payload Access via HPEG Service  Start the ERIS HPEG Service  Login to ePVT (Login) server with username, RSA token and password  Select Role  Select MOP  Start the HPEG Service providing Out-of-Band connection information  HPEG Service provides a list of authorized Ground Node IDs, if applicable  User must select a Ground Node ID that is not currently in use  HPEG Service provides a list of all authorized payloads and services

NASA MSFC Mission Operations Laboratory MSFC Page 14 Payload Access via HPEG Service  HPEG Service provides the current user enablement  HPEG Service provides the current HPEG Subsystem status  HPEG enablement  Ku-Forward AOS/LOS  Ku-Return AOS/LOS  HPEG Service waits for an action by the user  Start a session with a payload  Stop a session with a payload  Terminate the HPEG Service  Upon a Start Session request, acquires an available Proxy IP address and provides it to the user  All services must use this IP Address to access payload

NASA MSFC Mission Operations Laboratory MSFC Page 15 Payload Access via HPEG Service  User accesses payload using preferred client (e.g. putty)  To terminate payload access, user issues a Stop Session request to the HPEG service  Allocated Proxy IP is returned to the available pool  To terminate the HPEG Service, simply terminate the Out- of-Band TCP connection  For more details on the interface to the HPEG service, reference the PGUIDD

NASA MSFC Mission Operations Laboratory MSFC Page 16 Payload Access via HPEG Service EPC HPEG Session Status UI

NASA MSFC Mission Operations Laboratory MSFC Page 17 Payload Access via HPEG Service HPEG User Monitor and Control UI Cadre/IST Tool

NASA MSFC Mission Operations Laboratory MSFC Page 18 Payload Access via HPEG Service Command System Management UI Cadre/IST Tool

NASA MSFC Mission Operations Laboratory MSFC Page 19 FAQ  Is this capability available today?  Yes. The Ku Forward capability is operational.  Are any payloads using this capability?  Yes. The AMS payload is currently using this capability.  Do I need any special software onboard or on the ground?  Not to flow the IP data. The HOSC provides software you can use to authenticate with the POIC and start the HOSC Payload Ethernet Gateway (HPEG) service that enables a path for your IP protocols. Once that has been done, standard IP protocols can be used between your ground software and flight software.  Exception: CFDP  EPC provides a CFDP ground client node  TReK provides both ground and payload CFDP nodes

NASA MSFC Mission Operations Laboratory MSFC Page 20 FAQ  How do I get access to this capability?  Tell your Payload Integration Manager that you would like to use this capability. Your PIM will include this in your Payload Integration Agreement.  How can I test this capability?  The HOSC will be hosting a test environment. The process of PD CoFR and testing of IP Ku-Band Services is still being worked. Contact CST for more information  Can I interact with my payload any time I want?  Ku-Band Service activities are coordinated, scheduled, and posted to OSTP. The PRO is responsible for payload IP Ku- Band Service enablement.  Does HPEG buffer IP packets?  No

NASA MSFC Mission Operations Laboratory MSFC Page 21 FAQ  Are there any additional requirements placed on a payload when using this capability?  The ISS Program (PSRP) will define any unique safety requirements pertaining to a Payload’s use of Ku Forward as part of the payload Safety Review process.  What performance can I expect?  Plans are in place to perform benchmark tests and publish the results. This is scheduled for the last quarter of CY2015. These results will be posted on the TReK Web Site.  Do I need to modify my flight software to take advantage of IP services?  Payload must be configured/(service started) to run the appropriate required services; e.g. sshd, httpsd, etc

NASA MSFC Mission Operations Laboratory MSFC Page 22 FAQ  Can my payload initiate an IP session with my control center?  No. Under the current design, the HOSC does not support TCP connections that originate from the payload.  UDP from the Payload to the Ground is supported as long as the Payload uses the correct Onboard NAT IP assigned by the HPEG Service during initialization and an authorized port. IP address can be determined programmatically by the Payload software.  Are there file size limitations for uplink or downlink?  No  Will the Cadre have access to my payload for emergencies?  Must be coordinated with the HOSC

NASA MSFC Mission Operations Laboratory MSFC Page 23 FAQ  How do I know if my protocols are allowed?  Contact HOSC Customer Support Team. The PGUIDD details the current set of protocols which are supported. Others may be added as needs arise in the community.  Do I lose my payload connection during LOS periods?  The HPEG service does not terminate service during LOS. The connection to the payload may survive LOS periods depending on the configuration of the service being used  Is any IP data logged?  All IP data to a given payload will be logged in a WireShark- like capture file for analysis by HOSC Network Admin, if required for forensics  For ssh, key must be provided to the HOSC CST during approval process to assist in analysis

NASA MSFC Mission Operations Laboratory MSFC Page 24 FAQ  Are any other IP services available onboard?  Under CR 13876, the ISS program will be deploying Network Attached Storage (NAS) which is accessible by onboard systems/users. Data will be partitioned/protected by user. Protocols supported are NFS, https, and iSCSI, TFTP, DHCP. Others are available as well though most are insecure for ground to space communication. One payload has expressed an interest in the use of PXE boot allowing relatively quick recovery of a corrupted hard drive.  Does the HOSC support port tunneling?  Certain services such as ssh can encapsulate other services and create a tunnel for those services. As an example, ftp can be run across ssh and provide a secure file transfer mechanism. The HOSC does not inhibit this behavior.

NASA MSFC Mission Operations Laboratory MSFC Page 25 Future Enhancements  Add Delay Tolerant Network as an additional Ku-Forward service supported by HPEG  Currently being developed  HOSC DTN Gateway  Provides a DTN Node at the HOSC  EPC DTN Bundle Client  Provides capability to upload/download files via CFDP over bundle protocol  Interfaces to HOSC DTN Gateway only  Will be available for Increment 45  Evaluation currently underway to determine risks/benefits of only restricting IP protocols (udp, tcp, icmp, etc) and not underlying services