Internet Connection with Wireless Sensor Networks

1
Internet Connection with Wireless Sensor Networks

• Lixia Zhang
• The Croucher Foundation Advanced Study Institute
• Wireless Sensor Networks
• December 6, 2006

2
Disclaimer

• Personal view
• Sharing my own experience from 25 years with
  TCP/IP development
• PHTYMH
• Potentially harmful to your mental health

3
Waves of research efforts

• A new direction is proposed
• Center of research gravity shifted
• Many efforts devoted to the new topic
• And . . .
• Are we pushing the frontier of science,
  engineering, or technology?

4
Why talking the connection

• between Internet and sensor networking ?
• Understand what we have learned
• How our past result may guide our future effort

5
What is the "connection" ?

• Between the Internet and wireless sensor
  networks?
• Sensors will be connected to the Internet!

6
(No Transcript)
7
But the most important connection

• The similarities between the two
• Sensor networks a new technology emerging on the
  horizon today
• That's where the Internet was 30 years ago
• Today's Internet a global scale communication
  infrastructure
• Sensor networking Expected to succeed as the
  Internet has
• and growing into large-scale deployment

8
Why multi-scale distributed sensor-networking
will transform ecology
Radioastronomy
Computing
Field ecology
Supercomputers
Single Telescopes
Individual observations
because it has done so over and over again
Very Large Array
Internet
NEON
D. Estrin, keyntote_at_3rd IMUA Conf
9
The second similarity

• Both are man-built artifacts
• A fundamental question Have we mastered the
  principles for designing successful large-scale
  distributed systems?
• Where to find these principles?

10
Here's what a famous scientist had to say

• "The principle of science, the definition,
  almost, is the following the test of all
  knowledge is experiment. Experiment is the sole
  judge of scientific 'truth'. "

11

• "But what is the source of knowledge? Where do
  the laws that are to be tested come from?
• Experiment, itself, helps to produce these laws,
  in the sense that it gives us hints."

12
The best way to find/learn the design principles

• Is to build a sensor network
• then one can learn from the successes, and more
  importantly from the lessons
• We do not have to start from a blank sheet of
  paper
• The Internet real-world example of the largest
  system human ever built
• Learn from a critical examination of the
  successes and lessons of the Internet

13
A Walk Through History
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
D. Estrin, keyntote_at_3rd IMUA Conf
14
Brief History of the Internet

• 1968 - DARPA (Defense Advanced Research Projects
  Agency) contracts with BBN (Bolt, Beranek
  Newman) to create ARPAnet
• 1970 - First five nodes
• UCLA
• Stanford
• UC Santa Barbara
• U of Utah, and
• BBN
• 1974 - TCP specification by Vint Cerf
• 1984 On January 1, the Internet with its 1000
  hosts converts en masse to using TCP/IP for its
  messaging

from William F. Slater, III Chicago Chapter of
the Internet Society
15
aren't there big enough differences

• Between Internet and sensor networking
• That would make the Internet experience
  irrelevant?
• e.g.
• Wireless bandwidth is intrinsically limited
• But see the progress in WiFi speed over the last
  few years
• "a fundamental challenge in wireless sensors is
  the energy problem"

16
(No Transcript)
17
The fundamental challenge

• Lies on discovering the principles for large
  scale systems
• Technologies can, and will, be moving forward to
  meet whatever the market needs

18
Network Design in Practice

• The initial packet switchted network design and
  validation were done while the system was small
• Focus solving the functional problems to get the
  system up and running
• TCP/IP delivering packets across networks made
  of different networking technologies
• Early experiments necessarily done in a small
  setting that can be understood and controlled
• ARPAnet started with a few nodes, then grew to
  dozens of nodes.

19
Scalability Consideration

• during the design phase
• Designs explicitly assumes that the network would
  grow large
• Larger number of nodes getting connected
• Larger number of route table entries
• Larger volume of data traffic
• More types of new applications
• And with different performance requirements

20
Internet scaling up

• A success design in enabling growth to
  large-scale.
• The Internet now faces new challenges resulted
  from its growth
• Many new (unforeseen) problems popped up from
  practice
• Many open challenges
• Take a look at a real large scale distributed
  network

21
The Internet as a Large System
the Internet has grown both in size and in
importance

• Expected impact of larger size
• More users
• Larger traffic volume
• Bigger routing tables
• Wider range of heterogeneity in networking
  technology

22
1. Growing Large IncludesChanges in User
Community

• Small-scale a close-nit, friendly research
  community
• Large-scale open system facing brutal real world
• Expected user population growth
• Unexpected changes in types of users diverse
  interest
