Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Computer security wikipedia , lookup
Distributed firewall wikipedia , lookup
Wireless security wikipedia , lookup
Deep packet inspection wikipedia , lookup
Computer network wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Network tap wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Disruption Tolerant Networking (DTN) Program Phase 1 And Phase 2/3 Program 23 March 2006 Preston Marshal, Program Manager [email protected] 703-696-5273 Distribution Statement: Distribution Limited to DoD and DoD Contractors Only Disruption Tolerant Networking (DTN) Program Concept source disrupted areas Disruption Closes Connection Packet traverses net until blocked by a disruption Custodian-to-custodian connections isolate disrupted regions destination End-to-end severely disrupted by one bad link Disruption Tolerant When disruption clears, packet traverses remainder of route Packet arrives at destination. In an IP network, packet wouldnever have left source DTN’s Goal is to is to develop and demonstrate technology that will provide network services in the face of disruption and massive differences in delay and bandwidth; and to reduce demands Distribution on network resources integrating storage Statement: Distribution by Limited to DoD and DoD Contractorsinto Only the network 2 Military Need FCS Vehicle, Ft. Benning 2006 • FCS Communications Position Reports Used as Measure • Highly Favorable Metric Used • Loss of 2 Successive (1 Sec Interval) Reports Considered as Disconnected Wireless networks can be good for local connect, but often can’t reach back to infrastructure Local storage – caching – can create access to information after infrastructure connectivity loss. Relying on IP for tactical military networks is dangerous • Episodically connected military MANETs see rapid topology changes • Tactical radios know names, not destination addresses • Tactical/edge military networks may be a mix of IP and non-IP radios Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 3 All Bandwidth is Not Equally Important • Similar to DARPA • Nodes can use local bandwidth to obtain DTN services, even if not on own node 64 Kilobps Episodic Connectivity GIG Fiber Core 10 Gigabps Highly Reliable Connectivity 10 Megabps Highly Reliable Connectivity • Highly reliable, high speed (1 Gigabit) from servers on campus • Several Megabits in and out to Internet Bandwidth/Reliability • Networks are not hierarchies of bandwidth, they are islands • Bandwidth within islands not as important as bandwidth between islands • DTN augmentation within islands provides major performance benefits between islands Distance DTN Can Augment Existing Networks without Being Inserted into Topology Wireless Enclaves Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 4 DTN Network Persistence Can Solve Fundamental Internet Application Shortfalls • DTN makes applications over disrupted networks robust • DTN is also an Opportunity to solve Fundamental Problems we’ve never before had a handle on, using Network-Managed Persistence Current Temporal Security Model Data decrypted at end system Data only decrypted for access DTN • Access information by content or type rather than by network address “I want maps for my area” instead of “I want to ftp to 192.168.4.17” • Retrieve once, provide to local users as requested • Learn from actual network usage • Exploit in-network storage/caches and pub/sub protocols to create a dynamic and self-forming “Akamai” • Use temporal security rather than physical security Time Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 5 Today’s Network: Push or Pull, Neither Optimal Conventional Pull: Copies to every requestor Only those who ask, get; but with delay; N requests use N times the bandwidth Multicast Push: Data goes to everyone I need a map I need a map I need a map I need a map Connected Network I need a map I need a map Connected Network need a map I I need a map Only one transfer, but data flows to everyone in the multicast group, not necessarily when / where the data is needed I need a map I need a map DTN Resolves Both Inefficiencies.. Pulls One Time, Distributes Locally To Requestors I need a map Resources Used to Get Data I need a map 1st Subsequent requests for same data consume as much bandwidth with as much delay as the first request. 2nd Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 3rd ··· Requests for same data 6 DTN Phase 1 Results • Demonstrated DTN v TCP with typical USMC wireless connectivity patterns (MITRE/CONDOR) • Demonstrated Network Delivery (BBN) • Demonstrated Trusted Delivery & Resistance to DDoS (Lehigh) • Designed architecture – intrinsic ability of DTN to operate to the extremes of the network without segmenting to match network characteristics – meta-architecture (MITRE/JPL) • Potential to move this extensible framework to other building blocks of the network • Have to adapt Cisco/Nortel/Lucent/Juniper behaviors • Implemented Experimental Operating Wireless DTN (GaTech/UMass) Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 7 Demonstrated DTN v. TCP with USMC Wireless Connectivity Patterns Consecutive 10-KByte File Retrievals over 24 hours, using HTTP and DTN 4000 INMARSAT terminal Number of File Transfers 3500 3000 2500 HTTP DTN 2000 Cisco 2811 1500 1000 KG-250 500 29 0 27 0 25 0 23 0 21 0 19 0 17 0 15 0 13 0 11 0 90 70 50 30 10 0 DT N File Retrieval Time (seconds) 10 KByte File Transfers in 24 hours 4000 Abandoned 10-KByte File Transfers in 24 hours 140 user 3500 3000 120 HTTP DTN 100 DTN 2500 EPLRS CONDOR Gateway cable map 80 2000 3580 .. 1500 60 1000 40 500 20 0 Cisco 3725 HTTP 115 368 Completed 0 0 Abandoned Demonstrated that DTN is Useful & Feasible, and that DTN can be Transitioned to COTS-based Military Systems DTN Is A Deployable Technology With Massive Performance Benefits for DoD Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 8 Phase 1 Go/NoGo Metric: Demonstrate DTN Network Performance in Disrupted Network & Evaluation Platform Hardware in the loop emulation of actual DTN nodes • 100% Reliable Delivery with • 80% Utilization over • 20% Available Links • Link characteristics • capacity: • delay: • MTU: 19.2 kb/s 5 ms 1480 bytes • Bundle traffic Go/NoGo criterion met for reliable delivery DTN would have delivered all traffic given enough time • size: 2800 bytes • total originated: 264 • Network Transit time >620ms • Link StateTransit time 4.3s • Mean time between link transitions ~5s • Run time: 3600 s For random link dynamics, at most 16 (out of 31) bi-directional links were up at any time Network changes faster than it updates.. never static. IP would never have correct topology.. would fail in a conventional MANET Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 9 Delivered Bundles Vs. Path Distance Run at 20% Target Availability: Random Link Dynamics 75 • Opportunistic Routing Found Ways to Deliver All Traffic, Regardless of Hops • TCP (End to End) Could Not Find Opportunities 50 • End to End requires Complete Path be Available Delivery Performance for DTN and TCP 100 Percent Bundels Delivered DTN • End to End is Fundamentally Unsuited for Military Operations 25 0 3 4 5 Num ber Hops 6 7 • 80% Links are only 20% Network Connected at 7 Hops • 20% Links are 0.001% Network Connected at 7 Hops • End to End IP (Without TCP) Shares All these Issues Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 10 Delivery Ratio: Worst Case Dynamics DTN versus End-to-End (E2E) Baseline • Would Complete All if Longer Duration created Opportunities • End to End Could Not Find Sufficient Opportunities in Any Disrupted Scenario • Failed Completely Below 50% Availability 100 DTN % Bundle Delivered • DTN Accomplished All Deliveries for Availabilities Above Go/NoGo Criteria 75 50 25 0 0 25 50 75 100 Average link Availability Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 11 Link Utilization Using DTN • DTN Effectively Used All Available Link Capacity 1 0.95 • Network Was So Dynamic that End to End 0.9 Would not be Aware of 0.85 Opportunities to Use Link Utilization • Efficiency Decreases at 0.8 High Availability, as More 0.75 Overhead, and Early Completion of Transfers 0.7 • Phase 2 Will Develop 0.65 Technology to Adapt and Use both End to End and0.6 DTN Based on Which 0.55 Would be Most Effective 0.5 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Link Availability Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 12 Trusted Delivery GNG Metric: ACHIEVED Phase 1 Go/No Go: “Demonstrate Trusted Delivery” • Demonstrate rejection of message from unauthenticated sender • Demonstrate authentication and forwarding of message from trusted sender • Demonstrate payload data encryption DTN will not propagate Distributed Denial-of-Service Attack DTN will Detect & Reject Fraudulent (Forged Address) Messages Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 13 Trusted Delivery GNG Metric: ACHIEVED Demonstrate rejection of message from unauthenticated sender • Two sending nodes - one legitimate, one malicious - attempt to send a bundle in a network with the BAH feature enabled • The malicious node (M1) sends a bundle without the appropriate BAH to the forwarding node (N2) • Result: N2 rejects the bundle - ACHIEVED • The legitimate sender (N1) sends a bundle with the appropriate BAH, allowing for successful authentication • Result: N2 forwards the bundle to the destination (N3) BAH: Bundle Authentication Header Security Perimeter N1 N2 N3 M1 Should have been part of the Internet from the beginning Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 14 Trusted Delivery GNG Metric: ACHIEVED Demonstrate: 1.) Authentication and Forwarding of Message From Trusted Sender and 2.) Payload Data Encryption • N1 sends a bundle to N4 (thru N2) with only the BAH activated • The link between N2 and N3 is insecure, so policy at N2 requires payload data encryption • N2 encrypts the payload, adds the PSH, and becomes the PSHsource, with destination N4 the PSH-destination for the bundle • N4 receives the encrypted bundle from N3 (thru N2) and decrypts the message: ACHIEVED N1 N2 PSH-Source DTN Enables Security Partitioning Based on Traffic Policies Rather than Physical Topology N3 N4 PSH-Destination BAH: Bundle Authentication Header PSH: Payload Security Header Red: Cleartext Black: Ciphertext Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 15 DTN System Architecture Bundle Engine Protocol Composition API Bundle TBD Services Bundle Encryption Bundle Flow/Congestion Ctl. Bundle End-to-end Reliability Bundle Custody Transfer DTN Policy/Management “DARPA” Routing Protocol “DTNRG” Routing Protocol Other Routing Protocol Autoconfiguration/ Neighbor Discovery Environmental Awareness API Legend Management API Routing API Configuration API Environmental Awareness API Convergence Layer Process Rendezvous Plug-ins/DLLs Single DTN Standard Will Be Extensible for Commercial or Uniquely Structured Military Apps Such As UAV Overflight, Sensor Nets, Tactical Disruption … Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 16 Technology for a Common Routing Structure with Mission-Unique Algorithms Wireless networks need diverse routing behaviors: “Open Biggest Battery First” (Battery-powered systems) “Use Advantaged Node Last” (Transient aircraft nodes) “Open Least Tx Energy Path First” (Energy-starved systems) “Open Least Used Reasonable Path First” (Fairness) Extend - don’t replace - COTS products Commercial World Core/Interoperable DoD Infrastructure minimal protocol set DoD Sensor Field Core/Interoperable GIG-unique routing algo. Core/Interoperable battery-aware routing algo. UAV flight schedule UAV flight schedule Core/Interoperable vendor-unique extension Color Legend: Buy commercial, specialize to military IRG DTN Network Standard Core Commercial DTN Extension Military DTN Extensions Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 17 DieselNet Initial Deployment May 2004 University DTN testbeds (GaTech/UMass) urban ops experiment with multipath and rapid topology change (route breakage) Long-term 24/7 Experiment at Low Cost with Mobile nodes, sensors, and throwboxes – analogs of tactical military wireless networks – urban+rural – manned & vehicular DieselNet: routers in 40 busses in Amherst Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 18 Algorithmic Results simulation time simulation time • Resource management: Virtual infrastructure with transport frames improves delivery rate in bottleneck scenarios • Flexible network simulation models with user-defined physical resource schedules simulation time AODV Factor 2-10 Reduction Factor 5-6 Increase AODV simulation time delivery rate • Reflective Route Planning: First DTN routing algorithm based on formal reasoning technology simulation time signaling overhead • Opportunistic Routing: SCaTR framework improves delivery rate and reduces signaling overhead virtual infrastructure delivery rate no resource management delivery rate • Knowledge management: Uniform information dissemination and improvement of buffer usage scenario size Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 19 DTN Progressive Maturity Protected, High Performance DTN for Static Applications with Store and Forward Phase 1 • • • • • Integrate Push and Pull Metaphors Cognitive Caching Information Addressing (not Network Addressing) Multiple Native Networks (JTIDS, IP, EPLRS, …) Initial Demo Board Implementation Phase 1 + Protected, DTN for Medium Scale, Static Applications with Caching and Distributed Query Phase 2 Progressive Technology Development Resulting in Proven and Deployable Product • Demo in Military Scenario to Assess Utility • Implement in Longer term, nonMilitary Application for Operational Experience • Self-Organizing in Response to Network needs • Large Scale • Red/Black Management of Persistent Data Dynamically Self-Organized Organized, Secure Local Store, Application Linkages, Proven Phase 3 • Integrate into Military Networks • Implement in Longer term nonMilitary Application to Acquire Experience Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 20 Merging Information and Networking Policy & reasoning enable sophisticated queries over the network • “I don’t know exactly what I’m looking for, but I know how to describe it” Late binding as a way of describing information • Don’t have to know where information resides – Google as a metaphor, not an overlay • Late binding can occur in the information domain, not only the addressing domain Want to build a formal structure for persistence and networking, a structure for solving tactical problems • Analogous to akamai, but akamai is static.. In tactical networks must build our persistence architecture on the fly Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 21 Adaptation to Reflect Network Dynamics DTN networks adapt to changing network topologies • Storage configures itself around paths thru the (intermittent) network • Self-forming Akamais for content distribution in response to network demands • Caching as a result of delay-bandwidth product discontinuities Military Utility – Reduce (eliminate?) burden of planning network deployment with unit deployment • Planning costs currently comparable to or greater than people and equipment costs • Network planning creates inertia/delay in deploying forces and reacting to unanticipated changes in the theatre • Avoid the Comms planning cycle! Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 22 Content-based Networking Support push from core, pull from edge, and meet-in-themiddle content-based networking Steinbet: “Users will pull data as needed instead of having massive amounts of information pushed to them regularly – regardless of whether it is needed. .. a key tenet of net-centric warfare is that the consumers of information are smarter than their sources about what is needed operationally right now, and that they should be able to pull those data when they need it. Enable users to subscribe to or query useful information services, and have data returned when there’s a new event or query match Edge networks can push data up into the network Source analysis systems can query DTN storage for Wolfpack systems – enables heterogeneous sensor data fusion Distribute policies with bundles – much of the flexibility of Active Networks without as much risk .. Update rules of engagement by disseminating policies thru DTN nets Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 23 Benefits of unifying networking and storage • Request information by content/type rather than by network address • “I want weather for my area” instead of “I want to ftp to 192.168.4.17” • Ability to cache rather than waste wireless bandwidth • It’s way cheaper to store data rather than to transmit it again • Integrating push-pull metaphor • Pushing sends to everyone and wastes bandwidth, can pre-place data • Pulling serves a single user, same data requested multiple times wastes bandwidth, incurs large delays delays in disrupted networks • Akamai uses static caches in a wired network to mitigate bandwidth wastage and delay • DTN Push/Pull exploits DTN in-network storage (persistent caches) and pub/sub protocols to create a dynamic and self-forming “akamai” • Temporal security • Show the data as encrypted/unencryptd Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 24 A New Security Model Red-black separation derives from the philosophy that the control center is protected – once in the black, info is physically safe With low-cost devices like WNaN, no longer true • • How to deal with the loss of equipment at the tactical edge? Information on this equipment is compromised with the equipment How to change the security model to deal with equipment that can’t be physically secured?? Current Rather than view red-black as physical separation, think temporal separation! Keep data encrypted unless the application is processing it! Encrypted data lives in local cache or edge network cache, decrypted by app Use a DTN security “convergence layer shim” for apps .. Withdraw access by app by revoking cert or similar action. Temporal Security Model DTN mechanism protects information “keyboard to eyeball” Data decrypted at end system Protection from app to app, not from node to node DTN Data only decrypted for access Distribution Statement: Distribution Limited to DoD and DoD Contractors Only Time 25 Summary •Bigger Challenge! •Larger Funding! •Massive Need! Distribution Statement: Distribution Limited to DoD and DoD Contractors Only 26