Loading ...
Sorry, an error occurred while loading the content.

6154Re: [decentralization] Saaf testimony

Expand Messages
  • Rod Price
    Oct 2, 2002
    • 0 Attachment
      A co-worker of mine has implemented a de-centralized version of an
      artificial immune system that would seem ideal for this application.
      The system can recognize "self" and will flag "not-self." I know
      this description is vague, but my co-worker isn't around right
      now (9:00 pm) to help me out. For details on artificial immune
      systems, look at http://www.cs.unm.edu/~forrest/papers.html,
      particularly "Architecture for an Artificial Immune System" on
      that site.

      Curiously, although this work is ideally suited to a de-centralized
      system, all the implementations so far have been on a single
      machine, with the exception of my co-worker's. I'll ask him
      tomorrow if he would be willing to post his recent conference
      paper.

      My initial thought for implementation is that "self" is defined as
      the attacking IP addresses, and "not-self" is anything else.
      Packets coming from "self" addresses get logged and ignored, while
      packets from "not-self" addresses are allowed in as normal.

      -Rod


      Kevin Prichard wrote:
      > On 2 Oct 2002, Wes Felter wrote:
      >
      >
      >>On Wed, 2002-10-02 at 15:07, Lucas Gonze wrote:
      >>
      >>>coderman wrote:
      >>>
      >>>>This type of DDoS is different, in that it is not relying on sheer traffic
      >>>>to implement a DoS, but issuing a number of file requests to tie up available
      >>>>download slots on peers sharing copyrighted content.
      >>>>
      >>>>This is certainly technically feasable, and if they used a distributed network
      >>>>themselves to implement the attacks it would be hard to defend against.
      >>>
      >>>Hm, ok, so servents stop using upload slots and instead let uploaders use
      >>>all available bandwidth, just like standard web servers.
      >>
      >>An obvious extension of these two ideas is to open a very large number
      >>of idle connections to each Gnutella node, possibly exploiting hard
      >>limits or non-scalability in the Windows 9x TCP stack.
      >
      >
      > Even if the attack is distributed, my hunch is an attack coming from a
      > given IP is an IP that will never be connected to a valid, human-operated
      > gnutellanet client. Blocking said IPs could be done, but identifying when
      > a downloader is Them (on a per-IP basis) may be difficult, as all
      > characteristics of today's clients can be mimic'd.
      >
      > Identifying IPs belonging to Them may require pattern analysis of these
      > "attacks" across many nodes, which means sharing, possibly pooling,
      > knowledge -not really good for decentralization. And, p2p being
      > distributed, they can present data themselves, to bias away from their
      > pool of IPs. Hrm.
      >
      > Just about anything that an author can build into a client can be
      > reverse-engineered and added to the DoS code. I wonder if there exists a
      > kind of "proof of membership" scheme whereby peer connection records could
      > be signed or encrypted, deposited in a distributed pool for analysis.
      > Records from actual human-operated clients, posessing proper
      > proof-of-membership credential, could be separated from DoS client
      > deposits.
      >
      > NNTP is a kind of decentralized, rolling database that could be used for
      > depositing and pooling connect records. Just about all ISP accounts have
      > NNTP access, it hasn't been legislated away (yet.) Problem is, any
      > decentralized means by which records get analysed can be used against
      > clients wanting to deny service to the DoSers. Unless they are encrypted
      > with a public key, and the analysis is carried out by a central node (on
      > Sealand. ;^)
      >
      > kevin
      >
      >
      > To unsubscribe from this group, send an email to:
      > decentralization-unsubscribe@egroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Show all 14 messages in this topic