Reason for SBIR - Tolerant Systems

Download Report

Transcript Reason for SBIR - Tolerant Systems

Randomized Failover Intrusion
Tolerant Systems (RFITS)
Ranga Ramanujan
Architecture Technology Corporation
Odyssey Research Associates
DARPA OASIS PI Meeting
July 24, 2001
Architecture Technology Corporation
Specialists in Computer Architecture
1
Background - Research Goals
ASP 1
Priv ate Virtual Network
10.1.x.x

Develop and
demonstrate
organic
survivability
techniques for
mission-critical
GIG applications

Focus on network
borne DDoS
attacks
• packet
flooding
• host takedown
10.1.1.x sub-net
ASP 2 Netw ork
10.1.2.x sub-net
Shared IP Backbone Netw ork
ASP 3 Netw ork
10.1.3.x sub-net
2
Background - RFITS Approach
ASP 1
Priv ate Virtual Network
10.1.x.x

10.1.1.x sub-net
ASP 2 Netw ork

10.1.2.x sub-net
Shared IP Backbone Netw ork
ASP 3 Netw ork
10.1.3.x sub-net
Attacker needs
knowledge of
• vulnerabilities
• choke points
• system
“posture”
Randomized
failover makes
prediction of
system posture
difficult
• buys sufficient
time for attack
neutralization to
be accomplished
3
Status

Completed and delivered RFITS Applications
Handbook
• Compilation of survivability design patterns
• Primarily targeted towards two kinds of
middleware services
– Survivable information transport services (SITS)
– Survivable server groups (SSG)


Commenced prototype implementation of
selected RFITS techniques
This presentation focuses on subset of SITS
techniques
4
SITS Technique #1
Spoofers
X1
C1
X2
R5
C2
R6
R4
R7
R2
R3
R1
R
S
Applicability
- Protects many-to-one
and one-to-one information
flows against DDoS
attacks
Attacks addressed
- spoofed packet floods
Assumptions
- A priori security
association exists between
end points
- Attack traffic generated
by outsiders
Technique chokes off attack
traffic as close as possible
to the source
5
SITS Technique #1 (Cont’d)
Spoofers
X1
C1
X2
R5
C2
R6
R4
R7
R2
R3
R1
R
S
- Destination S can only
be reached via IP
multicast address, say M1
- Using RSVP, router R1
configured to filter out all
downstream traffic except
multicast packets
- Upon detecting a
flooding attack, S
switches to a new
multicast address M2 and
securely notifies clients; it
also de-registers from M1
- Clients send packets to
M2; spoofed traffic goes
to M1and is filtered out at
R5 and R6
6
SITS Technique #2
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
MC Group
MC Group
MC Group
MC Group
MC Group
MC Group
MC Group
MC Group
Server

Protects many-to-one information flows
against attack traffic generated by
insider
7
SITS Technique #2

Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
MC Group
MC Group
MC Group
MC Group
MC Group
MC Group
MC Group
MC Group
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
Client
Group
MC Group
MC Group
MC Group
MC Group
MC Group
MC Group
MC Group
Server


Clients partitioned
among multiple
multicast channels
Upon detection of a
flooding attack,
suspect group is repartitioned among
new multicast
channels
Enables isolation
and choking off of
attack traffic close to
source
8
SITS Technique #3
Spoofers
X1
C1
X2
R5
C2
R6
R4
R7
R2
R3
R1
R
S
- Variant of technique #1
- Uses source selective multicast
(SSM) to conserve multicast
addresses
- S selects sources C1 and C2 for
its address M1
- Using RSVP, router R1
configured to filter out all
downstream traffic except
multicast packets from C1 and C2
- Upon detecting a flooding
attack, C1 and C2 reconfigured
with new source addresses
- S associates M1 with new
addresses of C1, C2
- Using RSVP, R1 is configured
9
with new filters for C1,C2
SITS Technique #4

Spoofers

X1
C1
X2
R5
C2
R6
R4
R7
R2
R3
R1

R
S
Variant of technique #3
Uses unicast destination
addresses instead of
multicast addresses
•
Can be deployed on
today’s Internet; not
dependent on
widespread deployment
of IP multicast
However, unlike technique
#3, filters attack traffic at
R1 instead of close to the
source at R5 and R6
10
VPN Gateway Prototype
Enterprise-Wide Private
Network
Public Internet
10.10.1.x subnet
ISP Router
VPN Gatew ay 1


10.10.2.x subnet
ISP Router
VPN Gatew ay 2
Interconnects geographically distributed sub-nets of an enterprise-wide private network
using secure, DoS-resistant VPNs
Implementation status
• Unit testing of VPN gateway software completed; integration testing in progress
• Initial release of prototype to be completed by Sept. 1, 2001
• Final release scheduled for December 2001
11
Planned Prototyping Effort

Initial RFITS Prototyping - Dec. 2001
• Standalone demonstration of prototype
products implementing RFITS survivability
techniques
– RFITS VPN Gateway
– RFITS VPN Client

Final RFITS Prototyping - Sept. 2002
• Enterprise-wide survivable application using
integrated set of RFITS techniques
12