1 / 22

CCSDS Service Management Validation Test Quick Report

CCSDS Service Management Validation Test Quick Report. 12. March 2008 JAXA YAGI Nobuhiro/SUZUKI Kiyohisa. Contents.

tuyet
Télécharger la présentation

CCSDS Service Management Validation Test Quick Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CCSDS Service Management Validation Test Quick Report 12. March 2008 JAXA YAGI Nobuhiro/SUZUKI Kiyohisa

  2. Contents 1 Background2 Objectives3 Test Procedure 3-1 Interface Test 3-2 Test Tracking 4 Test Result 4-1 Interface Test 4-1-1 Security 4-1-2 Data Compression 4-2 Test Tracking

  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, 2006. • 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 assuredand 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

  4. J PL J AXA/T s ukuba a SLE SM SLE SM Internet Service - provider Service - user Prototype Prototype (CSSXP) (UMR - 1) SLE - SM message exchanged by SMTP 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 theservice-provider prototype and the service-user prototype. -SPACE LINK EXTENSION SERVICE MANAGEMENT SERVICE SPECIFICATION (CCSDS 910.11-R-1) -Service Management Schema File Set V 0.3.0.P1 Figure 3-1 Interface TEST Configuration

  5. Table 3-1 difference of Implemented service management operations and Interface test operations

  6. 3-2. 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.

  7. Figure 3-2 Test Tracking Configuration

  8. Table 3-2 difference of Implemented service management operations and Test tracking operations

  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 e-mails using the protocol SMTP between UMR-1 and CSSXP. • The rules of exchanged e-mails are as follows: Table 4‑1 Rules of E-mail Structure

  10. Table 4-2 result of Interface test

  11. 4-1-1 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. Table 4-3 Implementation of Encryption

  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”

  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

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

  15. 1) For Invocation, Acknowledgement, Successful return and Failed return <sleSmDocument> <sleSmVersionRef>0.3.0</sleSmVersionRef> <sleSmMessageSet> <sleSmCreatorName>UMR-1</sleSmCreatorName> <serviceAgreementRef>SA1</serviceAgreementRef> <createServicePackageInvocation> : : </createServicePackageInvocation> </sleSmMessageSet> </sleSmDocument> <sleSmDocument> <sleSmVersionRef>0.3.0</sleSmVersionRef> <sleSmMessageSet> <sleSmCreatorName>UMR-1</sleSmCreatorName> <serviceAgreementRef>SA1</serviceAgreementRef> <xenc:EncryptedData> : : </xenc:EncryptedData> </sleSmMessageSet> </sleSmDocument>

  16. 2) For sleSmExceptionResponse <sleSmDocument> <sleSmVersionRef>0.3.0</sleSmVersionRef> <sleSmExceptionResponse> : : </sleSmExceptionResponse> </sleSmMessageSet> </sleSmDocument> <sleSmDocument> <sleSmVersionRef>0.3.0</sleSmVersionRef> <xenc:EncryptedData> : : </xenc:EncryptedData> </sleSmMessageSet> </sleSmDocument> 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.

  17. 4-1-2 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 wasused 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

  18. 4. Test Result 4-2. Test Tracking Test Tracking was scheduled from End of February in 2008. This testing was performed with DSN network and Test facilities. The desired time for testing is shown in the table 4-4. Table 4-4 Test Tracking Result NOTE: *1) The start/end time were the duration from BOA(=BOT-45min.) to EOA(=EOT+15min).

  19. Test Case 3 Test Case 1 2 Oprs 6 Oprs Test Case 2 2 Oprs Acq#2 Acq#1 Acq#3 Acq#4 Pass#2 Pass#3 Pass#1 Trk#3 Trk#4 Trk#1 Trk#2 Figure 4-3 Test Tracking TIMELINE

  20. Test Case Resource Test Case 1 Feb 28(DOY 059) March 1(DOY 061) SLE-SM Pass-1 UMR-1(JAXA) ACP QSA ATP CSP ACP ACP CSSXP(JPL) DSN Pass BOA BOT 13:00 EOT 15:00 EOA Acquisition #1 Pass#1 SpaceLink TransferService SLE Transfer (Only RAF) JAXA/Sagamihara ServiceUse TDS(JPL) TransferService Figure 4-4 Test case 1 TIMELINE

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

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

More Related