2008 Spring CCSDS meeting ( Washington, USA ) SMWG 1 CCSDS Service Management Validation Test Quick Report 12. March 2008 JAXA YAGI Nobuhiro/SUZUKI Kiyohisa

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 2 Contents 1 Background 2 Objectives 3 Test Procedure 3-1 Interface Test 3-2 Test Tracking 4 Test Result 4-1 Interface Test Security Data Compression 4-2 Test Tracking

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 3 1 ． Background Interoperability test activity by participant agencies of the CCSDS to validate the Service Management was determined at a meeting of the IOAG-10 on October, JPL and JAXA agreed to develop the following prototypes based on the CCSDS Service Management(R-1) Specification and validate the effectiveness of information and procedure exchanged by the Service Management to assured and control required resources for the spacecraft mission operations. - JPL ： The development of the SLE SM service-provider prototype - JAXA/Tsukuba ： The development of the SLE SM service-user prototype 2. Objectives Primary Objectives - Validation of the SLE SM standard via prototyping - Demonstration of SM interoperability across JPL and JAXA. Specifically; - Validate demonstration scenario - Validate service request exchange protocol - Gain experience in application of security techniques

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 4 3. Test Procedure 3-1. Interface test This test was conducted to verify the SLE-SM interface between service- provider prototype and service-user prototype. SLE-SM message exchange was handled by SMTP. In this test, the following specification and schema were applied to the service-provider prototype and the service-user prototype. -SPACE LINK EXTENSION SERVICE MANAGEMENT SERVICE SPECIFICATION (CCSDS R-1) -Service Management Schema File Set V P1 Figure 3-1Interface TEST Configuration SLESM Service-provider Prototype (CSSXP) JPL Internet JAXA/Tsukuba a SLESM Service-user Prototype (UMR-1) SLE-SM message exchanged by SMTP

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 5 SM ServiceOperationsJPLJAXAInterface test Service AgreementQuery Service AgreementQSAXXX Trajectory Prediction Add Trajectory PredictionATPXXX Delete Trajectory PredictionDTPXXX Query Trajectory PredictionQTPXN/A Configuration Profile Add Carrier ProfileACPXXX Delete Carrier ProfileDCPXXX Query Carrier ProfileQCPXXX Add Event ProfileAEPN/A Delete Event ProfileDEPN/A Query Event ProfileQEPN/A Service Package Create Service PackageCSPXXX Delete Service PackageDSPXXX Select Alternate ScenarioSASXN/A Apply New TrajectoryANTXN/A Query Service PackageQSPXXX Replace Service PackageRSPXN/A Service Package CancelledSPCXXX Service Package ModifiedSPMN/A Table 3-1 difference of Implemented service management operations and Interface test operations

2008 Spring CCSDS meeting ( Washington, USA ) SMWG Test tracking Test Tracking was conducted to verify the end to end interface and procedures of SLE transfer service utilization by SLE-SM Red-1 coordination. In the test tracking, JPL and JAXA used the JAXA’s “SELENE” spacecraft which is in the lunar orbit. Test tracking outline Service request was sent from the SLE-SM service-user prototype”UMR-1” at JAXA/Tsukuba to the JPL SLE-SM service-provider prototype “CSSXP”. JPL/DSN received return data from the SELENE compliant with the service request, and then transmitted these data to JAXA/Sagamihara using SLE transfer service (RAF). JAXA/Sagamihara checked the received date by the SELENE control system.

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 7 Figure 3-2 Test Tracking Configuration

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 8 SM ServiceOperationsJPLJAXA Interface Test Test tracking Service Agreement Query Service Agreement QSAXXXX Trajectory Prediction Add Trajectory Prediction ATPXXXX Delete Trajectory Prediction DTPXXX Configuration Profile Add Carrier ProfileACPXXXX Delete Carrier Profile DCPXXX Query Carrier ProfileQCPXXX Service Package Create Service Package CSPXXXX Delete Service Package DSPXXX Query Service PackageQSPXXX Service Package Cancelled SPCXXX Table 3-2 difference of Implemented service management operations and Test tracking operations

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 9 4. Test Result 4-1. Interface test The structure of service management data was XML-based text files. These were transferred as attached files on s using the protocol SMTP between UMR-1 and CSSXP. The rules of exchanged s are as follows: No.ItemRules 1 Subject:The following subjects are accepted. SLESM SleServiceManagement sleSmResponse sleExceptionMessage sleSmError 2 Content-Type:text/plain 3 Body of message:Not limited 4 Character:ISO-2022-jp or ASCII 5 Attached file:Only one file per one message Table 4 ‑ 1 Rules of Structure

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 10 SM ServiceOperationsJPLJAXA Interface test Result Service Agreement Query Service AgreementQSAXXX good Trajectory Prediction Add Trajectory PredictionATPXXX good Delete Trajectory PredictionDTPXXX good Query Trajectory PredictionQTPXN/A - Configuration Profile Add Carrier ProfileACPXXX good Delete Carrier ProfileDCPXXX good Query Carrier ProfileQCPXXX good Add Event ProfileAEPN/A - Delete Event ProfileDEPN/A- Query Event ProfileQEPN/A- Service Package Create Service PackageCSPXXX good Delete Service PackageDSPXXX good Select Alternate ScenarioSASXN/A- Apply New TrajectoryANTXN/A- Query Service PackageQSPXXX good Replace Service PackageRSPXN/A- Service Package CancelledSPCXXX good Service Package ModifiedSPMN/A- Table 4-2 result of Interface test

