- Test - lists.nanog.org

What could have been done differently?
by Sean Donelan 05 Feb '03

05 Feb '03

On Tue, 28 Jan 2003, The New York Times wrote: > A spokesman for Microsoft, Rick Miller, confirmed that a > number of the company's machines had gone unpatched, and > that Microsoft Network services, like many others on the > Internet, experienced a significant slowdown. "We, like the > rest of the industry, struggle to get 100 percent > compliance with our patch management," he said. Many different companies were hit hard by the Slammer worm, some with better than average reputations for security awareness. They bought finest firewalls, they had two-factor biometric locks on their data centers, they installed anti-virus software, they paid for SAS70 audits by the premier auditors, they hired the best managed security consulting firms. Yet, they still were hit. Its not as simple as don't use microsoft, because worms have hit other popular platforms too. Are there practical answers that actually work in the real world with real users and real business needs?

20 29

Re: EuroNOG
by woody＠pch.net 05 Feb '03

05 Feb '03

Oh! Sorry, we didn't know Jim FLEMING was behind it. I'm sure we're all glad to be thus reassured of its bona fides. ----Original Message---- From: Nicolas DEFFAYET <nicolas.deffayet+woody%ndsoftware.net(a)paixhost.pch.net> Subject: Re: EuroNOG On Tue, 2003-02-04 at 11:09, Stephane Bortzmeyer wrote: As requested by Pascal Gloor on EuroNOG mailing-list, i reply to Stephane's message. Flames & co > /dev/null > On Mon, Feb 03, 2003 at 04:52:57PM -0800, > bmanning(a)vacation.karoshi.com <bmanning(a)vacation.karoshi.com> wrote > a message of 45 lines which said: > > > how/why is this proposed group distinct from the European Operator Forum? > > Bill, Nicolas Deffayet just wanted a NOG for himself. Let him play. > > For those who are not members of the 6bone or who do not know France, > let's remind them that: > > * NDsoftware does not exist (it is not in the French directory of > companies) NDSoftware exist. > * Mike Cheney does not exist (NDsoftware lists several english names > because it is "more serious" but all of them are actually fake) Mike CHENEY exist. Mike is (with 2 other people) the EuroNOG founder. > * Euronog is just a spinoff of NDsoftware, no operator ever > participated in it. EuroNOG is neutral. NDSoftware is just a sponsor for domain, website and hosting. There is many operators on euronog(a)ml.euronog.org and there are active: 1: First message 2 Feb 2003 Nicolas DEFFAYET 2: EuroNOG (European Network Operators Group) 3 Feb 2003 Mike CHENEY 3: lets start!!! 3 Feb 2003 Pascal Gloor 4: Re: lets start!!! 3 Feb 2003 Pascal Gloor 5: Re: lets start!!! 3 Feb 2003 Nicolas DEFFAYET 6: Welcome & Workgroup Proposal 4 Feb 2003 Jan Czmok 7: Re: Welcome & Workgroup Proposal 4 Feb 2003 Nicolas DEFFAYET 8: Re: lets start!!! 4 Feb 2003 Blindauer Emmanuel 9: TODO proposal 4 Feb 2003 Nicolas DEFFAYET 10: Re: TODO proposal 4 Feb 2003 Henk Uijterwaal (RIPE-NCC) 11: Re: TODO proposal 4 Feb 2003 Mike CHENEY 12: "...explain how Euronog will differ..." ? 4 Feb 2003 Jim Fleming 13: DDoS tracking WG 4 Feb 2003 Daniel Concepcion 14: Re: DDoS tracking WG 4 Feb 2003 Jim Fleming 15: Re: DDoS tracking WG 4 Feb 2003 Michael Hallgren 16: Re: DDoS tracking WG 4 Feb 2003 Daniel Concepcion 17: Re: TODO proposal 4 Feb 2003 Mike CHENEY 18: Re: DDoS tracking WG 5 Feb 2003 Mike CHENEY 19: explanations needed 5 Feb 2003 Pascal Gloor 20: Re: DDoS tracking WG 5 Feb 2003 Jan Czmok 21: Re: explanations needed 5 Feb 2003 Jim Fleming 22: Re: DDoS tracking WG 5 Feb 2003 Jan Czmok 23: Re: DDoS tracking WG 5 Feb 2003 Daniel Concepcion 24: NOC contact list...database development... 5 Feb 2003 Jim Fleming If you want subscribe to the mailing-list: euronog-subscribe(a)ml.euronog.org. -- Nicolas DEFFAYET, NDSoftware NDSoftware NOC: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ EuroNOG: http://www.euronog.org/

