CS 6250 Test3 – Georgia Tech
9. Software Defined Network
- Network Management Overview
- Network Operations and Management
- Software Defined Networking
- Traffic Engineering
- Network Security
- What is network management?
- Process of configuring network to achieve a variety of tasks
- Load balancing
- Security
- Business Relationships
- Mistake can leads to..
- Oscillation
- Routers can’t agree to the route to destination
- Loops
- Partitions
- Black hole
- A packet reach to a router that doesn’t know what to do and drop it
- Why is configuration hard?
- Defining correctness is hard
- Interactions between protocols -> unpredictability
- Operators make mistakes
- Each device is configured to the vendor specific
- What operators need (and what SDN provides)
- Network-wide views
- Network-level objectives
- Direct Control
- Rather than configuring each device
- Direct manipulation of data plane
- Router should..
- Forward packets
- Collect measurements
- (x) Compute routes
- Can be (logically) centralized and controlled
- SDN
- => Remove routing from routers
- SDN
- What is an SDN?
- Today’s network has 2 functions
- Data plane
- Forward traffic to destination
- Control Plane
- => Data & Control on routers
- In SDN
- Control plane runs on logically centralized controller
- Network-wide control
- Separation of Data and control
- Moved from vertically integrated devices, slow innovation => Open interface, fast innovation
- Control devices by software
- What are advantages of SDN?
- Overview
- History
- Pre-2004, distributed configuration
- Router control protocol
- BGP only
- 2005, 4D
- Decision plane
- Data plane
- Dissemination / Discovery plane
- 2008, Openflow
- Can be practical only when vendors open their api
- To make switch cheap sets can be controlled from software
- Allow us to decouple control and data
- Infrastructures
- Applications
- Advantages of SDN
- Separate control plane
- Coordination
- Evolve
- Reasoning
- => Allow us to apply all CS techniques
- Infrastructure
- Control plane
- Software program (python, C)
- Controller affects forwarding state using control command
- Data plane
- Applications
- This course
- Data centers
- Backbone networks
- Enterprise networks
- Internet exchange points (IXPs)
- Home networks
- Examples of control plane operations
- Compute state (forwarding path) that satisfies high-level policy
- Computing a shortest path routing tree
- Authenticating a user’s device based on MAC address
- (x) rate-limiting traffic
- Typically done in data plane
- (x) Load balancing traffic based on hash of source IP
- Decision made in forwarding time not by centralized controller
- Control and Data Planes
- Control Plane
- Logic that controls forwarding behavior
- Examples:
- Routing protocols
- Configuration for network middleboxes
- Data Plane
- Forward traffic according to control plane logic
- Examples:
- Routing protocol (control plane)
- => Forwarding table entries (data plane)
- Why separating data and control a good idea?
- Independent evolution
- Control from high-level program
- Easier debug/check behavior
- Provide opportunities
- Data centers
- Better network management
- Routing
- More control over decision logic
- Enterprise network
- Research
- (x) No single point of failure
- (x) Ability to scale
- Example: Data center
- There are many racks of servers
- Problem
- Provisioning/migration in response to varying load
- Solution
- Program switch state from a central database
- If we migrate a VM from a server to another,
- We must update switch state
- It is easier to do with central controller (db)
- Servers are addressed with layer 2 addressing
- -> Servers can be migrated without requiring new VM to obtain new address
- -> All it needs to be happen is to update the switch state
- Challenges
- Example: Backbone security
- Goal
- Filter attack traffic
- Measurement system detect attacker’s entry point
- RCP (controller) install null route to ensure no traffic comes from the attacker
- Scalability
- One controller responsible for hundreds of switches
- Consistency
- Ensure different replicas (controllers) see same view
- Security/Robustness
- Coping with scalability
- Eliminate redundant data structure
- Only perform control-plane operations for a limited # of ops
- Cache forwarding decisions in switches
- Run multiple controllers
- (x) sending all traffic to controller
- Different SDN controllers
- NOX
- RYU
- Floodlight
- Pryetic
- Frenetic
- NOX
- First generation openflow controller
- Open source, stable, widely used
- Two flavors
- Components
- Switches
- Network-attached servers
- Abstraction
- Control
- Flow granuality
- Flow = {srcIP, dstIP, srcPort, …}
- Operation
- Flow <header:counter, actions>
- header : 10 tuples
- Counter: maintain statistics
- Actions
- Should be performed on packets that matches to the flow definitions
- Forward, drop, seed to controller
- Update controllers
- Applies corresponding actions
- Program Interface
- Events
- Controller
- Know how to process different types of events
- Keeps track of network view
- Events
- Switch join/leave, packet received, …
- NOX characteristics
- C++
- Openflow 1.0
- Model : event based
- -> event handlers for NOX control
- (o) performance
- (x) need to use low-level openflow commands
- (x) only C++ (slow for dev) (POX for python)
- When to use POX?
- Class, University research
- (x) performance
- (o) eash (python)
- Ryu, Floodlight, Nox, Pox
- Ryu
- Python
- OF 1.0~1.3, Nicria
- Openstack
- (x) performance
- Floodlight
- Java
- OF 1.0
- Fork from “beacon”
- (o) Documentation
- (o) Integration with REST
- (o) performance
- (x) hard to learn
- Nox
- C++
- OF 1.0
- (o) performance
- (x) Slow programming
- Pox
- Python
- OF 1.0
- (x) performance
- (o) easy to program
- Customizing Control
- Review hub/switches
- Pox controller w/ simple Mininet topology
- Two types of control
- Hub
- Maintains no state
- Simply forwards the input packet to every output ports
- In Pox
- Add listener for a switch connect
- Use OF flow modification to the switch to flood
- Switch
- Maintain switch table
- Learning switch
- When a packet arrives from a host using a port, the switch updates table
- In Pox
- Update address/port table
- Controller maintains the table
- If multicast, flood
- If no table entry (dst), flood
- If src == dst, drop
- Install flow flow table entry
- Prevents future packet to the flow from being redirected to the controller
- It can be directly handled by switch
- Summary
- OF makes modifying forwarding bahavior easy
- Switching
- {*,*, …, DST MAC, *} -> output port
- Flow switching
- {switch port, srcMac, … all filled} -> output
- Firewall
- {*, srcMac, *, *, …} -> forward/ drop
- Caching
- Packets only reach controller if no flow table entry at switch
- When controller decides an action, installs it in switch
- Decision/ flow table is cached
- Customizing control is easy
- Turning switch -> firewall < 40 lines of code
- Performance benefits of caching rules/decisions
9.1 Programming SDNs
10. Traffic Engineering
- Traffic Engineering Overview
- Traffic Engineering
- Process of reconfiguring the network in response to changing traffic loads, to achieve some operational goal
- Some goals…
- Peering ratios
- Relieve congestion
- Balance load
- IP networks must be managed
- “Self-management”
- TCP
- Send less during congestion
- Routing
- Adopt to topology changes
- Problem:
- Does the network run efficiently?
- How routing should adapt to traffic?
- Avoid congested links
- Satisfying application requirements
- Outline
- Tuning routing protocol configuration
- Intra & Interdomain Traffic Engineering
- Multipath routing
- Intradomain TE: Tuning link weights
- Routers flood information to learn topology
- Operator configures link weights
- Possible settings:
- Inversely proportional to capacity
- Proportional to propagation delay
- Network-wide optimization
- Measuring, Modeling, and Controlling traffic
- 3 steps: Measure, Model, Control
- Measure topology and traffic
- Build “what-if” model
- Change configuration to control network behavior
- Intradomain TE: Optimization
- Input: Graph G(R,L) (R: router, L: links), cl: capacity of l
- Mij: Traffic from router i to router j
- Output:
- Link utilization Function
- Objective function
- Utilization: ul/cl
- Objective: min f(ul/cl) in the all links
- Practice:
- Minimize # of degrees to network
- Resistance to failure
- Robust to measurement noise
- Intra vs Interdomain routing /TE
- Intradomain:
- Within a domain (e.g, ISP, campus, datacenter)
- Interdomain:
- Between domains
- eg)
- Peering between ISPs or university networks
- Peering at an internet exchange point
- BGP in interdomain TE
- Interdomain traffic engineering
- Allowing congestion on edge links
- Using new/upgrade edge lineks
- Changing end-to-end path
- -> reconfiguration of BGP
- Goals for Interdomain TE
- Predictability
- Try to avoid globally visible changes
- Or it can make it works (check lecture figures)
- Limit influence of neighbors
- Forcing consistent advertisement is difficult but doable
- Limit AS path influence
- Reduce overhead of routing changes
- Group routes that has same path
- Can move groups of prefixes according to the groups of the prefixes that shares AS paths
- Multipath routing
- Operator establish multipath in advance
- For Interdomain
- Equal cost multipath (ECMP)
- Traffic splitting
- 35% to upper, 65% to lower path
- How can a source router adjust path?
- Alternating between forward table entries
- Have multiple forward table entries for same dst
- Data center networking
- Charastertics
- Multi-tenancy
- (o) Allow to amortize cost shared infrastructure
- (x) Security because multiple users
- (x) Resource isolation
- Elastic resources
- Operator can expand or contract resources depends on demand
- Flexible service management
- Ability to move workload to other locations inside of datacenter
- Workload management, migration
- -> Requires TE
- Enabler: Virtualization
- Data Center Network Challenges
- Challenges
- Traffic load balance
- Support for virtual machine migration
- Power saving
- Provisioning
- Security
- Data center topology (check out lecture figures)
- Core
- Historically connected to layer3
- Modern: all layer-2 topology
- (o) easier migration
- Since servers can stay in same layer-2 network
- -> no need new IP address
- (o) easier load balance
- (x) scale
- Too many servers in a single “flat” topology
- Problem with this topology
- (x) potential single point of failure
- (x) links on top can be oversubscription
- Aggregation
- Access
- Data center topology
- (x) scale
- One solution
- Pods
- Each pod has address
- Each server has “pseudo mac” corresponding to pod
- Switches no longer need to maintain forwarding table for every host
- Only need to maintain entries for reaching other pods
- Once it reaches the pod, the switch for the pod has entries for the servers
- Problem: mapping
- Pseudo mac -> real mac!
- Interrupt ARP
- The switch forward it to fabric manager instead of flooding it
- Fabric manager responds with the pseudo address
- The server sends the frame with the destination pseudo address
- The receiving switch switch pseudo mac -> real mac
- Achieve hierarchical forwarding in a large layer-2 topology without modifying any host’s software
- Data center (intradomain) TE
- Limited server-to-server capacity
- Links at “top” of fat tree topology are over-subscribed
- Fragmentation (for resource)
- Because of migrations
- May require complicated L2/L3 re-configuration
- VL2
- Want: Abstraction of BIG L2 switch
- Achieve layer-2 semantics across the entire data center topology
- Done by name, location separation and a resolution that resembles fabric manager
- Achieve uniform high capacity between servers and balance load across links
- Flow based random traffic interaction
- Valiant load balancing
- Goals
- Spread traffic evenly across servers
- Access layer randomly select a switch from indirection layer
- The intermediate switch forward the packet to the dst
- Location Independence
- Jellyfish: Networking Data Centers Randomly
- Goal
- High throughput
- Incremental expandability
- Easy replacement of servers
- Problem: Structure constrains expansion
- Hypercube: 2^k switches
- 3-level fat tree: 5k^2/4 switches
- Top level switches constrains expansion
- Jellyfish: Random Regular Graph
- Random:
- Each graph is randomly selected from regular graphs
- Regular graph
- Each node has same degree
- Graph
- Construction
- Construct random graph at top of switch layer
- RRG(N,k,r)
- ki : total ports
- ri: to connect to other TopofRack switches
- Ki-Ri ports to connect to servers
- With N rackes, the network supports
- Constructing Jellyfish (check lecture figures)
- Pick a random (not neighboring) switch pair
- Join them with a link
- Repeat until no links can be added
- High capacity is achieved because of shorter paths
- Can reach more servers in same number of hop jumps
- Open questions
- Topology design
- How close are random graphs to optimal?
- What about heterogeneous switches?
- System design
- How to physically cable?
- How to perform routing or congestion control?
11. Network Security
- Need for Network Security
- Attacks on:
- Routing (BGP)
- Naming (DNS)
- Reflection (DDos)
- Generate large amout of traffic targetted at a victim
- Phishing
- An attacker expliots the DNS and attempt to trick a customer
- Internet is Insecure
- Internet is designed for simplicity
- Security was not a primary issues
- On by default
- When a host is connect to internet, it is reachable any other hosts with public IP by default
- Hosts are insecure
- Attacks can look like “normal” traffic
- Collection of traffics can be a attack
- Federated design
- Because there are many individual networks run by different network operators, it is difficult to coordinate a defense
- (x) IP addresses are easy to guess
- Resource Exhaustion Attack
- Packet Switching Network Vulerable: Resource Exhaustion
- A link can be shared by different senders by statistical multiplexing
- A large number of senders can overload node or link
- Phone network doesn’t have this problem (statically dedicated resource)
- Attacks a basic component of security (availability)
- Components of Security
- Ability
- Ability to use a resource
- Confidentially
- Conceal information (bank, …)
- Authenticity
- Assures origin of information
- Integrity
- Prevent unauthorized changes
- Threat: Potentially violate one of the conponents of security
- Attack: Action that violates the components
- Attacks on Confidential
- Eavesdropping
- Packet sniffing tools
- Wireshark, tcpdump
- Set network card in promiscuous mode
- DNS
- What website someone is visiting
- Packet headers
- Full packet payload
- See everything you are sending on network
- Content, messages, …
- Attack on Authenticity
- Eve might modify it and reinject to the network
- Man in the middle
- Negative impacts of attacks
- Thief of confidential info
- Unauthorized use
- False info
- Disruption of service
- Routing Security (BGP)
- Control plane security (authentication)
- Determine the veracity of routing advertisement
- Session
- Protects point-to-point between routers
- Path
- Origin
- Guarantee the origin AS that advertises the prefix is the owner of prefix
- Router hijack
- Because the advertisement was not from right owner
- Data plane
- Data travelling to the intended locations (route)
- Route Attacks
- How?
- Misconfiged router error
- Routers compromised by attacker
- Attacker reconfigure the router
- Unscrupulous ISP
- Types of attack
- Config / or change config with sw
- Tamper with software
- Tamper with routing data
- Most common
- Route Hijacking
- Why hijack matter: DNS masquerade
- Attacker runs rough DNS server and hijack DNS query or to return false IP
- MITM
- Traffic reaches the destination, but the attacker inserts themselves in the path
- Problem:
- We need to somehow disrupt the routes to the rest of the internest while leaving the routes between the attacker and the legitimate AS
- Solution:
- By AS poisoning
- insert 10, 20 on AS path MITM
- 10 and 20 will drop the announcement becasue they think they’ve already heard it and don’t want to form a loop
- Other ASes will switch path
- Attacker can hide!
- Even when sender runs trace route
- Trace route consists of ICMP time exceeded message
- Attacker don’t decrease TTL where other hops decrease it
- Then it won’t generate no time exceeded message
- Session Authentication
- The session is TCP connection between routers
- Use MD5 authentication
- Send (M (message), MD5(M, k)); k: shared secret
- Network agree on k at the outside of network
- TTL hack
- AS1 send with TTL224, and AS2 drops packets TTL < 224
- Origin and Path Authentication
- Guaranteeing Origin & Path Authentication
- New BGP
- Secure BGP (BGPSEC)
- Add signature to route advertisement
- Origin Authentication (Address Attestation)
- Certificate binding prefix to owner
- Certificate must be signed by trusted party
- Path Attestation
- Setup signature along AS path
- ki : secret key of AS i
- P -> AS1 -> AS2 -> AS3
- [1]
- (P, 1) : (prefix, AS path)
- {2,1}k1 : attestation
- [2]
- (P, 2 1)
- {3, 2, 1} k2
- Use this to make sure next hop is 2
- {2,1}k1
- Check if there’s any other AS inserted by comparing with (P, 2 1)
- Why have {3,2,1} and {2,1}?
- If AS1 generate {1}k1, an attacker can steal and replay right away
- But if AS1 generate {1,2}k1, an attacker cannot make {1}k1 or {4,1}k1 because the attacker doesn’t have k1 key
- => AS generate signs with its own AS path and next AS along the path
- Prevents
- Hijacking
- Path shortening attack
- Modification
- Cannot prevent
- Suppression
- If an AS fails to advertise a route or a route withdrawl, there’s no way for the path attestation BGPSEC to prevent that kind of attack
- Replay
- Premature re-advertisement of a withdrawn route
- No way to guarantee the data traffic travels along the advertised AS path
- Significant weakness of BGP
- DNS Security
- DNS architecture
- MITM
- Stub -> Caching resolver
- Read query and it responds
- -> use DNSSEC protection
- Cache Resolver
- Cache poisining
- Attacker can send reply back to the resolver before real reply comes back
- -> use 0x20 protection
- Spoofing
- Master Authenticative (<- cache resolver)
- SlaveAuthenticative (<-Master Authenticative)
- Dynamic update system (-> Master Authenticative)
- -> use DNSSEC protection
- Corrupt
- Zone file (->Master Authenticative)
- DNS reflection attack
- DNS can be a “weapon” for DDos
- Why is DNS vulerable
- Resolvers trust responses
- regardless where those comes from
- Responses can contain info unrelated to query
- No means for Authentication for responses!!
- DNS quires are connectionless (UDP)
- Resolver can’t map response for the query (other than query id)
- query id can be forged by attacker
- DNS cache poising
- Stub resolution (A, google.com) -> Recursive resolver -> (A, google.com) -> SoA (Server of Authority)
- Attacker -> Recursive resolver
- Flood with replies with different query id
- Attacker doesn’t need to see the actual id, it just flood
- If attack respond reaches faster than the actual response,
- Cache the bogus response!
- Defenses
- query id
- Randomized ID (only 16 bits)
- Rather than having a resolver send quires with sequencly incrementing ID the resolve pick random id
- It is harder to guess for attacker, but it’s still not too hard
- Attacker can generate his own DNS quries
- 1. google.com, 2. google.com, …
- It will generate new race
- Eventually, attacker will win one of the races
- Attacker can respond with NS record not only A
- Kaminsky attack
- Create one of these races using an A record query, and responding not only with the A record, but also with the authoritative NS record for the entire zone
- Attacker can own the entire zone
- Defense to DNS cache poisoning
- ID + Randomization
- Source port randomization
- Randomize the port which it sends query
- Adding another 16 bits
- (x) it can be resource intensive
- (x) NAT (network address translator) could derandomize the port
- 0x20 Encoding
- DNS is case insensitive
- GoOGle.com == google.com
- Adding another entropy
- Only the resolver and the authoritative know exact pattern
- Add another entropy
- DNS Amplification Attack
- Exploits asymmetry in size between queries & responses
- Attacker send DNS query with victim’s IP as source
- DNS will response to the victim with large size which causes traffic
- DDos on victim
- Defenses:
- Prevent IP address Spoofing
- Using appropriate filtering rules
- Disable open resolver
- Disable the resolver to resolve queries from arbitrary locations
- DNSSEC DNS Security
- DNSSEC
- Add Authentication to DNS responses
- By adding signatures
- Resolver -> (root)
- Resolver <- (NS.com) (sig(IP + Pk of .com server)) (root)
- signed by root’s private key
- Pk: Public key of .com server
- As long as the resolver have public key corresponding to root, it can check signature, and it knows public key for .com server
- Resolver <- (NS google.com) (sig(IP + Pk of google.com)) (.com)
- Resolver can check if the respond is not bogus because it already has .com’s public key
11.1 Internet Worms
- Types of Viruses and Worm Overview
- Virus
- Infection of an existing program that results in modification of behavior
- Spread typically requires user action
- Spread manually
- Worm
- Code that propagate/replicate across the network
- Spread by exploiting flaws
- Spread automatically
- By scanning vulerabilities and infect vulerable hosts
- Types of Viruses
- 1. Parasitic
- 2. Memory-resident
- 3. Boot-sector
- Spreads when system is booted
- 4. Polymorphic
- Encrypt part of virus program using randomly generated key
- Worm might use any of the techniques to infect before spread
- Worm Lifecycle
- 1. Discover
- Scan for vunlerable hosts
- 2. Infect vulnerable machines via remote exploit
- 3. Remain undiscoverable
- First Worm: “Morris Worm”
- Robert, 1988
- No malicious payload
- but, resrouce exhaustion
- affected 10% of internet hosts
- Spread through multiple vectors
- Remote shell execution/ weak password
- Targeted trusted hosts by already infected machine
- Buffer overflow/ remote exploit
- Debug command in sendmail service
- Worm Outbreaks In Detail
- Three major worm outbreaks
- 1. Code Red 1 (2001)
- “modern” worm
- IIS buffer overflow
- 1th ~ 20th : spread
- Infects “random” scanning bug
- Payload
- DDos on whitehouse.gov
- But failed because it targetted an IP not the domain
- 2. Code Red 2
- Same vulerability, different payload
- Only spread on Windows 2002
- Scan preferred nearby addresses
- Because if there’s 1 vulnerable host, it is likely to be more (maybe because same admin)
- Payload
- 3. Nimda (multi-model)
- Spread by
- IIS vulnerablilty
- Build email
- Network shares
- Installed code in webpage
- Anyone browser visiting the webpage would be infected
- Signature based defenses don’t help
- Because it uses many ways to spread
- Zero-day attack
- Email carrying Nimda was untouched
- Because it had unknown signature, and the scanner couldn’t detect
- The signature of worm was not extracted
- Extrremely easy to spread befure any anti-virus catches up
- Modeling Fast-spreading Worms
- Random Constant Spread
- k: initial compromised rate
- N: vulerable hosts
- a: fraction of host already compromised
- Nda (new infected in dt) = (Na) * (k(1-a) (rate of uninfected machines become compromised)) dt
- a = (e^k(t-T))/(1+e^k(t-T))
- => we need to have “k” (initial compromised rate) as high as possible
- Increasing Initial Compromised Rate
- Hit List
- Create hit list (list of vulnerable hosts) ahead of time
- Permutation Scanning
- Every infected hosts has shared permutation of IP address lists.
- Start from own IP & work down
- Different own IP -> make sure to not duplicate
- Slammer Worm
- Entire code in one UDP packet!
- => UDP is connectionless!
- Damage on ATM, cellphone, …
- Did not have payload
- But the bandwidth exhaustion cause resource exhaustion
11.2 Spam
- Span: Unwanted Commercial Email
- Most span ends up in your spam folder
- Problem
- 1. Filters
- Someone has to design this
- 2. Storage
- Server has to keep the spam until user deletes it
- 3. Security Problem
- Filter
- Prevent message from reaching inbox
- How to differentiate Spam from “ham”?
- 1. Content based (particular words)
- (x) easy to evade
- (x) building filter and update it is expensive
- 2. IP address of sender (blacklist)
- Sender -> receiver -> DNSBL (blacklist)
- Receiver can decide to not even receive it
- 3. Behavior features
- Filter based on “how” message is sent
- Particular time or of day or location
- Sent batch of emails with roughly same size
- Challenges
- 1. Understanding network level behavior
- 2. Building classifiers using network features to execute the filter
- Surprise: BGP “Agility”
- 1. Hijack IP prefix (short period of time: 10 min)
- 2. Send spam
- 3. Withdraw
- => Ephemeral IP address
- IP blacklist is ineffictive
- Set of Network-level features
- 1. Single-packet
- Distance b/w sender & receiver
- Density of IP space
- How many email senders are nearby
- Time of day
- AS of sender’s IP
- 2. Single-message
- # of recipients
- length of message
- 3. Aggregate
- See groups of messages
- Variation in message length
- SNARE (Spatio Temperal Netowk Level Automated Reputation Engine)
- Use Network-level features
- 70% detection: good enough
11.3 Denial of Service Attacks
- Denial of Service Overview
- What is DDos?
- Attempt to exhaust resources
- Network bandwidth
- TCP connections
- Host might have limited # of TCP connections
- Server resources
- Web server might have to do complicate job to render
- Defenses
- Ingres Filtering
- drop if src != 111.111.111/24
- Works with stub system
- Stub network has only one IP address
- (o) fool proof
- (o) works at edge
- (x) doesn’t work in core
- uRPF
- User routing tables to determine where the packet could feasibly arrived on a particular interface
- x -> 10.0.1.0/24 -> AS1, x -> 10.0.18.0/24 -> AS2
- if src (10.0.18.3) from 1 -> x
- (o) automatic
- (x) requires symmetric routing
- routing in internet is often asymmetric
- Sync Cookies (TCP)
- TCP 3-way handshake
- C -> syn -> S
- S -> syn-ack -> C
- C -> ack -> S
- S -> ack -> C
- Problem
- Client can send syn to make server to allocate buffer
- The syn can be spoofed IP
- Solution : Syn Cookie
- No buffer allocated on C->syn->S
- Instead create seq# = f(srcIP, …, random # to prevent reply attack)
- S -> syn-ack (seq#) -> C
- C -> ack (seq#) -> S
- (x) can be applied in the network “core”
- (x) Defense against UDP flooding attacks
- inferring Dos Activity (“Backscatter”)
- IP address spoofing -> “blackscatter”
- attacker(y) -> tcp syn(src:x) -> victim
- victim -> syn-ack -> x (backscatter)
- If src:x is selected random,
- we can setup a portion of network Telescope/8 to monitor the backscatter traffic
- syn-ack goes to this network
- If src:x is picked uniformly random, the amount of traffic we see as backscatter represents exactly fraction of propotional to the size of overall attack
- n IP address, m backscatter packets,
- We expect to see (n/2^32) * m of total backscatter packets == total attack rate
- Total attack rate (m) = x * (2^32/n)
- x: observered attack rate
- n: 2^24 because Telescope/8
