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