1. CCSDS IPsec Compatibility Testing
10/28/2013
OKECHUKWU MEZU
CHARLES SHEEHE CCSDS GRC POC

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

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

4. IPsec draft test topology
Cisco 3825 Router
Ground Station R1
CCSDS Satellite R2
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)

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

6. Backup

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