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.