August 2002 - Test - lists.nanog.org

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
by Scott Gifford 26 Aug '02

26 Aug '02

Brad Knowles <brad.knowles(a)skynet.be> writes: [...] > Moreover, even if all servers on the Internet were secured in > this manner and there were no open relays, it would also require > perfect reverse DNS because the MXes are listed by name and not IP > address -- that's assuming you do a reverse lookup on the IP address > and require that the returned name is on the list. The proposal suggests that you get all of the A records for all of the accepted names, then make sure that one of the A records matches the address that the connection came from. See sec. 2.3. Even if it did require good reverse DNS, that would only be needed for domains that chose to implement this, and only for addresses that are allowed to send mail from that domain. ----ScottG.

2 1

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
by Iljitsch van Beijnum 26 Aug '02

26 Aug '02

On Mon, 26 Aug 2002, Greg A. Woods wrote: > > As a user, I pay my ISP to forward IP packets. If there happen to be TCP > > segments in those packets, that's something between me and the person the > > packet is addressed to, whether the destination port of those TCP segments > > is 25 or something else. > Well, you might be able to pay your ISP for that kind of service, but > not all ISPs need supply such service and certainly not many users > really _need_ such a level of service. So now I have to justify the kind of services I want to use? What's next, me having to register the words I'd like to say over the phone with my phone company? I'll tell you what. I'll filter port 25 for the entire world on my routers, and you mail guys go back to running UUCP like in the good old nearly-spam-free days.

1 0

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
by Scott Gifford 26 Aug '02

26 Aug '02

David Van Duzer <dvanduzer(a)infidels.org> writes: > On Mon, 2002-08-26 at 15:47, Scott Gifford wrote: > > > > The problem that this deals with is the user who needs to dial in to > > AOL and send mail from their corporate account. The proposed solution > > is to tunnel mail through the corporate server, by proving your right > > to relay via SMTP AUTH or else via a VPN. > > > > To make this work well requires support for SMTP AUTH and probably > > STARTTLS (unless the company implementing this proposal wants > > cleartext passwords flying over AOL's network) for all domains which > > want to support Paul's proposal. This isn't necessarily all that > > unreasonable, but should be spelled out more clearly, and makes > > implementation much more involved. > > > Precisely. It's only an issue for those who implement the feature. > Another thought that came to mind was a sort of hybrid between this and > the central registry of trusted servers. If a large ISP, say AOL, implements this, and I operate the mailserver with users who send (relay through me) mail with a from address of their (legitimate) AOL account, I'm choosing to ignore the feature entirely, but it's still affecting me and my users. If a large ISP, say AOL, implements this, and I'm an end-user trying to send mail with a from address at my (legitimate) AOL account, I'm choosing to ignore the feature entirely, but it's still affecting me. I know this isn't what you're looking for, but individual domains aren't so isolated that you can implement this sort of thing without zero effect on other mailservers. You really have to solve the whole problem before it becomes usable at all. I'm not saying it's an unsolvable problem, just that these two issues need to be better addressed before it's a usable suggestion. ----ScottG.

1 0

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
by Scott Gifford 26 Aug '02

26 Aug '02

David Van Duzer <dvanduzer(a)infidels.org> writes: [...] > The presumably appropriate topic for discussion on this list is why > a system such as this would be a problem for network operators who > choose not to implement such a callback feature. So far the only > objection I've seen is "It won't make any difference" and that seems > to be a flimsy argument. Please correct me if I'm missing > something. The problems with it are clearly laid out within the document itself: 3.2. Transport-level e-mail forwarding must be more explicit under this specification. For example if VIXIE(a)NETBSD.ORG's account has a ".forward" file pointing at VIXIE(a)ISC.ORG, then e-mail sent to the former will be received by the latter, but with no change in the payload of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be configured to implicitly add NETBSD's outbound mail relays as "multistage inbound relays." This could scale poorly and may add pressure toward transport remailing (with a new envelope) rather than transport forwarding (reusing the old envelope.) No real solution is proposed for the above; if you remail with a new envelope, how does the original sender get the bounce? And if you don't, the proposal isn't workable without refusing to support forwarding at all, which would just encourage mail service providers to enforce an annoying restriction. 3.3. Roaming hosts such as laptop computers will probably not be able to be listed in the MAIL-FROM MX RR for their return address domain name, and may be forced to use an intermediary for outbound e-mail. STARTTLS or an SSL/SSH tunnel back "home" may become a necessary first hop for mobile e-mail. The problem that this deals with is the user who needs to dial in to AOL and send mail from their corporate account. The proposed solution is to tunnel mail through the corporate server, by proving your right to relay via SMTP AUTH or else via a VPN. To make this work well requires support for SMTP AUTH and probably STARTTLS (unless the company implementing this proposal wants cleartext passwords flying over AOL's network) for all domains which want to support Paul's proposal. This isn't necessarily all that unreasonable, but should be spelled out more clearly, and makes implementation much more involved. ----ScottG.

2 1

Measuring BGP routes
by Dr. Mosh 26 Aug '02

26 Aug '02

Wonder if anyone of you have come across the need for this. I'm basically looking for a Cisco IOS MIB that tells me the number of BGP routes a router currently has, for graphing purposes to keep track over time. Anyone know the mib handy? Thanks private reply works -- -------------- http://www.zeromemory.com - metal for your ears.

4 3

.mil domain root only hosted by one server??
by Vinny Abello 26 Aug '02

26 Aug '02

I just stumbled across something I thought was interesting. All the .mil domain names used by the U.S. Military are served by one single root server. I thought that was a bit odd. I'm sure that one server is more than enough to handle the queries for all the .mil domains with no problem, but it doesn't seem very redundant or safe at all. Especially for something our military uses. There's something that could be beefed up a little bit. My other thought (which others may know) was that perhaps the military runs G.ROOT-SERVERS.NET and I'm just not aware of it. Maybe it's a policy to only run .mil on what they can control? Even still, I think it might be in their best interest to setup a few more. These are the results I got when I queried A.ROOT-SERVERS.NET: ; <<>> DiG 9.2.1 <<>> @a.root-servers.net mil. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;mil. IN A ;; AUTHORITY SECTION: mil. 86400 IN SOA G.ROOT-SERVERS.NET. HOSTMASTER.N IC.mil. 2002082000 3600 900 1209600 86400 ;; Query time: 390 msec ;; SERVER: 198.41.0.4#53(a.root-servers.net) ;; WHEN: Wed Aug 21 15:38:58 2002 ;; MSG SIZE rcvd: 90 I'd like comments from anyone with more information on this. I'm just curious as to why it is this way and what the reasoning behind it is. Maybe I'll email hostmaster.nic.mil and ask. ;) Vinny Abello Network Engineer Server Management vinny(a)tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN

