Dan Kaminsky, CISSP

1

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 Whats
New Whats Coming
Dan Kaminsky, CISSP DoxPara Research www.doxpara.c
om
2
Interesting Problems

• Instant Portscan
• Is it possible to discover instantaneously what
  network services have been made available, even
  on massive networks?
• Guerrila Multicast
• Is it possible to send a single packet to
  multiple recipients, using todays multicast-free
  Internet?
• 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?
• NAT Deadlock Resolution
• Is it possible to establish a TCP connection
  between two hosts, both behind NATs?

3
More interesting problems

• Spread Spectrum Mapping
• It it possible to quickly discover traits of the
  exponentially branching routes accessible from a
  given point on a network?
• Non-Covert Capacity Sidebands
• 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?

4
New For nVidia

• Stateless HTTP
• Is it possible to statelessly host a web page,
  possibly with dynamic content?
• GigaFLOP Networking
• Is it possible to tap newly available GPU
  resources to do useful things for a network?

5
On Possibility

• Restraint Free Engineering
• Abandon All Practicality, Ye Who Enter Here
• Youve got what youve got. Make interesting
  things happen.
• It might end up practical.
• It might end up secure.
• Right now, its impossible. Fix that first.
• Maybe.

6
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 itll see the light of day
• Opposite is true the more pain, the less gain,
  the less chance itll get used
• Client Network and Server Network have become
  much more relevant w/ Firewalls

7
Layers Not What, But Who

• One medium, many messages
• Listeners reconstruct meanings relevant to
  themselves, ignore the rest
• Listeners decide for themselves whats important
  and whats not to them
• These decisions can change firewalls, load
  balancers, etc. increase role of client/server
  networks, assume roles once reserved only to
  endpoints

8
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
• Were going to modulate TCP in interesting ways

9
TCP (and UDP) Connection Traits Ports

• IP handles who were 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

10
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 Isnt Random?
• You can hijack and kill arbitrary connections!
• How do you detect that?

11
Zalewskis Phase Space Visualization

• Phase Space
• Take a 1D stream of numbers
• Get four numbers from it
• sn-3, sn-2, sn-1, sn
• Plot points in a volume
• xsn-3-sn-2
• ysn-2-sn-1
• Zsn-1-sn
• Drop a point!

12
Phase Viz (1)
13
Phase Viz (2)
14
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

15
Phentropy Bash RANDOM
16
Phentropy BSD Kernel
17
Phentropy Photograph
18
Phentropy Photograph (2)
19
TCP Connection Traits Flags

• The Famous Three Way Handshake
• Connection Request (Alice -gt Bob)
• SYN I want to talk to you
• Connection Response (Bob -gt Alice)
• SYNACK OK, lets talk.
• RSTACK I aint listening
• Connection Initiation (Alice -gt Bob)
• 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

20
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 (SYNACK) or
  Down(RSTACK)
• Why do we need to remember who we scanned?
  Everything we want to know is included in their
  response.

21
Issue Spoofed Responses

• Easy to spoof hosts being up if the scanner isnt
  tracking who (or how it scanned)
• Solution Invert SYN Cookies!

22
SYN Cookies

• By DJB in 96, defense against SYN floods
• Attack
• Spoof many SYNs from invalid IPs. Kernel sends
  SYNACKs, wastes large amounts of memory waiting
  for ACKs that will never come. Kernel eventually
  dies
• Defense Mechanism
• ACK reflects 32 bit SEQ of SYNACK(1) in ACK
• Defense Implementation
• Receive SYN packet
• Respond with SYNACK
• Encrypt connection state into the SYNACKs SEQ
• Receive ACK
• Decrypt connection state from ACKs ACK
• If IP is being spoofed, attacker never receives
  SYNACK, so cannot receive cookie from SYNACK

23
Inverse SYN Cookies

• SYNACK also reflects SEQ of SYN in its ACK
• Instead of tracking SYNACK reflections in the
  ACK, track SYN reflections in the SYNACK
