1. Network Layer Security Howie Weiss (NASA/JPL/Cobham Analytic Solutions) Mike Pajevski (NASA/JPL) May 2010

2. 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.

3. What is Network Layer Security?
Space extensions to FTP
SCPS-FP
FTP
Features
FTP
Other Apps
Space extensions to the Socket Interface
SCPS-TP “TCP
Tranquility”
options
TCP
Options
TCP
UDP
Space-optimized
IPSec variant
SCPS-SP
IPSec
Common Network-
Layer 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

4. 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

5. 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

6. 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?

7. 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?

8. 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?