2008 Spring CCSDS meeting ( Washington, USA ) SMWG Security This section shows the method of security implementation from the technical point of view, and these was based on the agreement between JAXA/Tsukuba and JPL. a. SCOPE JAXA suggested an assumption to satisfy the following items. spoofing defacing sniffing At first we considered within the range of W3C of Recommendation (red-1) appendix, based on that conditions, and we proposed the following coverage of security in the prototype. ItemsImplementContent of security Security (i.e. Encryption, Digital Signature) not applyAll parameters are to be written in the attached file, and any parameter information is not set to the mail text at all. XML Encryption Syntax and Processing applyXML is encrypted using AES128 and RSA (Ver. 1.5). The data leakage to the third person can be prevented by the encryption. As it is not possible to decrypt by the third person, the defacing and the spoofing can be prevented. The public keys are exchanged each other beforehand. XML Signature Syntax and Processing not apply XML Key Management Specification not apply Table 4-3 Implementation of Encryption

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 12 b. IMPLEMENTATION FOR XML ENCRYPTION In the XML encryption, the following methods were used. XML data was encrypted using Symmetric Key. The encrypt key was generated by AES128 (128bit of the AES method) at every XML making. The encrypt key was wrapped by using the public key (RSA version 1.5) which were exchanged each other beforehand, and was stored in KeyInfo. The Key Encrypted Key (KEK) was mutually generated as a symmetric key beforehand. Only public keys were exchanged each other beforehand. The receiver decrypts using a private key. Figure 4-1 Exchange of “ Public Key ”

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 13 Sender 1.Generate symmetric key (AES 128). 2.“Cipher Data” was encrypted by using “Encrypt Key” from XML data. 3.“KeyInfo” was encrypted by using receiver’s “Public Key” from “Encrypt Key”. 4.“Encrypted XML” was generated from “CipherData” and “KeyInfo”. Receiver 5.“KeyInfo” and “Cipher Data” were detected from received “Encrypted XML”. 6.“Encrypt Key” was decrypted by using “Private Key” from “KeyInfo”. 7.XML data was decrypted from “Cipher Data” by using “Encrypt Key”. Figure 4 ‑ 2 Process Flow of Encrypted XML data Exchange

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 14 c. SCOPE OF XML ENCRYPTION In the XML encryption, the scope of encryption was all items excluded SleSmDocument and SleSmMessageSet. Both items of SleSmDocument and SleSmMessageSet were not encrypted in order to make the access control efficient. This section shows the samples of encryption, in which the name space and the contents of data are omitted. NOTE: Apache XML security was used in the prototype as a middleware for encryption. We encrypted in the prototype by the form that didn't omit “xenc”, because it was necessary for the name space of the encryption tag in apache XML security. The version of Apache XML security which were used in JAXA/TACC and NASA/JPL was

2008 Spring CCSDS meeting ( Washington, USA ) SMWG UMR-1 SA1 : 1) For Invocation, Acknowledgement, Successful return and Failed return UMR-1 SA1 :