• Encrypt I scanned you instead of you connected
  to me, heres how
• Implementation
• Send SYN packet
• Encrypt connection state into SYNs SEQ
• Presently not including time this prevents
  stateless latency detection
• Receive SYNACK or RSTACK
• Decrypt connection state from return packets
  ACK-1. If doesnt match, dont accept packet.

24
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

25
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

26
Scanrand (1)
27
Scanrand (2)
28
Observed Results

• Since no state is maintained within the scanner,
  we can send SYNs at wire speed
• Implementation can get faster
• Found 8300 web servers on a corporations Class
  B
• Time spent 4 Seconds
• Collisions
• Initial SYNs might collide, but SYNACKs resend
• SYNACKs are given RSTs by present kernels
  automatically
• The SYNs were generated in userspace the kernel
  has no idea the connection request was ever sent

29
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 local-valid)

30
Scanrand MassTrace (Class C)
31
Scanrand MassTrace (Class B1)
32
Scanrand MassTrace (Class B2)
33
Scanrand MassTrace (Class B3)
34
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 TTL1 to TTL3 to discover neighbors
• Source route through immediate neighbors to other
  immediate neighbors to determine mesh
• Source Routes not supported yet but very soon

35
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 SYNACK never elicits a RST, remote host will
  provide detectable signature of what operating
  system its running
• Requires RST suppression probably by using an
  alternate IP, possibly by using Dug Songs
  generic firewall interface

36
Future of Scanrand (2)

• Stateless Content Download
• Suppress normal RST to unknown SYNACK
• ACK incoming SYNACKs, send arbitrary payload
  (HEAD / HTTP 1.1 MM)
• 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

37
Implications

• Userspace manipulation of packets can lead to
  less overhead
• Kernels are optimized to talk to other hosts, not
  simply to scan them
• Packet content can be overloaded
• A random field can always be replaced with
  encrypted data (and vice versa)
• Elegant solutions sometimes can be reapplied
  elsewhere
• SYN(really SYNACK) cookies made SYN reception
  more efficient
• Inverse SYN cookies make SYN transmission more
  efficient

38
A New Problem

• Scanrand
• How does one host learn about many?
• With lots and lots of traffic!
• What if we dont 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 FFFFFFFFFFFF or
  01005Exxxxxx multicast, packet should be
  broadcast to all ports
• Usually, last IP in subnet maps to broadcast.
  Usually.

39
Broadcast GHosts

• Guerrila Multicast
• Is it possible to send a single packet to
  multiple recipients, using todays 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

40
IP Incorporated

• Retrieve an IP
• 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)
• Answer ARP requests for that IP with Broadcast
  MAC (or Multicast MAC)
• 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!

41
Firewall Issues

• NAT
• 100 NAT penetration, as long as the
  implementation doesnt refuse to NAT for a
  broadcast MAC
• PIX refuses FFs, 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

42
TCP w/ Guerrila Multicast

• TCP Harder problem listeners need to
  acknowledge incoming data
• 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

43
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
• Someones timer will expire first if they fail,
  someone else will take place

44
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?

45
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 theyre 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

46
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-gtL3
• ARP L3-gtL2
• MAT L4-gt(L3,L2)
• Multiplex with L2/L3 instead of just L3
• Make ARP Table dynamic, based on each individual
  L4 connection

47
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!
• P0f Passive Fingerprinting shows promise

48
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

49
Minewt (1)
50
Minewt (2)
51
Minewt (3)
52
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
  end-to-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)

53
NAT2NAT

• NAT makes outgoing connectivity easy, incoming
  connectivity really hard
• Can we fix this? Can Minewt fix this?

54
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

55
Incoming NAT L3 Flooding

• Switches flood if they dont know IP can too
• Only Server Network Needs Patch
• Stateless approach Ask everybody, drop RSTACK,
  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

56
Incoming State

• Stateful Approach
• Flood all hosts w/ any unknown packet
• Not just ones that match established sessions
• 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)
• 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!

