1. 1 Network Layer Security: Status Update Howie Weiss (NASA/JPL/Parsons) Bordeaux, France April 2013

2. 2 Agenda What is an “Adaptation Profile?” CCSDS Network Layer Security – IPSec+IKE Profile for CCSDS » What is included? » What is excluded? » How is it used? Testing

3. 3 What is Network Layer Security? SCPS-NPIP Space Link Subnet: CCSDS Data Link SCPS-SP Other Apps IPSec UDPTCP SCPS-FP TCPOptionsTCPOptions FTP FTPFeaturesFTPFeatures Space extensions to the Socket Interface Common Network- Layer Interface SCPS-TP “TCP Tranquility” options Space-optimized IP variant Space-optimized IPSec variant Space extensions to FTP IKE

4. 4 Adaptation Profile Email “conversation” with Tom Gannett: – “I will be launching off to write an adaptation profile soon. Are there any worked examples of what this is within the CCSDS context? Or at a minimum, is there a template for what it should look like? Or is there Gannett advice on what to make it look like?” – “We have no templates, but Peter cites examples of his favorites in his boot camp slides (attached). My advice is to make it look like a Blue Book (which it will be).” – “Ok - I'll take a look. The intent was that it would be a blue book but I was wondering how it was to be structured.” – “Structure depends on content. If you have an outline of what is to be included, I can make recommendations about structure.” – “So, do we just use the IETF RFC as a normative reference and have a section that says here's where we differ from the RFC? Or do we have more "meat" and "detail?" The major piece of this work is the set of options we choose to support - nothing else changes. » I would say certainly the former. The less "meat" and "detail" in a Blue Book the better.”

5. 5 IPSec: one protocol, many options Tunnel mode vs. transport mode Default cipher suite (encryption + auth + mode) – Authenticated encryption? – Null encryption (authentication-only)? » ESP w/null encrypt or AH? – What would be allowed? Anti-replay option Keying and rekeying – Pre-placed keys? – IKE auto rekey » Automatic when keys expire – regardless of mission state? » Rekey “now” button?

6. 6 Issues to be resolved Transport or tunnel mode or both? – Tunnel mode ESP-only? AH-only? – ESP-only ESP + AH? – No Authentication-only w/o encryption allowed? (null encryption) – Yes Authenticated Encryption or Encryption w/o auth allowed? – AEAD Yes, warning that encryption-only is unsafe Keying and rekeying questions – Automated vs. manual » IKEv1 or IKEv2 IKEv2 w/rekey commanding “button” – Push-to-rekey – Push-to-inhibit rekey » Manual keying allowed – SA lifetimes Policy Management – Silent for now Define default cipher suite(s) – Follow algorithm document + IKE & IPsec RFCs Compression – Optional IPcomp

7. 7 Transport vs. Tunnel Mode Transport Mode: – Single IP header – End-to-End mode (writer-2-reader) – Not generally used commercially Tunnel Mode: – Dual IP headers – entire IP packet is encapsulated – Allows Gateway-to-Gateway mode » Allows IPSec to be outboard in security gateways » E.g., commercial VPNs Recommendation for CCSDS: – Tunnel Mode

8. 8 IPSec is TWO Protocols AH: IP Authentication Header (RFC 4302) – connectionless integrity – data origin authentication. – optional replay protection – No confidentiality ESP: Encapsulating Security Payload (RFC 4303) – confidentiality, – data origin authentication, – connectionless integrity, – anti-replay protection (w/automated key management), – limited traffic flow confidentiality. » Provides encryption-only service for confidentiality » Provides integrity-only service » Provides confidentiality + integrity service

9. 9 AH Packet Format IPv4 Header 20 bytes AH Header 24 bytes IPv4 Header 20 bytes ICMP Header 8 bytes ICMP Data 80 bytes Next Header =IPIP 1 byte Length (this header) 1 byte Pad 2 bytes AH SPI 4 bytes AH Seq # 4 bytes AH ICV 12 bytes AH (IP protocol 51) total length 152 bytes AH Authenticated (108 bytes)

10. 10 ESP w/Null Encryption ESP SPI 4 bytes ESP Seq # 4 bytes IPv4 Header 20 bytes ICMP (8 bytes hdr + 80 bytes data) 88 bytes Pad varies per RFC 2406 - in this example 2 bytes Pad Len 1 byte Next Hdr 1 byte Authentication Data varies: 8, 12,or 16 byte 12 bytes ESP Auth IPv4 Header 20 bytes ESP Null Encrypted Payload 132 bytes ESP (IP protocol 50) total length 152 bytes ESP HeaderESP Trailer ESP Authenticated (132 bytes)

