Distributed OS: Winter 2011: Difference between revisions

From Soma-notes
Lmundt (talk | contribs)
Line 29: Line 29:


===1: Stopping DDoS===
===1: Stopping DDoS===
Group members: Seyyed, Andrew Schoenrock, Thomas McMahon
Group members: Seyyed, Andrew Schoenrock, Thomas McMahon, Lester Mundt


*Have the machine routing packets(could be ISP provider) detect suspicious packets, if the packets are signed, then those suspicious packets could be blocked,  
*Have the machine routing packets(could be ISP provider) detect suspicious packets, if the packets are signed, then those suspicious packets could be blocked,  

Revision as of 23:52, 19 January 2011

Readings

January 13, 2011: CCR (two papers)

January 18, 2011: OceanStore and Pond

Internet Governance

Problems to Solve

  • Attack computers with almost no consequences
    • DDoS
    • botnets
    • capture and analyze private traffic
    • distribute malware
    • tampering with traffic
    • Unauthorized access to data and resources
    • Impersonate computers, individuals, applications
    • Fraud, theft
    • regulate behavior

Design Principles

  • subjects of governance: programs and computers
  • bind programs and computers to humans & human organizations, but recognize binding is imperfect
  • recognize that "bad" behavior is always possible. "good" behavior is enforced through incentives and sanctions.
  • rules will change. Even rules for rule changes will change. Need a "living document" governing how rules are chosen and enforced.

Scenarios

1: Stopping DDoS

Group members: Seyyed, Andrew Schoenrock, Thomas McMahon, Lester Mundt

  • Have the machine routing packets(could be ISP provider) detect suspicious packets, if the packets are signed, then those suspicious packets could be blocked,

the sender could be put on a black list.


  • Stopping DDoS against files, services, programs, etc
    • Have file replication built into the system (similar to OceanStore) so that files are always available from different servers
    • If files are not replicated then we could have a tiered messaging system (at the top level would be OS messages) and servers could then prioritize the incoming traffic. If a given server is experiencing an overload, it could send out a distress signal to its neighbours and then distribute what it is has to them. The system should have a built-in mechanism to re-balance the overall load after something like this happens. This would then mean that any DDoS attack would result in the service being more available.
  • Stopping DDoS against specific machines
    • I don't think that this should be specifically addressed. I think measures introduced to guard against this will ultimately negatively impact the overall system in terms of performance.
  • Stopping DDoS
    • I'm not sure what it means by stopping, I don't think we can stop DDos given the way things are currently ran, we can only block it. From my knowledge most softwares that stop DDoS do so by blocking, or even complete shut down like Mccolo.

2: Stopping phishing

Group members: Waheed Ahmed, Nicolas Lessard, Raghad Al-Awwad

  • A way of automatically checking the signature of a message to make sure it really is from a trusted source.
    • ie: "Nation of Banks, did your member TD send me a message to reset my password?"

3: Limiting the spread of malware

Group members: keith, Andrew, David Barrera


4: Bandwidth hogs

Group members: Mike Preston, Fahim Rahman, Michael Du Plessis

  • limit bandwidth for each user
  • if user has significant bandwidth demands for a certain period of time
    • add them to a watch list
    • monitor their behaviour