- NANOG - 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

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

FYI: CIDR Report changes
by Philip Smith 26 Aug '02

26 Aug '02

Hi, As most of you know, the CIDR Report was conceived by Tony Bates in 1995 as a means to monitor and inform the community about the amount of CIDRisation activities being carried out by Internet Service Providers. The CIDR Report has been highly successful, much referred to and well respected snapshot of the growth in the Routing Table, as well as providing information on the level of aggregation being carried out in our community. In recent years it has become more of a challenge to maintain the software to keep up with the rapid growth in the Internet. Philip Smith, who has produced a widely published Routing Table Report since late 1998, has helped to keep the Report up to date with current allocation and assignment information. But with the large number of views of the routing table, and with the numerous requests many individuals and organisations have been making for enhancements to the CIDR Report, we have agreed that the future of the CIDR Report now rests alongside the very comprehensive BGP Table Analysis which Geoff Huston has been running for the last year. This Friday's CIDR Report (23rd August) was the last one posted from Tony's original system. As from the coming Friday (30th August), the CIDR Report will come from Geoff Huston's new implementation. The e-mail will go to the same operations mailing lists, will look very similar in layout, and will have greatly updated information compared with the original. Furthermore, the routing table view will be the summary from the RouteViews project. The supporting website for the CIDR Report has been vastly improved, with greater detail, the ability to search on aggregation effort per AS, and so on. A snapshot of Geoff's implementation can be found at http://bgp.potaroo.net/cidr/. Regular users of the information contained in the CIDR Report should check out the website and the new features in the report. As ever, comments and feedback are most welcome; these should be sent to <cidr-report(a)potaroo.net>. Tony Bates, Geoff Huston, Philip Smith

1 0

DNS "attack"
by Mark Kent 25 Aug '02

25 Aug '02

FYI, I'm seeing a lot of DNS lookups for all the three letter domain names for which we are listed as authoritative (we have five). The requests look like this: req: nlookup(foo.com) id 64450 type=255 class=255 212.100.232.17.domain > myserver.domain: 31881+ ANY ANY? foo.com. (25) 4500 0035 1e38 0000 ed11 e20a d464 e811 c7f5 4909 0035 0035 0021 0000 7c89 0100 0001 0000 0000 0000 0365 6f73 0363 6f6d 0000 ff00 ff We get about 400 requests per minute, per "attacking" machine, per authoritative name server, per domain. This happened on July 25 with these two sources: 194.186.87.197 130.94.23.70 and today, August 25, with this source: 212.100.232.17 Clearly, this is not a problem right now. But if the number of attacking machines grows, then any machine that serves many three-letter domain names might notice. And who knows, maybe the cretins will get creative and move to four letter domains! Just FYI, -mark P.S. I mentioned the two dates above (7/25, 8/25) purely for entertainment purposes. Consistent with the NY Times article last weekend about putting too much weight in events that are merely coincidences, I don't mean to imply that there is a "25th of the month" conspiracy afoot.

1 0