Network layer security howie weiss nasa jpl sparta cobham parsons boulder co november 2011
This presentation is the property of its rightful owner.
Sponsored Links
1 / 21

Agenda PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Network Layer Security Howie Weiss ( NASA/JPL/ SPARTA / Cobham /Parsons) Boulder, CO November 2011. Agenda. CCSDS Network Layer Security IPSec+IKE Profile for CCSDS What is included? What is excluded? How is it used ? Review WG results from Berlin meeting.

Download Presentation


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Network layer security howie weiss nasa jpl sparta cobham parsons boulder co november 2011

Network Layer SecurityHowie Weiss(NASA/JPL/SPARTA/Cobham/Parsons)Boulder, CONovember 2011



  • CCSDS Network Layer Security

    • IPSec+IKE Profile for CCSDS

      • What is included?

      • What is excluded?

      • How is it used?

  • Review WG results from Berlin meeting

What is network layer security

What is Network Layer Security?

Space extensions to FTP

Other Apps





Space extensions to the Socket Interface









IPSec variant




Common Network-

Layer Interface


IP variant



Space Link Subnet: CCSDS Data Link

Ipsec one protocol many options

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?

Issues to be resolved

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

Transport vs tunnel mode

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

Ipsec is two protocols

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

Ah packet format

AH Packet Format

AH (IP protocol 51)

total length 152 bytes

AH Authenticated (108 bytes)

Esp w null encryption

ESP w/Null Encryption

ESP (IP protocol 50)

total length 152 bytes

ESP Header

ESP Trailer

ESP Auth

ESP Authenticated (132 bytes)

Esp w aes gcm


ESP (IP protocol 50)

total length 160 bytes

Encrypted (128 bytes)

ESP Header

ESP Trailer

ESP Auth

ESP Authenticated (140 bytes)

Esp w aes gcm ah


AH (IP protocol 51)

total length 184 bytes

AH Authenticated (148 bytes)

Encrypted (128 bytes)

ESP Header

ESP Trailer

ESP Auth

ESP Authenticated (140 bytes)

Esp and or ah

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

Security services allowed

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



  • 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

Internet key exchange ike

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

Ike operation

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


Manual keying

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)


Policy management

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?

Cipher suite

Cipher Suite

  • Follow CCSDS Algorithms document

    • 128-bit key size

    • AES

    • AES-GCM for authenticated encryption

    • AES-CMAC, AES-GMAC, HMAC for authentication/integrity



  • 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



  • 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)

  • Login