16 28

Notes on the Internet for Bell Heads
by Sean Donelan 26 Aug '02

26 Aug '02

Has anyone written the equivalent of the old Bell Systems Notes on the Network for the Internet? A couple of books come close, Hueston's ISP Survival Guide and Cisco's ISP Essentials. But there doesn't seem to be anything that helps Bell heads understand what switching, routing or signaling means on the Internet. There are a lot of words which are spelled alike, but mean very different things in the Bell world and the Internet world. I've been thinking of it like driving in England or the USA. We drive on different sides of the road. Its safe until you get someone who doesn't know the rules of the road driving on the other side of the Atlantic. So how do you explain the rules of the Internet road to someone used to driving on the telephone system?

18 23

Heads-up
by Randy Bush 26 Aug '02

26 Aug '02

[ posted for a non-nanog friend who is definitely a respected security wonk -- rb ] All: I'm currently doing a study of software upgrading behavior with an eye to figuring out what variables cause people to upgrade or otherwise. Unfortunately, this requires doing some probing of the sampled systems (about 900). I've carefully designed these probes not to cause any damage but there's a real probability that they will raise some IDS alarm bells. The source netblocks these scans are coming from are: 198.144.203.240/28 198.144.201.112/29 I want to apologize for any inconvenience or concern this might have caused or will cause. If you notice any actual damage arising from this testing, please let me know immediately so I can appopriately modify my sensors. Thanks, -Ekr -- [Eric Rescorla ekr(a)rtfm.com] http://www.rtfm.com/

1 0

Traffic Threshold monitoring?
by Rob Mitzel 26 Aug '02

26 Aug '02

