CCSDS IPsec Compatibility Testing 10/28/2013 OKECHUKWU 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 Router Ground Station R1 Cisco 3825 Router CCSDS Satellite R2 Cisco 3825 Router Receive Station R3 GE 0/ GE 0/ GE 0/ GE 0/ GE 0/ GE 0/ 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 parameters CategoryPrimaryOptions Modes 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 V4V6 IPCOMP YESNO 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