Download slides #2 - The Fengs

BLACK OPS OF TCP/IP
Hivercon [Preview]
Nov. 26-27, 2002
Dublin, Ireland
Instant Network Auditing
Spread Spectrum Tracing
Guerilla Multicasting
Advanced NAT/MAT/NAT2NAT
Sideband Crypto
Phentropy: Entropy Viz
Parasitic Traceroute
PAKETTO KEIRETSU 1.0
What’s New
What’s Coming
Dan Kaminsky, CISSP
DoxPara Research
www.doxpara.com
Interesting Problems

Instant Portscan


Guerrila Multicast


“Is it possible to send a single packet to multiple
recipients, using today’s multicast-free Internet?”
“NATless NAT”



“Is it possible to discover instantaneously what network
services have been made available, even on massive
networks?”
“Is it possible to share a globally addressable IP address
without translating private IP ranges a la NAT?”
Is it possible to allow incoming connections to an IP
multiplexed in this manner?
NAT Deadlock Resolution

“Is it possible to establish a TCP connection between
two hosts, both behind NATs?”
More interesting problems

Spread Spectrum Mapping


Non-Covert Capacity Sidebands


“It it possible to quickly discover traits of the
exponentially branching routes accessible from a
given point on a network?”
“Is it possible to send more than a few bits per
packet of ‘extra data’ not associated with the
original payload, without breaking existing
systems?”
Sideband Crypto Signatures

“Is is possible to sign outgoing data in such a
fashion that those who can not verify experience
no interference?”
New For nVidia
 Stateless
HTTP
 “Is
it possible to statelessly host a web
page, possibly with dynamic content?”
 GigaFLOP
 “Is
Networking
it possible to tap newly available GPU
resources to do useful things for a
network?”
On Possibility

Restraint Free Engineering


“Abandon All Practicality, Ye Who Enter Here”
You’ve got what you’ve got. Make interesting
things happen.



It might end up practical.
It might end up secure.
Right now, it’s impossible. Fix that first.

Maybe.
How To Do Impossible Things
(AKA Practical Impracticality)

Five Party Model for Technology Migration:
Client, Client Network, “Internet”, Server
Network, Server


Each have different goals, administrators, skill
levels, efficiency requirements, concern for error
recovery, profit from a given technology
Generally, the fewer parties must be tapped to
deploy a new technology, and the more direct
benefit to the parties actually deploying it, the
more likely it’ll see the light of day


Opposite is true – the more pain, the less gain, the less
chance it’ll get used
Client Network and Server Network have become
much more relevant w/ Firewalls
Layers: Not What, But Who
 One
medium, many messages
 Listeners
reconstruct meanings relevant to
themselves, ignore the rest
 Listeners decide for themselves what’s
important and what’s not to them

These decisions can change – firewalls, load
balancers, etc. increase role of client/server
networks, assume roles once reserved only to
endpoints
Message Modulation

Messages at one layer can modulate
messages received at another

Parties in the middle can be made to change
messages received at either end



Firewalls drop packets
Insufficient postage will prevent a correctly addressed
letter from getting sent
One way to create new functions is to use
inter-layer modulation to expose new
functionality

We’re going to modulate TCP in interesting ways
TCP (and UDP)
Connection Traits: Ports


IP handles who we’re talking to; Ports handle what
we want from them
Local Port: What application requested the
connection. Usually a random number, 0-65535.


0 is a valid port
Remote Port: What application accepted the
connection. Usually a “known number”



80 for HTTP
143 for IMAP
443 for HTTP/SSL
TCP Connection Traits:
Sequences

Sequence Numbers



32 bit number, randomly generated, must be
reflected by the opposite party in a TCP
handshake
After initial reflection, used to relay information
about successful packet acquisition
What if Sequence Number Isn’t Random?


You can hijack and kill arbitrary connections!
How do you detect that?
Zalewski’s Phase Space
Visualization
 Phase
Space
 Take
a 1D stream of numbers
 Get four numbers from it

