* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download slides #2 - The Fengs
Wireless security wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Airborne Networking wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Computer network wikipedia , lookup
Point-to-Point Protocol over Ethernet wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Network tap wikipedia , lookup
Serial digital interface wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Parallel port wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Internet protocol suite wikipedia , lookup
Deep packet inspection wikipedia , lookup
Wake-on-LAN wikipedia , lookup
TCP congestion control wikipedia , lookup
Real-Time Messaging Protocol wikipedia , lookup
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