CCSDS IPsec Compatibility Testing
10/28/2013OKECHUKWU MEZU
CHARLES SHEEHE CCSDS GRC POC
IPsec Project Overview
• Performing Encapsulating Security Payload (ESP) using pre-shared keys on a CCSDS Internet Protocol (IP) packet going from source node over a satellite in space to a destination node
• Why this is important– Two independent verifications of a specification are required prior to
acceptance– NASA GRC IPsec compatibility testing will satisfy one independent
tests– It will be recorded in the CCSDS yellow book as official documentation
of testing
• CCSDS IPsec testing expected start date November 2013
IPsec Project Process
• IPsec compatibility testing for CCSDS– Evaluate IPsec/CCSDS related standards– Define CCSDS/IPsec approved parameters by CCSDS working group– Develop Test Plan by working group– Approval of Test Plan by working group– Perform Compatibility Testing based on defined IPsec parameters– Validate Compatibility Testing results– Documentation of test results– Present result to CCSDS GRC working group– Present results to CCSDS working group
• Key deliverable– Test report in CCSDS format for inclusion in yellow book
IPsec draft test topology
Cisco 3825 RouterGround Station
R1
Cisco 3825 RouterCCSDS Satellite
R2
Cisco 3825 RouterReceive Station
R3
GE
0/0
192.
168.
1.1
GE
0/1
192.
168.
2.1
GE
0/0
192.
168.
2.2
GE
0/1
192.
168.
3.1
GE
0/1
192.
168.
4.1
GE
0/0
192.
168.
3.2
192.168.1.2192.168.4.2
IPsec VPN
Legend
GE – Gigabit Ethernet
Tunnel represents a direct logical connection between R1 & R3 through R2.
However, all communication between R1 & R3 go through R2 (representing a satellite/networked cloud)
Test plan parametersCategory Primary OptionsModes Tunnel Mode
Protocol ESP only
Security Services Allowed Authenticated encryption mode
Authentication only
Keying Automated keying: Internet Key Exchange
Manual key management
IKE Operation IKEv2 w/rekey commanding “button”
Cipher suite AES-256
Hash function SHA-2
IP Version V4 V6
IPCOMP YES NO
Fragmentation Yes/No/Size
Backup
Questions• Appendix D: Fragment Handling Rationale• • There are three issues that must be resolved regarding processing of• (plaintext) fragments in IPsec:• • - mapping a non-initial, outbound fragment to the right SA• (or finding the right SPD entry)• - verifying that a received, non-initial fragment is authorized• for the SA via which it is received• - mapping outbound and inbound non-initial fragments to the• right SPD/cache entry, for BYPASS/DISCARD traffic• • The first and third issues arise because we need a deterministic• algorithm for mapping traffic to SAs (and SPD/cache entries). All• three issues are important because we want to make sure that• non-initial fragments that cross the IPsec boundary do not cause the• access control policies in place at the receiver (or transmitter) to• be violated.• • • Conclusions• • • There is no simple, uniform way to handle fragments in all contexts.• Different approaches work better in different contexts. Thus, this• document offers 3 choices -- one MUST and two MAYs. At some point in• the future, if the community gains experience with the two MAYs, they• may become SHOULDs or MUSTs or other approaches may be proposed