57
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 Yesbut it aint 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

58
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 others
  that its 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?

59
Trust Relationship An Analogy

• Bill Gates n Larry Ellison
• Why? They can call anyone they want their
  secretaries wont stop em.
• None of us can call them their secretaries will
  stop us.
• If Bill or Larry did call us, theyd actually be
  able to hear us reply.
• Asymmetry is in the initiation
• UDP has no inherent asymmetry, while TCP has
  SYN/SYNACK/ACK
• Once initiation is done, TCP and UDP are
  symmetrical

60
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

61
The Attempt

• Alice tries to send a message to Bob
• SYN hits Alices firewall, is given global IP
  entry in state table connection attempted
• SYN travels across Internet
• SYN hits Bobs firewall, RSTACK sent
• RSTACK hits Alices firewall, entry in state
  table torn down, RSTACK readdressed to Alice
• Alice gets nowhere
• Bob does the same thing

62
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

63
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

64
TTL Results

• Alice SYNs w/ Doomed TTL
• Alices Firewall expects response
• Internet returns TTL Time Exceeded
• Bobs Firewall never returns RSTACK
• Bob SYNs w/ Doomed TTL
• Same as Alice
• Both firewalls have a hole open for eachother
• Both waiting for SYNACK
• Opposite Source/Destination IPs
• Opposite Source/Destination Ports
• Opposite 32 bit SEQ/ACK Sequence Numbers
• Neither firewall can supply SYNACK

65
The Other Shoe Drops

• Now you add a connection broker
• HANDSHAKE ONLY.
• Sends the SYNACK 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?

66
Local Port Strategies

• Some firewalls do best effort to match
• Just have clients use chosen ports
• Some use random local ports
• If both sides random, cant 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
• Need to discover what strategy is being used

67
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

68
TTL-Based Firewall Analysis

• Emit a SYN with a low TTL
• SYN spawns ICMP time exceeded error
• 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 arent corrected
• Lowers the amount of Broker-based firewall
  analysis, allows clients to be aware even
• Requires firewall to pass ICMP time exceeded
  messages
• Some issues with ICMP error mangling
• Scanrand parses ICMP errors in verbose mode,
  Fspy tool coming to actively audit

69
Tricking Firewalls/IDSs

• Alice can forge a connection from an arbitrary IP
  by cooperating with Charlie
• Alice looks like shes 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

70
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 extract the correct MAC from the state table

71
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

72
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 doesnt match, pass along the timestamps of
  others

73
IP Timestamps 32 Bytes Of Reflected State

• Insert timestamps from invalid IPs 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

74
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-gtL3
• Massively Experimental Solution Nonfragmentable
  Reflective IP Options
• IP Options can copy-on-fragment
• Its a bit you set
• Only IP Timestamps are supposed to reflect
• Stream IDs might, but are small (ongoing
  research)
• IP Timestamps have capacity, but no frag
  protection.

75
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!
• Dont know if fragment rule holds

76
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

77
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

78
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-gtcaplen), is
  options
• SHOULDNT route, but does?
• Probably switches
• Huge capacity, up to the frame limit(MTU)
• 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.

79
Uses for Ethernet Trailers

• Obviously an excellent covert channel
• Most sniffers drop the trailer, due to its common
  randomness
• (Its not actually random its whatever was
  left over in the network cards buffer)
• Thiscan be attacked.
• Less obviously, a perfect channel for local,
  experimental cryptographic signatures

80
Ethernet Options for Crypto

• Sign every frame
• Sign your ARPs
• Opportunistic anyone who doesnt support
  doesnt 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

81
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

82
Weil Pairing Possibilities

• Weil Pairing
• 159 bit signatures, equivalent to RSA1024
• Heart of new Identity-Based Encryption system
  from Dan Boneh _at_ Stanford
• 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
• 159 bits is small enough to opportunistically add
  to TCP options
• IP options slow routing and get irrevocably
  blocked by PIX
• More work on this coming soon