s[n-3], s[n-2], s[n-1], s[n]
 Plot
points in a volume
x=s[n-3]-s[n-2]
 y=s[n-2]-s[n-1]
 Z=s[n-1]-s[n]
 Drop a point!

Phase Viz (1)
Phase Viz (2)
Phase Viz w/ Pixel Shaders

Using OpenQVIS, insanely powerful
volumetric viewer

GPL

Does all that nice funky MRI rendering
 20-40fps for 256x256x256


Pixel Shaders Are A Good Thing
Phentropy: Compiles arbitrary data to phase
space format for OpenQVIS
 “Putting GigaFLOPS To Work”
Phentropy: Bash $RANDOM
Phentropy: BSD Kernel
Phentropy: Photograph
Phentropy: Photograph (2)
TCP Connection Traits: Flags

The Famous Three Way Handshake

Connection Request (Alice -> Bob)


Connection Response (Bob -> Alice)



SYN|ACK: OK, lets talk.
RST|ACK: I ain’t listening
Connection Initiation (Alice -> Bob)


SYN: I want to talk to you
ACK: OK, beginning conversation.
Portscan Types



Normal: Send one, wait for its response
Fast: Send many, wait for every response
Usually keep track of who was scanned
Stateless Pulse Scanning

Instant Portscan


“Is it possible to discover instantaneously what
network services have been made available, even
on massive networks?”
Answer: Yes, practically, even securely


Separate scanner and listener processes
Sending


Directly send n SYN packets from same local port
Receiving


Kernel filter packets arriving to that local port
Extract from received packets IP, Remote Port, and
whether that Port was up (SYN|ACK) or Down(RST|ACK)

Why do we need to remember who we scanned?
Everything we want to know is included in their response.
Issue: Spoofed Responses
 Easy
to spoof hosts being up if the
scanner isn’t tracking who (or how it
scanned)
 Solution: Invert SYN Cookies!
SYN Cookies

By DJB in ’96, defense against SYN floods

Attack


Defense Mechanism


Spoof many SYNs from invalid IP’s. Kernel sends
SYN|ACKs, wastes large amounts of memory waiting for
ACKs that will never come. Kernel eventually dies
ACK reflects 32 bit SEQ# of SYN|ACK(+1) in ACK#
Defense Implementation


Receive SYN packet
Respond with SYN|ACK


Encrypt connection state into the SYN|ACK’s SEQ#
Receive ACK


Decrypt connection state from ACK’s ACK#
If IP is being spoofed, attacker never receives SYN|ACK,
so cannot receive cookie from SYN|ACK
Inverse SYN Cookies

SYN|ACK also reflects SEQ# of SYN in its
ACK#

Instead of tracking SYN|ACK reflections in the
ACK, track SYN reflections in the SYN|ACK
Encrypt “I scanned you” instead of “you
connected to me, here’s how”
 Implementation


Send SYN packet

Encrypt “connection state” into SYN’s SEQ#


Presently not including time – this prevents stateless
latency detection
Receive SYN|ACK or RST|ACK

Decrypt connection state from return packet’s ACK#-1. If
doesn’t match, don’t accept packet.
Inverse SYN Cookies
 Components
of reply known and
controlled by sender:
 Source