• Millions of users contribute and gain from the
  Internet
• Spammers, phishing, DDoS

23
Phishing
24
DDoS Example
25
could sensors possibly be abused?

• In day-1 of Internet, no one thought it could
  possibly be abused either
• What bad things can be done to sensor networking?
• Military applications?
• Terrorists?
• Bottom line When sensor networks start providing
  valuable services to some people, there will be
  some others who have a different interest

26
2. Growing Large IncludesChanges in Operational
Community

• Small-scale knowledgeable operators committed to
  growth and promotion of system
• Collaboration toward the common goal.
• Large-scale diverse operators with competing
  agendas
• Highly diverse levels of expertise
• Competition instead of collaboration

?
Large operator community with different degrees
of expertise
27
Operational Errors an example

• Operational errors have been the cause of most
  major outages so far
• One common configuration error route leak-out

Global Internet
regional ISP
28
A few route leak-out cases

• Apr. 25, 1997 At 1130 am EST, a router in AS7007
  accidentally advertised to its peers 73,000
  routes. A large number of networks became
  unreachable as a result. This incident was partly
  aggravated by some BGP implementations inability
  to remove the false routes even after AS7007
  disconnected their router, the false routes still
  persisted for at least seven hours
• Apr. 7, 1998 AS8584 announced over 11,000
  prefixes belonging to other networks
• Apr. 7, 1999 AS7374 leaked many routes via the
  Internet exchange point CIX (AS1280). It appears
  to be announcing routes for most of the Internet
  ...
• Apr. 6, 2001 Cable and Wireless (AS3561) had a
  configuration error that caused it to propagate
  route announcements from a downstream customer
  AS15412.
• ........
• December 2004 AS9121 announced routes to almost
  all the Internet destinations, successfully
  hijacked a large number of prefixes hosted by
  tier-1 ISPs such as ATT and UUNET

29
Persistent existence
"Understanding BGP Misconfiguration", SIGCOMM 2002
30
Another example DNS misconfiguration
DNS stores all data in Resource Records (RR)

• NS Resource Record
• Provides the names of a zones authoritative
  servers
• Stored both at the parent and at the child zone

com

• A Resource Record
• Associated with a NS resource record
• Stored at the parent zone (glue A record)

foo.com
31
Common config. error Lame Delegation
foo.com. NS A.foo.com. foo.com. NS
B.foo.com.
A.foo.com. A 1.1.1.1 B.foo.com. A 2.2.2.2
com
1) Non-existing server
foo
2) Non-authoritative
3) Useless referral
A.foo.com
B.foo.com
32
Lame Delegation how bad is it?
33
Major incidents due to config. errors
Microsoft's websites were offline for up to 23
hours -- the most dramatic snafu to date on the
Internet --because of an equipment
misconfiguration -- Wired News,
Jan 2001
34
3. Growing Large Includes unforeseen protocol
impl. consequence

• We are not talking about implementation bugs here
• Though it is a serious problem
• i.e. all the viruses/worms resulted from
  exploitation of bugs (in either OS or
  applications)
• The problem protocol implementors do not
  understand the consequence of specific protocol
  implementation decisions

35
Benign implementation ? security threat

• In spring'03 U. Wisc experienced sudden increase
  in incoming traffic potential DDoS?
• Notified the ISP and blocked the attack traffic
• The traffic did not stopped

36
The culprit
37
What happened?

• Several popular Netgear products "relied on a
  separate NTP-based time source to set the current
  date and time, as it did not have an internal
  battery and clock. The product is hard-coded with
  specific NTP time sources that are accessible
  through the public Internet."
• "The Candidate Firewall Product met all the
  criteria elements in the Baseline and Residential
  modules and therefore has attained ICSA Labs
  Firewall Certification."

These home routers send 1 NTP query per second!
38
4. Growing Large Includes unforeseen protocol
design consequence

• In designing a protocol exactly what information
  should/not be carried in the protocol message?
• One common view the more the better
• One design case BGP aggregator attribute

1.2.3.0/24 AggrR1
R3
R1
1.2.3.0/25
R2
1.2.3.128/25
39
subtle design issues show up at worst time

• R1 and R2 connect to the upstream ISP.
• AS X local decision to prefer R1 or R2 as entry
  point.
• AGG value differs depending on choice of R1 or
  R2.
• During a worm attack wild route
  fluctuation?global flood of updates

AS209
R1
R2
We are here
Local instability ? global overhead
40
5. Growing Large Includes unforeseen component
behaviors

• Routing protocols are designed with quick
  reactions to all topological changes