Hi everyone, Quick question. We're currently using MRTG to monitor traffic on a number of cisco switches connected to various customers. Now, this is all great and everything, except there's no real way to monitor if a customer's traffic goes completely out of whack (i.e. they start hammering 20 mbps instead of 300kbps) without manually checking MRTG every few minutes (and that'd be kinda time-consuming, you'd think.) We also show individual MRTG pages to our customer base via some handy mods we made. So my question is...what's out there that will allow us to check thresholds on traffic, and notify us if needed? We do have monitoring stations, running CastleRock SNMPc software. We have it set up to tell us when there's broadcast storms and suff, but I've never seen anything for actual traffic monitoring. Thanks in advance! -Rob.

6 5

Bush's Cyber-Security Plan Targets E-Mail
by blitz 26 Aug '02

26 Aug '02

>Here's Big brother...now we're all going to be spies on our fellow citizens. > >http://www.eweek.com/article2/0,3959,481112,00.asp > >August 23, 2002 >By Caron Carlson and Dennis Fisher > >In an effort to bolster the nation's cyber-security, the Bush >administration has plans to create a centralized facility for >collecting and examining security-related e-mail and data and will >push private network operators to expand their own data gathering, >according to an unreleased draft of the plan. > >The proposed cyber-security Network Operations Center is included in a >draft of The National Strategy to Secure Cyberspace, which was >developed by the president's Critical Infrastructure Protection Board >with input from the private sector and is due to be released Sept. 18. > >The call for expanded data collection and analysis results from >administration concerns that efforts to secure cyber-space are >hampered by the lack of a single point of data collection to detect >cyber-security incidents and issue rapid warnings, according to the >draft strategy, obtained by eWEEK. Critics, however, worry that such a >system would be expensive and difficult to manage, and would allow >government agencies to expand their surveillance powers. > >Other recommendations include restricting the use of wireless >technologies by government agencies; requiring corporations to >disclose their IT security practices; establishing a "test bed" for >multivendor patches; creating a certification program for security >personnel; and mandating certifications for all federal IT purchases. > >Howard Schmidt, vice chairman of the PCIPB, said that the center would >consolidate threat data from the country's collection end points, such >as the FBI's National Infrastructure Protection Center, the Critical >Infrastructure Assurance Office, the Department of Energy and >commercial networks. Private companies would be encouraged to increase >the amount of data collected and share it with the government. > >"Major companies generally report this information internally," >Schmidt told eWEEK. "We're looking for that to come back to a central >location." > >According to the draft strategy, the public/private initiative would >involve the major ISPs, hardware and software vendors, IT security >companies, and Computer Emergency Response Teams, in addition to law >enforcement and other agencies. > >Some feel that the government's internecine rivalries and >information-sharing rules will hamstring any attempt at centralized >collection and analysis. > >"There are such high barriers in government to being able to >disseminate information and adjusting the environment to react to >threats, I don't think it will have much impact," said William Harrod, >director of investigative response at TruSecure Corp. in Herndon, Va., >and a former FBI computer forensic specialist. "They'll have different >information coming in from different analysts, and they'll have to >weed through it." > >The proposed strategy recommends that the center be partially >federally funded, but it would inevitably impose new costs on the >private sector without commensurate benefits, critics charged. > >"Government doesn't have a good track record when it comes to >collecting and disseminating massive volumes of data," said Kevin >Baradet, network systems director at Cornell University's Johnson >Graduate School of Management in Ithaca, N.Y. "We could be drowning in >data, most of it noise." > >Then there are the privacy concerns. > >"Whatever the federal government wants to do with its own data is OK >with me as long as it doesn't waste my personal and corporate tax >dollars," said Karl Keller, president of custom software developer IS >Power Inc., in Thousand Oaks, Calif. "The privacy aspects, however, >concern me greatly. This sounds like a dramatic and evil expansion of >Echelon and Carnivore." > >The strategy also calls on the FBI, Secret Service and Federal Trade >Commission to establish a single system for corporations to report >Internet fraud and extortion, illegal hacking, and unauthorized >network intrusions. It recommends that the federal government >systematically collect data on cybercrime victims and cyber-intrusions >from businesses. The administration hopes to assuage industry fears by >recommending legislative changes--including exemptions from Freedom of >Information Act requirements and exemption from antitrust laws--that >would reduce liability for companies turning over communications to >law enforcement.

1 0