Network Layer Security

Download Report

Transcript Network Layer Security

Network Layer Security
Howie Weiss
(NASA/JPL/Cobham Analytic Solutions)
Mike Pajevski
(NASA/JPL)
October 2009
1
Agenda
• Review slides from Colorado Springs
– What is network layer security?
– Benefits of network layer security
– CCSDS approaches to network layer security
• Decide on an approach for a CCSDS network layer security
standard.
2
Space extensions
to FTP
Space extensions
to the Socket
Interface
SCPS-TP
“TCP
Tranquility”
options
SCPS-FP
What is Network Layer Security?
FTP
Features
TCP
Options
Space-optimized
IPSec variant
Other Apps
FTP
TCP
SCPS-SP
UDP
IPSec
Common NetworkLayer Interface
Space-optimized
IP variant
SCPS-NP
IP
Space Link Subnet: CCSDS Data Link
The CCSDS protocol suite supports either “native” or “space enhanced” Internet services,
at the discretion of the Project organization
3
Benefits of Network Layer
Security
• “Value-Added” network security
– Implement and certify (security-wise) once
– All upper layer applications are not aware of it
• Routable in an IP environment
– Underlying IP network is unaffected
• Saves cost and schedule
– Implement once vs. at each application
– Certify once vs. for each application
– Ensures correctness of implementation (done once with
great scrutiny)
• End-to-End Protection
4
Drawbacks of Network Layer Security
• No fine-grained access control
– Provides “all-or-nothing” access to a networked service
(e.g., cannot control which file(s) can be accessed)
• Increased overhead (vs. link layer security)
– Really a protocol-specific issue
» A protocol with low bit overhead is possible
• More complex management (vs. link layer security)
– Depends on flexibility of the protocol
» A link layer solution could be just as complex
• Does not support non-network based communications
• Can impair some QoS, header compression, and smart
routing techniques
5
CCSDS Approaches
• Do we care? YES
• Assuming we do care:
– Adopt IPsec? (Constellation has already done so)
» ESP (RFC 4303)
» AH (RFC 4302)
» Both?
– Re-do/repair SCPS-SP? NO – decide at last mtg.
» Min 2 byte overhead vs. 10 bytes for IPSec
» Do we care about 64 extra bits/packet given the
prevailing links?
6
Next Steps?
• Should the Security WG take this on as a new program
of work?
• How should we approach this?
– Study?
– Just adopt IPsec?
» Any constraints/extensions needed?
» KM (aka IKE or others)
– Repair SCPS-SP?
– Write a new protocol?
– Go home and call it a day? 
Conclusion: study IPSec and KM to start off and we’ll
see where we go from there. What are the possible
scenarios, interoperability use cases?
7
Network Layer Security Directions
• IPSec is the current Internet international (IETF) standard
– Two parts: ESP (encrypted + authenticated), AH
(authenticated-only).
– Do we want/need both?
» AH was developed to counter export control issues.
» There has been several attempts to deprecate it.
» Pro: it covers more of the header for integrity than does
ESP w/integrity
– Lots of off-the-shelf implementations.
• SCPS-SP
– Its still an international standard (ISO via CCSDS)
– Flawed wrt integrity
– Lower overhead than IPSec
– No off-the-shelf implementations unlike IPSec
• KM issues
– IKE vs. manual key?
8