2 1

Re: Remote email access
by John R Levine 04 Feb '03

04 Feb '03

> Blocking "direct-from-dialup" spam is best done on the receiving end, > blocking *unauthenticated* SMTP connections made directly from dial-up > IPs. If there were a definitive list of dialup and DHCP IP ranges, I might agree. But after some years of compiling the MAPS DUL, Pan Am's PDL, the osirusoft list, and who knows how many others, there isn't, so I don't see how that's a practical approach. Blocking outbound SMTP also prevents relay exploits of unsecured servers that will never be secured, and there'll never be a definitive list of them, either. > IMHO, to block ALL outbound port 25 traffic > on the sending end is throwing the baby out with the bathwater. It certainly is, but for most ISPs, there's a very small baby in a huge tub of spam. Remember that this whole question only occurs for dialup or DHCP users who are not using their ISP's mail service. While that probably includes just about everyone you and I know, overall, it's a teensy minority of ISP customers. Regards, John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner "A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

2 2

Tracing where it started
by Phil Rosenthal 04 Feb '03

04 Feb '03

Hello, It might be interesting if some people were to post when they received their first attack packet, and where it came from, if they happened to be logging. Here is the first packet we logged: Jan 25 00:29:37 EST 216.66.11.120 --Phil ISPrime

21 32

Re: Remote email access
by Dave Crocker 04 Feb '03

04 Feb '03

JC, Monday, February 3, 2003, 9:43:01 PM, you wrote: JD> Dave Crocker wrote: >> Recently I had protracted discussions with a number of Ops folks about >> this issue and have chosen to drop that debate. I do not agree with >> blocking port 25, either, but am far more concerned about having a ... JD> Why does a single solution need to be "broadly supported"? interoperability. when there are choices for solving the same problem, a service can make one choice -- or, in this case, each of at least two different services can make different choices -- and a software vendor can make yet another another. then there is no interoperability. that is exactly the problem that I have repeatedly experienced. JD> IMHO, all JD> that is needed is for each individual to find a solution that works for JD> them, given their preferred email client, email host, and provider options. hmmm. sounds like I have not described the problem clearly enough. So here is the short form: My email service provider permits me to post new email from anywhere on the net, as long as I go through proper authentication. (The details of how this is done do not matter; the method is reasonable and sufficient.) The provider happens to support this posting via port 25. When I am traveling, my access often is through a provider that kindly block outbound port 25, so I cannot post email. Each provider has behaved as you suggest, and the result is that I cannot post email. JD> My present solution is to ssh into a server where I have an account, Once again: I have no doubt that individuals are able to solve their individual problems, individually, especially when they are technically savvy. That approach does not make for a viable, large-scale (as in mass-market) industry. d/ -- Dave <mailto:dcrocker@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850

7 14

ATT Dallas Latency? Master Ticket
by Brennan_Murphy＠NAI.com 04 Feb '03

04 Feb '03

Anyone know of a master ticket for latency on ATT's Dallas network? Looks like they have some routing problems this morning. We see traceroutes hit 2sec latency at various hops in their Dallas network. Anyone else see this? Wouldnt normally post a note like this but having trouble getting clear communication from carrier. TIA. 4 | | 12.123.16.30 | gbr1-a30s8.dlstx.ip.att.net | Dallas, TX, USA | | 0 | x | 12.123.16.0 | | 5 | | 12.122.12.57 | tbr1-p013801.dlstx.ip.att.net | Dallas, TX, USA | | 1917 | ----x----- | 12.122.12.0 | | 6 | | 12.122.12.74 | ggr1-p340.dlstx.ip.att.net | Dallas, TX, USA | | 0 | x | 12.122.12.0 | | 7 | | 208.172.129.129 | acr2-so-2-1-0.Dallas.cw.net | Dallas, TX, USA | | 0 | x | 208.172.129.0 | | 8 | | 208.172.130.104 | agr4-loopback.Dallas.cw.net | Dallas, TX, USA | | 0 | x | 208.172.130.0 | | 9 | | 208.172.139.29 | dcr1-so-1-3-0.Dallas.cw.net | Dallas, TX, USA | | 0 | x | 208.172.139.0 |

1 0

Remote email access
by Dave Crocker 04 Feb '03

04 Feb '03

