1 ITS-ZeeWave Meeting 2/26/2004 UCCS Chow C. Edward Chow Department of Computer Science University...
-
Upload
rodger-houston -
Category
Documents
-
view
218 -
download
0
Transcript of 1 ITS-ZeeWave Meeting 2/26/2004 UCCS Chow C. Edward Chow Department of Computer Science University...
1ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
C. Edward Chow
Department of Computer ScienceUniversity of Colorado at Colorado Springs
C. Edward Chow
Department of Computer ScienceUniversity of Colorado at Colorado Springs
Network and Wireless Security Network and Wireless Security
Part of this work is based on research sponsored by the Air Force Research Laboratory, under agreement number F49620-03-1-0207. It was sponsored by NISSC
Summer/Fall2003 grants.
2ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Outline of the TalkOutline of the Talk Overview of Network/Wireless Security Research Projects of Network/System Lab
Secure Collective Internet Defense (SCOLD)– Modified Bind9 server and Secure DNS update with new DNS entries
containing multiple indirect routing info– Implemented Secure Indirect Routing Protocol
Autonomous Anti-DDoS (A2D2)– Integrated enhanced Snort IDS with multi-level adaptive rate limiting firewall– Design enterprise IDS/IHS with IDIP.
Secure Groupware for First Responders (SGFR)– Integrated Group Rekeying with Instant Massaging– Run on Linux-based IPAQ/Palmtop with MANET.
Secure Mobile Ad Hoc Network (SMANET) – Implemented PEAP module on freeRadius server– Compared performance of PEAP vs. TTLS– Investigate how to defense cyber attacks on MANET.
First Responder Sensor Network (FRSN)– Track Fire Fighters with Crossbow Mote-based Sensor Network.– Design Interface between SMANET and FRSN.
Overview of Network/Wireless Security Research Projects of Network/System Lab Secure Collective Internet Defense (SCOLD)
– Modified Bind9 server and Secure DNS update with new DNS entries containing multiple indirect routing info
– Implemented Secure Indirect Routing Protocol Autonomous Anti-DDoS (A2D2)
– Integrated enhanced Snort IDS with multi-level adaptive rate limiting firewall– Design enterprise IDS/IHS with IDIP.
Secure Groupware for First Responders (SGFR)– Integrated Group Rekeying with Instant Massaging– Run on Linux-based IPAQ/Palmtop with MANET.
Secure Mobile Ad Hoc Network (SMANET) – Implemented PEAP module on freeRadius server– Compared performance of PEAP vs. TTLS– Investigate how to defense cyber attacks on MANET.
First Responder Sensor Network (FRSN)– Track Fire Fighters with Crossbow Mote-based Sensor Network.– Design Interface between SMANET and FRSN.
3ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Intrusion Related Research AreasIntrusion Related Research Areas
Intrusion PreventionGeneral Security Policy Ingress/Egress Filtering
Intrusion DetectionHoney potHost-based IDS Tripwire Anomaly DetectionMisuse Detection
Intrusion Response Identification/Traceback/PushbackIntrusion Tolerance
Intrusion PreventionGeneral Security Policy Ingress/Egress Filtering
Intrusion DetectionHoney potHost-based IDS Tripwire Anomaly DetectionMisuse Detection
Intrusion Response Identification/Traceback/PushbackIntrusion Tolerance
4ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Wouldn’t it be Nice to Have Alternate Routes?Wouldn’t it be Nice to Have Alternate Routes?
DNS1
...
Victim
AA A A A A A A
net-a.mil net-b.mil net-c.mil
DNS2 DNS3
... ......
R R R
R
R2 R1R3
Alternate Gateways
DNS
DDoS Attack Traffic
Client Traffic
How to reroute clients traffic through R1-R3?
Multi-homing
5ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Secure Collective DefenseSecure Collective Defense Main IdeaExplore secure alternate paths for clients to come in; Utilize geographically
separated proxy servers. Goal:
Provide secure alternate routes Hide IP addresses of alternate gateways
Techniques: Multiple Path (Indirect) Routing Enhanced Secure DNS extension: how to inform client DNS servers to add new DNS
entries with alternate routes (Not your normal DNS name/IP address mapping entry). Utilize a consortium of Proxy servers with IDS that hides the IP address of alternate
gateways. Partition clients to come in at different proxy servers.
can help identify the origin of spoofed attacks! How clients use the new multiple path indirect DNS entries and route traffic through
proxy servers? Use Sock protocol, modify resolver library
6ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Implement Alternate RoutesImplement Alternate Routes
DNS1
...
Victim
AA A A A A A A
net-a.mil net-b.mil net-c.mil
DNS2 DNS3
... ......
R R R
R
R2 R1R3
Alternate Gateways
DNS
DDoS Attack Traffic
Client Traffic
Need to Inform Clients or Client DNS servers!
But how to tell which Clients are not compromised?
How to hide IP addresses of
Alternate Gateways?
7ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Possible Solution for Alternate RoutesPossible Solution for Alternate Routes
DNS1
...
Victim
AA A A A A A A
net-a.mil net-b.mil net-c.mil
DNS2 DNS3
... ......
R R R
R R2R1 R3
New route via Proxy3 to R3
Proxy1
block
Proxy3Proxy2
Attack msgs blocked by IDSBlocked by IDS
Sends Reroute Command with DNS/IP Addr. Of
Proxy and VictimDistress Call
8ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SCOLDPhase1SCOLDPhase1
DNS1
...
Victim
AA A A A A A A
net-a.mil net-b.mil net-c.mil
DNS2 DNS3
... ......
R R R
R
Proxy1
Proxy2Proxy3
R2
R1 R3
block
RerouteCoordinato
rAttack TrafficClient Traffic
1. IDS detects intrusion Blocks Attack Traffic Sends distress call to Reroute Coordinator
block
9ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SCOLDPhase 2SCOLDPhase 2
DNS1
...
Victim
AA A A A A A A
net-a.mil net-b.mil net-c.mil
DNS2 DNS3
... ......
R R R
R
Proxy1
Proxy2 Proxy3
R2
R1 R3
block
Attack TrafficClient Traffic
1. IDS detects intrusion Blocks Attack Traffic Sends distress call to Reroute Coordinator
RerouteCoordinato
r
2. Sends Reroute Command with (DNS Name, IP Addr. Of victim,
Proxy Server(s)) to DNS
10ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SCOLDPhase3SCOLDPhase3
DNS1
...
Victim
AA A A A A A A
net-a.mil net-b.mil net-c.mil
DNS2 DNS3
... ......
R R
R
Proxy1
Proxy2 Proxy3
R2
R1 R3
Attack TrafficClient Traffic
RerouteCoordinato
r
2. Sends Reroute Command with (DNS Name, IP Addr. Of victim,
Proxy Server(s)) to DNS
3. New route via Proxy3 to R3
3. New route via Proxy2 to R2
3. New route via Proxy1 to R1
R
block
11ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SCOLDPhase4SCOLDPhase4
DNS1
...
Victim
AA A A A A A A
net-a.mil net-b.mil net-c.mil
DNS2 DNS3
... ......
R
Proxy1
Proxy2Proxy3
R1
Attack TrafficClient Traffic
RerouteCoordinato
r
3. New route via Proxy3 to R3
3. New route via Proxy2 to R2
3. New route via Proxy1 to R1
R
block4a. Attack traffic detected by IDSblocked by Firewall
4. Attack traffic detected by IDSblocked by Firewall
R R
R3R2
12ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SCOLD Secure DNS Updatewith New Indirect DNS EntriesSCOLD Secure DNS Update
with New Indirect DNS Entries
(target.targetnet.com, 133.41.96.7, ALT 203.55.57.102)
203.55.57.103185.11.16.49
A set of alternate proxy servers for indirect routes
New DNS Entries:
Modified
Bind9
Modified
Bind9IP Tunnel
IP Tunnel
Modified
ClientResolveLibrary
Trusted DomainWAN
DMZ
ClientDomai
n
proxy2
13ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SCOLD Indirect RoutingSCOLD Indirect Routing
IP tunnelIP tunnel
14ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SCOLD Indirect Routing with Client running SCOLD client daemon
SCOLD Indirect Routing with Client running SCOLD client daemon
IP tunnelIP tunnel
15ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Performance of SCOLD v0.1Performance of SCOLD v0.1
Table 1: Ping Response Time (on 3 hop route)
Table 2: SCOLD FTP/HTTP download Test (from client to target)
Table 1: Ping Response Time (on 3 hop route)
Table 2: SCOLD FTP/HTTP download Test (from client to target)
No DDoS attack, direct route
DDoS attack, direct route
No DDoS attack, indirect route
with DDoS attack indirect route Doc
Size
FTP HTTP FTP HTTP FTP HTTP FTP HTTP 100k 0.11 s 3.8 s 8.6 s 9.1 s 0.14 s 4.6 s 0.14 s 4.6 s 250k 0.28 s 11.3 s 19.5 s 13.3 s 0.31 s 11.6 s 0.31 s 11.6 s 500k 0.65 s 30.8 s 39 s 59 s 0.66 s 31.1 s 0.67 s 31.1 s 1000k 1.16 s 62.5 s 86 s 106 s 1.15 s 59 s 1.15 s 59 s 2000k 2.34 s 121 s 167 s 232 s 2.34 s 122 s 2.34 s 123 s
No DDoS attack direct route
DDoS attackdirect route
No DDoS attack indirect route
DDoS attack indirect route
0.49 ms 225 ms 0.65 ms 0.65 ms
16ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Current SCOLD Project ResultsCurrent SCOLD Project Results
Proposed new DNS entries for intrusion tolerance, containing multiple proxy servers info for establishing indirect routes.
Modified Bind9 DNS server to accept secure DNS updates and to serve queries with new indirect DNS entries.
Developed new secure DNS update utility to securely update target zone file in the new enhanced Bind9 DNS server.
Implemented new secure indirect routing protocol to allow client DNS to query target DNS during DDoS attack. to allow client to communicate with target server through proxy
server and alternate gateway.
Proposed new DNS entries for intrusion tolerance, containing multiple proxy servers info for establishing indirect routes.
Modified Bind9 DNS server to accept secure DNS updates and to serve queries with new indirect DNS entries.
Developed new secure DNS update utility to securely update target zone file in the new enhanced Bind9 DNS server.
Implemented new secure indirect routing protocol to allow client DNS to query target DNS during DDoS attack. to allow client to communicate with target server through proxy
server and alternate gateway.
17ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Benefits of Secure Collective DefenseBenefits of Secure Collective Defense
Security When attacked, users switch to different routes dynamically Urgent/critical packets sent over multiple routes simultaneously Encrypted content sent over multiple routes Information on DDoS attacks used to isolate source of attacks
Reliability: Users can choose most reliable route dynamically Packet content spread over multiple routes Use redundant transmission or error correction to reduce PLR
Performance: Multiple indirect routes provide additional bandwidth Can be used for dynamic bandwidth provisioning
Security When attacked, users switch to different routes dynamically Urgent/critical packets sent over multiple routes simultaneously Encrypted content sent over multiple routes Information on DDoS attacks used to isolate source of attacks
Reliability: Users can choose most reliable route dynamically Packet content spread over multiple routes Use redundant transmission or error correction to reduce PLR
Performance: Multiple indirect routes provide additional bandwidth Can be used for dynamic bandwidth provisioning
18ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
A2D2: Autonomous Anti DDoSA2D2: Autonomous Anti DDoS Main Idea Integrate enhanced IDS with adaptive firewall
for autonomous intrusion defense.
Goal:
Automate adaptive intrusion handling triggered by enhanced intrusion detection
Investigate the impact of various intrusion types on QoS
Techniques:
Enhanced Snort Plug-in with subnet spoofing detection
Adaptive rate limiting firewall with user defined threshold and intrusion history.
19ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Attack
Attack Attack
Private Subnet192.168.0
Attack Network128.198.61
IP: 128.198.61.12NM: 255.255.255.128
GW: 128.198.61.1
eth0
Pluto
Titan
DMZ
Multi-LevelRate Limiting
Class-BasedQueuing(CBQ)
as Linux Router
Firewall(iptables)
Security Policy
IP: 192.168.0.1NM: 255.255.0.0
GW: 128.198.61.12
eth1
RealServer
Re
alS
erv
er
Tra
ffic
IDS
Ale
rts
tr
igg
er
Mu
lti-L
eve
lR
ate
-Lim
itin
g
IDS
70
% H
TT
P,
Re
alP
laye
r
1
5%
SM
TP
, P
OP
3
1
0%
SS
H,
SF
TP
5
% S
YN
, IC
MP
, D
NS
10 Mbps Hub
eth0
IP: 192.168.0.2NM: 255.255.0.0GW: 192.168.0.1
Public Network128.198
Internet
Alpha128.198.61.15
DDoSAgent
Gamma128.198.61.17
DDoSAgent
Beta128.198.61.16
DDoSAgent
Delta128.198.61.18
DDoSAgent
SimulatedInternet
100Mpbs Switch
Master Client& Handler
DDoS
Saturn128.198.61.11
NM: 255.255.255.128GW: 128.198.61.1
Autonomous Anti-DDoS Network(A2D2)
Client1128.198.a.195
Real Player Client
Client2128.198.b.82
Real Player Client
Client3128.198.c.31
Real Player Client
100Mpbs Switch
20ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
A2D2 Multi-Level Adaptive Rate Limiting For
Anti-DDos Defense
A2D2 Multi-Level Adaptive Rate Limiting For
Anti-DDos Defense
IP: 128.198.61.12NM: 255.255.255.128
GW: 128.198.61.1
eth0
Firewall Gateway
Multi-LevelRate Limiting
as Linux Router
IP: 192.168.0.1NM: 255.255.0.0
GW: 128.198.61.12
eth1
IDS
snort.confFloodPreprocessor
Threshold
snort.confFloodRateLimiter
PreprocessorThresholds
rateif.conflevels, rate,expiration,port # etc.
./snort -A UNSOCK
report.c./alert
rateif.pl
Level 4
Open(5 days)
Level 3
100 p/s
Level 2
50 p/s
Level 1
Block(2 hrs)
Level 0
Block(2 days)
Level 1Expires
21ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
A2D2 Results – Non-stop AttackA2D2 Results – Non-stop Attack
Packets Received: 8,039
Retransmission Request: 2,592
Retransmission Received: 35
Lost: 2,557
Connection Timed-out
Packets Received: 8,039
Retransmission Request: 2,592
Retransmission Received: 35
Lost: 2,557
Connection Timed-out
QoS Experienced at A2D2 Client
22ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
A2D2 Results – UDP AttackMitigation: Firewall Policy
A2D2 Results – UDP AttackMitigation: Firewall Policy
Packets Received: 23,407
Retransmission Request: 0 Retransmission Received: 0 Lost: 0
Packets Received: 23,407
Retransmission Request: 0 Retransmission Received: 0 Lost: 0
QoS Experienced at A2D2 Client
23ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
A2D2 Results – ICMP AttackMitigation: Firewall Policy
A2D2 Results – ICMP AttackMitigation: Firewall Policy
Packets Received: 7,127
Retransmission Request: 2,105
Retransmission Received: 4
Lost: 2,101
Connection Timed-out
Packets Received: 7,127
Retransmission Request: 2,105
Retransmission Received: 4
Lost: 2,101
Connection Timed-out
QoS Experienced at A2D2 Client
24ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
A2D2 Results – ICMP AttackMitigation: Firewall Policy & CBQ
A2D2 Results – ICMP AttackMitigation: Firewall Policy & CBQ
Packets Received: 23,438
Retransmission Request: 0 Retransmission Received: 0 Lost: 0
Packets Received: 23,438
Retransmission Request: 0 Retransmission Received: 0 Lost: 0
QoS Experienced at A2D2 Client
25ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
A2D2 Results – TCP AttackMitigation: Policy+CBQ
A2D2 Results – TCP AttackMitigation: Policy+CBQ
Packets Received: 22,179
Retransmission Request: 4,090
Retransmission Received: 2,641
Lost: 1,449
Screen Quality Impact
Packets Received: 22,179
Retransmission Request: 4,090
Retransmission Received: 2,641
Lost: 1,449
Screen Quality Impact
QoS Experienced at A2D2 Client
26ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
A2D2 Results – TCP AttackMitigation: Policy+CBQ+RateA2D2 Results – TCP Attack
Mitigation: Policy+CBQ+Rate
Packets Received: 23,444
Retransmission Request: 49 – 1,376
Retransmission Received: 40 – 776
Lost: 9 – 600
Packets Received: 23,444
Retransmission Request: 49 – 1,376
Retransmission Received: 40 – 776
Lost: 9 – 600
QoS Experienced at A2D2 Client
27ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Autonomous Anti-DDoSAutonomous Anti-DDoS
IDIP DiscoveryCoordinator
FirewallIDIP Neighbor
Class-BasedQueuing
(CBQ)
Firewall(iptables)
Security Policy
Multi-LevelRate Limiting
eth0 eth1
Local IDS ResponseMulti-Level Adaptive
Rate Limiting
EnhancedIDS
+IDIP Application Layer
Cooperative TracebackCooperative Detection
Net RestructuringIntrusion Pushback
TracebackMsg Sent
IDIPNeighbor
NotificationTo IDIP
DiscoveryCoordinator
Rates Dependenton Traffic Type
SnortAlerts
InternetTraffic
28ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SGFR: Secure Groupware for First Responder
SGFR: Secure Groupware for First Responder
Main Idea design a framework for enhancing security of groupware packages such as instant messenger and video monitoring/conferencing tool.
Goal: Investigate proper interface between group rekeying system and
groupware. Develop secure instant messaging system with remote group file download
and remote display. Experiment the prototype software on PDA with mobile ad hoc network. Integrate with stress level and tool usage effectiveness evaluation
This is a joint project with Dr. Chip Benight of psychology department at UCCS.
Techniques:
Scalable group key management (Keystone from UT Austin)
Efficient groupware (Jabber Instant Messaging System)
Mobile Ad Hoc Network (NIST)
29ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SGFR FeaturesSGFR Features
Security Enhanced GroupwareInstant messenger
(JabberX)
Group Communication ServerInstant Messaging Server
(Jabber)
Psychology EvaluationStress Level Tracking
Effectiveness of Tool Usage(Keyboard/Mouse Event Tracking,History of Commands, Mistakes,
Popup Quiz?)
Group Key ManagmentSecure Group
Rekeying system(Keystone)
30ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SGFR System ArchitectureSGFR System Architecture
SGFR Client
SGFR Client
SGFR Client
SGFR Group Key Server
SGFR Instant Messenger
Server
Group key distribution
Sign-in create/join chat groups
Registration/authentication
Encrypt/Decrypt msgs using group key
31ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SGFR System Operation SGFR System Operation
Registrar
JabberXclient
ControlManager
KeyServer
Jabber Server
DataBroadcast
JabberXClient
JabberXClient
Multicast/Unicast
Rekey messages
Rekey messages
Registration
Requests
ApplicationData
32ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Associate JabberX client with Keyserver and Jabber server
Associate JabberX client with Keyserver and Jabber server
Users login to the Jabber server If login successful, the client registers with the
Keyserver. When a user creates/joins a group, the Keyserver gives
a key to the client. When a user leaves the group, the Keyserver
generates a new key for the remaining members of the group.
Users login to the Jabber server If login successful, the client registers with the
Keyserver. When a user creates/joins a group, the Keyserver gives
a key to the client. When a user leaves the group, the Keyserver
generates a new key for the remaining members of the group.
33ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Output of the Keystone Server
User ganesh joining group g1
User ayen joining group g1
First group key assigned to group
Second group key assigned to groupWhen a member
joined
34ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Packet captured by Ethereal Packet Sniffer
Output of the Jabber server running on a machine
Encrypted “Hello”
Surrounded by <body>tag
35ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Testing ResultsTesting Results
Runs Client Registration Time (ms)
Group Join Time (ms) Group Leave Time (ms)
1 279.62 233.46 135.54
2 249.28 652.74 126.78
3 253.93 706.04 769.08
4 259.46 118.15 434.12
Avg/Run 260.57 427.59 366.38
Table 1 time taken for client registration group join, group leave
File size Time Taken (ms)
8.5K 35302.47
25K 105986.05
60K 305934.53
195K 1007949.38
Table 2 time taken for file transfer
36ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
ConclusionConclusion A secure group communication software package SGFR v.0 was
developed. Use Digital Certificate to authenticate client access. Group keys are distributed when members join/leave or based
on some time period. Group key is used to encrypted the messages. Enhanced Jabber-based text chat with remote file download
and remote display. Ported the SGFR v.0 to run on handheld devices include iPAQ PDA
running Linux and Sony PalmTop with 802.11b mobile ad hoc network.
A secure group communication software package SGFR v.0 was developed. Use Digital Certificate to authenticate client access. Group keys are distributed when members join/leave or based
on some time period. Group key is used to encrypted the messages. Enhanced Jabber-based text chat with remote file download
and remote display. Ported the SGFR v.0 to run on handheld devices include iPAQ PDA
running Linux and Sony PalmTop with 802.11b mobile ad hoc network.
37ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Secure Wireless Access ControlSecure Wireless Access Control Goal:
Compare performance of two proposed wireless authentication protocols, PEAP vs. TTLS.
Develop a PEAP module for freeRadius server on Linux.
Techniques/Tools used:
Xsupplicant, Window XP
freeRadius, Win 2003 server
OpenSSL
38ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
UCCS Secure Wireless Access TestbedUCCS Secure Wireless Access Testbed
Client
RADIUS
39ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Client/Server Machine ConfigurationsClient/Server Machine Configurations
Machine Spec IP Address OS Software
wiper.uccs.edu1.8 Ghz, 1 GB RAMRADIUS Server and
DHCP server
128.192.61.132 RedHat 9.0Running Linux
2.2.20-19.9 kernel
FreeRadiusModified
CVS snapshot radiusd-
09.03.03.tar.gz
willow.uccs.eduAccess Point
Cisco Aironet 1200
128.192.61.130 RedHat 9.0 Running Linux
2.2.20-19.9 kernel
Cisco 1200 series
Software
Toshiba – 366 Mhz, 512 MB
Wireless ClientUsing Cisco Aironet
350 PC Card
Dynamic IP address
128.192.61.144to
128.98.61.152
RedHat 6.2 running Linux 2.2.20-19.9
kernel
Open1x XsupplicantVersion 9.0
Hobbit – 1 Ghz Dell Optiplex, 512 MBWireless Client
Using Cisco Aironet 350 PCI Card
Dynamic IP address
128.192.61.144to
128.98.61.152
Windows XP-SP1And RedHat 9.0 Running Linux 2.2.20.9 kernel
Open1x Xsupplicant for
Linux and built in Service Pack for
XP
40ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
PEAP vs. TTLS on Toshiba machine
PEAP vs. TTLS on Toshiba machine
PEAP vs TTLS[Toshiba - 366.604mhz]
500600700800900
100011001200130014001500
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
No. of Runs
Tim
e in
ms
ec
TTLS
PEAP
PEAP TTLS
Average 1046 949
Variance 8142 12060
41ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
PEAP-TTLS Average Performances over varying Distances
800
900
1000
1100
1200
1300
1400
1500
DIST1 DIST2 DIST3 DIST4 DIST5
Distance Range
Ave
rag
e-T
ime/
mse
c
PEAP
TTLS
PEAP vs. TTLS Average Performance
PEAP vs. TTLS Average Performance
42ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
ConclusionConclusion
Developed a Radius Server on Linux that supports both PEAP and TTLS.
PEAP is relatively more influenced by Client’s processor speeds, distance range and network transient nature as compared to TTLS.
Although the higher performance shown by TTLS over PEAP is negligible, it is worth noting that TTLS was outperforming PEAP on an average by 10% in all the tests.
The enhanced Radius Server can serve both Windows and Linux clients.
Developed a Radius Server on Linux that supports both PEAP and TTLS.
PEAP is relatively more influenced by Client’s processor speeds, distance range and network transient nature as compared to TTLS.
Although the higher performance shown by TTLS over PEAP is negligible, it is worth noting that TTLS was outperforming PEAP on an average by 10% in all the tests.
The enhanced Radius Server can serve both Windows and Linux clients.
43ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
First Responder Sensor NetworkFirst Responder Sensor Network
Goal: How wireless sensor network can assist first responders.
Status:Created a wireless sensor testbed with Crossbow Professional Mote Kits and Intel stargate gateway devices.
Current Tasks: Investigate how to deploy sensor networks (pre-
planned/dynamically deployed). Develop algorithms for tracking first responders using
wireless sensors. Security in SMANET+FRSN.
Goal: How wireless sensor network can assist first responders.
Status:Created a wireless sensor testbed with Crossbow Professional Mote Kits and Intel stargate gateway devices.
Current Tasks: Investigate how to deploy sensor networks (pre-
planned/dynamically deployed). Develop algorithms for tracking first responders using
wireless sensors. Security in SMANET+FRSN.
44ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Scenario 1:Preplanned Wireless Sensors
Scenario 1:Preplanned Wireless Sensors
Building is surveyed and deployed with wireless sensors and include floor plan info in the gateway device.
When there is fire, first responders can tap into the secure wireless sensor network to find the condition of the building and over with the floor plan picture.
Building is surveyed and deployed with wireless sensors and include floor plan info in the gateway device.
When there is fire, first responders can tap into the secure wireless sensor network to find the condition of the building and over with the floor plan picture.
45ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Scenario 2: Dynamically Deploy Sensors
Scenario 2: Dynamically Deploy Sensors
Fire Fighter drops the wireless sensors along the route in. If sensors detects temperature increase or location movement!!, they relay the
date through multiple hop wireless sensor network to both the team inside and the team outside.
Fire Fighter drops the wireless sensors along the route in. If sensors detects temperature increase or location movement!!, they relay the
date through multiple hop wireless sensor network to both the team inside and the team outside.
46ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
Secure Access to Sensor NetworkSecure Access to Sensor Network
Terrorist may access the sensors and information on the gateway.
Need authentication for secure access. Need encryption for avoid sniffing by terrorist. Need redundancy for fault tolerance and verifying the
sensor results.
Terrorist may access the sensors and information on the gateway.
Need authentication for secure access. Need encryption for avoid sniffing by terrorist. Need redundancy for fault tolerance and verifying the
sensor results.
47ITS-ZeeWave Meeting 2/26/2004 UCCS Chow
SummarySummary
We have innovated ideas on intrusion tolerance/SMANET We have developed expertise in
Secure DNS system Secure multiple path indirect routing Autonomous system with Enhanced IDS+Firewall Secure wireless access and MANET Group key management Secure groupware Wireless sensor network for first responders Content switching Network restoration
Very interested in research and development collaboration.
We have innovated ideas on intrusion tolerance/SMANET We have developed expertise in
Secure DNS system Secure multiple path indirect routing Autonomous system with Enhanced IDS+Firewall Secure wireless access and MANET Group key management Secure groupware Wireless sensor network for first responders Content switching Network restoration
Very interested in research and development collaboration.