• Unforeseen started seeing small number of
  unstable edge networks
• Inevitable in large scale
• Global impact

C
Internet
D
A
B
X
Y
E
41
Let's fix it BGP Damping Design

• Use penalty to track route instability
• Increase upon receiving an update
• Otherwise decay exponentially
• Suppress the route if penalty is over the cutoff
  threshold
• Reuse when the penalty drops below the reuse
  threshold

42
Expected BGP Damping Behavior
C
Internet
D
damped

A
B
X
Y
E
C
Internet
D
?
A
B
X
Y
E
43
"Route Flap Damping Exacerbates Internet Routing
Convergence"

• "We analyze a previously not well-studied
  interaction between BGP's route withdrawal
  process and its route flap damping mechanism for
  ensuring the overall stability of the Internet
  routing system.
• "This interaction can, depending upon the
  topology, suppress up to one hour the propagation
  of a route that has been withdrawn once and
  re-announced."

44
6. Growing Large Includes unforeseen dynamics
in large scale
Internet
C
XCBA
D
XDBA
W
XEBA
W
XDCBA
W
A
B
damped!
X
Y
E
45
Secondary Charge
Path exploration
Secondary charging
46
7. Growing Large Includes Growth in value and
importance!

• Value and importance of the Internet attract
  malicious attacks
• There exists an underground economy that is
  driving all the bad traffic in the Internet today
• Using our network, our technology to attack us
• This was not expected
• Thus the original Internet protocol design and
  implementation were vulnerable in face of these
  attacks

47
8. Growing Large IncludesTrust Exploited By
Attackers

• Original DNS design
• information piggybacking ? performance improvement

Google DNS server
UCLA Caching Server
Query www.google.com
UCLA Laptop
48
DNS cache poisoning byattracting servers to bad
place
Response www.attacker.com A
128.9.128.127 attacker.com NS
ns.attacker.com attacker.com NS
www.google.com ns.attacker.com A
128.9.128.2 www.google.com A
128.9.128.127
UCLA Caching Server
attacker.com DNS server
Query www.attacker.com
UCLA Laptop
Remote attacker
49
DNS cache poisoning by Exploiting weakness in
protocol design
google.com NS ns.google.com ns.google.com A
4.4.4.1
128.9.128.2
www.google.com A 128.9.128.127
Google DNS server
UCLA Caching Server
UCLA Laptop
50
Putting the Problems in Context

• The above is only a small sample set of observed
  problems due to growing large
• The original protocol design/implementation
  enabled Internet growth to large scale, but are
  not well suited to maintain it at large scale

51
Internet protocol design starting Small

• Aim at the minimal set of bits necessary for data
  delivery
• Explicitly enumerates all possible physical
  failures
• Node failure fail stop
• Link failure disconnect
• Data delivery failure bit error, our of order,
  loss, duplicates
• Implicitly assumes that
• Every component follows the rules
• No faults other than physical failures listed
  above
• Reality taught us other types of faults lead to
  failures

52
"On Being the Right Size"

• Let us take the most obvious of possible cases,
  and consider a giant man sixty feet high ...
  These monsters were not only ten times as high as
  Christian, but ten times as wide and ten times as
  thick, so that their total weight was a thousand
  times his ... Unfortunately the cross sections of
  their bones were only a hundred times those of
  Christian, so that every square inch of giant
  bone had to support ten times the weight borne by
  a square inch of human bone.

For every type of animal there is a most
convenient size, and a large change in size
inevitably carries with it a change of form.
53
Broader Lessons of Large Scale

• Large-Scale deployment of sensor networks
  (millions of motes) envisioned
• Sensor networks
• The initial deployment is necessarily small in
  scale
• Thus will not expose those problems that can only
  surface when the system grows large
• once the size grows large enough,
• Will include some faulty components
• Will see a move from a few expert operators to
  the broad public (with diverse expertise)
• Will experience unexpected interactions
• Will attract attacks if system is successful
• Are these issues adequately considered in the
  current design efforts?

54
ACM Conference on Embedded Networked Sensor
Systems (Sensys)

• Look at one conference

55
Sensys 2005 Program

• Sensornet Services
• Radio Interferometric Geolocation
• High-Accuracy, Low-Cost Localization System for
  Wireless Sensor Network
• A New Approach for Establishing Pairwise Keys for
  Securing Wireless Sensor Networks
• TSAR A Two Tier Sensor Storage Architecture
  Using Interval Skip Graphs
• Deployment Experience
• A Macroscope in the Redwoods
• Design and Deployment of Industrial Sensor
  Networks Experiences from the North Sea and a
  Semiconductor Plant
