network layer security howie weiss nasa jpl sparta cobham parsons boulder co november 2011
Download
Skip this Video
Download Presentation
Agenda

Loading in 2 Seconds...

play fullscreen
1 / 21

Agenda - PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Agenda ' - mabyn


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

agenda
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
what is network layer security
What is Network Layer Security?

Space extensions to FTP

Other Apps

SCPS-FP

FTP

Features

FTP

Space extensions to the Socket Interface

SCPS-TP “TCP

Tranquility”

options

TCP

Options

TCP

UDP

Space-optimized

IPSec variant

IPSec

SCPS-SP

IKE

Common Network-

Layer Interface

Space-optimized

IP variant

IP

SCPS-NP

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

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)

110010110010011100110110

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
compression
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
summary
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)
ad