11. 11 ESP w/AES-GCM IPv4 Header 20 bytes ESP AES128 Encrypted Payload 140 bytes ESP SPI 4 bytes ESP Seq # 4 bytes ESP IV 8 bytes IPv4 Header 20 bytes ICMP (8 bytes hdr + 80 bytes data) 88 bytes Pad varies per RFC 2406 - in this example 2 bytes Pad Len 1 byte Next Hdr 1 byte Authentication Data varies: 8, 12,or 16 bytes 12 bytes ESP (IP protocol 50) total length 160 bytes Encrypted (128 bytes) ESP Authenticated (140 bytes) ESP HeaderESP AuthESP Trailer

12. 12 ESP w/AES-GCM + AH AH Authenticated (148 bytes) IPv4 Header 20 bytes AH Header (ref AH format) 24 bytes ESP AES128 Encrypted Payload 140 bytes ESP SPI 4 bytes ESP Seq # 4 bytes ESP IV 8 bytes IPv4 Header 20 bytes ICMP (8 bytes hdr + 80 bytes data) 88 bytes Pad varies per RFC 2406 - in this example 2 bytes Pad Len 1 byte Next Hdr 1 byte Authentication Data varies: 8, 12, 16 bytes 12 bytes AH (IP protocol 51) total length 184 bytes Encrypted (128 bytes) ESP Authenticated (140 bytes) ESP HeaderESP AuthESP Trailer

13. 13 ESP and/or AH ? AH does not support confidentiality ESP supports both confidentiality and integrity – Supports null encryption AH was designed because of export control issues regarding encryption algorithms AH and ESP can be nested but why? – Too much overhead Recommendation for CCSDS: – ESP-only

14. 14 Security Services Allowed Authentication-only mode – CCSDS Recommendation: allow – Needed for commanding w/o need for confidentiality Authenticated Encryption mode – CCSDS Recommendation: allow (must) – Encryption w/o authentication is shown to be a dangerous practice Non-authenticated Encryption mode – CCSDS Recommendation: unsafe, not recommended – Operational overhead and mission risk analysis may have need for this but it should not be done without analysis

15. 15 Keying Conformant IPSec must support BOTH automated and manual keying – Automated keying: Internet Key Exchange – Manual keying: ad-hoc (each implementation determines how) Issues regarding automated keying: – Rekey at “bad” time in the mission timeline » E.g., critical burn maneuver » E.g., critical upload/download – Requires little human intervention Issues regarding manual keying: – “simple” but requires human resources – Physical distribution and protection required

16. 16 Internet Key Exchange (IKE) IKE v1 (RFC 2409) – Complicated, robust protocol – Commercially widely used IKE v2 (RFC 4306) – Simpler than IKEv1 (maybe safer…) – Commercially not widely used, yet. Requires on-board flight code – More flight code to certify » But do it once and reuse, reuse, reuse

17. 17 IKE Operation IKE rekeys when thresholds are met, for example: – Number of bytes transmitted – Elapsed time For space, IKE Rekey-Upon-Command is needed – E.g., button-push to rekey – E.g., button-push to inhibit rekey For space, timers will have to be tweaked vs. commercial (terrestrial) implementations Recommendation for CCSDS: – IKEv2 w/rekey commanding “button” » Push-to-rekey » Push-to-inhibit rekey

18. 18 Manual Keying Sometimes simple is enough…. Need ability to preload keys (e.g., 512 keys, 1024 keys) onboard – Maybe have a key upload ability? Command to change keys Preload and manage Security Associations (SA) Recommendation for CCSDS: – Require manual key w/management (testing, ground checkout) 110010110010011100110110

19. 19 Policy Management IPSec supports policies, e.g.: – Security services on a connection – Access controls for connection No standards for loading, updating, supporting IPSec policies – SNMP-based approaches: » RFC 4807: IPSec Security Policy Database Configuration MIB » IPSec Security Policy IPSec Action MIB (IETF draft) » IPSec Security Policy IKE Action MIB (IETF draft) – Microsoft IPSec Policy Agent Service – KeyNote, ipsecconf, proprietary, etc What do we want to do?

20. 20 Cipher Suite Follow CCSDS Algorithms document – 128-bit key size – AES – AES-GCM for authenticated encryption – AES-CMAC, AES-GMAC, HMAC for authentication/integrity

21. 21 Compression Overhead vs. Bandwidth! – IPSec adds overhead – Everyone complains about not having enough bandwidth IP Payload Compression Protocol (IPComp) (RFC 3173) – Commercially supported – Compresses IP datagrams BEFORE security processing on outbound – Decompresses IP datagrams AFTER security processing on inbound Recommendation for CCSDS: – Optional use of IPComp

22. 22 Summary IPSec: ESP-only Null encryption allowed Authenticated encryption – Non-authenticated encryption unsafe IKEv2 w/rekey button Manual keying w/management Policy management needed - ? Cipher suites follow algorithms blue book Compression (IPComp)

23. 23 Testing New policy: when adding a new Blue Book project all resources including testing must be included. Call to Working Group for testing volunteers: – NASA Glenn Research Center has volunteered. Any others?