• Networking
• A Unifying Link Abstraction for Wireless Sensor
  Networks
• Z-MAC A hybrid MAC for wireless sensor networks
• Packet Combining in Sensor Networks
• Siphon Overload Traffic Management using
  Multi-Radio Virtual Sinks
• Synchronization
• Estimating Clock Uncertainty for Efficient
  Duty-Cycling in Sensor Networks
• Firefly-Inspired Sensor Network Synchronicity
  with Realistic Radio Effects
• Applications
• Design Frameworks
• Lightweight Detection and Classification for
  Wireless Sensor Networks in Realistic
  Environments

56
Sensys 2005 Posters

• Exploiting Multi-Channel Diversity to Speed Up
  Over-the-Air Programming of Wireless Sensor
  Networks
• Bayesian Localization in Wireless Networks Using
  Angle of Arriva
• Impact of Intentional Mobility in Sparse Sensor
  Networks
• CONCERT aggregation-based CONgestion Control for
  sEnsoR neTworks
• Accuracy-aware Data Modeling in Sensor Networks
• Secure Dissemination of Code Updates in Sensor
  Networks
• Splitting The Sensor Node
• A Sensor Network Based Landslide Prediction
  System
• Sensor Networks for Landslide Detection
• Robot Couriers Precise Mobility in a Wireless
  Network Testbed
• A Dynamic En-route Scheme for Filtering False
  Data Injection in Wireless Sensor
• A New Scheme on Link Quality Prediction and its
  Applications to Metric-Based Routing
• Automatic Programming with Semantic Streams
• Stop the Clock! New Directions for Embedded
  Controllers in Wireless Sensor Networks

57
Sensys 2006 session topics

• Operating Systems
• Sensing
• Routing and Dissemination
• Configuration
• In-network Processing
• Radio Propagation and Transport
• Storage and Abstractions
• Architecture
• CarTel A Distributed Mobile Sensor Computing
  System
• MELETE Supporting Concurrent Applications in
  Wireless Sensor Networks
• The Tenet Architecture for Tiered Sensor Networks
• Media Access Control

58
Implications For New Designs

• The Fundamental Design Problem is Scale
• Internet Problems Will Recur in Overlays, Sensor
  networks, separate control planes, etc.
• Difficult to test on smaller scales, but will be
  facts once the size grows large enough
• Expected Results of any successful system
• Will include some faulty components
• Will see a move from a few expert operators to
  the broad public (with diverse expertise)
• Will experience unexpected interactions
• Will attract attacks if system becomes valuable

59
Security and Resiliency

• Resiliency resistant to known and unknown faults
• Security definition?
• Cryptographic-based protection?
• E.g. secrecy, authentication, non-repudiation
• A thought exercise
• Which of the above mentioned problems can be
  eliminated by crypto?
• Which of them can be eliminated without using
  crypto?

60
Challenges in designing for large scale

• Systems grow into large-scale along multiple
  dimensions
• The size is perhaps the easiest part to handle
• Most problems do not occur till the system grows
  large
• Large-Scale Systems Difficult to Model
• Testbeds dont achieve desired scale, lack
  complex input factors
• Simulations do not have the ingredients in real
  large scale setting

61
Resiliency and the Internet

• Internet has taught us a rich set of lessons
• Have we collected them all?
• Internet can serve as primary experimental lab
• Exhibits real problems of large-scale
• Use it as a lab to identify challenges and test
  concepts

62
Here's some quote from a great scientist (to
back myself up)
63

• The principle of science, the definition, almost,
  is the following the test of all knowledge is
  experiment. Experiment is the sole judge of
  scientific "truth".

64

• But what is the source of knowledge?
• Where do the laws that are to be tested come
  from?
• Experiment, itself, helps to produce these laws,
  in the sense that it gives us hints.

65

• But also needed is imagination to create from
  these hints the great generalizations to guess
  at the wonderful, simple, but very strange
  patterns beneath them all, and then to experiment
  to check again whether we have made the right
  guess.

66
What to carry away

• Internet proved that we know how to make a small
  system successful
• If successful ? growing large
• Lessons Scalability is a multi-dimension
  challenge
• When growing large new problems show up
• Being able to grow large ?being able to sustain
  at large

67
What to carry away

• Need a vision to forecast technology advances and
  their potential impact on the growth of the
  system to be designed
• Research challenge mastering the principles for
  designing large-scale systems
• Internet serves as a great lecture hall
• Prinicples and lessons learned should be
  applicable to other types of large scale
  deployment

68
Thank you!
Questions?

• lixia_at_cs.ucla.edu