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 CCSDS Satellite R2 Receive 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.2 192.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 parameters Category Primary Options Modes Protocol 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