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
4
Disseminating Dynamic Resource Information
Sensor
Network
Consumer
Consumer
Consumer
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
23
For MoreInformation
• Peter Dinda– http://www.cs.northwestern.edu/~pdinda
• Minet– http://www.cs.northwestern.edu/~pdinda/minet/
• Prescience Lab– http://www.cs.northwestern.edu/~plab
