SRM / Intro to security

SRM:
- Reliable delivery of messages in multicast is difficult
  - If a message is lost, does everyone ask for it?
  - If sender is responsible, it'd have to track everyone
  - What about retransmit timers?
  - Ordering is difficult to define (lack of naming)
  - And how can you possibly make this scale to many senders/receivers?
- Solution: Use ALF to name data, leave func. and flex. up to the app.
  - SRM is unicast, guarantees eventual delivery of the data in arb. order
- Motivating app: wb, network conferencing white board
- Each individual is responsible for detecting loss
  - By seq no gaps
  - and by periodically broadcasting highest seq no
- Requests for repairs:
  - Broadcast to the whole multicast group
  - Wait a random time determined by distance to the sender
  - Any host with a copy can answer the request, sets timer based on
    distance to the requesting host
  - Nodes cancel timeouts when they hear others' messages
- Repair timer: (C1 + C2r)d 
  - r is rand b/w 0 and 1
  - d is one-way distance to sender
  - exp. backoff if you hear someone else's request for repair
  - C1 and C2 depend on topology
- Chain topology: distance-based response matters
  - the furthest node receives the repair sooner than it would have otherwise
  - small chain example?
- Star topology:  randomization matters (probabilistic suppression)
- Above algorithms are ok if you're willing to have a small number of
  duplicate messages, see paper for optimizations


(Cribbed from Feamster's 02 security notes and Dina's security slides, 
 Wikipedia:DoS, dos-attacks.com)

Security:
- Focus on *network* security, as opposed to *host* security (buffer 
  overflows, etc)
- Attacks:
  - Denial of Service (DoS and DDoS)
  - Spam
  - Worms/viruses (virii?)
    - Code Red, Code Red II, Nimda, Witty
- Targets:
  - Hosts (web servers, home workstations, you)
    - Online gambling
    - Anyone who can pay some amount of money
  - Links
  - Routers
  - DNS

- DoS attacks
  - Use one machine to take out another machine
  - Usually relies on a software/hardware weakness; not brute force
  - The Ping of Death (nuke attack): send malformed ICMP pkt to crash machine
  - Fork bomb
  - Ping flood (T1 > dialup)

- Controlling hosts:
  - It's feasible to control armies of O(million) hosts
  - These can become bot nets, for rent or personal use
  - Use for DDoS, Spam, Web servers for illegal content, etc
  - Software vulnerabilities, malware, etc
  - Leads to a "CyberMafia" of sorts

- DDoS attacks:
  - Send lots of traffic to flood a bottleneck link
    - ICMP echo attack:
      - Masters tells slaves to mount attack
      - Slaves spoof IMCP echo request from target (smurf amplification 
        networks)
      - Target gets lots of ICMP echo replies
    - Just simple junk traffic from all over the Internet
  - Resource attacks create state and use resources on target systems
    - TCP SYN floods, just send one packet to make server devote resources
    - TCP ACK flood
    - SSL handshakes attacks (force server to do cryptographic operations)
    - Web service attacks
      - Very difficult to tell diff. b/w DDoS and legitimate flash crowd 
        (Slashdot effect)
  - Lots of known tools
    - Trinoo, TFN, Stacheldraht

- Defenses (if there's time)
  - Simple IP address change
  - Traffic filtering for unsophisticated attacks
  - SYN cookies
  - Force the attackers to do work
    - solve puzzles
    - send more traffic
  - Turing test
    - solve captchas
  - Needs to work without devoting resources at server
  - Explicit in-network capabilities