- NANOG - lists.nanog.org

NAT monitoring
by Matt Duggan 25 Jun '02

25 Jun '02

Hi, I'm currently working on a project to determine if it is possible to provide a cross-vendor NAT management/monitoring solution. I would like to know what your thoughts are regarding NAT management and ideally... 1. What hardware do you use with NAT and in what configuration? (just general info, not configs ;-) ) 2. What do you use to monitor/manage NAT? (opensource?) 3. What corners, if any, did you have to cut? 4. Are you aware of any vendor-specific MIBs solely for NAT? - I seem to remember a draft a while ago. Any other thoughts or comments would also be most useful. regards, Matt. _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

1 0

Re: packet inspection and privacy
by blitz 25 Jun '02

25 Jun '02

At 09:31 6/24/02 -0700, you wrote: >I recently claimed that, in the USA, there is a law that prohibits an >ISP from inspecting packets in a telecommunications network for >anything other than traffic statistics or debugging. > >Was I correct? I would imagine privacy laws prohibit disclosure of this type of information in some places like Europe, but privacy protection is nil in the US. How else could all this spy-ware be legal to jam down people's throats? >I'ld also like to get opinions on privacy policies for network >operators. We operate much like the FCC rules on radio eavesdropping. If we hear/see something, we do not tell anyone else about it, nor ever use it for financial gain. (One of my major gripes about spyware) >It has been suggested that we should adopt a policy that >says that we'll notify customers if: >1) we inspect traffic, If youre a good network operator, you will always have occasions to do this for performance and security issues that only you can determine the validity of. No need to scare the customer. The customer deserves their privacy to the extent you can facilitate it. By taking their money, they should expect their email and web viewing habits will remain private. You might include a line in your TOS that you might inspect traffic for operational purposes, but anything seen will remain confidential and never used for financial gain. (I'm not a lawyer, so I highly suggest you consult one on this aspect). >2) we're aware that an upstream is inspecting traffic Thats a touchy subject, while we expect our feeds will always be doing similar maintenance/security testing, blowing them in and causing customer angst might get you sued or disconnected. >3) we're required to inspect traffic (by anyone). Since the police-state/anti-privacy measures rammed down our throats post 9.11 they might haul you off to the gulag for doing this. Or worse, declare you an "enemy of the state", strip your citizenship and lock you away forever. >Point 3) is just about the same as 1), but it does imply >a slightly different motivation behind the inspection. I know informing a suspect of a phone tap, in the telecom business will get you hard time. SO again, check with your law people...a lot's changed since 9.11 and the police state is doing things that havent been ruled legal or illegal by the USSC. So beware and get competent legal council before implementing anything. These are offered only as opinions...

3 2

packet inspection and privacy
by Mark Kent 24 Jun '02

24 Jun '02

I recently claimed that, in the USA, there is a law that prohibits an ISP from inspecting packets in a telecommunications network for anything other than traffic statistics or debugging. Was I correct? I'ld also like to get opinions on privacy policies for network operators. It has been suggested that we should adopt a policy that says that we'll notify customers if: 1) we inspect traffic, 2) we're aware that an upstream is inspecting traffic 3) we're required to inspect traffic (by anyone). Point 3) is just about the same as 1), but it does imply a slightly different motivation behind the inspection. Thanks, -mark

3 2

SPEWS?
by Alex Rubenstein 24 Jun '02

24 Jun '02

I've had a little run-in with SPEWS, and the crowd on news:news.admin.net-abuse.email. I'm curious; do folks take these guys serious? I'll admit, we had an issue with a customer who spammed, and it took us a little while to zap him. Nevertheless, he was zapped. He had a /27, and SPEWs listed the entire /24 surrounding it. When I asked about this, they said, in not-so-many-words, that by doing this, punishing innocent bystanders, that as long as the ISP noticed and fixed the issue, this was essentially OK to do. Of course, I disagreed, and was called all sorts of names that I'd not used since I was 14. So, to the point; what is the consensus on SPEWs? I've never really noticed them until this point. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

42 98

Korean Ministry unveils anti-spam guideline
by Hank Nussbacher 23 Jun '02

23 Jun '02

For those suffering from spam: http://www.koreaherald.com/SITE/data/html_dir/2002/06/20/200206200013.asp Just FYI - not to open a discussion. -Hank

1 0

re: GE over oc48
by brett watson 23 Jun '02

23 Jun '02

