Exploiting Packet Header Redundancy for Zero Cost Dissemination of Dynamic Resource Information...
-
date post
21-Dec-2015 -
Category
Documents
-
view
217 -
download
0
Transcript of Exploiting Packet Header Redundancy for Zero Cost Dissemination of Dynamic Resource Information...
Exploiting Packet Header Redundancy forZero Cost Dissemination of Dynamic
Resource Information
Peter A. DindaPrescience Lab
Department of Computer Science
Northwestern University
http://www.cs.northwestern.edu/~pdinda
2
Overview
• Piggyback information on outgoing packets• Encode information into redundant or unused
TCP, IP, and Ethernet fields• Result: Disseminate information with no
additional packets or increased packet size
• Identified: >=86 bits per packet• Proof-of-concept: 17 bits per packet
3
Outline
• Disseminating dynamic resource info
• Theoretical redundancy
• Mechanisms for exploiting redundancy
• Prospects
• Proof-of-concept
• Using the mechanisms
• Conclusion and future work
5
Current Model
Transport
Network
Data Link
Physical
Transport
Network
Data Link
Physical
App AppSensor Consumer
Sensor is just another application
6
Problems With Current Model
• Bandwidth consumption– Can be reduced via adaptive techniques– Different available BW to different consumers
• Additional packets injected into network
• Consumers must know to ask for data
But packets already flow through the network!
7
Proposed Model
App
Transport
Network
Data Link
Physical
App
Transport
Network
Data Link
Physical
Sensor
Header Editing
Consumer
DataExtraction
Sensor data piggybacked on application packets
8
Header Editing
DataTCPIPEthernet Padding
Overwrite unused or redundant fields with sensor data
Sensor Data
How much redundancy is there and how do we exploit it?
9
Packet Traces
• NLANR Passive Measurement Network
• All packets at points of presence
• 28 90 second traces– 4 sites (U. Buffalo, Columbia, Colorado
State, U. Memphis)– Late September, 2001– 68,000 to 3 million packets per trace
10
How Much Redundancy Is There?
• Headers as a sequence of 1 byte symbols
• Shannon entropy– Number of bits needed per symbol– Does not capture correlation
• Mutual information– Bits per byte assuming one-step correlations
Evaluate the theoretical limits to redundancy
11
Redundancy in IP Headers
• Shannon entropy: 4.8 bits per byte– 40 % redundant– 8 extra bytes per header
• Mutual information: 1.2 bits per byte– 85 % redundant– 17 extra bytes per header
How does this redundancy manifest in practical ways?
Considerable redundancy is available
12
Practical Mechanisms: TCP Header
flagshlen reserved
destination port
window sizechecksum
sequence number
options
Mechanism Bits
Reserved bits 6
Ack field when ACK=0 32
Urgent field when URG=0 16
NOP option padding varies
Total >=54
source port
acknowledgement number
urgent pointer
13
Prospects: TCP Header
flagshlen reserved
destination port
window sizechecksum
sequence number
options
Mechanism Bits
Reserved bits 6
Ack field when ACK=0 32
Urgent field when URG=0 16
NOP option padding varies
Total >=54
source port
acknowledgement number
urgent pointer
Always Zero!UntestedUntestedOptions rare
14
Practical Mechanisms: IP Headervers hlen TOS length
identifier fragment offsetTTL protocol checksum
source addressdestination address
options
flags
Mechanism Bits
Reserved TOS bits 2
Reserved IP flag 1
Identifier when DF=1 16
Fragment offset when DF=1 13
NOP option padding varies
Total >=32
15
Prospects: IP Headervers hlen TOS length
identifier fragment offsetTTL protocol checksum
source addressdestination address
options
flags
Mechanism Bits
Reserved TOS bits 2
Reserved IP flag 1
Identifier when DF=1 16
Fragment offset when DF=1 13
NOP option padding varies
Total >=32
95% ZeroAlways zero90% DF=1
Options rare90% DF=1
16
Practical Mechanisms: Ethernet Padding
DataTCPIPEthernet Padding
Ethernet frame’s data must be at least 46 bytes long
TCP+IP+keystroke = 20+20+1 = 41 bytes
TCP ACK = 20+20 = 40 bytes
Prospects: Untested
17
Proof-of-concept
• Evaluate IP Header approaches
• Random bit source for data
• Minet user-level stack– ~20 lines of header-editing/data extraction code– ~200 lines of ancillary code (output)
• Study interaction with Linux stack (2.2 kernel) and Cisco router
18
Proof-of-concept results
Mechanism BitsMinet to
Linux
Minet to Router
to Minet
Minet to Router
to Linux
Demon-strated
bits
Reserved TOS bits 2 OK FAILS OK 0
Reserved IP flag 1 OK OK OK 1
Identifier when DF=1 16 OK OK OK 16
Fragment offset when DF=1 13 FAILS FAILS FAILS 0
NOP option padding varies untested untested untested 0
Total >=32 17
IP Header can transport 17 extra bits 90% of the time
What should we use them for?
19
Using the Bits
• 1 sample per packet– Host load: 1.4-15 bits per sample – Network bandwidth / latency: ?– Sample resolution can be varied
• Timestamps– Easy for TCP packets – use RTT estimate
20
Using the Bits
• Using this channel to transport streams
• Unreliable like IP
• Also can’t choose where/when data is sent– Only goes to “friendly” hosts– Or have to wait until someone sends a packet
to the machine you are targeting
• What are appropriate coding approaches?
21
Diffusion
App
Transport
Network
Data Link
Physical
Sensor
Header Editing
Consumer
DataExtraction
Information diffuses out from a sensor to “friendly” hosts
RandomDrop
22
Conclusions and Future Work
• Introduced concept of exploiting packet header redundancy for zero cost information dissemination– Intentionally extreme approach
• Identified mechanisms and prospects• Demonstrated proof-of-concept
• Future work: Linux kernel implementation