Folks, The Ops community and the IETF Email community appear to have different views about appropriate methods for email posting. The difference frequently means that an effort to post a new message from a network with a firewall, to a remote SMTP, is blocked by the outbound firewall. Blocking outbound SMTP (port 25) is supported by the Ops community as a spam-suppression mechanism. Ops support for this blockage appears to be deeply and broadly held. This note is *not* an effort to debate the Ops concern or the preference for blocking outbound port 25. Rather, I would like to pursue a discussion that simply resolves the disparity between the two communities. The goal is to obtain a coherent recommendation that is acceptable to the Ops and the Email communities. It would permit normal users to easily use their normal software and achieve normal access to normal services. Whatever the current choices are, they are inconsistently available and they frequently require technically knowledgeable users and/or special cooperation by the user's remote ISP. My guess is that a brief IETF BCP document would suffice for describing the recommended profile. For completeness, I suggest that the BCP cover "Remote email access" for posting and retrieval, and that it recommend the details that will permit private, authenticated access for all standardized email services. Some current choices: Email standards provide for posting of email to the usual port 25 or to port 773 for the newer "submit" service. (Submit is a clone of SMTP that operates on a different port and is permitted to evolve independently of SMTP, in order to tailor posting by originators, differently from server-to-server email relaying.) There is also a de facto standard for doing SMTP over SSL on port 465, although this collides with the IANA assignment of that port to another service. Standardized SMTP authentication uses the SMTP Auth command or the SASL service within SMTP. It can also use the de fact "POP hack". All 3 of these mechanisms are inline -- as part of the posting protocol -- so that they work over whatever port is being used for posting. Standardized privacy for SMTP uses SMTP over SSL or it uses SMTP with SASL. SASL can be used on any SMTP or Submit port. SSL can only be used on port 25 if the SMTP service is not available to other SMTP servers for relaying (or, really, for last-hop SMTP delivery). Some choices are easier for users. Some are easier for service providers. Some are supported more broadly in current software. We need to narrow down the recommended choices, preferably to one per service. Thoughts? d/ -- Dave <mailto:dhc2@dcrocker.net> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850

9 9

RIRs getting new /8s from IANA
by Harsha Narayan 04 Feb '03

04 Feb '03

Hello, Could someone please answer the following question? Under exactly what conditions does an RIR qualify for a new /8 from IANA? Harsha.

2 1

Information about NASA web site performance
by Sean Donelan 03 Feb '03

03 Feb '03

The New York Times (free registration required) is running a story about the performance of NASA's web site over the weekend, and some of the changes they made to handle the load. NASA introducted their new web site at Midnight, the morning of the loss of Columbia, it experienced a 25-fold increase in traffic. http://www.nytimes.com/2003/02/03/technology/03WEB.html As several folks have pointed out, NASA is working on a lot of other stuff right now. So network stats are probably low on the priority list. But appears to be making an effort to release whatever information they can.

1 0

RE: IP QoS case-studies
by Mike Bernico 03 Feb '03

03 Feb '03

Pete, Our network is currently offering DiffServ QoS to customers. It's a new service, but so far it is working well and has been very well received by our customers. I'd be happy to answer any questions about what we do or why offline but here are some "talking points" of our policy. 1. We established a network wide delay budget and then put together some software that monitors network latency. 2. We control the classification feature. We classify all our customer traffic for them with Cisco class based policing at the CPE router. 3. We use Cisco's LLQ or MDRR queuing only on our links from distribution to the network edge. On our high speed links (622Mb and above) we don't queue. There are two schools of thought on this, but we currently subscribe to the theory that just letting FIFO happen is faster than applying custom queues in the core. YMMV with very fast routers, ASICs, and all that. Hope that helps! Mike -----Original Message----- From: Pete Kruckenberg [mailto:pete@kruckenberg.com] Sent: Monday, February 03, 2003 1:04 PM To: nanog(a)merit.edu Subject: IP QoS case-studies I've found there's no shortage of advice and theory about the viability of IP QoS (DiffServ) in a large wide-area (converged) network. I have not had much luck with finding documentation about experiences implementing and operating such a beast. Presumably that's yet another (silent) confirmation that It Doesn't Work or There's a Better/Easier Way. Nevertheless, I'd still like to find anyone who has tried (successfully or not) to converge (ie VoIP/H.323/data) a high-speed (~ 1Gb/s) IP network and use IP QoS for what it is sold to do. White paper/presentation references or off-line conversation would be appreciated. Pete.

1 0