2008 Spring CCSDS meeting ( Washington, USA ) SMWG : 2) For sleSmExceptionResponse : NOTE: The sleSmExceptionResponse.unrecoginzedMessageSetResponse was not encrypted, considering the case that the receiver did not recognize the sender or the service agreement was not recognized. The sleSmExceptionResponse.invalidMessageResponse was encrypted.

2008 Spring CCSDS meeting ( Washington, USA ) SMWG Data Compression ATP operation went out of control by limiting data communication at JAXA since volume of the OEM, which was exchanged at ATP operation, was a large amount of data (this time it was greater than 5 Mbytes). Therefore, we conducted data compression of the OEM to reduce the data volume. This section shows the method of data compression which was used for transmission of the much volume data between JAXA/Tsukuba and JPL. a. DATA TYPE The following data was always compressed between JAXA/Tsukuba and JPL. Data Type:Trajectory Prediction Message Type:Orbit Data Message ODM Type: Orbit Ephemeris Message (OEM) File Type:Text SM operation:Add Trajectory Prediction (ATP) b. IMPLEMENTATION FOR DATA COMPRESSION JAXA/UMR-1(UM) stored the OEM text into bilateralTrajectoryData of ATP invocation. bilateralTrajectoryFormatId: ZipOEMTxt Compress: Zip Encodeing : Base64

2008 Spring CCSDS meeting ( Washington, USA ) SMWG Test Result 4-2. Test Tracking Test Tracking was scheduled from End of February in This testing was performed with DSN network and Test facilities. The desired time for testing is shown in the table 4-4. Test CaseOperationsTimeDateResult Test Case 1Service Management Feb 28, 2008 (DOY059) succeeded Transfer Service *1Mar 1, 2008 (DOY061) succeeded Test Case 2Service Management Feb 28, 2008 (DOY059) Succeeded Transfer Service *1Mar 3, 2008 (DOY063) Succeeded Test Case 3Service Management Mar 3, 2008 (DOY063) Succeeded Transfer Service *1Mar 6, 2008 (DOY066) succeeded Table 4-4 Test Tracking Result NOTE: *1) The start/end time were the duration from BOA(=BOT-45min.) to EOA(=EOT+15min).

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 19 Date Resource Feb 28Feb 29Mar 1Mar 2Mar 3Mar 4Mar 5Mar 6 DOY 059DOY 060DOY 061DOY 062DOY 063DOY 064DOY 065DOY 066 SLE-SM DSN Pass SLE Transfer (Only RAF) Test Case 1 Test Case 2 Test Case 3 Pass#1 Trk#1Trk#2 Acq#1 Acq#2 Pass#2 Trk#3 Acq#3 Pass#3 Trk#4 Acq#4 6 Oprs 2 Oprs Figure 4-3Test Tracking TIMELINE

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 20 ACP Test Case Resource SLE-SM CSSXP(JPL) DSN Pass Test Case 1 QSAATP UMR-1(JAXA) CSP SLE Transfer (Only RAF) Feb 28(DOY 059) Pass-1 TDS(JPL) JAXA/Sagamihara March 1(DOY 061) ACP TransferService ServiceUse BOABOT 13:00 EOT 15:00 EOA SpaceLink Acquisition #1 Pass#1 Figure 4-4Test case 1 TIMELINE

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 21 Test Case Resource SLE-SM CSSXP(JPL) DSN Pass Test Case 2 SpaceLink TransferService UMR-1(JAXA) CSP SLE Transfer (Only RAF) Pass-23 TDS(JPL) JAXA/Sagamihara TransferService ServiceUse Feb 28(DOY 059)March 3(DOY 063) Acquisition #23 BOABOT 13:00 EOT 14:35 EOA Pass#2 Figure 4-5Test case 2 TIMELINE

2008 Spring CCSDS meeting ( Washington, USA ) SMWG 22 Test Case Resource SLE-SM CSSXP(JPL) DSN Pass Test Case 3 ATP UMR-1(JAXA) CSP SLE Transfer (Only RAF) Pass-3 TDS(JPL) JAXA/Sagamihara Mar 4 (DOY 064)March 6(DOY 066) TransferService ServiceUse TransferService ServiceUse BOABOT 20:50 EOT 21:04 BOT 21:47 EOT 22:15 EOA SpaceLink Acquisition #31 Acquisition #42 Pass#3 The occultation UMR-1 generated two acquisition requests in one service package for SELENE operation. Figure 4-6Test case 3 TIMELINE