IP and Destination IP
 Source Port and Destination Port
 Initial Sequence Number (SEQ#)
 Source
IP, Destination IP, and
Destination Port are fixed
 Leaves Source Port and SEQ#
 48
bits worth of reflected capacity
Implementation: Scanrand 1.0

Element of: Paketto Keiretsu
 Couple hundred lines of libnet and libpcap




No per-host state stored
Scans at ~11-20mbit
Moderately portable
HMAC-SHA1 truncated at 32 bits


Actually simply authenticating message against stored
secret instead of encrypting/decrypting
Out “Real Soon Now”
Scanrand (1)
Scanrand (2)
Observed Results

Since no state is maintained within the
scanner, we can send SYNs at wire speed


Found ~8300 web servers on a corporation’s
Class B


Time spent: ~4 Seconds
Collisions


Implementation can get faster
Initial SYNs might collide, but SYN|ACKs resend
SYN|ACKs are given RSTs by present
kernels automatically

The SYNs were generated in userspace – the
kernel has no idea the connection request was
Spread Spectrum Traceroute

Mass Scan: Iterate Across IPs/Ports
 Traceroute: Iterate Across TTLs
 MassTrace: Iterate Across IPs/Ports/TTLs



“Take me one hop there, take me two hops there,
etc”, send me back an ICMP Error
Usually UDP or ICMP Ping
We do TCP – statelessly

ICMP contains original IP/TCP packets


Can use it to reconstruct
Inverse SYN cookies still work, but fail behind SEQ#
modulating firewalls (SEQ# not changed back to localvalid)
Scanrand MassTrace (Class
C)
Scanrand MassTrace (Class
B[1])
Scanrand MassTrace (Class
B[2])
Scanrand MassTrace (Class
B[3])
Advanced Scanrand Usage

Multiparty Scanning



Multiple hosts may send scans, spoofing their
sending address as the collector.
Scanrand supports explicit key synchronization –
important to vary keys over time or scans, or
replay attacks become (long term) trivial
Weaver: Source Route Network Analysis




Traceroute to point, discover TTL distance
Source route through point to faraway networks,
use TTL+1 to TTL+3 to discover neighbors
Source route through immediate neighbors to
other immediate neighbors to determine mesh
Source Routes not supported yet – but very soon
Future of Scanrand (1)

Temporal Host Identification (RING)

TCP is a reliable protocol – retransmits if it thinks
a packet was dropped




Retries x times
Waits yn milliseconds between retransmits
X and yn vary from OS to OS
If SYN|ACK never elicits a RST, remote host will
provide detectable signature of what operating
system it’s running

Requires RST suppression – probably by using an
alternate IP, possibly by using Dug Song’s generic
firewall interface
Future of Scanrand (2)

Stateless Content Download



Suppress normal RST to unknown SYN|ACK
ACK incoming SYN|ACKs, send arbitrary payload
(HEAD / HTTP 1.1 ^M^M)
ACK all incoming responses


Result: Lots and lots of packets
Postprocess with LibNIDS to convert raw packets to
usable information


Repurposing LibNIDS back into a network stack, albeit
unidirectional!
Code required to prevent remote host from keeping
connection state indefinitely based on our responses to
keepalives
Implications

Userspace manipulation of packets can lead
to less overhead


Packet content can be overloaded


Kernels are optimized to talk to other hosts, not
simply to scan them
A random field can always be replaced with
encrypted data (and vice versa)
Elegant solutions sometimes can be
reapplied elsewhere


SYN(really SYN|ACK) cookies made SYN
reception more efficient
Inverse SYN cookies make SYN transmission
more efficient
A New Problem

Scanrand



How does one host learn about many?
With lots and lots of traffic!
What if we don’t want to send lots of traffic?


What if we want to send data to lots of hosts,
using only one single packet?
Multicast: All Five Parties Must Cooperate


Internet only speaks Unicast
Client and Server networks speak Unicast and Broadcast


If Destination MAC = FF:FF:FF:FF:FF:FF or
01:00:5E:xx:xx:xx [multicast], packet should be broadcast
to all ports
Usually, last IP in subnet maps to broadcast. Usually.
Broadcast GHosts

Guerrila Multicast



“Is it possible to send a single packet to multiple
recipients, using today’s multicast-free Internet?”
Answer: Yes, barely.
ARP-Link a unicast IP to the broadcast MAC
address; all responses to that IP will then be
broadcast throughout a subnet!

No individual client need duplicate the datastream
– the switch will issue copies of the data to all
downstream hosts
IP Incorporated

Retrieve an IP



Answer ARP requests for that IP with
Broadcast MAC (or Multicast MAC)


Possibly via DHCP, possibly not
May or may not use broadcast MAC in DHCP
request – just trying to validate that nobody else is
using the IP (can also ARP Ping)
At L2, w/o IGMP Snooping working, Multicast =
Broadcast
Issue standard TCP/UDP requests from this
broadcast-linked IP
 Responses will go to anyone listening!
Firewall Issues

NAT

100% NAT penetration, as long as the
implementation doesn’t refuse to NAT for a
broadcast MAC



PIX refuses FF’s, but accepts Multicast MACs!
Multicast through NAT!
UDP


No mandatory acknowledgments for firewall state
machines to latch onto
Remote side can send data forever – as long as it
keeps packets coming in before the UDP state
expires, no further data is required from behind the
wall
TCP w/ Guerrila Multicast
Harder problem – listeners need to
acknowledge incoming data
 TCP
 Without
any listeners, stream dies
 With one listener, stream should operate
normally
 With many listeners, only one should
participate in acknowledging the stream

If any one dies, another should take its place
Solution: Random Delays

Solution: Random delays



On reception of a packet to be acknowledged,
queue a response within the next 50-1500ms
Broadcast response, public notification of
response (Everyone – I ACKed)
If another host broadcasted a response before you
had the chance to, unschedule your response


If another host sent data, sync SEQ# using info from
broadcast
Someone’s timer will expire first – if they fail,
someone else will take place
Recontextualizing L2/L3
 One
IP, normally linked to one host, can
be transformed at L2 into all hosts at a
given subnet
 This
transformation is undetectable outside
the subnet
 Do we have another other situation where
one IP “stands in” for many hosts?
NAT: Splitting IPs For Fun
and Profit

NAT multiplexes several hosts into one IP
address by splitting on local port


Behind the NAT, everyone has a private IP; in front
of the NAT, nobody knows exactly what local port
they’re sending from
NAT destroys end-to-end packet integrity

Like a postal service opening all mail and
transferring it into a new envelope – it can be
made to work, but has side effects
MAC Address Translation

“NATless NAT”



“Is it possible to share a globally addressable IP
address without translating private IP ranges a la
NAT?”
Is it possible to allow incoming connections to an
IP multiplexed in this manner?
Answer: Yes. Oh yes.



NAT: L4->L3
ARP: L3->L2
MAT: L4->(L3,L2)


Multiplex with L2/L3 instead of just L3
Make ARP Table dynamic, based on each individual L4
connection
Packet Integrity

If we can always match IP and Port, then we
can always maintain end-to-end correctness


May be adaptable to IPSec security
associations
Only have a problem 1/256 connections to
the same host

Decent chance that two hosts will randomly pick
the same local port number


Birthday Paradox: Collision chance = 1 /
sqrt(range_of_local_ports) = 1 / sqrt(65K) = 1/256
Alternate strategies exist – maybe switch on
SEQ#, force remote window to vary during periods
of near-sequence-overlap

Actively researching new techniques!
Implementation: MiNewt 1.0
 “My
New Translation Engine”
 Another
part of Paketto Keiretsu
 Translates
arbitrary local IP addresses
into globally routable IP addresses
 Complete userspace implementation –
an IP just “shows up” on your network
 Makes
for an excellent testbed
Minewt (1)
Minewt (2)
Minewt (3)
Minewt State Model

Instead of just storing IP_SRC, stores
IP_SRC, ETHER_DHOST, and
ETHER_SHOST
 Whoever you think you are, Minewt
dynamically returns your traffic to you




If IP_SRC == External IP, packets will retain endto-end integrity
If IP_SRC == RFC1918 IP, packets will be NATted
normally
If IP_SRC == Yahoo/Microsoft/Whatever, packets
will be NATted a little less normally
Multiple hosts can share the same IP address, if
MAC is different(and vice versa – Proxy ARP)
NAT2NAT
 NAT
makes outgoing connectivity easy,
incoming connectivity really hard
 Can we fix this? Can Minewt fix this?
NAT2NAT Standard: uPNP?

Upcoming Standard: Client + Client Network
+ Server Network + Server: uPNP



Standard based on HTTP-over-UDP
Part of observed on-installation cracks for net-aware XP
uPNP somewhat unrealistic for NAT
penetration – no real security model, which is
a dealbreaker for firewall cooperation

Physical connectivity implies a property
relationship; no such property relationship is
implied by network connectivity
Incoming NAT: L3 Flooding

Switches flood if they don’t know – IP can too


Only Server Network Needs Patch
Stateless approach: Ask everybody, drop
RST|ACK, forward everything else.



Everybody = All
Drop all RSTs, pass all streams/ACKs
Breaks down when two people are listening on the
same port



Can split port range(1022, 2022, 3022, etc. all being
different instances of 22/ssh)
Apply host-level heuristics – priority for incoming
selection based on outgoing sessions
Floods every packet – not just initialization
Incoming State

Stateful Approach

Flood all hosts w/ any unknown packet


Allow NAT state to be created by any valid
response that returns


Normal NAT just establishes state on SYN
Minewt implements response mode, but no
incoming host flooder (yet)


Not just ones that match established sessions
Minewt able to reconstruct state, even if the hosting
machine changes, when backend hosts send TCP
keepalives
Minewt is a proof of concept


OpenBSD PF in userspace much better idea
Networks not likely to install Minewt as a gateway!
NAT2NAT w/ Existing
Networks

NAT Deadlock Resolution


“Is it possible to establish a TCP connection
between two hosts, both behind NATs, without
modifying the client or server network?”
Answer: Yes…but it ain’t pretty.

Problem: Both firewalls want to make outgoing
connections, neither firewall wants to accept
incoming connections

Firewalls have no means of noticing they have mutually
opposing entries in their state tables (yet)


Spec later
Solution: Convince each firewall that the other
accepted the connection
NAT2NAT AFTER THIS IS
COMPLETELY ACADEMIC

Just use UDP!!!


Both sides flood eachother w/ oppositely ported
UDP packets
Eventually, both firewalls will have a packet
floating out on the internet addressed to eachother




Each will assume when they receive the other’s that it’s a
response to their own
Game developers figured this out years ago
Encapsulate FULL TCP STREAM (not just TCP
payload via UDP), and TCP handles unreliability
as normal
Networked TCP is harder. Why?
Trust Relationship:
An Analogy

Bill Gates ‘n Larry Ellison




Why? They can call anyone they want – their
secretaries won’t stop ‘em.
None of us can call them – their secretaries will
stop us.
If Bill or Larry did call us, they’d actually be able to
hear us reply.
Asymmetry is in the initiation


UDP has no inherent asymmetry, while TCP has
SYN/SYN|ACK/ACK
Once initiation is done, TCP and UDP are symmetrical
Setting Up
 Alice
and Bob both behind NATting
firewalls
 Firewalls
authorize all outgoing sessions,
block all incoming sessions
Block w/ state – no faking
 Only accept fully validated responses to
outgoing messages




Ports must oppose
SEQ#/ACK# must oppose
Total outgoing trust, minimal incoming trust
The Attempt

Alice tries to send a message to Bob






SYN hits Alice’s firewall, is given global IP + entry
in state table “connection attempted”
SYN travels across Internet
SYN hits Bob’s firewall, RST|ACK sent
RST|ACK hits Alice’s firewall, entry in state table
torn down, RST|ACK readdressed to Alice
Alice gets nowhere
Bob does the same thing
Analysis
 Good
 Entry
in firewall state table, awaiting a reply
 Bad
 Negative
reply, entry in state table
destroyed
 Can
we get the former without the
latter?
 phear
Doomed TTLs

Packet first hits local firewall, gets NAT entry,
travels across Internet, hits remote firewall,
gets shot down.


Good stuff closer to us, bad stuff farther away
TTL: Time To Live – SET TO ~4



Maximum number of hops packet is allowed to
travel along the network before being dropped
Used by IP to prevent routing loops
Used by us to prevent other firewall from
modifying our state table just yet
TTL Results

Alice SYNs w/ Doomed TTL




Bob SYNs w/ Doomed TTL


Alice’s Firewall expects response
Internet returns TTL Time Exceeded
Bob’s Firewall never returns RST|ACK
Same as Alice
Both firewalls have a hole open for eachother

Both waiting for SYN|ACK




Opposite Source/Destination IPs
Opposite Source/Destination Ports
Opposite 32 bit SEQ#/ACK# Sequence Numbers
Neither firewall can supply SYN|ACK
The Other Shoe Drops

Now you add a connection broker


HANDSHAKE ONLY.
Sends the SYN|ACK Host/Port/SEQ#
combination “virtually added” to firewall
packet acceptance rules

Larry Ellison: “Bill Gates is going to call here in
the next two minutes, please put his call through.”

Broker spoofs Alice to Bob, and Bob to Alice
 Broker requires significant cooperation from
Alice and Bob

“What ports did you send on? What SEQ# did you
use? How might your firewall have changed
these values?”
Local Port Strategies

Some firewalls do best effort to match


Some use random local ports




Just have clients use chosen ports
If both sides random, can’t do anything
If one side random, can use Birthday Paradox –
both sides send 256 TTL-limited attempts at
eachother; one should collide
53 bytes * 256 = 13Kbyte
Some increment from a fixed counter


Find minimum difference between two ports, flood
send that many connections
No TTL manipulation – we just want to sync
counters
Discovery Strategies

Broker-Query



Send test SYNs to broker, broker returns values
detected over legitimate TCP session
Usually necessary for IPs
Broker Source-Route



Source route through connection broker, drop the
route once the connection goes live
Should be very effective, possibly can be
implemented without libpcap/libnet
Needs much testing though
TTL-Based Firewall Analysis

Emit a SYN with a low TTL
 SYN spawns ICMP time exceeded error



Lowers the amount of Broker-based firewall
analysis, allows clients to be aware even


From scanrand traceroute, we know these contain
limited amounts of data about the original scan
Commonly “corrects” scan IP, but since Time
Exceeded messages usually came from
UDP/ICMP traceroutes, usually TCP ports and
sequence numbers aren’t “corrected”
Requires firewall to pass ICMP time exceeded
messages
Some issues with ICMP error mangling
Tricking Firewalls/IDSs

Alice can forge a connection from an arbitrary
IP by cooperating with Charlie




Alice looks like she’s connecting to Yahoo, but is
informing Charlie of the specifics of the connection
attempt
Charlie replies as if he was Yahoo, and begins a
TCP stream of arbitrary data to Alice from “Yahoo”
Alice acknowledges all data to “Yahoo” with the
doomed TTL – we continue low TTL count through
the data stream
Really messy in terms of ICMP time
exceeded messages, BUT logging systems
might drop these messages
Other NAT Strategies

State Management
 State = Buffers



Buffers need to be searched
Buffers need to be allocated
Buffers need to be overflown


If your name is Gobbles
NAT normally needs to be stateful

A packet comes in, and given the Source IP, the
Source Port, and the Destination Port, we check
our tables to rewrite on the internal interface the
Destination IP(not firewall) and maybe the
destination port too

The MAC address is always rewritten, but with MAT we
Stateless NAT: Possible?

State is all about things we have to remember


Stateless scanning is about extracting what we
need from what we get back
“Can we embed the NAT state in every
outgoing IP packet such that every response
received will contain the full NAT state”?

Answer: Yes, with a dozen bytes per packet
reflective side channel


Whatever I send is sent back to me
“Cookie”
IP Timestamps For Reflection

IP Timestamps Mode 3 (courtesy Jason
Spence)



IP Option against each host along the route. Up to
four 4 byte IP addresses are specified, with space
for up to four 4 byte timestamps to be added
If IP in the timestamp request matches IP of the
router, the router replaces the timestamp with its
own
If IP doesn’t match, pass along the timestamps of
others
IP Timestamps: 32 Bytes Of
Reflected State
Insert timestamps from invalid IP’s containing
not actual timestamps but NAT state
 Encrypt NAT state so it may not be modified
en route
 Decrypt NAT state upon packet return
 Problems




Need to insert IP options – may overflow packet,
may need to fragment, etc.
IP options are sometimes blocked by firewalls
Possibilities with TCP Timestamps too

Reply field contains 32 bits of user specified stamp
Fragmentation Handling

No Paketto Code Presently Handles
Fragmented Responses



Stateless fragment handling is a Hard Problem
NAT must reassemble – or keep old assembly – to
direct L4->L3
Massively Experimental Solution:
Nonfragmentable Reflective IP Options

IP Options can copy-on-fragment


Only IP Timestamps are supposed to reflect


It’s a bit you set
Stream ID’s might, but are small (ongoing research)
IP Timestamps have capacity, but no frag
protection.
Force-Defragmented IP
Timestamps
 Supported
by Minewt
 Set the high bit, see if people treat it
right
 Linux/BSD drop it (but they often fail to
reflect at all)
 Windows reflects happily!
 Don’t
know if fragment rule holds
More Options for Options

Options: Optional footers that are ignored
unless stacks explicitly coded to support them


Often used for side channels
Header-Length Options:

TCP: Explicit length field(th_off * 4) describes
header length, anything left over is options


40 bytes max
IP: Explicit length field(ip_hl * 4) describes header
length, anything in excess of fixed
length(LIBNET_IP_H) is options. Anything left
over, up to the length in ip_len, is the L4 header +
Payload.

40 bytes max
UDP Trailer Ops

UDP: Explicit length field(uh_len) describes
payload, anything left over – up to the limit
described in ip_len -- is options



Option data appears to be ignored – but this
may not be true for all platforms
If length is less than data in header, or extends
header past ip_len, all known platform reject
packet
Trailer Strategy Works For More Than UDP
Ethernet Trailers

Ethernet(encapsulating IP): Explicit length
field(ip_len) describes payload – the IP
packet. Anything left over, up to the limit
described in the Out Of Band frame
length(pkthdr->caplen), is options

SHOULDN’T route, but does?


Huge capacity, up to the frame limit(MTU)


Probably switches
Technically, no limit, though libnet probably enforces
MTU limitations
Ethernet(encapsulating ARP): ARP has fixed
length, with minor variability for hardware
addressed. Anything extra is your options.
Uses for Ethernet Trailers
 Obviously
an excellent covert channel
 Most
sniffers drop the trailer, due to its
common “randomness”
 (It’s not actually random – it’s whatever
was left over in the network card’s buffer)

This…can be attacked.
 Less
obviously, a perfect channel for
local, experimental cryptographic
signatures
Ethernet Options for Crypto

Sign every frame


Sign your ARPs
Opportunistic – anyone who doesn’t support
doesn’t notice signatures




Obviously can only sign/identify – encrypt/decrypt
pollutes genuine data
Intermediate hardware can identify, even append extra
signature
Does waste bandwidth somewhat – hosts are
sending data that may never be parsed!
Distribute keys/certs either in every
frame(high bw) or in each ARP

Resolves some MTU overflow issues

IPSec has been suffering with these
Crypto Signature Algorithms

RSA/DSA


Most trusted
Way too big for normal option usage



40 byte capacity in TCPo/IPo
There exists a “Secure TCP” spec w/ oversized options
for key exchange
ECC



Moderately trusted
366 bit signatures, 192 bit keys
Works well for Ethernet
Weil Pairing Possibilities

Weil Pairing


159 bit signatures, equivalent to RSA1024
Heart of new “Identity-Based Encryption” system
from Dan Boneh @ Stanford




159 bits is small enough to opportunistically add to
TCP options


Excellent if oversold crypto
Clients may compute a “subset” from a master public
key, encrypt to it such that only the full master private key
or the matching subset of that key may decrypt.
Works for signing too
IP options slow routing and get irrevocably blocked by
PIX
More work on this coming soon