point of clarification: i mentioned luminous and "RPT". their marketing folks call it that, it is in fact RPR (resilient packet ring). -b

1 0

RE: Jamming authorized:
by Matthew Asham 22 Jun '02

22 Jun '02

>Wouldn't count on that cell phone in Canada..... And in other news, http://strategis.ic.gc.ca/SSG/sf05958e.html : Industry Canada is announcing that it will no longer authorize the use of jamming devices. This is consistent with the Departmental mandate to manage the radio frequency spectrum. With respect to the use of jamming devices in connection with federal security and law enforcement functions for national security purposes, an alternative authorization process is currently under review.

1 0

Gig-E over OC48?
by Ralph Doncaster 22 Jun '02

22 Jun '02

What's the cheapest way to get Gig-E over OC48? A couple used Cerent(Cisco) boxes would work, but the $15-$20K price tag is too high. Ralph Doncaster principal, IStop.com

2 1

Jamming authorized:
by blitz 22 Jun '02

22 Jun '02

Wouldn't count on that cell phone in Canada..... >Jamming of radio signals authorized > >Special permission for RCMP, military >restricted to G8 summit, Pope's visit > >By PAUL WALDIE > >Friday, June 21, 2002 Print Edition, Page A1 > >TORONTO -- The Canadian military and the RCMP have been given special >authorization to jam radio and cellphone signals during the G8 Summit >next week and the Pope's visit to Canada in July. > >It's the first time police or the military have ever been allowed to >block signals, an official said. > >The authorization allows the Department of National Defence and the RCMP >to use jamming devices around Calgary and Kananaskis, Alta., from June >17 to June 29 for the summit of leaders from Group of Eight nations. >They will have the same power to jam signals in Toronto from July 16 to >July 31 -- the Pope is scheduled to arrive in Canada July 23 and depart >July 29, with three Toronto appearances in between. > >RCMP spokesman Corporal Benoît Desjardins said jamming is an important >part of the security measures for both events. > >"The RCMP must ensure the safety and security of those attending," he >said yesterday. > >"It could be used, for example, if there was threat of a detonation of >some type of a remote-controlled device. We could jam the frequencies to >make sure nobody could send a signal to that bomb." > >He did not know, however, how the jamming would affect cell phones or >commercial radio transmissions. > >The order, signed by the Minister of Industry on June 6, exempts the >army and police from provisions of the Radiocommunication Act, which >prohibits "the interference with or obstruction of radiocommunication >without lawful excuse." > >The exemption "will provide a way to address the problematic application >of the prohibitions," the order says. > >It specifies that "every reasonable effort shall be made to confine or >restrict to the extent possible interference with or obstruction of a >radiocommunication . . . to the smallest physical area, the fewest >number of frequencies and the minimum duration required to accomplish >the objectives of the interference or obstruction." > >David Warnes, a senior adviser in Industry Canada's telecommunications >branch, said yesterday that it is the first time this kind of order has >been granted. > >He added that cellphone jammers are illegal in Canada, but the >department will soon release a policy on the devices. > >The department held public consultations on cellphone jammers last year >and it is considering permitting them in theatres, hospitals and other >public places. Jamming devices are also illegal in the United States, >but there is a growing underground market for the devices, which can be >bought for about $2,200. >A survey of 2,000 people last year by Decima Research found about 50 per >cent support for jammers in public places. > >Copyright © 2002 Bell Globemedia Interactive Inc. All Rights Reserved.

1 0

Qwest Megacentral DSL weirdness
by Christopher J. Wolff 22 Jun '02

22 Jun '02

Greetings, Approximately two weeks ago, dsl customers over our Qwest Megacentral service began to randomly drop offline. According to Qwest, each of the customers had "good birectional cell flow." However, each of the affected customers were unable to pass any IP traffic. I was able to restore traffic to the affected customers by bouncing their ATM subinterface. No hardware or software changes were made at our NOC. I find this to be a curious situation since many of our dsl customers have been connected continuously for 9-12 months. A few Qwest technicians covertly mentioned that "something was going on at the CO" but used codewords for fear of losing their jobs, while other Qwest technicians claim it was not their problem. Some of the techs outright hung up on the customer. So to make a long story short, I'm curious to know if anyone has the 'inside scoop' or has similar issues that just cropped up. Thanks in advance for your advice. Regards, Christopher J. Wolff, VP CIO Broadband Laboratories http://www.bblabs.com

1 0