Re: Routing public traffic across county boundaries in Europe
On Thu, Jul 26, 2007 at 08:52:55AM +0100, Andy Loukes wrote: > What (if any) are the legal implications of taking internet destined > traffic in one country and egressing it in another (with an ip block > correctly marked for the correct country). > Somebody mentioned to me the other day that they thought the Dutch > government didn't allow an ISP to take internet traffic from a Dutch > citizen and egress in another country because it makes it easy for > the local country to snoop. I'm not in a position where I would know for sure, but I'd be surprised if it were the case, in a atmosphere of European common market and police cooperation and all European police-judiciary trust all other European police-judiciary even more than the ones of US states do (as in a Dutch judge can issue a arrest warrant and French / German / ... police will execute it without intervention of a French / German / ... judge, nor decision by any administration, ... Possibly, it could be construed as a violation of the concept of European common market, and thus it is forbidden to forbid. What I would expect is that you still have to obey lawful intercept legislation, so you need to interconnect with the government "black box" rooms, and these are at the major IXs in the country. (And I've repeatedly heard that in the Netherlands, for some time in the past at least, the way the ISPs got rid of the lawful intercept obligation was to have the AMS-IX send a copy of *all* the traffic to the government black box. Not that they had to do that, but it was the easiest / cheapest way.) If there were any such obligation, I'd expect the real reason not to be "the egress country can snoop", but "it is harder for the originating country to snoop". Also, I've heard that Canada had (maybe still has) this legislation forbidding you to route intra-Canadian *telephone* traffic through another country. Something about else nobody would build a intercontinental coast-to-coast Canadian network, would just send long-distance traffic to the USA, go to other coast and send it back to Canada and being this dependent on a foreign country, that's bad. -- Lionel
Re: Home media servers, AUPs, and upstream bandwidth utilization.
On Mon, Dec 25, 2006 at 12:44:37AM +, Jeroen Massar wrote: > Roland Dobbins wrote: >> I recently purchased a Slingbox Pro >> What I'm wondering is, do broadband SPs believe that this kind of >> system will become common enough to make a signficant difference in >> traffic paterns, and if so, how do they believe it will affect >> their access infrastructures in terms of capacity... > That said ISP's should simply have a package saying "50GiB/month > costs XX euros, 100GiB/month costs double" etc. As that covers what > their transits are charging them, nothing more, nothing less. I thought IP transit was mostly paid by "95% percentile highest speed over 5 minutes" or something like that these days? Meaning that ISP's costs are maximised if everyone maxes our their line for the same 6% of the time over the month (even if they don't do anything the rest of the time), and minimised if the usage pattern were nicely spread out? -- Lionel
Re: Tor and network security/administration
On Thu, Jun 22, 2006 at 05:37:25PM +1000, Matthew Sullivan wrote: > Lionel Elie Mamane wrote: >> How an open proxy that will not connect to port 25 is relevant for >> an *email* blacklist is beyond me. > Perhaps because SORBS is not just an email blacklist? My bad. I must have misunderstood its tagline. > Perhaps because it is also used for webmail and other things... Someone running a webmail that doesn't ask for authentication before accepting mail is asking for trouble. You know it, and I'm fairly sure you would list him. If the user has authenticated himself on the webmail, why care whether the TCP connection came from an open TCP or HTTP proxy? The user has identified himself, so you know who it is. >>> All of my discussions with Tor people have indicated [they] do not >>> think I should have the right to deny traffic based on IP address, >>> and that I should find other methods of authenticating traffic >>> into my networks. >> Isn't it rather that they think that filtering on the base of IP >> address is broken in today's Internet, even if tor didn't exist? >> Open proxies, trojans, multi-user computers, dynamic IPs, ... all >> this makes that substituting IP address for people is very, very, >> imprecise. > and that is your opinion, Actually, no. It is what I understand the tor people's opinion to be from their public statements. As for my opinion, I think IP-based is the best you've got when you are dealing with the world at large and not just with a finite, known group of users. As with an MX. As with a webshop. But IP-based authentication should be avoided if you can, and does get over-used in contexts where it is worse than other solutions. A prime example is the scientific journals publishers blindly trusting the whole IP space of universities. We do give shell accounts on some of our machines to externals: Other scientists from abroad, high school students that can make good use of surplus computing resources for a project, ... -- Lionel
Re: Tor and network security/administration
On Thu, Jun 22, 2006 at 11:58:34AM +1000, Matthew Sullivan wrote: > Jeremy Chadwick wrote: >> On Wed, Jun 21, 2006 at 05:02:47PM -0400, Todd Vierling wrote: >>> If the point of the technology is to add a degree of anonymity, >>> you can be pretty sure that a marker expressly designed to state >>> the message "Hi, I'm anonymous!" will never be a standard feature >>> of said technology. That's a pretty obvious non-starter. >> Which begs the original question of this thread which I started: >> with that said, how exactly does one filter this technology? > Of course SORBS' position is actually this - if you are allowing > Trojan traffic over the Tor network you will get listed (regardless > of whether the Trojans can talk to port 25 or not) How an open proxy that will not connect to port 25 is relevant for an *email* blacklist is beyond me. > ...and for what it's worth, I have no problems with anonymous > networks for idealistic reasons, however they are always abused, > they will continue to be abused, Tor is being abused, and I should > be able to allow or deny traffic into my networks as I see fit > All of my discussions with Tor people have indicated [they] do not > think I should have the right to deny traffic based on IP address, > and that I should find other methods of authenticating traffic into > my networks. Isn't it rather that they think that filtering on the base of IP address is broken in today's Internet, even if tor didn't exist? Open proxies, trojans, multi-user computers, dynamic IPs, ... all this makes that substituting IP address for people is very, very, imprecise. -- Lionel
Re: Tor and network security/administration
On Wed, Jun 21, 2006 at 02:53:06PM -0700, Jeremy Chadwick wrote: > On Wed, Jun 21, 2006 at 05:02:47PM -0400, Todd Vierling wrote: >> If the point of the technology is to add a degree of anonymity, you >> can be pretty sure that a marker expressly designed to state the >> message "Hi, I'm anonymous!" will never be a standard feature of >> said technology. That's a pretty obvious non-starter. > Which begs the original question of this thread which I started: > with that said, how exactly does one filter this technology? The list of IP addresses of tor nodes is *public*. If tor users can get it, you can, too. Some IRC networks already run a stripped-down tor client to always tag connections from tor as such, and permit channel operators to ban such connections from their channel should they wish so. -- Lionel
Re: Tor and network security/administration
On Wed, Jun 21, 2006 at 01:14:52PM -0400, Todd Vierling wrote: > On 6/20/06, Lionel Elie Mamane <[EMAIL PROTECTED]> wrote: >>>> You don't do your financial transactions over HTTPS? If you do, by >>>> the very design of SSL, the tor exit node cannot add any HTTP >>>> header. That would be a man-in-the-middle attack on SSL. >>> Which, for an anonymizing network, could be a deliberate situation. >> The user then loses end-to-end encryption with the final server he >> want to connect to. > Depends on your definition of "end-to-end" -- if one "end" is "an > agent on the user's computer", it still fits. But I think you > misunderstand the reason for a filtering proxy in the context of > anonymizing networks; read on: >> So suddenly this daemon needs an UI on every single user on >> the desktop of the user. > Here's where your misunderstanding is evident. The filtering proxy > is not at the Tor exit node; it's at the *entry*. If the proxy is not at the Tor exit node, how can the tor network enforce the addition of the "this connection went through tor" HTTP header that Kevin Day was asking for? Fundamentally, if you rely on a program sitting on the user's computer adding that header, then malevolent users can not add this header, so Kevin Day's purpose is not served. And that is what is being discussed here. >> Let's suppose the tor exit node does this https-man-in-the-middle >> dance. It is not desirable for all connections, so you need some >> way for the user to say per connection what whether it should >> happen or not. SOCKS doesn't have such a thing in its protocol, >> so... > With SOCKS, automated filter control based on IP address (and > hostname, if using SOCKS4a or SOCKS5 with DOMAINNAME address type) is > trivial. What I was trying to say was: The SOCKS protocol has no mechanism for the SOCKS proxy to tell the SOCKS client "before I establish that connection, please ask the user that question and report the answer back to me". -- Lionel
Re: Tor and network security/administration
On Mon, Jun 19, 2006 at 04:25:09PM -0400, Todd Vierling wrote: > On 6/19/06, Lionel Elie Mamane <[EMAIL PROTECTED]> wrote: >> You don't do your financial transactions over HTTPS? If you do, by >> the very design of SSL, the tor exit node cannot add any HTTP >> header. That would be a man-in-the-middle attack on SSL. > Which, for an anonymizing network, could be a deliberate situation. > Tor users are already encouraged to filter through a localhost > instance of a second-stage proxy such as Privoxy. There are other > projects underway to provide similar second-stage proxy services, > possibly capable of functioning as HTTPS m-i-t-m on an intentional > basis. If a user desires to filter browser headers even if > SSL-secured, certainly s/he would know why the "forged" SSL > certificate warning was being presented by the browser. The user then loses end-to-end encryption with the final server he want to connect to. That is unacceptable for a whole range of uses. If a _user_ wants to control browser headers, he can instruct the _browser_ in what headers to send or not. Let's suppose the tor exit node does this https-man-in-the-middle dance. It is not desirable for all connections, so you need some way for the user to say per connection what whether it should happen or not. SOCKS doesn't have such a thing in its protocol, so... you use another protocol and fix all programs on the face of earth to support it? You do an UI call-back where the tor daemon on the user's machine pops up a question "should this HTTPS connection get the extra headers"? So suddenly this daemon needs an UI on every single user on the desktop of the user. Text if that's what the user is using, X11 if that's what he is using, ... And on every single desktop of every logged in user on the system. Wow. And how do you handle client certificates in there? By very design of SSL (unless it is _broken_), the tor exit node won't be able to fake that, too. And how do you handle the verification of the server certificate? How do you know which CA's the client trusts? And even if you have solved all this for SSL, then there is the _next_ protocol that you have to "man in the middle fiddle with". This way lies madness. And above all, it still does not solve your problem. Because the malicious user can choose not to have the additional header added. -- Lionel
Re: Tor and network security/administration
On Sat, Jun 17, 2006 at 08:49:43AM -0500, Kevin Day wrote: > On Jun 17, 2006, at 8:29 AM, Jeremy Chadwick wrote: >> Being as I'm not a network administrator myself (although I do >> filter some stuff using pf and ipfw on my severs), I'm curious what >> NAs think of the following technology: > We've had considerable problems with Tor. > Idiots who like to use stolen credit cards to buy things online find > Tor a nice haven of deniability and covering their tracks. > Our IRC servers, and discussion sites also have had to ban all Tor > IPs that we've seen because of troublemakers using them to evade > bans. > I don't find the anonymity a bad thing, but I would be a whole lot > happier if the default configuration for people running Tor servers > included an option to add HTTP headers saying that it's going > through Tor, so we could decide if we wanted to conduct financial > transactions with them or not. You don't do your financial transactions over HTTPS? If you do, by the very design of SSL, the tor exit node cannot add any HTTP header. That would be a man-in-the-middle attack on SSL. (Unless you count that users will click "accept" on any "this could be a forged certificate" warning.) More generally, tor is not an HTTP proxy, but a TCP proxy. Which doesn't mean it cannot (as in "there is a Turing machine that does it") also go up from layer 4/5 to layer 7 for certain specific application protocols; it would only be harder, ask for more resources from the node, ... -- Lionel
Re: Registrar and registry backend processes.
On Tue, Jan 18, 2005 at 10:03:31AM +0100, Elmar K. Bins wrote: > [EMAIL PROTECTED] (Lionel Elie Mamane) wrote: >>> A nonprofit firm in Frankfurt, Denic eG, which manages Germany's >>> eight million registered .de domain names, has also indicated that >>> it is planning to bid. >> For what it is worth, some consider the .de whois server broken; >> see below. Let's note that the new RFC (3912) doesn't mention the >> "help methodology" anymore. > And some call this not broken but necessary. I can explain off-list, > if you like. >> $ telnet whois.denic.de whois >> Trying 81.91.162.7... >> Connected to whois.denic.de. >> Escape character is '^]'. >> ? >> domain: ? >> status: invalid > Which is defined in what RfC? RFC 954, which has recently (September 2004) been obsoleted by RFC 3912, which doesn't mention it anymore. -- Lionel
Re: Registrar and registry backend processes.
On Mon, Jan 17, 2005 at 06:16:25PM -0800, [EMAIL PROTECTED] wrote: > P.S. > can anyone comment on the reputations of the .net registry > administration contenders (no need to comment on verisign)? > A nonprofit firm in Frankfurt, Denic eG, which manages Germany's > eight million registered .de domain names, has also indicated that > it is planning to bid. For what it is worth, some consider the .de whois server broken; see below. Let's note that the new RFC (3912) doesn't mention the "help methodology" anymore. Begin Quote The .DE whois server is broken. I should be able to telnet to the WHOIS server on the whois port, send it a domain, and get results. If I do that, I get: $ telnet whois.denic.de whois Trying 81.91.162.7... Connected to whois.denic.de. Escape character is '^]'. denic.de domain: denic.de status: connect Connection closed by foreign host. The only way to get "real" data out of the .DE whois server is to use cryptic options: $ telnet whois.denic.de whois Trying 81.91.162.7... Connected to whois.denic.de. Escape character is '^]'. -T dn,ace -C US-ASCII denic.de % Copyright (c)2004 by DENIC % Version: 1.00.0 % % Restricted rights. [ snip ] Further, these options are not documented anywhere, because the usual "help" methodology, as documented by the RFC, doesn't work: $ telnet whois.denic.de whois Trying 81.91.162.7... Connected to whois.denic.de. Escape character is '^]'. ? domain: ? status: invalid Connection closed by foreign host. -- Lionel Elie Mamane
