slides #2 - The Fengs
Download
Report
Transcript 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