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