From ardagna at dti.unimi.it Thu Jun 1 08:00:01 2006 From: ardagna at dti.unimi.it (Claudio Ardagna) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] CFP - LAST CALL FOR PAPERS: 2ND INTERNATIONAL WORKSHOP ON SECURITY AND TRUST MANAGEMENT (STM'06) Message-ID: <013101c68551$621d2440$1e00000a@Berlino> CALL FOR PAPERS *********************************************************************************************** ****EXTENDED DEADLINE JUNE 04, 2006**** 2ND INTERNATIONAL WORKSHOP ON SECURITY AND TRUST MANAGEMENT (STM'06) Hamburg,Germany - September 20, 2006 (in conjunction with ESORICS 2006) http://www.hec.unil.ch/STM06/ *********************************************************************************************** STM (Security and Trust Management) is a recently established working group of ERCIM (European Research Consortium in Informatics and Mathematics). STM 2006 is the second workshop in this series, and has the following aims: - to investigate the foundations and applications of security and trust in ICT - to study the deep interplay between trust management and common security issues such as confidentiality, integrity and availability - to identify and promote new areas of research connected with security management, e.g. dynamic and mobile coalition management (e.g., P2P, MANETs, Web/GRID services) - to identify and promote new areas of research connected with trust management, e.g. reputation, recommendation, collaboration etc - to provide a platform for presenting and discussing emerging ideas and trends Topics of interest include but are not limited to: - semantics and computational models for security and trust - security and trust management architectures, mechanisms and policies - networked systems security - privacy and anonymity - Identity management - ICT for securing digital as well as physical assets - cryptography The primary focus is on high-quality original unpublished research, case studies, and implementation experiences. We encourage submissions discussing the application and deployment of security technologies in practice. Paper submissions. Submitted papers must not substantially overlap papers that have been published or that are simultaneously submitted to a journal or a conference with proceedings. Papers must have authors' affiliation and contact information on the first page. Papers are limited to 12 pages in ENTCS style format (using the generic template). Excessively long papers will be returned without review. Accepted papers will be published in a post-workshop ENTCS volume. To submit a paper, please visit http://www.easychair.org/STM06/ . For more information contact stm06@dti.unimi.it Papers must be received by the deadline of June 04, 2006. IMPORTANT DATES Paper submission due: ****Extended Deadline June 04, 2006**** Acceptance notification: June 30, 2006 Final Papers due: August 20, 2006 GENERAL CHAIRS Solange Ghernaouti H?lie Univ. Lausanne, CH email: sgh@unil.ch Ulrich Ultes-Nitsche Univ. Fribourg, CH email: uun@unifr.ch PROGRAM CO-CHAIRS Sandro Etalle University of Twente, NL email: sandro.etalle@utwente.nl Pierangela Samarati Universita' di Milano - Italy email: samarati@dti.unimi.it PUBLICATION CHAIR Sara Foresti Universita' di Milano - Italy email: foresti@dti.unimi.it PUBLICITY CHAIR Claudio A. Ardagna Universita' di Milano - Italy email: ardagna@dti.unimi.it PROGRAM COMMITTEE: Viajy Atluri, Rutgers Univ., USA Joris Claessens, Microsoft EMIC, DE Sabrina De Capitani di Vimercati, Univ. Milano, IT Theo Dimitrakos, British Telecom, UK Mara Isabel Gonz?lez Vasco, Univ. Rey Juan Carlos, SP Stefanos Gritzalis, Univ. of Aegean, GR Peter Herrmann, NTNU, NO Valerie Issarny, INRIA, FR Guenter Karjoth, IBM Research, CH Antonio Lioy, Politecnico di Torino, IT Javier Lopez, Univ. Malaga, SP Fabio Martinelli, IIT-CNR, IT Sjouke Mauw, Technical Univ. Eindhoven, NL Daniel Olmedilla, L3S, GR Babak Sadighi, SICS, SE Luca Vigano', ETH Zurich, CH Will Winsborough, Univ. Texas at S. Antonio, USA Ting Yu, North Carolina State Univ., USA Alec Yasinsac, Florida State Univ., USA This call for papers and additional information about the conference can be found at http://www.hec.unil.ch/STM06 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060601/bacac754/attachment.htm From adi_gio at libero.it Thu Jun 1 09:45:11 2006 From: adi_gio at libero.it (adi_gio@libero.it) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] (no subject) Message-ID: Hi, I'm an italian student and I'm seraching for components or libraries .Net or Delphi of any p2p protocol such Gnutella, OpenNap, BItTorrent and more and Kademlia, DHTs too... Can anyone help me? P.S: Sorry for my English, Andrea From rrrw at neofonie.de Fri Jun 2 13:06:38 2006 From: rrrw at neofonie.de (Ronald Wertlen) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Re: Altnet goes after p2p networks with obvious patent Message-ID: <448037DE.5090209@neofonie.de> About 15 months ago, was a thread on this list. There was a bit of fuss, briefly, and I'd like to get feedback on whatever happened. Limewire is an especially interesting case, about which I have heard nothing further. The reason I am asking, is because Altnet has now cast its net a little further. I.e. we got one of these letters now too. Can anyone comment? Best regards to you all, Ron From rrrw at neofonie.de Fri Jun 2 15:14:20 2006 From: rrrw at neofonie.de (Ronald Wertlen) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Re: Altnet goes after p2p networks with obvious patent Message-ID: <448055CC.5030303@neofonie.de> Altnet Patents... I took the time to read one, 5,978,791 Filed October 24, 1997. " Data processing system using substantially unique identifiers to identify data items, whereby identical data items have the same identifiers " see also http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=5,978,791.PN.&OS=PN/5,978,791&RS=PN/5,978,791 The patent shows some internal inconsistencies. It argues from a very restricted filesystem based case and extends without justification to other scenarios like databases. "Substantially Unique Identifier" The argument in the patent is that it is possible to provide access to data in a "context free" fashion by using the data itself, in fact ALL the data of a data item. Hash/Digest algorithms are specifically named (MD5, SHA1, etc.). We can use a three step argument to highlight the internal inconsistency of the patent: i. real time constraints prevent one from simply increasing address space indefinitely to prevent collisions. ii. the data itself is reduced to bits in a filesystem. In this scenario the patent works fairly well. However, the patent says that the scheme can be extended to other schemes such as databases, etc. As soon as one moves away from the simple filesystem case, however, one introduces context, as different DBs store their data differently to produce different hashes for the same data (in a context free sense). iii. Thus it is NOT the case that the patent provides an apparatus which automatically ensures that the same data items in two different contexts have the same name. The TrueName method is very much context-bound! Quote from the patent: "In prior art systems for identifying data items there is no direct relationship between the data names and the data item. The same data name in two different contexts may refer to different data items, and two different data names in the same context may refer to the same data item. " Other Loopholes: 1. P2P Systems not using DHTs are exempt. 2. Hybrid systems, like JXTA also seem to be exempt. [Anyone know if Altnet have been going after JXTA?] JXTA uses its SRDI (shared resource distributed index) to track common resources like advertisements in the network - which clearly is a kind of content based addressing. However it's easy too see that there are differences. Specifically, these are in the extensible Walker system. Walkers are context sensitive constructs which are most likely not covered by the altnet patent. 3. Hash codes based on only portions of the data. The patent is fairly repetitive on this point. Quote: "This invention provides, in a data processing system, a method and apparatus for identifying a data item in the system, where the identity of the data item depends on _all of the data_ in the data item and _only_ on the data in the data item." [rw: my underscore] 4. Prior Art: as Ian Clarke suggested on this list previously there is bound to be prior art. Mentioned Prior Art: Freenet Xanadu.com Besides that, it is a pretty throrough description of a P2P filesharing system. The authors, David A. Farber and Ronald D. Lachman, had a lot of time and patience. They should have invested it in the Wikipedia (yeah I know it didn't exist back then) or something useful. cheers, Ron -- Ronald Wertlen From Arnaud.Legout at sophia.inria.fr Fri Jun 2 16:00:55 2006 From: Arnaud.Legout at sophia.inria.fr (Arnaud Legout) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] New version of the paper "Rarest First and Choke Algorithms Are Enough " Message-ID: <448060B7.5070403@sophia.inria.fr> Hello, I received a lot of good comments on the first version of this paper. You can find a new version of the paper that takes into account these comments here: http://hal.inria.fr/inria-00001111/en The major modifications compared to the previous version are: -New torrents with a single (or few) seed(s) and several hundred of leechers were added. These new torrents are now used as an illustration of the transient and steady state. This is to answer to the comments that pointed out that small torrents are not challenging for the rarest first algorithm. -I rewrote a large part of the methodology section in order to better discuss the experimental setup and the limitations of the study. In particular I discuss the single client monitoring restriction, and how the torrents were chosen. -A new figure is presented for the section on the choke algorithm to better illustrate the correlation between the number of unchokes and the interested duration. As always, comments and critics are welcomed. Regards, Arnaud Legout. From saikat at cs.cornell.edu Mon Jun 5 14:23:31 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Real-world UPnP stats In-Reply-To: <444D1F47.1070905@hamachi.cc> References: <444D1F47.1070905@hamachi.cc> Message-ID: <1149517411.23856.172.camel@localhost.localdomain> On Mon, 2006-04-24 at 11:56 -0700, Alex Pankratov wrote: > We've recently added UPnP support to our client software and > now I got some server-side stats and they are most interesting. > > Check this out - > > Roughly a half of all clients that reported success talking to > their 'routers' and establishing TCP/UDP port mappings were > still inaccessible from an outside via their mapped ports. Interesting. Some reasons for this I can think of are as follows: - If I recall, UPnP on a NAT that is behind yet another NAT doesn't work well (since the UPnP Internet Gateway Device on most NATs typically doesn't act as a client for the outer NAT's UPnP IGD). This comes into play when some connects a wireless router to their existing wired-only NAT or something. - UPnP doesn't have nice crash semantics. If an application registers a mapping, crashes, is restarted, and re-registers the same mapping, some NATs ignore the new registration while other NATs silently reap the old mapping. The first case would result in broken behavior. - On the flip side, if two different applications register the same mapping, the latter mapping may silently override the former mapping or alternatively, the latter may get silently ignored. Either way, one of the applications suffers. > Anyone care to comment or compare this to their own numbers ? While I don't have numbers, I suspect UPnP success rate (for NATs that support UPnP) would depend on the application as well as the topology common for the target user population. As a side note, if you want to test UPnP functionality, target Japanese users -- based on anecdotal evidence, UPnP seems far more popular in the far east than anywhere else. cheers, -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060605/04ef8204/attachment.pgp From saikat at cs.cornell.edu Mon Jun 5 14:12:48 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ANN: tutorial on NAT and P2P In-Reply-To: <71b79fa90604041052o427cfcd0q1dcd51e335616168@mail.gmail.com> References: <71b79fa90604041052o427cfcd0q1dcd51e335616168@mail.gmail.com> Message-ID: <1149516768.23856.161.camel@localhost.localdomain> Hi Davide, (really behind on p2p-hackers mail) On Tue, 2006-04-04 at 19:52 +0200, Davide "dada" Carboni wrote: > Hi, I've prepared a slide-based course on NAT traversal. > You can find it on http://p2p-mentor.berlios.de/ > Any comment is welcome. The slides are quite instructive for p2p devs, thanks! Just a few minor nits: - The nomenclature for NATs is changing. The "cone" and "symmetric" terminology has been deprecated. NAT behavior is now defined in terms of "mapping" and "filtering", with four choices along each axis. See draft-ietf-behave-nat-udp (-06.txt). This is about to become an RFC. - ICE is a generic framework that incorporates STUN(T)/TURN to traverse NATs. It handles most of the complexity of stacked NATs (hairpining), different types of NATs (endpoint independent filtering, address dependent filtering etc.) and even rendezvous/signaling (over SIP) See draft-ietf-mmusic-ice (-08.txt). Now, if only Jonathan had chosen a more Google-friendly name than ICE, library implementations would easier to find. :-p cheers, -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060605/aad11166/attachment.pgp From vyzo at media.mit.edu Tue Jun 6 07:21:47 2006 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] good luck finding holes in a finite order logic Message-ID: http://web.media.mit.edu/~vyzo/papers/computability.pdf I can tell you this. It is a correct program. But you can't reason about it even in Infinite Order Logic. You have to go beyond. Give to to anyone who thinks he can disprove LISP. I just wrote the smallest possible program that demonstrates that the entire science of centralization, as accepted today is wrong. This is the most beautiful program I ever wrote. Good luck reverse engineering it. -- vyzo From dbarrett at quinthar.com Mon Jun 12 17:04:45 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Testing Message-ID: <20060612170447.92CDB3FC1E@capsicum.zgp.org> 1.2.3. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060612/f97cb39c/attachment.html From lemonobrien at yahoo.com Mon Jun 12 17:48:23 2006 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Testing In-Reply-To: <20060612170447.92CDB3FC1E@capsicum.zgp.org> Message-ID: <20060612174823.30356.qmail@web53608.mail.yahoo.com> its up? David Barrett wrote: 1 2 3 _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060612/4b676d4f/attachment.htm From fbochot at hotmail.com Mon Jun 12 17:41:43 2006 From: fbochot at hotmail.com (=?iso-8859-1?B?ZulsaWNpZW4gYm9jaG90?=) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] (no subject) In-Reply-To: Message-ID: as tu msn si tu la ajoute mon adresse et je t'expliquerai _________________________________________________________________ Retrouvez tout en un clin d'oeil avec la barre d'outil MSN Search ! http://desktop.msn.fr/ From alenlpeacock at gmail.com Mon Jun 12 17:59:34 2006 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Re: Altnet goes after p2p networks with obvious patent In-Reply-To: <448055CC.5030303@neofonie.de> References: <448055CC.5030303@neofonie.de> Message-ID: Perhaps it is time to gather up a few thousand bucks and initiate a re-exam (http://www.uspto.gov/web/offices/pac/mpep/documents/appxr_1_17.htm)? If this truly locks away royalty-free use of DHTs and content-addressable storage (CAS) via hashing until 2019... well... I can't imagine most of us not being upset enough by it to toss in a few bucks. Maybe we could get PubPat (http://www.pubpat.org/) to spearhead the challenge? Alen From ap at hamachi.cc Mon Jun 12 17:47:58 2006 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Testing In-Reply-To: <20060612170447.92CDB3FC1E@capsicum.zgp.org> References: <20060612170447.92CDB3FC1E@capsicum.zgp.org> Message-ID: <448DA8CE.2090602@hamachi.cc> David Barrett wrote: > 1...2...3... .. boom. The list seems to be back in business. From travis at redswoosh.net Mon Jun 12 18:16:13 2006 From: travis at redswoosh.net (Travis Kalanick) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Re: Altnet goes after p2p networks with obviouspatent In-Reply-To: Message-ID: <200606121826.k5CIQw18023859@be9.noc0.redswoosh.com> Alen, I think you're on to something. I would throw some money into the pool to help overturn it. T -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Alen Peacock Sent: Monday, June 12, 2006 11:00 AM To: Peer-to-peer development. Subject: Re: [p2p-hackers] Re: Altnet goes after p2p networks with obviouspatent Perhaps it is time to gather up a few thousand bucks and initiate a re-exam (http://www.uspto.gov/web/offices/pac/mpep/documents/appxr_1_17.htm)? If this truly locks away royalty-free use of DHTs and content-addressable storage (CAS) via hashing until 2019... well... I can't imagine most of us not being upset enough by it to toss in a few bucks. Maybe we could get PubPat (http://www.pubpat.org/) to spearhead the challenge? Alen _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From m.rogers at cs.ucl.ac.uk Mon Jun 12 19:35:29 2006 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Modelling Latency and Packet Loss on the Public Net In-Reply-To: <8B99AE12-C303-4A09-934C-65F6524F886A@memefeeder.com> References: <8B99AE12-C303-4A09-934C-65F6524F886A@memefeeder.com> Message-ID: <448DC201.2020203@cs.ucl.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Will, I'm writing a p2p simulator at the moment and I've been facing similar questions. Here's what I've come up with. If you're looking for the distribution of the mean latencies of different links (rather than the distribution of the latencies of packets on a given link), Figure 5 of [1] shows what looks to me like a lognormal distribution with median 140ms, 20th percentile 70ms and 80th percentile 280ms. Lognormally distributed samples are easy to generate: exp(x) where x is normally distributed. As for packet loss, er, I'm at a loss. Figure 3a of [1] gives distributions for upstream and downstream bandwidth (unfortunately not as neat as the latency distribution). But even if we know the bandwidth of the access link, the amount of packet loss you experience will depend on the amount of background traffic, how the background traffic reacts to packet loss, and how your traffic reacts to packet loss. If your traffic is TCP-friendly and you can estimate how many other TCP or TCP-friendly connections will be sharing the access link then it should be possible to work out the steady-state packet loss... possibly by rearranging Equation 1 in [2] to give p as a function of T, s, and R? I have a feeling that t_RTO can be estimated as 4*R but I can't remember where I read it. :-) That's as far as I've got - any pointers appreciated! Cheers, Michael [1] http://www.cs.washington.edu/homes/gribble/papers/mmcn.pdf [2] http://www.icir.org/tfrc/aimd.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEjcIByua14OQlJ3sRAj+YAJ9d8c34/USAfSe3fQ0Vip4+WFuFyACeJqrP HJtP8b16E/TSOLvw3OjzYeM= =DiuN -----END PGP SIGNATURE----- From alenlpeacock at gmail.com Mon Jun 12 20:47:55 2006 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Re: Altnet goes after p2p networks with obvious patent In-Reply-To: <448037DE.5090209@neofonie.de> References: <448037DE.5090209@neofonie.de> Message-ID: I wonder if the C&D letter contains a concise summary of what it is that Altnet thinks it 'owns?' Ronald, are you at liberty to post the contents of the letter you received (either here or at chillingeffects.org)? Alen On 6/2/06, Ronald Wertlen wrote: > > The reason I am asking, is because Altnet has now cast > its net a little further. I.e. we got one of these > letters now too. From coderman at gmail.com Mon Jun 12 20:48:24 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Re: Altnet goes after p2p networks with obvious patent In-Reply-To: References: <448055CC.5030303@neofonie.de> Message-ID: <4ef5fec60606121348s4f66b8fdq6ed0a2b0a9132cf@mail.gmail.com> On 6/12/06, Alen Peacock wrote: > ... > If this truly locks away royalty-free use of DHTs and > content-addressable storage (CAS) via hashing until 2019... perhaps i'm missing something, but if this patent is valid (which i'd bet almost any amount of money it is not) than a lot more than just DHT's anc CAN's are affected, aren't they? this is "calling a datum by its digest", or self certifying identifier, and is enmeshed in more secure protocols and systems than i can count. how is this even novel? ... i must be missing something. From alenlpeacock at gmail.com Mon Jun 12 21:42:24 2006 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Re: Altnet goes after p2p networks with obvious patent In-Reply-To: <4ef5fec60606121348s4f66b8fdq6ed0a2b0a9132cf@mail.gmail.com> References: <448055CC.5030303@neofonie.de> <4ef5fec60606121348s4f66b8fdq6ed0a2b0a9132cf@mail.gmail.com> Message-ID: On 6/12/06, coderman wrote: > > perhaps i'm missing something, but if this patent is valid (which i'd > bet almost any amount of money it is not) than a lot more than just > DHT's anc CAN's are affected, aren't they? > > this is "calling a datum by its digest", or self certifying > identifier, and is enmeshed in more secure protocols and systems than > i can count. > > how is this even novel? ... i must be missing something. I'm no patent lawyer, but as far as I can tell, you are absolutely right. They make some claims that are outright false (again, in my estimation) in the patent itself, for example, "In prior art systems for identifying data items there is no direct relationship between the data names and the data item. The same data name in two different contexts may refer to different data items, and two different data names in the same context may refer to the same data item." The earlier thread in p2p-hackers provides evidence that this was done at least as early as 1995. Alen From alenlpeacock at gmail.com Mon Jun 12 21:50:07 2006 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Re: Altnet goes after p2p networks with obvious patent In-Reply-To: References: <448037DE.5090209@neofonie.de> Message-ID: On 6/12/06, Alen Peacock wrote: > I wonder if the C&D letter contains a concise summary of what it is > that Altnet thinks it 'owns?' Ronald, are you at liberty to post the > contents of the letter you received (either here or at > chillingeffects.org)? Never mind -- it looks like most of it is already online: http://p2pnet.net/story/3512 (although putting a full copy in chillingeffects' database is still a good idea). Alen From dcarboni at gmail.com Mon Jun 12 23:22:03 2006 From: dcarboni at gmail.com (Davide "dada" Carboni) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ANN: tutorial on NAT and P2P In-Reply-To: <1149516768.23856.161.camel@localhost.localdomain> References: <71b79fa90604041052o427cfcd0q1dcd51e335616168@mail.gmail.com> <1149516768.23856.161.camel@localhost.localdomain> Message-ID: <71b79fa90606121622p2837398bn580eac74a7587fa8@mail.gmail.com> > The slides are quite instructive for p2p devs, thanks! Just a few minor > nits: > > - The nomenclature for NATs is changing. The "cone" and "symmetric" > terminology has been deprecated. NAT behavior is now defined in terms > of "mapping" and "filtering", with four choices along each axis. See > draft-ietf-behave-nat-udp (-06.txt). This is about to become an RFC. > Thank you. I'll try to read this draft as soon as I can. D. -- http://powerjibe.blogspot.com http://people.crs4.it/dcarboni From wesley at felter.org Tue Jun 13 00:38:17 2006 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Merkle Hash Trees + live stream In-Reply-To: References: Message-ID: (Strange; this message was sent on May 18th, but I just received it on June 12th.) On May 18, 2006, at 9:31 AM, Luigi De Don? wrote: > Hi all, > > I would like to use a type of Merkle Hash Trees for verifying the > integrity > of a live stream delivered using an application level multicast > distribution > tree. I found a bunch of academic work related to this topic under the keyword "multicast data origin authentication". Several of the proposed techniques use hash chaining. http://citeseer.ist.psu.edu/challal04taxonomy.html http://citeseer.ist.psu.edu/723894.html It may also be worth using ECC instead of RSA/DSA to sign the Merkle tree roots for better performance. I haven't heard of any P2P systems that use such techniques, so good luck. Wes Felter - wesley@felter.org - http://felter.org/wesley/ From dbarrett at quinthar.com Tue Jun 13 00:39:47 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] I hate SPI Firewalls In-Reply-To: <20060530052833.4848.qmail@web53612.mail.yahoo.com> Message-ID: <20060613003950.5E0833FD3E@capsicum.zgp.org> Do you specifically mean how to impersonate other protocols so as to avoid SPI (stateful packet inspection, I assume) firewalls? Or is there some more "correct" way, such as UPnP? -david _____ From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Lemon Obrien Sent: Monday, May 29, 2006 10:29 PM To: Peer-to-peer development. Subject: [p2p-hackers] I hate SPI Firewalls does anyone know where i can obtain easy documentation on how to punch and maintain a hole through SPI; any helpful hints? i'm having problems with Netgear Routers. thanks. You don't get no juice unless you squeeze Lemon Obrien, the Third. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060612/689f0624/attachment.html From lemonobrien at yahoo.com Tue Jun 13 00:47:29 2006 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] I hate SPI Firewalls In-Reply-To: <20060613003950.5E0833FD3E@capsicum.zgp.org> Message-ID: <20060613004729.20817.qmail@web53608.mail.yahoo.com> specifically...do SPI firewalls use a different port number for each new destination ip address? Or do they actuall check the packet; or is it determined by vendor? thanks David Barrett wrote: v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} st1\:*{behavior:url(#default#ieooui) } Do you specifically mean how to impersonate other protocols so as to avoid SPI (stateful packet inspection, I assume) firewalls? Or is there some more ?correct? way, such as UPnP? -david --------------------------------- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Lemon Obrien Sent: Monday, May 29, 2006 10:29 PM To: Peer-to-peer development. Subject: [p2p-hackers] I hate SPI Firewalls does anyone know where i can obtain easy documentation on how to punch and maintain a hole through SPI; any helpful hints? i'm having problems with Netgear Routers. thanks. You don't get no juice unless you squeeze Lemon Obrien, the Third. _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060612/e2cf3646/attachment.htm From dbarrett at quinthar.com Tue Jun 13 01:27:19 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] I hate SPI Firewalls In-Reply-To: <20060613004729.20817.qmail@web53608.mail.yahoo.com> Message-ID: <20060613012723.56CC23FC22@capsicum.zgp.org> It's my understanding that firewalls employing deep packet inspection work like any other, except also use the contents of the packet (or stream of packets) in their filtering decisions. Thus I'm not sure they really deserve special treatment, unless you find that your protocol is being specifically targeted by admins. And if so, you might want to tunnel over SSL or SSH or some other encrypted protocol that probably isn't blocked. What specifically are you seeing in the field that's mucking you up? -david _____ From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Lemon Obrien Sent: Monday, June 12, 2006 5:47 PM To: Peer-to-peer development. Subject: RE: [p2p-hackers] I hate SPI Firewalls specifically...do SPI firewalls use a different port number for each new destination ip address? Or do they actuall check the packet; or is it determined by vendor? thanks David Barrett wrote: Do you specifically mean how to impersonate other protocols so as to avoid SPI (stateful packet inspection, I assume) firewalls? Or is there some more "correct" way, such as UPnP? -david _____ From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Lemon Obrien Sent: Monday, May 29, 2006 10:29 PM To: Peer-to-peer development. Subject: [p2p-hackers] I hate SPI Firewalls does anyone know where i can obtain easy documentation on how to punch and maintain a hole through SPI; any helpful hints? i'm having problems with Netgear Routers. thanks. You don't get no juice unless you squeeze Lemon Obrien, the Third. _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060612/2dcd6f81/attachment.html From lemonobrien at yahoo.com Tue Jun 13 01:34:09 2006 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] I hate SPI Firewalls In-Reply-To: <20060613012723.56CC23FC22@capsicum.zgp.org> Message-ID: <20060613013409.11846.qmail@web53612.mail.yahoo.com> basically once i finished punching a hole through NAT; a business partner went out to buy a new router; with a double firewall, NAT + SPI...and it cause problems. I don't really want to do upnp thing to set the router. I can punch through the SPI firewall by adding a test server side to test the remote-address against the assumed global; and have relay-peers translate to and from to the rest of the network; if they actually inspect the packet; well; i'm fucked. upnp will take too long; and probably won't work well either from what i'm gathering from reading this list. el David Barrett wrote: v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} st1\:*{behavior:url(#default#ieooui) } It?s my understanding that firewalls employing deep packet inspection work like any other, except also use the contents of the packet (or stream of packets) in their filtering decisions. Thus I?m not sure they really deserve special treatment, unless you find that your protocol is being specifically targeted by admins. And if so, you might want to tunnel over SSL or SSH or some other encrypted protocol that probably isn?t blocked. What specifically are you seeing in the field that?s mucking you up? -david --------------------------------- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Lemon Obrien Sent: Monday, June 12, 2006 5:47 PM To: Peer-to-peer development. Subject: RE: [p2p-hackers] I hate SPI Firewalls specifically...do SPI firewalls use a different port number for each new destination ip address? Or do they actuall check the packet; or is it determined by vendor? thanks David Barrett wrote: Do you specifically mean how to impersonate other protocols so as to avoid SPI (stateful packet inspection, I assume) firewalls? Or is there some more ?correct? way, such as UPnP? -david --------------------------------- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Lemon Obrien Sent: Monday, May 29, 2006 10:29 PM To: Peer-to-peer development. Subject: [p2p-hackers] I hate SPI Firewalls does anyone know where i can obtain easy documentation on how to punch and maintain a hole through SPI; any helpful hints? i'm having problems with Netgear Routers. thanks. You don't get no juice unless you squeeze Lemon Obrien, the Third. _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060612/d681198c/attachment.htm From matthew at matthew.at Tue Jun 13 03:13:34 2006 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] amicima updates Message-ID: <00c501c68e97$5e200340$0202fea9@matthewdesk> Originally sent on May 21st, resending now that it looks like the list is back online... Just an update from us here at amicima: New releases of MObj, MFP, and MFPNet are up on the website at http://www.amicima.com Summary of relevant updates to MObj, MFP, and MFPNet source code since our last release (more details are available in each component's CHANGES.txt file): 1) We've taken advantage of the extensible keying framework we put in the default cryptographic plugin for MFP a few months back, and went ahead and added Diffie-Hellman key agreement, to provide perfect forward secrecy for MFP sessions. The old-style key agreement scheme, using public key encryption of secret keying data, is still available for backward compatibility, but its use is deprecated. MFPNet enables the backward compatibility mode by default (sending both Diffie-Hellman and legacy keying when initiating sessions) but prefers the new style. 2) All components have updated Makefiles for building Universal (PPC & Intel) libraries and binaries on Mac OS X. 3) MFP includes an important fix for a bug that can cause a deadlock in certain circumstances, so this update is strongly recommended. 4) MObj includes numerous small, non-serious bug fixes and some new features. And new releases of amiciPhone -- our secure P2P VoIP, text messaging, file transfer, photo sharing and live presence application that demonstrates MFP and MFPNet -- are available for Windows XP and Mac OS X, also on the website. And we're still hard at work on MFPGroup, which will let you build large self-organizing networks over which both DHT-like operations and efficient application-level multicast may be performed. More news about that once we've got something to demo. Matthew Kaufman matthew@matthew.at http://www.amicima.com From enzomich at gmail.com Tue Jun 13 10:13:36 2006 From: enzomich at gmail.com (Enzo Michelangeli) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] peertech quorum public offset 0000000 / januswireless / alpine / feedbackfs References: <4ef5fec60605221101hfd9a70ci8e0de32ab09e7807@mail.gmail.com> Message-ID: <000e01c68eda$7420f710$07000100@EMLT> From: "coderman" Sent: Tuesday, May 23, 2006 2:01 AM >i promised i'd have a site again once physical and info security > prerequisites were in place. > > taken much longer than expected but better late than never... > (additional updates to follow in the coming weeks) > > http://public.peertech.org/ The archive at http://januswifi.dyndns.org:85/JanusVM.zip appears to be corrupted... The installer, on the other hand, is OK. By the way, doesn't VMware's .vmem file, left on the disk, represent a privacy hole? That's one reason I like qemu better than VMware, despite its slower speed (esp. when used without kqemu). Enzo From coderman at gmail.com Tue Jun 13 18:01:32 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] peertech quorum public offset 0000000 / januswireless / alpine / feedbackfs In-Reply-To: <000e01c68eda$7420f710$07000100@EMLT> References: <4ef5fec60605221101hfd9a70ci8e0de32ab09e7807@mail.gmail.com> <000e01c68eda$7420f710$07000100@EMLT> Message-ID: <4ef5fec60606131101m1c462b6fw1c19de159d355271@mail.gmail.com> On 6/13/06, Enzo Michelangeli wrote: > ... > The archive at http://januswifi.dyndns.org:85/JanusVM.zip appears to be > corrupted... The installer, on the other hand, is OK. thanks for the heads up; there was a bad image at one point due to an FTP as ASCII issue and i'll have Kyle double check this. > By the way, doesn't VMware's .vmem file, left on the disk, represent a > privacy hole? That's one reason I like qemu better than VMware, despite its > slower speed (esp. when used without kqemu). there are a number of privacy holes in this release. it's really more a proof of concept than a finished cut. (any suggestions for mitigating the .vmem issue?) some other known holes we are in the process of fixing (slowly, due to external factors) and intend to have published by the 4th of july or earlier: - dns leaks, which will be mitigated by dns-proxy-tor - http on ports other than 80 and 8080, which will be mitigated by L7 matching for http type - https and other TCP traffic which is not going through tor to be mitigated by trans-proxy-tor. - general hardening of the appliance against users on the same local network. - removing caching for squid, and using it transparent http proxy only, since it is too aggressive with caching pages and images. - resolving some issues with CGI get parameters through squid/privoxy. - release sources and scripts for building your own installers and images. thanks again, From coderman at gmail.com Tue Jun 13 19:09:51 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] janusvm privacy appliance Message-ID: <4ef5fec60606131209n5862603fif9fb3204933ee7d3@mail.gmail.com> On 6/13/06, coderman wrote: > ... > some other known holes we are in the process of fixing (slowly, due to > external factors) and intend to have published by the 4th of july or > earlier: note that the dns-proxy-tor, trans-proxy-tor and L7 classification are all supported in the image just not configured or enabled (if you want to play with it). you'll need to modify the /etc/rc.d/rc.S or /etc/init.d/* scripts accordingly. also, openvpn is included (and statically linked for linux systems if you want to grab the binary) for those who want to use on OSX/bsd/solaris/etc. you'll have to regenerate the ca/server/client certs as i forgot to include a generic client cert for use with the server cert in place on the image. [you'll need to modify /etc/init.d/janus.routing to support the tun0 device] last but not least, has anyone tried running an openvpn server as a hidden service? the latency is probably extreme but it seems like it should work. i'll try this soon if someone hasn't already; i'm curious if this is usable or not. best regards, From dbarrett at quinthar.com Fri Jun 16 07:16:34 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 Message-ID: <20060616071643.9AEC73FC50@capsicum.zgp.org> Do you know of any way to break down current bandwidth usage by application? For example, is there some application like netstat or Sysinternal's TCPview that not only shows which connections are currently active (and to which processes they belong), but how much bandwidth they are actually using? Alternatively, do you know of any Win32 API functions that could be used to write such a utility? -david -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060616/4978c460/attachment.html From ap at hamachi.cc Fri Jun 16 15:47:15 2006 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <20060616071643.9AEC73FC50@capsicum.zgp.org> References: <20060616071643.9AEC73FC50@capsicum.zgp.org> Message-ID: <4492D283.6080206@hamachi.cc> I am not aware of any Win32 API that does what you are asking for and I would be surprised if there's such functionality. I can think of three ways of doing what you want though, all are pretty hacky and fairly complex. Option (a) is to inject your traffic accounting DLL into each process using CreateRemoteThread trick (see injLib for details) and hook send/recv/etc functions. This is not hard to do, but requires some voodoo magic for taking care of freshly spawned processes. Option (b) involves writing TDI driver or doing some sort of hooking at TDI level. That's I think how TCPView works. Option (c) is to write generic driver that does NDIS hooking to get an access to network data at TCP/IP level. You will be able to trace Send requests back to the calling application, but you will need to create and maintain the state to deduce who Receives are for. Alex David Barrett wrote: > Do you know of any way to break down current bandwidth usage by application? > > > > For example, is there some application like netstat or Sysinternal?s > TCPview that not only shows which connections are currently active (and > to which processes they belong), but how much bandwidth they are > actually using? > > > > Alternatively, do you know of any Win32 API functions that could be used > to write such a utility? > > > > -david > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From travis at redswoosh.net Fri Jun 16 16:06:01 2006 From: travis at redswoosh.net (Travis Kalanick) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling Message-ID: <200606161617.k5GGH318029763@be9.noc0.redswoosh.com> Doing a bunch of traveling recently in Asia (adventures blogged here: http://blog.redswoosh.net ), I've found myself in many situations where I've had to purchase wireless Internet access, quite often at double or triple the prices seen in the States. Before paying however, I am almost always able to do a DNS look-up and sometimes even ping remote hosts, though normal Internet traffic over port 80 (and various other ports) is blocked. It got me to thinking about ICMP tunneling around these wireless "toll booths" so I could travel Asia and even the states without having to communicate over those popular ports that cost money to communicate over. Maybe something could be coded up to tunnel over ICMP to a proxy server (or proxy peer), that then translates communication back to the intended protocol and port and forwards communication along. It seems that at least theoretically, with raw sockets and promiscuous settings, even on Windows machines, this should be possible. Anybody have experience with tunneling over this widespread, but often forgotten protocol and port? Could it also be useful for NAT traversal in extreme conditions? Alex (pankratov), do you have any experience with Hamachi on this tip? T Travis Kalanick Red Swoosh, Inc. Blog - http://blog.redswoosh.net High quality video without bandwidth costs! www.redswoosh.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060616/8345f518/attachment.htm From saikat at cs.cornell.edu Fri Jun 16 17:05:52 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling In-Reply-To: <200606161617.k5GGH318029763@be9.noc0.redswoosh.com> References: <200606161617.k5GGH318029763@be9.noc0.redswoosh.com> Message-ID: <1150477552.28939.48.camel@localhost.localdomain> On Fri, 2006-06-16 at 09:06 -0700, Travis Kalanick wrote: > Maybe something could be coded up to tunnel over ICMP to a proxy > server (or proxy peer), that then translates communication back to the > intended protocol and port and forwards communication along. Here's a starting point: http://www.cs.uit.no/~daniels/PingTunnel/ -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060616/5a414eea/attachment.pgp From coderman at gmail.com Fri Jun 16 17:13:57 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling In-Reply-To: <200606161617.k5GGH318029763@be9.noc0.redswoosh.com> References: <200606161617.k5GGH318029763@be9.noc0.redswoosh.com> Message-ID: <4ef5fec60606161013x609bdf11w24a6e1a6f9b23498@mail.gmail.com> On 6/16/06, Travis Kalanick wrote: > ... > It got me to thinking about ICMP tunneling around these wireless "toll > booths" so I could travel Asia and even the states without having to > communicate over those popular ports that cost money to communicate over. depending on how the captive portal is setup i've had luck using an openvpn connection in UDP mode to port 53 to a server i run at home or elsewhere. obviously that means you can't run DNS on this host too. if the portal is setup properly (that is, they provide a DNS server and restrict all lookups to this endpoint) then you would have to use a more inefficient Kaminsky style DNS tunnel. the problem with using ICMP (which otherwise might work well) is how frequently it gets dropped or filtered, especially if you try sending large payloads in ping packets for example. this would be a fun experiment. there was also a very NOT legal utility released last year at defcon (i think it was called "partyline" but i can't find it anymore) that would sniff for authenticated users who paid for service, set your wireless MAC to match, and then use a UDP openvpn tunnel for transport on their session without kicking them off or causing problems (like the TCP stack does when two hosts are sharing an IP/MAC). and last, it's not really applicable to your situation but there is even a covert tunnel utility using tun/tap devices that performs raw packet injection of specific types of 802.11 control/mgmt packets that are always responded to so that two clients could use a WISP tower AP for backhaul for example. i'd be curious to know if you have much luck, or if anyone else on the list is aware of other tunneling applications/methods. this always reminded me of NAT busting to some degree, and i expect over time a good p2p toolkit will include all sorts of such features for internetworking across various transports and environments. From sgentle at gmail.com Fri Jun 16 18:31:11 2006 From: sgentle at gmail.com (Sam Gentle) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <20060616071643.9AEC73FC50@capsicum.zgp.org> References: <20060616071643.9AEC73FC50@capsicum.zgp.org> Message-ID: <489e77c10606161131r6a1a29dbxbd567aa32d6fdbae@mail.gmail.com> On 6/16/06, David Barrett wrote: > For example, is there some application like netstat or Sysinternal's TCPview > that not only shows which connections are currently active (and to which > processes they belong), but how much bandwidth they are actually using? There is a utility called AnalogX PacketMon that serves as a packet sniffer (using win2k/xp's raw sockets) - I realise that's not exactly what you're looking for, but I often use it to get an idea of what's using bandwidth. It might be possible to use a system similar to that to get definite numbers, if those are required. Sam From dbarrett at quinthar.com Fri Jun 16 19:24:42 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <4492D283.6080206@hamachi.cc> Message-ID: <20060616192447.144603FC3E@capsicum.zgp.org> Thanks Alex. All good suggestions, though I agree they're a bit on the fringe. The process injection technique is especially clever. I was hoping you'd know of a secret undocumented "GetProcessNetStatistics" function, but alas, it doesn't appear to exist. -david > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Alex Pankratov > Sent: Friday, June 16, 2006 8:47 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] Measure per-application bandwidth in Win32 > > I am not aware of any Win32 API that does what you are asking > for and I would be surprised if there's such functionality. > > I can think of three ways of doing what you want though, all > are pretty hacky and fairly complex. > > Option (a) is to inject your traffic accounting DLL into each > process using CreateRemoteThread trick (see injLib for details) > and hook send/recv/etc functions. This is not hard to do, but > requires some voodoo magic for taking care of freshly spawned > processes. > > Option (b) involves writing TDI driver or doing some sort of > hooking at TDI level. That's I think how TCPView works. > > Option (c) is to write generic driver that does NDIS hooking > to get an access to network data at TCP/IP level. You will be > able to trace Send requests back to the calling application, > but you will need to create and maintain the state to deduce > who Receives are for. > > Alex > > David Barrett wrote: > > Do you know of any way to break down current bandwidth usage by > application? > > > > > > > > For example, is there some application like netstat or Sysinternal's > > TCPview that not only shows which connections are currently active (and > > to which processes they belong), but how much bandwidth they are > > actually using? > > > > > > > > Alternatively, do you know of any Win32 API functions that could be used > > to write such a utility? > > > > > > > > -david > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > _______________________________________________ > > Here is a web page listing P2P Conferences: > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From dbarrett at quinthar.com Fri Jun 16 19:26:12 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling In-Reply-To: <4ef5fec60606161013x609bdf11w24a6e1a6f9b23498@mail.gmail.com> Message-ID: <20060616192622.4DEDE3FD5D@capsicum.zgp.org> Damn, that partyline application sounds tricky. Very clever. > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of coderman > Sent: Friday, June 16, 2006 10:14 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] ICMP tunneling > > On 6/16/06, Travis Kalanick wrote: > > ... > > It got me to thinking about ICMP tunneling around these wireless "toll > > booths" so I could travel Asia and even the states without having to > > communicate over those popular ports that cost money to communicate > over. > > depending on how the captive portal is setup i've had luck using an > openvpn connection in UDP mode to port 53 to a server i run at home or > elsewhere. obviously that means you can't run DNS on this host too. > > if the portal is setup properly (that is, they provide a DNS server > and restrict all lookups to this endpoint) then you would have to use > a more inefficient Kaminsky style DNS tunnel. > > the problem with using ICMP (which otherwise might work well) is how > frequently it gets dropped or filtered, especially if you try sending > large payloads in ping packets for example. this would be a fun > experiment. > > there was also a very NOT legal utility released last year at defcon > (i think it was called "partyline" but i can't find it anymore) that > would sniff for authenticated users who paid for service, set your > wireless MAC to match, and then use a UDP openvpn tunnel for transport > on their session without kicking them off or causing problems (like > the TCP stack does when two hosts are sharing an IP/MAC). > > and last, it's not really applicable to your situation but there is > even a covert tunnel utility using tun/tap devices that performs raw > packet injection of specific types of 802.11 control/mgmt packets that > are always responded to so that two clients could use a WISP tower AP > for backhaul for example. > > i'd be curious to know if you have much luck, or if anyone else on the > list is aware of other tunneling applications/methods. this always > reminded me of NAT busting to some degree, and i expect over time a > good p2p toolkit will include all sorts of such features for > internetworking across various transports and environments. > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From dbarrett at quinthar.com Fri Jun 16 19:29:17 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <489e77c10606161131r6a1a29dbxbd567aa32d6fdbae@mail.gmail.com> Message-ID: <20060616192922.3962A3FD67@capsicum.zgp.org> That'd work as well, but what's the latest on raw socket support in XP SP2? I seem to recall you need to install a device driver (which requires admin privileges and a reboot). Is there any way to do raw sockets on XP SP2 with less hassle? -david > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Sam Gentle > Sent: Friday, June 16, 2006 11:31 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] Measure per-application bandwidth in Win32 > > On 6/16/06, David Barrett wrote: > > For example, is there some application like netstat or Sysinternal's > TCPview > > that not only shows which connections are currently active (and to which > > processes they belong), but how much bandwidth they are actually using? > > There is a utility called AnalogX PacketMon that serves as a packet > sniffer (using win2k/xp's raw sockets) - I realise that's not exactly > what you're looking for, but I often use it to get an idea of what's > using bandwidth. It might be possible to use a system similar to that > to get definite numbers, if those are required. > > Sam > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From sgentle at gmail.com Fri Jun 16 21:25:13 2006 From: sgentle at gmail.com (Sam Gentle) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <20060616192922.3962A3FD67@capsicum.zgp.org> References: <489e77c10606161131r6a1a29dbxbd567aa32d6fdbae@mail.gmail.com> <20060616192922.3962A3FD67@capsicum.zgp.org> Message-ID: <489e77c10606161425r48795a8pbcff4fb6fe81a7aa@mail.gmail.com> On 6/17/06, David Barrett wrote: > That'd work as well, but what's the latest on raw socket support in XP SP2? > I seem to recall you need to install a device driver (which requires admin > privileges and a reboot). Is there any way to do raw sockets on XP SP2 with > less hassle? Hmm, it seems to have been half-crippled. By the looks of things, you'll get incoming traffic but not outgoing. What a pain... http://seclists.org/lists/nmap-hackers/2005/Apr-Jun/0000.html That said, I'm pretty sure raw sockets always required admin priveleges. Sam From coderman at gmail.com Sat Jun 17 12:29:22 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] user centric network endpoint based session authentication/privacy Message-ID: <4ef5fec60606170529g26e914f6r401c84b582907a8a@mail.gmail.com> http://groups.google.com/group/peertech/browse_thread/thread/accc3adeaa53328a """ throwing down the gauntlet: --- using various authentication and key management methods at the TCP session level associated with a specific IP/port endpoint pair for access to network services[1][2][3][4][5]* is a relic from decades past and is not only inefficient and inflexible but actively detrimental to good usable security due to the baggage and complexity inherent in these methods.[6][7][8] access to network services should be provided on top of a network endpoint local to the two domains requesting and providing services respectively, with user centric authentication for initialization of the secure IPv4/IPv6 tunnel session to which services are bound and revocation performed by terminating this session and the ability to reestablish it. revocable delegation is implemented by proxy of traffic between peers to the delegated domain and irrevocable delegation implemented by sharing authentication credentials for the desired endpoint service(s) with the trusted peer for direct communication without proxy. ... in a sense this is simply a way to exchange "the capability to communicate with me privately" and then utilize the services made available to your peers when this capability is exercised. """ From larytet.8753341 at bloglines.com Sat Jun 17 12:48:25 2006 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling Message-ID: <1150548505.1097611250.25567.sendItem@bloglines.com> "Maybe something could be coded up to tunnel over ICMP to a proxy server (or proxy peer), that then translates communication back to the intended protocol and port and forwards communication along." check http://rodi.sf.net - it has DNS tunnel (port 53) and bouncers (proxys) i could allow port 53 on http://www.gomyplace.com/ if you think you need it and design gomyplace daemon in a way to use UDP instead of TCP From tianhao.qiu at gmail.com Mon Jun 19 05:56:59 2006 From: tianhao.qiu at gmail.com (Tianhao Qiu) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <20060616071643.9AEC73FC50@capsicum.zgp.org> References: <20060616071643.9AEC73FC50@capsicum.zgp.org> Message-ID: <44963CAB.90505@gmail.com> David Barrett wrote: > Do you know of any way to break down current bandwidth usage by application? > > > > For example, is there some application like netstat or Sysinternal?s > TCPview that not only shows which connections are currently active (and > to which processes they belong), but how much bandwidth they are > actually using? There is a nice software called netlimiter: http://www.netlimiter.com/. It's not free though. I recommend the old version: http://www.netlimiter.com/download/nl_v130.exe, which is much cleaner than its newest version. If you don't want to pay, there is a freeware version: http://www.netlimiter.com/download/nl_208_mon.exe. > Alternatively, do you know of any Win32 API functions that could be used > to write such a utility? > > > > -david > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From dbarrett at quinthar.com Mon Jun 19 06:53:59 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <44963CAB.90505@gmail.com> Message-ID: <20060619065409.5196F3FC70@capsicum.zgp.org> Wow, that's incredible. Do you have any idea how it does it? I note it requires a reboot to work; probably some low-level driver? -david > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Tianhao Qiu > Sent: Sunday, June 18, 2006 10:57 PM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] Measure per-application bandwidth in Win32 > > David Barrett wrote: > > Do you know of any way to break down current bandwidth usage by > application? > > > > > > > > For example, is there some application like netstat or Sysinternal's > > TCPview that not only shows which connections are currently active (and > > to which processes they belong), but how much bandwidth they are > > actually using? > > There is a nice software called netlimiter: http://www.netlimiter.com/. > It's not free though. I recommend the old version: > http://www.netlimiter.com/download/nl_v130.exe, which is much cleaner > than its newest version. If you don't want to pay, there is a freeware > version: http://www.netlimiter.com/download/nl_208_mon.exe. > > > Alternatively, do you know of any Win32 API functions that could be used > > to write such a utility? > > > > > > > > -david > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > _______________________________________________ > > Here is a web page listing P2P Conferences: > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From tianhao.qiu at gmail.com Mon Jun 19 07:05:04 2006 From: tianhao.qiu at gmail.com (Tianhao Qiu) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <20060619065409.5196F3FC70@capsicum.zgp.org> References: <20060619065409.5196F3FC70@capsicum.zgp.org> Message-ID: <44964CA0.1020400@gmail.com> David Barrett wrote: > Wow, that's incredible. Do you have any idea how it does it? > > I note it requires a reboot to work; probably some low-level driver? As far as I know, it uses Winsock 2 Layered Service Provider. Some links about LSP: http://www.microsoft.com/msj/0599/LayeredService/LayeredService.aspx http://www.komodia.com/index.php?page=lsp.html > > -david > >> -----Original Message----- >> From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On >> Behalf Of Tianhao Qiu >> Sent: Sunday, June 18, 2006 10:57 PM >> To: Peer-to-peer development. >> Subject: Re: [p2p-hackers] Measure per-application bandwidth in Win32 >> >> David Barrett wrote: >>> Do you know of any way to break down current bandwidth usage by >> application? >>> >>> >>> For example, is there some application like netstat or Sysinternal's >>> TCPview that not only shows which connections are currently active (and >>> to which processes they belong), but how much bandwidth they are >>> actually using? >> There is a nice software called netlimiter: http://www.netlimiter.com/. >> It's not free though. I recommend the old version: >> http://www.netlimiter.com/download/nl_v130.exe, which is much cleaner >> than its newest version. If you don't want to pay, there is a freeware >> version: http://www.netlimiter.com/download/nl_208_mon.exe. >> >>> Alternatively, do you know of any Win32 API functions that could be used >>> to write such a utility? >>> >>> >>> >>> -david >>> > From dbarrett at quinthar.com Mon Jun 19 08:13:22 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Real-world UPnP stats In-Reply-To: <1149517411.23856.172.camel@localhost.localdomain> Message-ID: <20060619081330.DCBA93FC27@capsicum.zgp.org> On the topic of UPnP, does anyone have any advice on whether to use the IUPnPNAT interface in Win32 versus going straight to the UPnP layer? As I understand it, IUPnPNAT is a wrapper/helper atop the lower-level UPnP interfaces. Is there any advantage to going with the low-level route versus sticking with the helper? Alternatively, Alex, how difficult did you find it to write your own UPnP code from scratch? And finally, does anybody use UPnP for anything other than NAT port mapping? Can you, for example, query a gateway's realtime bandwidth usage using UPnP somehow? -david > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Saikat Guha > Sent: Monday, June 05, 2006 7:24 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] Real-world UPnP stats > > On Mon, 2006-04-24 at 11:56 -0700, Alex Pankratov wrote: > > We've recently added UPnP support to our client software and > > now I got some server-side stats and they are most interesting. > > > > Check this out - > > > > Roughly a half of all clients that reported success talking to > > their 'routers' and establishing TCP/UDP port mappings were > > still inaccessible from an outside via their mapped ports. > > Interesting. Some reasons for this I can think of are as follows: > > - If I recall, UPnP on a NAT that is behind yet another NAT doesn't work > well (since the UPnP Internet Gateway Device on most NATs > typically doesn't act as a client for the outer NAT's UPnP IGD). This > comes into play when some connects a wireless router to their existing > wired-only NAT or something. > > - UPnP doesn't have nice crash semantics. If an application registers a > mapping, crashes, is restarted, and re-registers the same mapping, some > NATs ignore the new registration while other NATs silently reap the old > mapping. The first case would result in broken behavior. > > - On the flip side, if two different applications register the same > mapping, the latter mapping may silently override the former mapping or > alternatively, the latter may get silently ignored. Either way, one of > the applications suffers. > > > Anyone care to comment or compare this to their own numbers ? > > While I don't have numbers, I suspect UPnP success rate (for NATs that > support UPnP) would depend on the application as well as the topology > common for the target user population. > > As a side note, if you want to test UPnP functionality, target Japanese > users -- based on anecdotal evidence, UPnP seems far more popular in the > far east than anywhere else. > > cheers, > -- > Saikat From kerry at vscape.com Mon Jun 19 15:34:27 2006 From: kerry at vscape.com (Kerry Bonin) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Application ICMP (traceroute) in XP? Message-ID: <4496C403.3020005@vscape.com> I was wondering if anyone could share tips on their experience with access to ICMP (at least traceroute) in crippled XP sockets? I'm working on integrating the network topology nearby clustering trick via upstream router registration - I'd been hoping the whole XP (SP2/MS05-019) raw sockets issue would get resolved cleanly before I got to this part of the code, but no such luck. Appreciate any help! From dbarrett at quinthar.com Mon Jun 19 18:05:19 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <44964CA0.1020400@gmail.com> Message-ID: <20060619180524.EB3663FC90@capsicum.zgp.org> Cool, thanks for the tip. > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Tianhao Qiu > Sent: Monday, June 19, 2006 12:05 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] Measure per-application bandwidth in Win32 > > David Barrett wrote: > > Wow, that's incredible. Do you have any idea how it does it? > > > > I note it requires a reboot to work; probably some low-level driver? > > As far as I know, it uses Winsock 2 Layered Service Provider. > > Some links about LSP: > http://www.microsoft.com/msj/0599/LayeredService/LayeredService.aspx > http://www.komodia.com/index.php?page=lsp.html > > > > > -david > > > >> -----Original Message----- > >> From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] > On > >> Behalf Of Tianhao Qiu > >> Sent: Sunday, June 18, 2006 10:57 PM > >> To: Peer-to-peer development. > >> Subject: Re: [p2p-hackers] Measure per-application bandwidth in Win32 > >> > >> David Barrett wrote: > >>> Do you know of any way to break down current bandwidth usage by > >> application? > >>> > >>> > >>> For example, is there some application like netstat or Sysinternal's > >>> TCPview that not only shows which connections are currently active > (and > >>> to which processes they belong), but how much bandwidth they are > >>> actually using? > >> There is a nice software called netlimiter: http://www.netlimiter.com/. > >> It's not free though. I recommend the old version: > >> http://www.netlimiter.com/download/nl_v130.exe, which is much cleaner > >> than its newest version. If you don't want to pay, there is a freeware > >> version: http://www.netlimiter.com/download/nl_208_mon.exe. > >> > >>> Alternatively, do you know of any Win32 API functions that could be > used > >>> to write such a utility? > >>> > >>> > >>> > >>> -david > >>> > > > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From ap at hamachi.cc Mon Jun 19 18:26:03 2006 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling In-Reply-To: <200606161617.k5GGH318029763@be9.noc0.redswoosh.com> References: <200606161617.k5GGH318029763@be9.noc0.redswoosh.com> Message-ID: <4496EC3B.2000702@hamachi.cc> > Alex (pankratov), do you have any experience with Hamachi on this tip? No, not with Hamachi. Implementing ICMP tunneling on Windows requires writing NDIS/IM driver or an equivalent and it is an absolutely royal pain in the butt to support. In other words it is somewhat hard to justify :) Alex Travis Kalanick wrote: > Doing a bunch of traveling recently in Asia (adventures blogged here: > http://blog.redswoosh.net ), I?ve found > myself in many situations where I?ve had to purchase wireless Internet > access, quite often at double or triple the prices seen in the States. > > > > Before paying however, I am almost always able to do a DNS look-up and > sometimes even ping remote hosts, though normal Internet traffic over > port 80 (and various other ports) is blocked. > > > > It got me to thinking about ICMP tunneling around these wireless ?toll > booths? so I could travel Asia and even the states without having to > communicate over those popular ports that cost money to communicate over. > > > > Maybe something could be coded up to tunnel over ICMP to a proxy server > (or proxy peer), that then translates communication back to the intended > protocol and port and forwards communication along. It seems that at > least theoretically, with raw sockets and promiscuous settings, even on > Windows machines, this should be possible. > > > > Anybody have experience with tunneling over this widespread, but often > forgotten protocol and port? Could it also be useful for NAT traversal > in extreme conditions? > > > > Alex (pankratov), do you have any experience with Hamachi on this tip? > > > > T > > > > > > Travis Kalanick > Red Swoosh, Inc. > > Blog ? http://blog.redswoosh.net > > High quality video without bandwidth costs! > > www.redswoosh.net > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From ap at hamachi.cc Mon Jun 19 18:53:43 2006 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Real-world UPnP stats In-Reply-To: <20060619081330.DCBA93FC27@capsicum.zgp.org> References: <20060619081330.DCBA93FC27@capsicum.zgp.org> Message-ID: <4496F2B7.1090705@hamachi.cc> David Barrett wrote: > On the topic of UPnP, does anyone have any advice on whether to use the > IUPnPNAT interface in Win32 versus going straight to the UPnP layer? Stay as far away from IUPnPNAT as possible. This bundle of joy tends to randomly fail perfectly valid requests with undocumented return codes. It also depends on SSDP service, which is frequently painted as a major security hole and therefore scares users off. > As I understand it, IUPnPNAT is a wrapper/helper atop the lower-level UPnP > interfaces. Is there any advantage to going with the low-level route versus > sticking with the helper? > > Alternatively, Alex, how difficult did you find it to write your own UPnP > code from scratch? It took me a couple of days to write everything from scratch (zero external dependencies), but that clearly depends on your development style and experience. > And finally, does anybody use UPnP for anything other than NAT port mapping? > Can you, for example, query a gateway's realtime bandwidth usage using UPnP > somehow? > > -david > >> -----Original Message----- >> From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On >> Behalf Of Saikat Guha >> Sent: Monday, June 05, 2006 7:24 AM >> To: Peer-to-peer development. >> Subject: Re: [p2p-hackers] Real-world UPnP stats >> >> On Mon, 2006-04-24 at 11:56 -0700, Alex Pankratov wrote: >>> We've recently added UPnP support to our client software and >>> now I got some server-side stats and they are most interesting. >>> >>> Check this out - >>> >>> Roughly a half of all clients that reported success talking to >>> their 'routers' and establishing TCP/UDP port mappings were >>> still inaccessible from an outside via their mapped ports. >> Interesting. Some reasons for this I can think of are as follows: >> >> - If I recall, UPnP on a NAT that is behind yet another NAT doesn't work >> well (since the UPnP Internet Gateway Device on most NATs >> typically doesn't act as a client for the outer NAT's UPnP IGD). This >> comes into play when some connects a wireless router to their existing >> wired-only NAT or something. >> >> - UPnP doesn't have nice crash semantics. If an application registers a >> mapping, crashes, is restarted, and re-registers the same mapping, some >> NATs ignore the new registration while other NATs silently reap the old >> mapping. The first case would result in broken behavior. >> >> - On the flip side, if two different applications register the same >> mapping, the latter mapping may silently override the former mapping or >> alternatively, the latter may get silently ignored. Either way, one of >> the applications suffers. >> >>> Anyone care to comment or compare this to their own numbers ? >> While I don't have numbers, I suspect UPnP success rate (for NATs that >> support UPnP) would depend on the application as well as the topology >> common for the target user population. >> >> As a side note, if you want to test UPnP functionality, target Japanese >> users -- based on anecdotal evidence, UPnP seems far more popular in the >> far east than anywhere else. >> >> cheers, >> -- >> Saikat > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > From ivan.arce at coresecurity.com Mon Jun 19 21:42:19 2006 From: ivan.arce at coresecurity.com (Ivan Arce) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Measure per-application bandwidth in Win32 In-Reply-To: <20060616192922.3962A3FD67@capsicum.zgp.org> References: <20060616192922.3962A3FD67@capsicum.zgp.org> Message-ID: <44971A3B.1000505@coresecurity.com> Regarding the ICMP tunneling discussion, ICMP covert channels have been used by security researchers and attackers for at least 10 years. Here's one of the first public reference implementations: http://www.phrack.org/show.php?p=49&a=6 and the actual source code is here http://www.phrack.org/show.php?p=51&a=6 As for the brain-damaged decision to cripple raw socket functionality in Windows XP SP2, the easiest way to circumvent it is to use a device driver and talk directly to it. The most popular option is winpcap (http://www.winpcap.org/) which requires installing a kernel driver (administrator) and a reboot but it is quite stable and mature code used by a large number of popular networking and security tools. Winpcap is usually used to capture packets off the wire but the functionality to inject arbitrary packets is also available using the pcap_sendpacket() function. -ivan David Barrett wrote: > That'd work as well, but what's the latest on raw socket support in XP SP2? > I seem to recall you need to install a device driver (which requires admin > privileges and a reboot). Is there any way to do raw sockets on XP SP2 with > less hassle? > > -david > >> -----Original Message----- >> From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On >> Behalf Of Sam Gentle >> Sent: Friday, June 16, 2006 11:31 AM >> To: Peer-to-peer development. >> Subject: Re: [p2p-hackers] Measure per-application bandwidth in Win32 >> >> On 6/16/06, David Barrett wrote: >>> For example, is there some application like netstat or Sysinternal's >> TCPview >>> that not only shows which connections are currently active (and to which >>> processes they belong), but how much bandwidth they are actually using? >> There is a utility called AnalogX PacketMon that serves as a packet >> sniffer (using win2k/xp's raw sockets) - I realise that's not exactly >> what you're looking for, but I often use it to get an idea of what's >> using bandwidth. It might be possible to use a system similar to that >> to get definite numbers, if those are required. >> >> Sam >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@zgp.org >> http://zgp.org/mailman/listinfo/p2p-hackers >> _______________________________________________ -- "Buy the ticket, take the ride" -HST Ivan Arce CTO CORE SECURITY TECHNOLOGIES http://www.coresecurity.com PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A From henryjen at ztune.net Tue Jun 20 00:29:19 2006 From: henryjen at ztune.net (Henry Jen) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] [Fwd: [JXTA user] JXTA-C 2.5 "Mahabaleshwar" Beta Release] Message-ID: <4497415F.7070307@ztune.net> Hi, JXTA-C/C++ is an open source project to provide a C/C++ implementation for JXTA protocol, on which we would like to build different language bindings. In fact, there has being a .NET binding since last release. The project will soon make a 2.5 release, and we would like to invite more developers to join the project, or at lease be aware of such a project and knowing that JXTA is a protocol available in C/Java SE/Java ME which gives you broad choice on devices to run your P2P application inter-operable. Cheers, Henry -------- Original Message -------- Subject: [JXTA user] JXTA-C 2.5 "Mahabaleshwar" Beta Release Date: Thu, 15 Jun 2006 02:26:17 -0700 From: Henry Jen Reply-To: user@jxta.org To: discuss@jxta.org, user@jxta.org, discuss@jxta-c.jxta.org, dev@jxta.org CC: announce@jxta.org Community Members, The next release of JXTA-C, 2.5 "Mahabaleshwar", is scheduled for June 20th, 2006. This release will contain the initial effort to reduce number of threads created. That include thread pool, callback mode for all listeners. Of course, it also include various enhancements of the JXTA-C platform. A Beta test version of JXTA-C 2.5 is now available. This Beta test is likely very close to what the final stable release will be. If you have not been following CVS branch then now would be a very good time to test the upcoming release with your applications. This is a Beta release, it is possible (and perhaps likely) that bugs still remain. It's critical that we find and fix those bugs before the official final release. Your input is essential in this task! How to get involved : 1. Build the beta from the CVS tag "JXTA_C_2_5_BETA" or download the source package from: 2. Rebuild your applications with JXTA-C 2.5 Beta. 3. Test with your applications. 4. File bugs, propose patches, provide comments at 5. If you want to have interactive discussion, drop in MyJxta chat-room with MyJxta2 application or #jxta channel on irc.freenode.net with your favorite IRC client The JXTA-C Release Team Acknowledgments ==================================================================== Special thanks to all of the community members who have contributed ideas, reported problems, provided patches, and have helped greatly to improve the quality, and robustness of this release. Particularly for this release: - Eric Xu : Code review, various patches. JXTA "Bug Day" Online Chat ====================================================================== On Thursday June 15th, 2006 from 7:30am to 12:30pm PDT (2006-06-15T15:30-2006-06-15T20:30 UTC) the JXTA dev teams will be participating in an online chat devoted to the upcoming JXTA-C, JXTA J2ME (JXME) and JXTA Java SE releases. If you are having problems with the beta releases, have questions for the developers or just want to say hello and see what's happening please stop by! Connect via the myJXTA2 application which you can download from : http://download.jxta.org/build/release/2.4b/jxta-myjxta-2.4b.zip Or easier yet, just run it using Java Web Start from: http://download.java.net/jxta/build/milestone/j2se/2.4b/jnlp/myjxta.jnlp JXTA-C Online Chat ==================================================================== If you are having problems with the new release, have questions for the developers or just want to stop by and see what's happening please stop by! Connect via the MyJxta2 application which you can download from : http://download.jxta.org/build/release/latest/ Or easier yet, just run it using Java web start at: http://download.jxta.org/build/release/latest/jnlp/myjxta.jnlp In case you are having problem with MyJxta2, you can join #jxta at irc.freenode.net, we would help you to get to MyJxta2. New Features & Significant Changes ==================================================================== Please refer to http://wiki.java.net/bin/view/Jxta/JxtaCMahabaleshwar for more details. - Thread pool support - jxta_log_callback function prototype changed Downloading and Installing ==================================================================== You can download the dist tarball from: http://download.jxta.org/build/release/c/2.5_beta/ or alternatively directly access CVS. The instruction on how to build JXTA-C can be found at: http://wiki.java.net/bin/view/Jxta/HowToBuildJXTA-C We are looking for people to maintain binary build for their favorite OS, please let us know if you want to contribute. Known incompatibilities between JXTA-C 2.5 and prior JXTA-C 2.x releases ==================================================================== - jxta_log_callback: If you provide your own jxta_log callback in your application, you will have to adapt the new prototype. Issued Closed During JXTA-C 2.5 ==================================================================== 234 DEFECT P5 don't replicate message back to ourselves 235 ENHANC P3 jxta_log_callback using string Known issues in JXTA-C 2.5 Beta ==================================================================== 246 DEFECT P2 jxtaShell segment fault if the port specified is in use --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@jxta.org For additional commands, e-mail: user-help@jxta.org From dbarrett at quinthar.com Tue Jun 20 00:44:25 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Real-world UPnP stats In-Reply-To: <4496F2B7.1090705@hamachi.cc> Message-ID: <20060620004428.A295A3FC3F@capsicum.zgp.org> > -----Original Message----- > From: Alex Pankratov > > David Barrett wrote: > > On the topic of UPnP, does anyone have any advice on whether to use the > > IUPnPNAT interface in Win32 versus going straight to the UPnP layer? > > Stay as far away from IUPnPNAT as possible. This bundle of joy tends > to randomly fail perfectly valid requests with undocumented return > codes. It also depends on SSDP service, which is frequently painted > as a major security hole and therefore scares users off. Did you skip SSDP and just send UPnP requests straight to the gateway? This seems reasonable, given that DHCP has already done all the hard work of locating it. -david From ap at hamachi.cc Tue Jun 20 04:45:24 2006 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Real-world UPnP stats In-Reply-To: <20060620004428.A295A3FC3F@capsicum.zgp.org> References: <20060620004428.A295A3FC3F@capsicum.zgp.org> Message-ID: <44977D64.1020409@hamachi.cc> David Barrett wrote: >> -----Original Message----- >> From: Alex Pankratov >> >> David Barrett wrote: >>> On the topic of UPnP, does anyone have any advice on whether to use the >>> IUPnPNAT interface in Win32 versus going straight to the UPnP layer? >> Stay as far away from IUPnPNAT as possible. This bundle of joy tends >> to randomly fail perfectly valid requests with undocumented return >> codes. It also depends on SSDP service, which is frequently painted >> as a major security hole and therefore scares users off. > > Did you skip SSDP and just send UPnP requests straight to the gateway? This > seems reasonable, given that DHCP has already done all the hard work of > locating it. UPnP code in Hamachi does not rely on SSDP. It does its own UPnP device discovery (via multicasted M-SEARCH) and then communicates with whatever device that supports required functionality. IIRC discovery portion is required, because it's the way to get URL for UPnP/SOAP calls on the device. Merely assuming that DHCP server is the device does not give you much. Alex From travis at redswoosh.net Tue Jun 20 07:59:52 2006 From: travis at redswoosh.net (Travis Kalanick) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling In-Reply-To: <4496EC3B.2000702@hamachi.cc> Message-ID: <200606200811.k5K8B118010817@be9.noc0.redswoosh.com> Regarding Windows implementation, it does not appear that SP2 restricts UDP datagrams over raw sockets (except in the case of spoofing). I'll qualify that I haven't seen/tried an implementation yet, but take a look at this: http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx What new functionality is added to [TCP] in Windows XP Service Pack 2? Restricted traffic over raw sockets Detailed description A very small number of Windows applications make use of raw IP sockets, which provide an industry-standard way for applications to create TCP/IP packets with fewer integrity and security checks by the TCP/IP stack. The Windows implementation of TCP/IP still supports receiving traffic on raw IP sockets. However, the ability to send traffic over raw sockets has been restricted in two ways: . TCP data cannot be sent over raw sockets. . UDP datagrams with invalid source addresses cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must exist on a network interface or the datagram is dropped. Why is this change important? What threats does it help mitigate? This change limits the ability of malicious code to create distributed denial-of-service attacks and limits the ability to send spoofed packets, which are TCP/IP packets with a forged source IP address. Limited number of simultaneous incomplete outbound TCP connection attempts Detailed description The TCP/IP stack now limits the number of simultaneous incomplete outbound TCP connection attempts. After the limit has been reached, subsequent connection attempts are put in a queue and will be resolved at a fixed rate. Under normal operation, when applications are connecting to available hosts at valid IP addresses, no connection rate-limiting will occur. When it does occur, a new event, with ID 4226, appears in the system's event log. Why is this change important? What threats does it help mitigate? This change helps to limit the speed at which malicious programs, such as viruses and worms, spread to uninfected computers. Malicious programs often attempt to reach uninfected computers by opening simultaneous connections to random IP addresses. Most of these random addresses result in a failed connection, so a burst of such activity on a computer is a signal that it may have been infected by a malicious program. According to MSFT, this is the only place where UDP restrictions for raw sockets seem to apply in SP2. I'm sure I'm missing something. . . Travis -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Alex Pankratov Sent: Monday, June 19, 2006 11:26 AM To: Peer-to-peer development. Subject: Re: [p2p-hackers] ICMP tunneling > Alex (pankratov), do you have any experience with Hamachi on this tip? No, not with Hamachi. Implementing ICMP tunneling on Windows requires writing NDIS/IM driver or an equivalent and it is an absolutely royal pain in the butt to support. In other words it is somewhat hard to justify :) Alex Travis Kalanick wrote: > Doing a bunch of traveling recently in Asia (adventures blogged here: > http://blog.redswoosh.net ), I've found > myself in many situations where I've had to purchase wireless Internet > access, quite often at double or triple the prices seen in the States. > > > > Before paying however, I am almost always able to do a DNS look-up and > sometimes even ping remote hosts, though normal Internet traffic over > port 80 (and various other ports) is blocked. > > > > It got me to thinking about ICMP tunneling around these wireless "toll > booths" so I could travel Asia and even the states without having to > communicate over those popular ports that cost money to communicate over. > > > > Maybe something could be coded up to tunnel over ICMP to a proxy > server (or proxy peer), that then translates communication back to the > intended protocol and port and forwards communication along. It seems > that at least theoretically, with raw sockets and promiscuous > settings, even on Windows machines, this should be possible. > > > > Anybody have experience with tunneling over this widespread, but often > forgotten protocol and port? Could it also be useful for NAT > traversal in extreme conditions? > > > > Alex (pankratov), do you have any experience with Hamachi on this tip? > > > > T > > > > > > Travis Kalanick > Red Swoosh, Inc. > > Blog - http://blog.redswoosh.net > > High quality video without bandwidth costs! > > www.redswoosh.net > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From travis at redswoosh.net Tue Jun 20 08:46:02 2006 From: travis at redswoosh.net (Travis Kalanick) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling Message-ID: <200606200857.k5K8vA18011507@be9.noc0.redswoosh.com> It's getting late here guys. . . What I meant to say was I do not see any restrictions here about SP2 blocking ICMP over raw sockets, though it clearly states there are absolute restrictions with TCP, and only some restrictions with regards to UDP. Maybe restrictions on ICMP is just another "undocumented feature" from our friends in Redmond. T -----Original Message----- From: Travis Kalanick [mailto:travis@redswoosh.net] Sent: Tuesday, June 20, 2006 1:00 AM To: 'Peer-to-peer development.' Subject: RE: [p2p-hackers] ICMP tunneling Regarding Windows implementation, it does not appear that SP2 restricts UDP datagrams over raw sockets (except in the case of spoofing). I'll qualify that I haven't seen/tried an implementation yet, but take a look at this: http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx What new functionality is added to [TCP] in Windows XP Service Pack 2? Restricted traffic over raw sockets Detailed description A very small number of Windows applications make use of raw IP sockets, which provide an industry-standard way for applications to create TCP/IP packets with fewer integrity and security checks by the TCP/IP stack. The Windows implementation of TCP/IP still supports receiving traffic on raw IP sockets. However, the ability to send traffic over raw sockets has been restricted in two ways: . TCP data cannot be sent over raw sockets. . UDP datagrams with invalid source addresses cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must exist on a network interface or the datagram is dropped. Why is this change important? What threats does it help mitigate? This change limits the ability of malicious code to create distributed denial-of-service attacks and limits the ability to send spoofed packets, which are TCP/IP packets with a forged source IP address. Limited number of simultaneous incomplete outbound TCP connection attempts Detailed description The TCP/IP stack now limits the number of simultaneous incomplete outbound TCP connection attempts. After the limit has been reached, subsequent connection attempts are put in a queue and will be resolved at a fixed rate. Under normal operation, when applications are connecting to available hosts at valid IP addresses, no connection rate-limiting will occur. When it does occur, a new event, with ID 4226, appears in the system's event log. Why is this change important? What threats does it help mitigate? This change helps to limit the speed at which malicious programs, such as viruses and worms, spread to uninfected computers. Malicious programs often attempt to reach uninfected computers by opening simultaneous connections to random IP addresses. Most of these random addresses result in a failed connection, so a burst of such activity on a computer is a signal that it may have been infected by a malicious program. According to MSFT, this is the only place where UDP restrictions for raw sockets seem to apply in SP2. I'm sure I'm missing something. . . Travis -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Alex Pankratov Sent: Monday, June 19, 2006 11:26 AM To: Peer-to-peer development. Subject: Re: [p2p-hackers] ICMP tunneling > Alex (pankratov), do you have any experience with Hamachi on this tip? No, not with Hamachi. Implementing ICMP tunneling on Windows requires writing NDIS/IM driver or an equivalent and it is an absolutely royal pain in the butt to support. In other words it is somewhat hard to justify :) Alex Travis Kalanick wrote: > Doing a bunch of traveling recently in Asia (adventures blogged here: > http://blog.redswoosh.net ), I've found > myself in many situations where I've had to purchase wireless Internet > access, quite often at double or triple the prices seen in the States. > > > > Before paying however, I am almost always able to do a DNS look-up and > sometimes even ping remote hosts, though normal Internet traffic over > port 80 (and various other ports) is blocked. > > > > It got me to thinking about ICMP tunneling around these wireless "toll > booths" so I could travel Asia and even the states without having to > communicate over those popular ports that cost money to communicate over. > > > > Maybe something could be coded up to tunnel over ICMP to a proxy > server (or proxy peer), that then translates communication back to the > intended protocol and port and forwards communication along. It seems > that at least theoretically, with raw sockets and promiscuous > settings, even on Windows machines, this should be possible. > > > > Anybody have experience with tunneling over this widespread, but often > forgotten protocol and port? Could it also be useful for NAT > traversal in extreme conditions? > > > > Alex (pankratov), do you have any experience with Hamachi on this tip? > > > > T > > > > > > Travis Kalanick > Red Swoosh, Inc. > > Blog - http://blog.redswoosh.net > > High quality video without bandwidth costs! > > www.redswoosh.net > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From dbarrett at quinthar.com Tue Jun 20 10:05:56 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Real-world UPnP stats In-Reply-To: <44977D64.1020409@hamachi.cc> Message-ID: <20060620100609.C24023FC31@capsicum.zgp.org> Ah, ok. I was thinking a multicast M-SEARCH *was* SSDP, but its just semantics. Regardless, I wonder how far you could get just by just hard-coding the POST URL to /upnp/service/WANIPConnection; is there some standard that mandates that URL, or is it merely coincidence that all the NATs I've tested with have it set this way? Incidentally, what have you found works well for AddPortMapping? Do you wildcard RemoteHost and/or ExternalPort, or re-open specifically for each intended peer? Perhaps I misunderstand, but it'd seem ExternalPort *must* be wildcarded for the NAT to function (else two apps or machines would fight for the same external mapping). RemoteHost could be set explicitly each time, but that would fill up the port-mapping table pretty quick for a P2P app. -david > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Alex Pankratov > Sent: Monday, June 19, 2006 9:45 PM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] Real-world UPnP stats > > > > David Barrett wrote: > >> -----Original Message----- > >> From: Alex Pankratov > >> > >> David Barrett wrote: > >>> On the topic of UPnP, does anyone have any advice on whether to use > the > >>> IUPnPNAT interface in Win32 versus going straight to the UPnP layer? > >> Stay as far away from IUPnPNAT as possible. This bundle of joy tends > >> to randomly fail perfectly valid requests with undocumented return > >> codes. It also depends on SSDP service, which is frequently painted > >> as a major security hole and therefore scares users off. > > > > Did you skip SSDP and just send UPnP requests straight to the gateway? > This > > seems reasonable, given that DHCP has already done all the hard work of > > locating it. > > UPnP code in Hamachi does not rely on SSDP. It does its own UPnP device > discovery (via multicasted M-SEARCH) and then communicates with whatever > device that supports required functionality. > > IIRC discovery portion is required, because it's the way to get URL for > UPnP/SOAP calls on the device. Merely assuming that DHCP server is the > device does not give you much. > > Alex > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From dcarboni at gmail.com Tue Jun 20 10:22:50 2006 From: dcarboni at gmail.com (Davide "dada" Carboni) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] tor and man in the middle Message-ID: <71b79fa90606200322u4975a141q98fe42d3e978399f@mail.gmail.com> I was wondering whether and how tor prevents man-in-middle. I notice in the paper [1] that if the attacker runs a malicious onion router and receives a cell *extend* she would be able to reply to the proxy with her own diffie-hellman handshake and thus be able to decrypt all traffic targeted to the second OR in the chain and so forth. I also notice that the proxy rotates to a new circuit once a minute, and this somehow mitigates the number of cells of a user decrypted by a malicious router. [1] Dingledine et al. Tor: the second generation onion router -- http://powerjibe.blogspot.com http://people.crs4.it/dcarboni From auto43348 at hushmail.com Tue Jun 20 21:16:17 2006 From: auto43348 at hushmail.com (auto43348@hushmail.com) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling Message-ID: <20060620211629.8AD22DA826@mailserver8.hushmail.com> and you can do it just over dns: http://dnstunnel.de/ rearden >From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers- >bounces@zgp.org] On >Behalf Of Alex Pankratov >Sent: Monday, June 19, 2006 11:26 AM >To: Peer-to-peer development. >Subject: Re: [p2p-hackers] ICMP tunneling > > > Alex (pankratov), do you have any experience with Hamachi on >this tip? > >No, not with Hamachi. Implementing ICMP tunneling on Windows >requires >writing NDIS/IM driver or an equivalent and it is an absolutely >royal pain >in the butt to support. In other words it is somewhat hard to >justify :) > >Alex > >Travis Kalanick wrote: >> Doing a bunch of traveling recently in Asia (adventures blogged >here: >> http://blog.redswoosh.net ), I've >found >> myself in many situations where I've had to purchase wireless >Internet >> access, quite often at double or triple the prices seen in the >States. >> >> >> >> Before paying however, I am almost always able to do a DNS look- >up and >> sometimes even ping remote hosts, though normal Internet traffic >over >> port 80 (and various other ports) is blocked. >> >> >> >> It got me to thinking about ICMP tunneling around these wireless >"toll >> booths" so I could travel Asia and even the states without >having to >> communicate over those popular ports that cost money to >communicate over. >> >> >> >> Maybe something could be coded up to tunnel over ICMP to a proxy > >> server (or proxy peer), that then translates communication back >to the >> intended protocol and port and forwards communication along. It >seems >> that at least theoretically, with raw sockets and promiscuous >> settings, even on Windows machines, this should be possible. >> >> >> >> Anybody have experience with tunneling over this widespread, but >often >> forgotten protocol and port? Could it also be useful for NAT >> traversal in extreme conditions? >> >> >> >> Alex (pankratov), do you have any experience with Hamachi on >this tip? >> Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 From sreeram at tachyontech.net Wed Jun 21 22:43:42 2006 From: sreeram at tachyontech.net (K.S.Sreeram) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] connect(user,service) Message-ID: <4499CB9E.5000901@tachyontech.net> Hi All! I'm working on a server-less secure communication platform, which provides a simple primitive.... 'connect(user,service)' where users are identified by their RSA public keys. So instead of using the standard 'connect(ip,port)' API, the 'connect(user,service)' API can be used for establishing connections. This platform will make it possible for anybody to build user-to-user communication applications. For instance, I've ported VNC to this platform, which makes it possible to do the equivalent of 'vncviewer ' instead of 'vncviewer '. How it works: - connect( user, service ) first uses a DHT to find the user's location - then it will establish a TCP connection to that location - if direct connection is not possible, it will use some third-party in the network to establish a relayed connection - after that it uses SSL to establish a secure channel. (Note: no PKI is involved at all. Users need to manually exchange their public keys before they can connect to each other) The application is developed in Python, and I'm hoping to get the code into an usable state really really soon. I'm also keen to know if there are any other existing/on-going projects which provide a similar server-less secure communication mechanism? Any feedback/comments/questions welcome!! Regards Sreeram -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060622/80b2c504/signature.pgp From matthew at matthew.at Thu Jun 22 16:17:38 2006 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] connect(user,service) In-Reply-To: <4499CB9E.5000901@tachyontech.net> Message-ID: <01b001c69617$646fcaa0$0202fea9@matthewdesk> Some of what you're describing is like how amicima's MFPNet works. Matthew Kaufman matthew@matthew.at http://www.amicima.com > -----Original Message----- > From: p2p-hackers-bounces@zgp.org > [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of K.S.Sreeram > Sent: Wednesday, June 21, 2006 3:44 PM > To: Peer-to-peer development. > Subject: [p2p-hackers] connect(user,service) > > Hi All! > > I'm working on a server-less secure communication platform, > which provides a simple primitive.... 'connect(user,service)' > where users are identified by their RSA public keys. > > So instead of using the standard 'connect(ip,port)' API, the > 'connect(user,service)' API can be used for establishing connections. > From ivan.arce at coresecurity.com Thu Jun 22 19:44:44 2006 From: ivan.arce at coresecurity.com (Ivan Arce) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling In-Reply-To: <200606200857.k5K8vA18011507@be9.noc0.redswoosh.com> References: <200606200857.k5K8vA18011507@be9.noc0.redswoosh.com> Message-ID: <449AF32C.9050805@coresecurity.com> Travis, I think you are correct, in theory there shouldn't be a problem with outbound ICMP over raw sockets (after all ping.exe does that right?) I don't recall the exact technical details but in the end we decided to move over to using winpcap after SP2. The reasons for that were centered around the crippling of raw sockets plus the TCP throttling and some undocumented changes to ARP table management. -ian Travis Kalanick wrote: > It's getting late here guys. . . > > What I meant to say was I do not see any restrictions here about SP2 > blocking ICMP over raw sockets, though it clearly states there are absolute > restrictions with TCP, and only some restrictions with regards to UDP. > > Maybe restrictions on ICMP is just another "undocumented feature" from our > friends in Redmond. > > T > > > -----Original Message----- > From: Travis Kalanick [mailto:travis@redswoosh.net] > Sent: Tuesday, June 20, 2006 1:00 AM > To: 'Peer-to-peer development.' > Subject: RE: [p2p-hackers] ICMP tunneling > > Regarding Windows implementation, it does not appear that SP2 restricts UDP > datagrams over raw sockets (except in the case of spoofing). I'll qualify > that I haven't seen/tried an implementation yet, but take a look at this: > > http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx > > > > > What new functionality is added to [TCP] in Windows XP Service Pack 2? > Restricted traffic over raw sockets > Detailed description > > A very small number of Windows applications make use of raw IP sockets, > which provide an industry-standard way for applications to create TCP/IP > packets with fewer integrity and security checks by the TCP/IP stack. The > Windows implementation of TCP/IP still supports receiving traffic on raw IP > sockets. However, the ability to send traffic over raw sockets has been > restricted in two ways: > > . TCP data cannot be sent over raw sockets. > > . UDP datagrams with invalid source addresses cannot be sent over raw > sockets. The IP source address for any outgoing UDP datagram must exist on a > network interface or the datagram is dropped. > > > Why is this change important? What threats does it help mitigate? > > This change limits the ability of malicious code to create distributed > denial-of-service attacks and limits the ability to send spoofed packets, > which are TCP/IP packets with a forged source IP address. > > Limited number of simultaneous incomplete outbound TCP connection attempts > Detailed description > > The TCP/IP stack now limits the number of simultaneous incomplete outbound > TCP connection attempts. After the limit has been reached, subsequent > connection attempts are put in a queue and will be resolved at a fixed rate. > Under normal operation, when applications are connecting to available hosts > at valid IP addresses, no connection rate-limiting will occur. When it does > occur, a new event, with ID 4226, appears in the system's event log. > > Why is this change important? What threats does it help mitigate? > > This change helps to limit the speed at which malicious programs, such as > viruses and worms, spread to uninfected computers. Malicious programs often > attempt to reach uninfected computers by opening simultaneous connections to > random IP addresses. Most of these random addresses result in a failed > connection, so a burst of such activity on a computer is a signal that it > may have been infected by a malicious program. > > > > > According to MSFT, this is the only place where UDP restrictions for raw > sockets seem to apply in SP2. I'm sure I'm missing something. . . > > Travis > > > > > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Alex Pankratov > Sent: Monday, June 19, 2006 11:26 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] ICMP tunneling > > > Alex (pankratov), do you have any experience with Hamachi on this tip? > > No, not with Hamachi. Implementing ICMP tunneling on Windows requires > writing NDIS/IM driver or an equivalent and it is an absolutely royal pain > in the butt to support. In other words it is somewhat hard to justify :) > > Alex > > Travis Kalanick wrote: >> Doing a bunch of traveling recently in Asia (adventures blogged here: >> http://blog.redswoosh.net ), I've found >> myself in many situations where I've had to purchase wireless Internet >> access, quite often at double or triple the prices seen in the States. >> >> >> >> Before paying however, I am almost always able to do a DNS look-up and >> sometimes even ping remote hosts, though normal Internet traffic over >> port 80 (and various other ports) is blocked. >> >> >> >> It got me to thinking about ICMP tunneling around these wireless "toll >> booths" so I could travel Asia and even the states without having to >> communicate over those popular ports that cost money to communicate over. >> >> >> >> Maybe something could be coded up to tunnel over ICMP to a proxy >> server (or proxy peer), that then translates communication back to the >> intended protocol and port and forwards communication along. It seems >> that at least theoretically, with raw sockets and promiscuous >> settings, even on Windows machines, this should be possible. >> >> >> >> Anybody have experience with tunneling over this widespread, but often >> forgotten protocol and port? Could it also be useful for NAT >> traversal in extreme conditions? >> >> >> >> Alex (pankratov), do you have any experience with Hamachi on this tip? >> >> >> >> T >> >> >> >> >> >> Travis Kalanick >> Red Swoosh, Inc. >> >> Blog - http://blog.redswoosh.net >> >> High quality video without bandwidth costs! >> >> www.redswoosh.net >> >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@zgp.org >> http://zgp.org/mailman/listinfo/p2p-hackers >> _______________________________________________ >> Here is a web page listing P2P Conferences: >> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > -- --- "Buy the ticket, take the ride" -HST Ivan Arce CTO CORE SECURITY TECHNOLOGIES http://www.coresecurity.com PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A From travis at redswoosh.net Thu Jun 22 20:14:00 2006 From: travis at redswoosh.net (Travis Kalanick) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ICMP tunneling In-Reply-To: <449AF32C.9050805@coresecurity.com> Message-ID: <200606222025.k5MKPL18005878@be9.noc0.redswoosh.com> The real question is whether the kernal somehow filters out ICMP-like data that is flowing over raw sockets. The only way, really to determine this is to try. .. will keep you posted. T -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Ivan Arce Sent: Thursday, June 22, 2006 12:45 PM To: Peer-to-peer development. Subject: Re: [p2p-hackers] ICMP tunneling Travis, I think you are correct, in theory there shouldn't be a problem with outbound ICMP over raw sockets (after all ping.exe does that right?) I don't recall the exact technical details but in the end we decided to move over to using winpcap after SP2. The reasons for that were centered around the crippling of raw sockets plus the TCP throttling and some undocumented changes to ARP table management. -ian Travis Kalanick wrote: > It's getting late here guys. . . > > What I meant to say was I do not see any restrictions here about SP2 > blocking ICMP over raw sockets, though it clearly states there are absolute > restrictions with TCP, and only some restrictions with regards to UDP. > > Maybe restrictions on ICMP is just another "undocumented feature" from our > friends in Redmond. > > T > > > -----Original Message----- > From: Travis Kalanick [mailto:travis@redswoosh.net] > Sent: Tuesday, June 20, 2006 1:00 AM > To: 'Peer-to-peer development.' > Subject: RE: [p2p-hackers] ICMP tunneling > > Regarding Windows implementation, it does not appear that SP2 restricts UDP > datagrams over raw sockets (except in the case of spoofing). I'll qualify > that I haven't seen/tried an implementation yet, but take a look at this: > > http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx > > > > > What new functionality is added to [TCP] in Windows XP Service Pack 2? > Restricted traffic over raw sockets > Detailed description > > A very small number of Windows applications make use of raw IP sockets, > which provide an industry-standard way for applications to create TCP/IP > packets with fewer integrity and security checks by the TCP/IP stack. The > Windows implementation of TCP/IP still supports receiving traffic on raw IP > sockets. However, the ability to send traffic over raw sockets has been > restricted in two ways: > > . TCP data cannot be sent over raw sockets. > > . UDP datagrams with invalid source addresses cannot be sent over raw > sockets. The IP source address for any outgoing UDP datagram must exist on a > network interface or the datagram is dropped. > > > Why is this change important? What threats does it help mitigate? > > This change limits the ability of malicious code to create distributed > denial-of-service attacks and limits the ability to send spoofed packets, > which are TCP/IP packets with a forged source IP address. > > Limited number of simultaneous incomplete outbound TCP connection attempts > Detailed description > > The TCP/IP stack now limits the number of simultaneous incomplete outbound > TCP connection attempts. After the limit has been reached, subsequent > connection attempts are put in a queue and will be resolved at a fixed rate. > Under normal operation, when applications are connecting to available hosts > at valid IP addresses, no connection rate-limiting will occur. When it does > occur, a new event, with ID 4226, appears in the system's event log. > > Why is this change important? What threats does it help mitigate? > > This change helps to limit the speed at which malicious programs, such as > viruses and worms, spread to uninfected computers. Malicious programs often > attempt to reach uninfected computers by opening simultaneous connections to > random IP addresses. Most of these random addresses result in a failed > connection, so a burst of such activity on a computer is a signal that it > may have been infected by a malicious program. > > > > > According to MSFT, this is the only place where UDP restrictions for raw > sockets seem to apply in SP2. I'm sure I'm missing something. . . > > Travis > > > > > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Alex Pankratov > Sent: Monday, June 19, 2006 11:26 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] ICMP tunneling > > > Alex (pankratov), do you have any experience with Hamachi on this tip? > > No, not with Hamachi. Implementing ICMP tunneling on Windows requires > writing NDIS/IM driver or an equivalent and it is an absolutely royal pain > in the butt to support. In other words it is somewhat hard to justify :) > > Alex > > Travis Kalanick wrote: >> Doing a bunch of traveling recently in Asia (adventures blogged here: >> http://blog.redswoosh.net ), I've found >> myself in many situations where I've had to purchase wireless Internet >> access, quite often at double or triple the prices seen in the States. >> >> >> >> Before paying however, I am almost always able to do a DNS look-up and >> sometimes even ping remote hosts, though normal Internet traffic over >> port 80 (and various other ports) is blocked. >> >> >> >> It got me to thinking about ICMP tunneling around these wireless "toll >> booths" so I could travel Asia and even the states without having to >> communicate over those popular ports that cost money to communicate over. >> >> >> >> Maybe something could be coded up to tunnel over ICMP to a proxy >> server (or proxy peer), that then translates communication back to the >> intended protocol and port and forwards communication along. It seems >> that at least theoretically, with raw sockets and promiscuous >> settings, even on Windows machines, this should be possible. >> >> >> >> Anybody have experience with tunneling over this widespread, but often >> forgotten protocol and port? Could it also be useful for NAT >> traversal in extreme conditions? >> >> >> >> Alex (pankratov), do you have any experience with Hamachi on this tip? >> >> >> >> T >> >> >> >> >> >> Travis Kalanick >> Red Swoosh, Inc. >> >> Blog - http://blog.redswoosh.net >> >> High quality video without bandwidth costs! >> >> www.redswoosh.net >> >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@zgp.org >> http://zgp.org/mailman/listinfo/p2p-hackers >> _______________________________________________ >> Here is a web page listing P2P Conferences: >> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > -- --- "Buy the ticket, take the ride" -HST Ivan Arce CTO CORE SECURITY TECHNOLOGIES http://www.coresecurity.com PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From sreeram at tachyontech.net Fri Jun 23 12:21:54 2006 From: sreeram at tachyontech.net (K.S.Sreeram) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ease of use in a decentralized communication system Message-ID: <449BDCE2.40207@tachyontech.net> Hi All As I had mentioned in my earlier post, I'm working on a decentralized communication system, where every user is identified by his RSA key. A DHT is used to map the user's public key to his network location (ip address). A user's contact list basically is just a list of public keys. It has a pretty easy to use GUI, where I can just right click on any contact and choose 'Remote Desktop', and I get a secure NAT/firewall friendly VNC session established. Similarly secure chat and filetransfer are available too. One of the biggest stumbling blocks that will hinder mass adoption of this product is the fact that users need to manually exchange their public keys (e.g thru email), before they can communicate with each other. I'm at a loss of ideas on how to tackle this problem. Right now i'm contemplating having a central key-server (some what like pgp key servers), which is used to fetch public keys when a user adds contacts. This is probably the simplest approach, but it does break the technical purity of a 'completely decentralized system'. Does anybody have any ideas on how this ease-of-use problem can be solved? Regards Sreeram -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060623/fc0c8af9/signature.pgp From alenlpeacock at gmail.com Fri Jun 23 18:22:50 2006 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ease of use in a decentralized communication system In-Reply-To: <449BDCE2.40207@tachyontech.net> References: <449BDCE2.40207@tachyontech.net> Message-ID: Couldn't you use usernames as keys into a DHT that contains the users' public keys (perhaps a parallel DHT to the one that you already have that does service lookups)? Of course you'd have to have some way to resolve namespace clashes, maybe using a petname scheme? And you'd have to figure out how to discourage malicious poisoning of username keys to public key values, but you'd have to do that in a centralized architecture, too. BTW, when you say that posession of the user's public key allows you to get a VNC connection, you're talking about an pre-authenticated session, right? When I first read your description, it sounded like all one needed was the user's public key, and they'd have free reign on that user's box. ;) Alen On 6/23/06, K.S.Sreeram wrote: > Hi All > > As I had mentioned in my earlier post, I'm working on a decentralized > communication system, where every user is identified by his RSA key. A > DHT is used to map the user's public key to his network location (ip > address). A user's contact list basically is just a list of public keys. > > It has a pretty easy to use GUI, where I can just right click on any > contact and choose 'Remote Desktop', and I get a secure NAT/firewall > friendly VNC session established. Similarly secure chat and filetransfer > are available too. > > One of the biggest stumbling blocks that will hinder mass adoption of > this product is the fact that users need to manually exchange their > public keys (e.g thru email), before they can communicate with each other. > > I'm at a loss of ideas on how to tackle this problem. Right now i'm > contemplating having a central key-server (some what like pgp key > servers), which is used to fetch public keys when a user adds contacts. > This is probably the simplest approach, but it does break the technical > purity of a 'completely decentralized system'. > > Does anybody have any ideas on how this ease-of-use problem can be solved? > > Regards > Sreeram > > > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > From bill at billrocks.org Fri Jun 23 19:24:04 2006 From: bill at billrocks.org (Bill Cox) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ease of use in a decentralized communication system In-Reply-To: <449BDCE2.40207@tachyontech.net> References: <449BDCE2.40207@tachyontech.net> Message-ID: <1151090645.5209.11.camel@newt> This sounds easy.... Since you've got a DHT running already, why not let users publish their public keys on the DHT. The key used to look it up could just be the SHA1 (or SHA-256) of their e-mail address. That would let users find buddies by their e-mail. Bill On Fri, 2006-06-23 at 17:51 +0530, K.S.Sreeram wrote: > Hi All > > As I had mentioned in my earlier post, I'm working on a decentralized > communication system, where every user is identified by his RSA key. A > DHT is used to map the user's public key to his network location (ip > address). A user's contact list basically is just a list of public keys. > > It has a pretty easy to use GUI, where I can just right click on any > contact and choose 'Remote Desktop', and I get a secure NAT/firewall > friendly VNC session established. Similarly secure chat and filetransfer > are available too. > > One of the biggest stumbling blocks that will hinder mass adoption of > this product is the fact that users need to manually exchange their > public keys (e.g thru email), before they can communicate with each other. > > I'm at a loss of ideas on how to tackle this problem. Right now i'm > contemplating having a central key-server (some what like pgp key > servers), which is used to fetch public keys when a user adds contacts. > This is probably the simplest approach, but it does break the technical > purity of a 'completely decentralized system'. > > Does anybody have any ideas on how this ease-of-use problem can be solved? > > Regards > Sreeram > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From bill at billrocks.org Fri Jun 23 19:09:44 2006 From: bill at billrocks.org (Bill Cox) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ease of use in a decentralized communication system In-Reply-To: <449BDCE2.40207@tachyontech.net> References: <449BDCE2.40207@tachyontech.net> Message-ID: <1151089784.5209.9.camel@newt> Well, if you already have a DHT running, why not allow users to publish their public keys using their e-mail address as the key? On Fri, 2006-06-23 at 17:51 +0530, K.S.Sreeram wrote: > Hi All > > As I had mentioned in my earlier post, I'm working on a decentralized > communication system, where every user is identified by his RSA key. A > DHT is used to map the user's public key to his network location (ip > address). A user's contact list basically is just a list of public keys. > > It has a pretty easy to use GUI, where I can just right click on any > contact and choose 'Remote Desktop', and I get a secure NAT/firewall > friendly VNC session established. Similarly secure chat and filetransfer > are available too. > > One of the biggest stumbling blocks that will hinder mass adoption of > this product is the fact that users need to manually exchange their > public keys (e.g thru email), before they can communicate with each other. > > I'm at a loss of ideas on how to tackle this problem. Right now i'm > contemplating having a central key-server (some what like pgp key > servers), which is used to fetch public keys when a user adds contacts. > This is probably the simplest approach, but it does break the technical > purity of a 'completely decentralized system'. > > Does anybody have any ideas on how this ease-of-use problem can be solved? > > Regards > Sreeram > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From wesley at felter.org Fri Jun 23 21:00:04 2006 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ease of use in a decentralized communication system In-Reply-To: <449BDCE2.40207@tachyontech.net> References: <449BDCE2.40207@tachyontech.net> Message-ID: <449C5654.6070501@felter.org> K.S.Sreeram wrote: > Hi All > > As I had mentioned in my earlier post, I'm working on a decentralized > communication system, where every user is identified by his RSA key. A > DHT is used to map the user's public key to his network location (ip > address). A user's contact list basically is just a list of public keys. > [snip] > > One of the biggest stumbling blocks that will hinder mass adoption of > this product is the fact that users need to manually exchange their > public keys (e.g thru email), before they can communicate with each other. The last time I tried Groove (back in the 1.0 days), it did initial introductions via email and it seemed fine to me. Maybe it's helpful here to distinguish initial introduction and transitive introductions: only one email message should be required to bring a new user into the network; after that users can introduce each other over the P2P network itself. Directories (e.g. key servers) have obvious privacy problems; I prefer the object-capability style where it is impossible to know that a user exists unless you have been specifically introduced. (Of course in any social network you will have the Marc Canters who want to crawl the whole thing, but oh well.) Wes Felter - wesley@felter.org From saikat at cs.cornell.edu Sun Jun 25 18:37:18 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] connect(user,service) In-Reply-To: <4499CB9E.5000901@tachyontech.net> References: <4499CB9E.5000901@tachyontech.net> Message-ID: <1151260638.5163.117.camel@localhost.localdomain> On Thu, 2006-06-22 at 04:13 +0530, K.S.Sreeram wrote: > I'm working on a server-less secure communication platform, which > provides a simple primitive.... 'connect(user,service)' > where users are identified by their RSA public keys. Interesting. We have been looking at similar enhancements to IP addressing, though more at the broader problem of connection establishment, not just naming. In particular, yes, ip:port is inadequate; and "user":"service" is more stable an identifier over the long-term. But also, that the old notion of being able to _unilaterally_ request to connect to someone (for example by sending a TCP SYN out of the blue) is: a) no longer possible because of NAT/firewalls b) no longer desired because the recipient may want to have a say in who can use the service and who cannot before it spends computational and network resources to service the connection. So in addition to user:service naming, it is useful to have _mediated_ connection establishment. By mediated I mean having an off-path signaling channel that endpoints can use to communicate specific bits of information indirectly with each other under the vigilance of mediating agents. Specific bits of information like public keys, ephemeral IP address and ports, etc. See [1] for details. [1] S. Guha and P. Francis. "Towards a Secure Internet Architecture Through Signaling," Under submission. Apr 2005. [Available online: http://nutss.net/pub/cucs06-nutss/] > I'm also keen to know if there are any other existing/on-going projects > which provide a similar server-less secure communication mechanism? Our implementation is quite similar to yours in that we allow existing applications to use user:service naming, and establish secure connections. We, however, use user@domain as global identifiers, use SIP as our signaling channel (which can either be distributed like DNS, or can run on top of a DHT -- see P2PSIP), distribute keys over this signaling channel, and support unmodified applications by hijacking calls into the OS's socket functions. It is still work-in-progress (see the implementation section in the paper above). cheers, -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060625/df5ca11a/attachment.pgp From dbarrett at quinthar.com Sun Jun 25 23:41:17 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ease of use in a decentralized communication system In-Reply-To: <449BDCE2.40207@tachyontech.net> Message-ID: <20060625234125.DB6C03FC24@capsicum.zgp.org> Here are some suggestions: 1) Put an "Email invitation" button on the client that automatically pops up Outlook, Eudora, Thunderbird, or whatever email clients you want to support. Thus the use needn't worry about saving some public key to disk and mailing it out manually. It might pre-populate the email with instructions on how the recipient should use the public key, as well as instructions on how to download the client if they don't already have it. 2) Put the public key into some kind of special .XYZ filetype that the client is registered to handle. Thus the recipient of the public key need only double-click on the .XYZ file and it'll automatically be imported into his buddy list. 3) Encode in this invitation some kind of secure token such that when you email me your public key and I import it, my client can automatically add my public key to your buddy list without me needing to email it back to you. (Ie, the whole exchange process requires only a single email, not a round trip.) 4) Integrate with IM clients to do the whole thing faster than email. 5) Use multicast such that when the two computers are in "range" of each other (generally on the same LAN) they detect this and do the key exchange direct -- perhaps show a screen "I've detected a client that claims to be on Bob's computer. The secret word is 'foobar'; go verify Bob's computer is showing this screen with the correct secret word. If so, click OK." Then on Bob's computer it'd say "I've detected a client that claims to be on Alice's computer. The secret word is 'foobar'; go verify Alice's computer is showing this screen with the correct word. If so, click OK." Granted, none of these are purely decentralized (well, maybe (5) is, if you're on an ad-hoc wireless network). Ultimately you're using DNS, SMTP, Jabber, or some other centralized protocol to make the exchange happen. But that's a semantics debate. -david > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of K.S.Sreeram > Sent: Friday, June 23, 2006 5:22 AM > To: p2p-hackers@zgp.org; p2p-hackers@lists.zooko.com > Subject: [p2p-hackers] ease of use in a decentralized communication system > > Hi All > > As I had mentioned in my earlier post, I'm working on a decentralized > communication system, where every user is identified by his RSA key. A > DHT is used to map the user's public key to his network location (ip > address). A user's contact list basically is just a list of public keys. > > It has a pretty easy to use GUI, where I can just right click on any > contact and choose 'Remote Desktop', and I get a secure NAT/firewall > friendly VNC session established. Similarly secure chat and filetransfer > are available too. > > One of the biggest stumbling blocks that will hinder mass adoption of > this product is the fact that users need to manually exchange their > public keys (e.g thru email), before they can communicate with each other. > > I'm at a loss of ideas on how to tackle this problem. Right now i'm > contemplating having a central key-server (some what like pgp key > servers), which is used to fetch public keys when a user adds contacts. > This is probably the simplest approach, but it does break the technical > purity of a 'completely decentralized system'. > > Does anybody have any ideas on how this ease-of-use problem can be solved? > > Regards > Sreeram > From seth.johnson at RealMeasures.dyndns.org Mon Jun 26 17:10:43 2006 From: seth.johnson at RealMeasures.dyndns.org (Seth Johnson) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] URGENT Net Neutrality Action TODAY: Please send/fax these materials References: <4498224B.C70DC424@RealMeasures.dyndns.org> Message-ID: <44A01513.A11D2E29@RealMeasures.dyndns.org> Please send the following materials on net neutrality TODAY to Senators on the Commerce and Judiciary Committees. Send me a note if you'd like rich text files of these materials. Commerce resumes markup on the Stevens Bill tomorrow morning. We are working to make sure that language that addresses the nature of network neutrality is in front of as many of the interested legislators as possible. We believe that our proposal can move all parties to a fuller, more constructive understanding of this issue. PLEASE FAX these materials or similar to the contacts below. If you compose your own cover notes, I recommend including: 1) a mention of Steve Wozniak's endorsement, 2) something saying this proposal shows the real definition of net neutrality, and 3) a statement that net neutrality language needs to talk about the transport layer, not just "applications, content and services" -- that that basically means use the word "packet." The Judiciary Committee has claimed it has oversight over the matters covered by the Stevens Bill, so there's a tiny text modification you can use in sending the same materials to them -- just replace the opening of the cover letter below with: Committee on the Judiciary United States Senate Dirksen Senate Office Building 224 Dirksen Senate Office Building 147 Washington, D.C. 20510-2603 Dear Members of the Senate Judiciary Committee: Please see the attached proposed legislative language for assuring "network neutrality." We think that the Judiciary Committee will find it particularly interesting in light of the current discussion related to the Stevens Bill, currently in the Commerce Committee. Thanks, all! :-) Seth Suggested Text to Send: See below the following logistical details. Targets: 1) Your own Senators You can get detailed info for any Senator by replacing the "NYJR" in the following link with appropriate values for the particular Senator. NYJR stands for New York's Junior Senator -- Hillary Clinton. So plug in the appropriate state and "graduating class" for the Senator you want: > http://www.visi.com/juan/congress/cgi-bin/newmemberbio.cgi?lang=&member=NYJR&site=ctc (These links have fax numbers for the committees as well as the individual members, and links to more detailed info about the members) 2) Senate Commerce Committee Majority Fax: 202-224-1259 Minority Fax: 202-228-0303 > http://www.visi.com/juan/congress/cgi-bin/newcommittee.cgi?site=ctc&lang=&commcode=scommerce Ted Stevens (R-AK) [Chairman] Fax: 202-224-2354 Daniel K. Inouye (D-HI) [Ranking Member] Fax: 202-224-6747 3) Senate Judiciary Committee Majority Fax: 202-224-9102 Minority Fax: 202-224-9516 > http://www.visi.com/juan/congress/cgi-bin/newcommittee.cgi?site=ctc&lang=&commcode=sjudiciary Arlen Specter (R-PA) [Chairman] Fax: 202-228-1229 Patrick Leahy (D-VT) [Ranking Member] Fax: 202-224-3479 4) The Sponsors of Snowe-Dorgan Sen Snowe, Olympia [] Fax: 202-224-1946 Sen Boxer, Barbara [CA] Fax: 202-228-2382 Sen Clinton, Hillary Rodham [NY] Fax: 202-228-0282 Sen Dodd, Christopher J. [CT] Fax: 202-224-1083 Sen Dorgan, Byron L. [ND] Fax: 202-224-1193 Sen Inouye, Daniel K. [HI] Fax: 202-224-6747 Sen Leahy, Patrick J. [VT] Fax: 202-224-3479 Sen Obama, Barack [IL] Fax: 202-228-4260 Sen Wyden, Ron [OR] Fax: 202-228-2717 Here are the rest of the Commerce Committee members with fax numbers: John McCain (R-AZ) 202-228-2862 Conrad R. Burns (R-MT) 202-224-8594 Trent Lott (R-MS) 202-224-2262 Kay Bailey Hutchison (R-TX) 202-224-0776 Olympia Snowe (R-ME) 202-224-1946 Gordon Smith (R-OR) 202-228-3997 John Ensign (R-NV) 202-228-2193 George Allen (R-VA) 202-224-5432 John Sununu (R-NH) 202-228-4131 James DeMint (R-SC) 202-228-5143 David Vitter (R-LA) 202-228-5061 Minority: John D. Rockefeller, IV (D-WV) 202-224-7665 John F. Kerry (D-MA) 202-224-8525 Byron L. Dorgan (D-ND) 202-224-1193 Barbara Boxer (D-CA) 202-228-2382 Bill Nelson (D-FL) 202-228-2183 Maria Cantwell (D-WA) 202-228-0514 Frank Lautenberg (D-NJ) 202-228-4054 Ben Nelson (D-NE) 202-228-0012 Mark Pryor (D-AR) 202-228-0908 Here are the rest of the Judiciary Committee members with fax numbers: Orrin G. Hatch (R-UT) 202-224-6331 Charles E. Grassley (R-IA) 202-224-6020 Jon Kyl (R-AZ) 202-224-2207 Mike DeWine (R-OH) 202-224-6519 Jeff Sessions (R-AL) 202-224-3149 Lindsey Graham (R-SC) 202-224-3808 John Cornyn (R-TX) 202-228-2856 Sam Brownback (R-KS) 202-228-1265 Tom Coburn (R-OK) 202-224-6008 Minority: Edward M. Kennedy (D-MA) 202-224-2417 Joseph R. Biden, Jr. (D-DE) 202-224-0139 Herb Kohl (D-WI) 202-224-9787 Dianne Feinstein (D-CA) 202-228-3954 Russell D. Feingold (D-WI) 202-224-2725 Charles Schumer (D-NY) 202-228-3027 Richard J. Durbin (D-IL) 202-228-0400 My Cover Letter and other materials: June 26, 2006 Committee on Commerce, Science, and Transportation United States Senate Dirksen Senate Office Building 508 Dirksen Senate Office Building 558 Washington, D.C. 20510-2603 Dear Members of the Senate Commerce Committee: Please see the attached proposed legislative language for assuring "network neutrality." This proposal has been endorsed by numerous technology, telecommunications and legal professionals, including co-founder of Apple Computer, Steve Wozniak, and one of the original developers of the Internet's fundamental protocols, David Reed. We designed this legislative approach to preserve the nature of the Internet itself, while distinguishing it from the unique types of networks being proposed. It incorporates a correct definition for the term "network neutrality." The right definition for "network neutrality" keeps the Internet platform flexible and reliable for everybody. It cannot merely talk about "applications, content or services" alone, but must talk about how information is transmitted in "packets" independently of how the information is being used. Any other approach will end the flexibility of the Internet and in fact end "network neutrality." S2917 comes the closest to meeting this goal, but still requires language to be added referring to the way information is transmitted in packets. If you enact legislation that authorizes broadband providers to break the principle of "network neutrality" as they purport to provide ?the Internet? -- and not follow the standards that define the Internet -- the effects will be far-ranging and disastrous. The effects don't only relate to the offering of ?tiered services.? Most critically, the enacting of such policy overrides the standards-making processes that establish the rules assuring the sound design of the Internet. It not only impacts areas of free speech and the potentials presently available to Internet users, it affects the ability for the Internet to support a wide variety of applications, and shapes the Internet in such a way as to favor the designs offered by the broadband providers, as opposed to innovative designs. It also affects the ability for global Internet providers to interoperate. We think that this legislative approach will be a revelation to many in the discussion related to network neutrality, and we think that it provides a way for all parties to come to understanding of what the best policy is for innovation, freedom and the appropriate treatment of the unprecedented type of public medium for communications that the Internet has brought to us all. Thank you for your kind and careful consideration. Cordially, Seth Johnson Corresponding Secretary New Yorkers for Fair Use (212) 543-4266 --- Preserve the Internet Standards for Net Neutrality: Introduction and Summary for the Proposed "Internet Platform for Innovation Act of 2006" Attached is a fresh approach to "network neutrality." It recognizes that the Internet is, in fact, neutral. Neither slick promotions offering ?premium? or ?exclusive? services, nor thoughtful legislation, can change that. Any service offered by one of the many networks that form a part of the ?network of networks? called ?the Internet? which favors the delivery of some data packets over others based on their content, source or destination, is simply not ?the Internet.? To pass off access to specially modified networks as ?Internet access? is false and deceptive. In over thirty years of global standards and Internet service provider behavior, Internet participants have come to assume that their traffic will be passed without interference. Because the global ?Internet Protocols? of the Internet are based on this concept, neutrality is inherent in it. So, when Congress seeks to preserve network neutrality, it need not do so by ?regulating the Internet,? as it would be difficult and unnecessary to legislate fundamental global protocols of Internet router behavior. Rather, it is far better to allow Internet-connected services and specially-tailored networks (even if perceived as more valuable to some) to compete freely in the marketplace, regulating those who would misrepresent them as ?Internet? services or ?Internet access.? This has the critical advantage of not allowing the standards to be overridden by these custom modifications. Without standards, there is no competition or ability to connect between networks. For as long as we have had an Internet, we have also had ?local area networks,? or LAN?s, typically operated within a single company. Today, major network access providers have the capability of offering very large LAN?s, and even networks of LAN?s, which may look a lot like the Internet to many unsuspecting consumers. If such LAN providers happen to be the only viable choice for Internet access, they will have the power, working with a few major corporations, to replace the Internet access for millions of Americans with access to a ?walled garden? containing only such portion of the Internet as they allow, and in which only those companies willing and able to pay will be able to have access - or best access - to their subscribers. It may be the case that some consumers will prefer the more limited access being offered, but such offers must compete on their own merits, and not at the loss of an open, consistent, and predictable platform for the transport of innovative products and services by all. Conversely, if networks that treat applications specially wish to create a global network consistent with their practices, they can enter into appropriate processes and work to develop standards. Thus, this proposal recommends that Congress authorize the Federal Trade Commission to enforce a prohibition on false and deceptive representations pertaining to ?Internet access? while leaving innovative networks free to develop their own proprietary services, so long as their nature is not misrepresented. This approach will enable consumers to make informed comparisons among the Internet access being offered as distinct from other products and services offered by their Internet access providers, while assuring that anyone who purchases true Internet access will get what they bargained for - access to the global Internet, unfettered communications throughout the globe, and access by myriad competitors, individuals, advocates, and news sources whose products, services and communications can be made available to them on a level playing field. --- Endorsers' Statement Facing Reality on Net Neutrality Is there a place for fresh thinking and new recommendations in the infamous "network neutrality" debate? The advocates below suggest there is. In the following document we recommend the prosecution of distorted offerings of Internet connectivity as "deceptive practice." When several incumbent telephone carriers announced their plans to give preferential treatment to favored Internet sites, a wide range of Internet users and designers felt in their guts that it somehow violated the very meaning of the term "Internet." On the other hand, many of these people feel uncomfortable letting Congress set parameters for Internet service. It is safer to deal with Internet offerings as a market issue, not to legislate fundamental protocols or router behavior. As a way to break the impasse, we offer the following draft language. We believe the gut feeling -- that one cannot discriminate and still call the service "Internet" -- is founded in reality. The very term "Internet" suggests that participants assume their traffic will be passed without interference; the concept is backed up by over thirty years of standards and ISP behavior. In effect, under the present circumstances, the system of developing specifications, which involves the writing and review of formal documents known as RFCs, which has held since the beginning of the Internet, would be tossed out by a few large providers and equipment manufacturers and replaced by corporate fiat. The loss of an open, consistent, and predictable platform would also crimp innovation at higher levels. Thus, we recommend that Congress clarify the meaning of offering Internet connectivity and set up rules for the Federal Trade Commission to enforce the definition. Two Types of Neutrality So far, much of the argument over "net neutrality" has been over whether service providers should be allowed to favor one application, destination or Internet service over another. This is Net neutrality at the application layer. But the real issue is the neutrality of the IP layer where routers treat alike bits from every type of application. This neutrality is what makes the Internet flexible -- while it also assures uniform treatment of information flow. If this neutrality is not maintained, the Internet will be changed fundamentally. It will no longer be the flexible, open platform that allows anyone with a good idea to compete on a level ground. IP-layer neutrality is not a property of the Internet. It is the Internet. The Internet is a set of agreements (protocols) that enable networks to work together. The heart of the Internet protocol is the agreement that all data packets will be passed through without regard to which application created them or what's inside of them. This reliable, uniform treatment of packets is precisely what has made the Internet a marketplace of innovation so critical to our economy. Providers certainly should be allowed to develop services within their own networks, treating data any way they want. But that's not the Internet. If they want to participate in the Internet, they need to follow the protocols that have been developed over the course of more than thirty years through consensus standards processes. Nor should they be permitted to single-handedly subvert the authority of the processes that have developed and maintained the Internet. We call on Congress to end the confusion and protect not only the Internet but the tens of millions of American citizens who need to know that when they buy Internet access, they're getting access to the real Internet. Network providers who offer services that depend on violating IP-layer neutrality should be prohibited from labeling those services as "Internet," as their doing so will only undermine the weight of consensus authority presently accorded to the existing standards. The term "Internet" represents specific standards that provide IP-layer neutral connectivity that supports the openness of access and innovation that have been the defining characteristics of the Internet since its origins. To that end, we present the attached draft legislative language and call for concerned citizens and members of Congress to offer their support for passing it into law. Signed, (Affiliations listed for identification only) John Bachir, Lead Developer, Lyceum Daniel Berninger, Senior Analyst, Tier1 Research Dave Burstein, Editor, DSL Prime Steven Cherry, Senior Associate Editor, IEEE Spectrum Gordon Cook, Editor, Publisher and Owner since 1992 of the COOK Report on Internet Protocol Susan Crawford, Associate Professor of Law, Cardozo Law School Cynthia H. de Lorenzi, Washington Bureau for ISP Advocacy Ray English, Director of Libraries, Oberlin College Miles R. Fidelman, President, The Center for Civic Networking Richard Forno (bio: http://www.infowarrior.org/rick.html) Bob Frankston, Telecommunications Analyst and Visionary Paul Ginsparg, Cornell University Lucas Gonze, founder, Webjay Bob Gregory, I. T. Manager, Community Action Opportunities Michael Gurstein, Chair: Community Informatics Research Network (CIRN) Dewayne Hendricks, CEO, Dandin Group Paul Hyland, Computer Professionals for Social Responsibility David S. Isenberg, Ph.D., Founder & CEO, isen.com, LLC Saleem Jahangeer, Ph.D. Seth Johnson, New Yorkers for Fair Use Paul Jones, School of Information and Library Science, University of North Carolina - Chapel Hill Peter D. Junger, Professor of Law Emeritus, Case Western Reserve University Joe Karaganis, Social Science Research Council Bruce Kushnick, chairman, Teletruth Michael Maranda, President, Association For Community Networking Kevin Marks, mediAgora Sascha Meinrath, Champaign-Urbana Community Wireless Network, Free Press Edward Mills, Independent Technology Consultant John Mitchell, InteractionLaw Steve Mossbrook, President, Wyoming.com Kenneth G. Olthoff, EFF Austin Advisory Board Andy Oram, Editor, O'Reilly Media Dave Pentecost, documentary television producer Bruce Perens, VP Sourcelabs, Co-founder of the Open Source initiative Jan L. Peterson, Software Developer David P. Reed, contributor to original Internet Protocol design David Rosen, Ed.D., Senior Associate, Newsome Associates Lawrence Rosen, Rosenlaw & Einschlag; Stanford University Lecturer in Law Pamela Samuelson, Richard M. Sherman Distinguished Professor of Law, UC Berkeley Clay Shirky, Interactive Telecommunications Program, New York University Jay Sulzberger, New Yorkers for Fair Use Rahul Tongia, Ph.D., Systems Scientist, School of Computer Science (ISRI) / Dept. of Engineering & Public Policy, Carnegie Mellon University Siva Vaidhyanathan, Department of Culture and Communication, New York University Eric F. Van de Velde, Ph.D., Director, Library Information Technology, California Institute of Technology Esme Vos, Founder, Muniwireless David Weinberger, Fellow, Harvard Berkman Center Michael J. Weisman, JD, LLM, Technology and Intellectual Property Law and Policy Steve Wozniak, Co-Founder of Apple Computer, Inc., Member, National Academy of Engineers Brett Wynkoop, Wynn Data Ltd. Contact: Seth Johnson (212) 543-4266 seth.johnson@RealMeasures.dyndns.org --- Legislative Proposal: ?The Internet Platform for Innovation Act of 2006? (See http://www.dpsproject.com) SECTION 1. SHORT TITLE. This Act may be cited as the "Internet Platform for Innovation Act of 2006". SEC. 2. FINDINGS. The Congress finds the following: (1) The Internet is the most successful means of communication ever developed, connecting people of all walks of life across the globe and enabling unprecedented flexibility in applications and unfettered exchange of information and ideas. (2) The success of the Internet is built on the establishment of certain commonly observed principles of practice, expressed in ?Internet protocols,? governing the manner in which transmissions are exchanged. Interoperation among competing Internet providers on the basis of these principles assures that the Internet remains a generic, flexible platform that supports innovation and free expression. (3) This flexible platform, commonly referred to as the ?IP layer? of the Internet, enables users to independently develop innovative applications by devising rules and conventions describing how information transmitted between connected users will be interpreted in order to serve diverse purposes. The vast collection of applications that have been freely created in this manner is commonly referred to as the ?application layer? of the Internet. (4) The Internet protocols that created this architecture have been developed and maintained by globally recognized standards bodies through participatory processes that work to develop optimal engineering designs and establish the consensus necessary for interoperability. (5) Among the commonly-observed principles of practice that govern Internet transmissions are the following: a) Transmissions are broken down into small pieces referred to as "packets," comprised of small portions of the overall information useful to the users at each transmission's endpoints. A small set of data is prefixed to these packets, describing the source and destination of each packet and how it is to be treated. b) Internet routers transmit these packets to various other routers, changing routers freely as a means of managing network flow. c) Internet routers transmit packets independently of each other and independently of the applications that the packets are supporting. (6) These principles governing the IP layer establish a technical behavior that not only assures the platform's flexibility, but also assures its reliability, availability, universal accessibility, and uniform treatment of information flow. The IP layer assures that all applications may compete on a level basis of connectivity, be they commercially developed by a major corporation and made available to millions, or non- commercial applications developed by individuals and offered at no charge. (7) These principles of practice are commonly understood and recognized as features of existing, commonly- observed communications standards defining the behavior of the Internet transport. (8) This settled understanding of the Internet, based on an architecture created by well-recognized standards bodies, leading to user expectations about the accessibility and behavior of the Internet, is what "the Internet" has come to mean to users in the United States and around the world. (9) Network providers who analyze and interpret the types of applications being conveyed within packets at the IP layer in order to offer special service features (including but not limited to prioritized delivery) intrinsically favor particular application designs that they recognize over competing ones. This practice therefore works at odds with the flexibility and other desirable features of the IP layer brought about by the above-described principles of practice. They depend, for their success, on the neutral platform afforded at the IP layer, even as they upset the neutrality of the IP layer to benefit services best offered at the application layer. (10) Network providers who offer special treatment for specific types of applications by identifying the applications being conveyed by packets, presently face competition from providers who provide neutral networks by means of the above principles, as well as from the diversity of applications, flexibility, uniform treatment of information flow, availability and access made possible by these networks. (11) If network providers in the United States were given support in legislation for presenting as "Internet" services that diverge from the above global principles of practice, as they offer special treatment of packet transmissions on the basis of identifying particular types of applications, the result would be to: a) supplant and undermine the consensus authority currently accorded to existing international protocols and standards-making processes; b) impair innovation and competition by undermining the flexibility and other desirable features afforded by the technical behavior of the Internet transport as described above; c) deny consumers the expectation of quality and breadth of service globally associated with the Internet; and d) suppress freedom of speech within the United States, while the people of other nations continue to enjoy unabridged Internet communications; (12) It is in the national interest to a) support the international consensus authority that gave rise to the current IP layer and associated protocols; b) encourage innovation in the applications layer of the Internet through the flexibility, reliability, availability, and accessibility afforded by the commonly established principles of practice expressed in existing consensus standards for the IP layer; and c) assure consumers in the United States that the globally accessible and open architecture of the Internet will be preserved even as some Internet access providers may choose to compete in offering additional features to their customers. SEC. 3. DECEPTIVE PRACTICES IN PROVIDING INTERNET ACCESS. (1) Definitions.? As used in this Section: (A) Internet.? The term ?Internet? means the worldwide, publicly accessible system of interconnected computer networks that transmit data by packet switching using the standard Internet Protocol (IP), some characteristics of which include: i) Transmissions between users who hold globally reachable addresses, and which transmissions are broken down into smaller segments referred to as "packets" comprised of a small portion of information useful to the users at each transmission's endpoints, and a small set of prefixed data describing the source and destination of each transmission and how the packet is to be treated; ii) routers that transmit these packets to various other routers on a best efforts basis, changing routers freely as a means of managing network flow; and iii) said routers transmit packets independently of each other and independently of the particular application in use, in accordance with globally defined protocol requirements and recommendations. (B) Internet access.? The term ?Internet access? means a service that enables users to transmit and receive transmissions of data using the Internet Protocol in a manner that is agnostic to the nature, source or destination of the transmission of any packet. Such IP transmissions may include information, text, sounds, images and other content such as messaging and electronic mail. (2) Any person engaged in interstate commerce that charges a fee for the provision of Internet access must in fact provide access to the Internet in accord with the above definition, regardless whether additional proprietary content, information or other services are also provided as part of a package of services offered to consumers. (3) Network providers that offer special features based on analyzing and identifying particular applications being conveyed by packet transmissions must not describe these services as "Internet" services. Any representation as to the speed or ?bandwidth? of the Internet access shall be limited to the speed or bandwidth allocated to Internet access. (4) Unfair or Deceptive Act or Practice- A violation of paragraphs 2 or 3 shall be treated as a violation of a rule defining an unfair or deceptive act or practice prescribed under section 18(a)(1)(B) of the Federal Trade Commission Act (15 U.S.C. 57a(a)(1)(B)). The Federal Trade Commission shall enforce this Act in the same manner, by the same means, and with the same jurisdiction as though all applicable terms and provisions of the Federal Trade Commission Act were incorporated into and made a part of this Act. From sreeram at tachyontech.net Mon Jun 26 19:29:00 2006 From: sreeram at tachyontech.net (K.S.Sreeram) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ease of use in a decentralized communication system In-Reply-To: <449C5654.6070501@felter.org> References: <449BDCE2.40207@tachyontech.net> <449C5654.6070501@felter.org> Message-ID: <44A0357C.3030303@tachyontech.net> Wes Felter wrote: > Directories (e.g. key servers) have obvious privacy problems; I prefer > the object-capability style where it is impossible to know that a user > exists unless you have been specifically introduced. (Of course in any > social network you will have the Marc Canters who want to crawl the > whole thing, but oh well.) I'm planning to make the public key registration with the key-server completely optional, so that users who really want it, can just manually email their public keys to each other. So you can be pretty much completely invisible. Even people who try crawling the entire DHT can just know what public keys are available in the system, but they wont know which user the key belongs to. Regards Sreeram -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060627/b6fe56ed/signature.pgp From sreeram at tachyontech.net Mon Jun 26 19:22:15 2006 From: sreeram at tachyontech.net (K.S.Sreeram) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] ease of use in a decentralized communication system In-Reply-To: <1151089784.5209.9.camel@newt> References: <449BDCE2.40207@tachyontech.net> <1151089784.5209.9.camel@newt> Message-ID: <44A033E7.7090402@tachyontech.net> Bill Cox wrote: > Well, if you already have a DHT running, why not allow users to publish > their public keys using their e-mail address as the key? How do you prevent somebody else from using *your* email address? And it is very difficult for the DHT to validate an email address. This could actually turn out to be a big security issue. Regards Sreeram -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060627/3954ed1a/signature.pgp