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


  • 90 Views
  • 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

Agenda

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)


  • Login