January 2003 - Test - lists.nanog.org

RE: routing between provider edge and CPE routers
by Mike Bernico 29 Jan '03

29 Jan '03

Thanks so much for all the feedback. All your input has been extremely helpful. Just to clarify: In our network core all customer routes are summarized and carried in iBGP. That was a recent change of mine. We use EIGRP to carry loopback and next hop information. I'm working on migrating us to IS-IS currently. (Hmm...that last sentence probably just opened up another can of worms...) At the network edge we use heavily filtered EIGRP. I was already leaning towards static routes, based on this groups input I would say that it will be a new priority. Thanks again Mike -----Original Message----- From: Bruce Robertson [mailto:bruce@greatbasin.net] Sent: Wednesday, January 29, 2003 11:09 AM To: Mike Bernico Cc: nanog(a)merit.edu Subject: Re: routing between provider edge and CPE routers We switched to BGP just recently, before things got out of hand. I highly recommend that you do so. It really does work better. It's very nice seeing your OSPF config carry essentially just the loopback interfaces. > In particular I'm wondering about the thousands of lines of > configuration used to make static routes work. You don't say whether you're using Cisco, but recent IOSes have no trouble with huge configurations. You may have to use 'service compress-config'. -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 http://www.greatbasin.net

1 0

Re: What could have been done differently?
by Iljitsch van Beijnum 29 Jan '03

29 Jan '03

Sean Donelan wrote: > 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. As a former boss of me was fond of saying when someone made a stupid mistake: "It can happen to anyone. It just happens more often to some people than others." > Are there practical answers that actually work in the real world with > real users and real business needs? As this is still a network operators forum, let's get this out of the way: any time you put a 10 Mbps ethernet port in a box, expect that it has to deal with 14 kpps at some point. 100 Mbps -> 148 kpps, 1000 Mbps -> 1488 kpps. And each packet is a new flow. There are still routers being sold that have the interfaces, but can't handle the maximum traffic. Unfortunately, router vendors like to lure customers to boxes that can forward these amounts of traffic wire speed rather than implement features in their lower-end products that would allow a box to drop the excess traffic in a reasonable way. But then there is the real source of the problem. Software can't be trusted. It doesn't mean anything that 1000000 lines of code are correct, if one line is incorrect something really bad can happen. Since we obviously can't make software do what we want it to do, we should focus on making it not do what we don't want it to do. This means every piece of software must be encapsulated inside a layer of restrictive measures that operate with sufficient granularity. In Unix, traditionally this is done per-user. Regular users can do a few things, but the super-user can do everything. If a user must do something that regular users can't do, the user must obtain super-user priviliges and then refrain from using these absolute priviliges for anything else than the intended purpose. This doesn't work. If I want to run a web server, I should be able to give a specific piece of web serving software access to port 80, and not also to every last bit of memory or disk space. Another thing that could help is have software ask permission from some central authority before it gets to do dangerous things such as run services on UDP port 1434. The central authority can then keep track of what's going on and revoke permissions when it turns out the server software is insecure. Essentially, we should firewall on software versions as well as on traditional TCP/IP variables. And it seems parsing protocols is a very difficult thing to do right with today's tools. The SNMP fiasco of not long ago shows as much, as does the new worm. It would proably a good thing if the IETF could build a good protocol parsing library so implementors don't have to do this "by hand" and skip over all that pesky bounds checking. Generating and parsing headers for a new protocol would then no longer require new code, but could be done by defining a template of some sort. The implementors can then focus on the functionality rather than which bit goes where. Obviously there would be a performance impact but the same goes for coding in higher languages than assembly. Moore's law and optimizers are your friends.

3 6

broadband in Singapore and Tokyo?
by Andy Grosser 29 Jan '03

29 Jan '03

Can anyone suggest a good consumer-grade broadband provider for a small number (~15) of remote users in Singapore and Tokyo? My company wants to allow our remote sales folks to use our VPN client, and presently most of them use dial-up. The push to use cable modems or DSL is on. We currently have SingTel as a provider in .sg, and Genuity in .jp, but I just wanted a couple of pointers to competing outfits. Please reply off-list. Thanks! --- Andy Grosser andy(a)meniscus.org ---

1 0

Dropouts since Saturday 1/25/03 only affecting web traffic?
by Sean Donelan 29 Jan '03

29 Jan '03

According to Matrix Systems (http://average.miq.net/Weekly/markR.html) there have been two additional dropouts of global Web reachability on January 26 and January 28. These dropouts have been for few hours or so, but nearly as large as we saw from the SQL worm. However it doesn't seem to affect other network services, as measured by Matrix. Just the measured web servers. The most recent was tonight from 3-5pm and again from 5-7pm EST (http://average.miq.net/) Any ideas what is causing them? Measurement artifact? Are you seeing something strange on your networks about that time?

3 3

Re: Bell Labs or Microsoft security?
by Steven M. Bellovin 29 Jan '03

29 Jan '03

In message <Pine.GSO.4.44.0301290256580.26281-100000(a)clifden.donelan.com>, Sean Donelan writes: > >On Tue, 28 Jan 2003, Steven M. Bellovin wrote: >> They do have a lousy track record. I'm convinced, though, that >> they're sincere about wanting to improve, and they're really trying >> very hard. In fact, I hope that some other vendors follow their >> lead. > >Of course we need to be honest with ourselves and recognize this has >been going on for a long time before Microsoft was even a glimmer in >Bill Gates eye. > >Multics security. Bell Labs answer: Unix. Who needs all that "extra" >security junk in Multics. We don't need to protect /etc/passwd because >we use DES crypt and users always choose strong passwords. We'll make >the passwd file world readable so we can translate uid's to usernames. >Multi-level security? Naw, its simplier just to make everything Superuser. Yes and no. The password file situation is a failure of prediction. They understood the problem -- password-guessing attacks on weak passwords (see Morris and Thompson's Nov. 1979 CACM paper on password security) -- but misjudged the effect of Moore's Law (much less well-known then than today) and algorithms optimized for password-cracking. It took a dozen years for the threat level to return to the one they countered in the 1970's -- and that's a pretty good lifespan for any program. The superuser question is a more interesting one. The 7th Edition Unix manuals included a short paper by Ritchie entitled "On the Security of UNIX". The second paragraph starts, "the first fact to face is that Unix was not developed with security, in any realistic sense, i nmind; this fact alone guarantees a vast number of holes." Later on, the paper notes "It must be recognized that the mere notion of a super-user is a theoretical, and usually practical, blemish on any protection scheme." In other words, they understood what they were doing -- and what they were doing wasn't designing a secure operating system, because that wasn't very interesting at the time. Remember that the machines weren't networked, and they had a well-controlled user base. I submit that the threat environment has changed. (One of the worst mistakes in system design is to use yesterday's answers for today's questions. The technological environment has changed. I seem to recall getting a Unix distribution on an RK05 disk pack. According to my trusty 7th Edition manual, such a pack held 2.4M bytes. My PDA has considerably more storage than that..) The real sin was not rethinking the design in the late 1980s, when machines were much larger and ubiquitous networking was clearly coming. Of course, the Bell Labs folks did just that, and produced Plan 9. Microsoft rethought some of these issues, but *not* from a security perspective. > >FORTRAN/COBOL array bounds checking. Bell Labs answer: C. Who wants >the computer to check array lengths or pointers. Programmers know what >they are doing, and don't need to be "constrained" by the programming >language. Everyone knows programmers are better at arithmatic than >computers. A programmer would never make an off-by-one error. The >standard C run-time library. gets(char *buffer), strcpy(char *dest, char >*src), what were they thinking? I wish I knew. McIlroy once told me that C was the best assembler language he had ever used. I saw Kernighan at a Secure Software conference a few weeks ago and gave him a hard time about the C library; he blames Ritchie. Next time I see Dennis, I'll mutter at him instead. > >> My big worry isn't the micro-issues like buffer overflows >> -- it's the meta-issue of an overall too-complex architecture. I >> don't think they have a handle on that yet. > >The strange thing about complexity is its much harder to design a "simple" >system than a Rube Goldberg contraption. > I don't agree. It's harder to design it per line of code. Overall, though, complex systems are *very* hard to get right, especially from a security perspective. That's what I think that Microsoft doesn't understand yet. For example, they have a security metric that they apply to revised systems. Programs gain insecurity points for, among other things, open network sockets -- but the penalty is the same for the time-of-day service as for IIS... But of course, complexity is a very hard thing to measure. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

1 0

RE: Aggregate traffic management
by Todd A. Blank 29 Jan '03

29 Jan '03

We are a RouteScience customer. We are using this box and it rules. We have been extremely happy with the results. We have multiple OC-x circuits that we are engineering traffic over, and this box gives us the ability to "see" things that we could not see before. It also really allows us to differentiate our upstream providers - or tell that they are really all the same. The reports it produces are excellent. We have even used it to negotiate better SLAs and pricing with our bandwidth providers. Feel free to email me off-list if you want more information. Sincerely, Todd A. Blank IPOutlet LLC -----Original Message----- From: Kyle C. Bacon [mailto:kbacon@fnsi.net] Sent: Tuesday, January 28, 2003 5:43 PM To: Stanislav Rost Cc: nanog(a)merit.edu; owner-nanog(a)merit.edu Subject: Re: Aggregate traffic management Take a look at a product called "Path Control" by RouteScience. http://www.routescience.com/ I have seen their product in action and it is very slick. Does exactly what you want, plus a whole lot more and does it transparently (so if it fails you aren't SOL) via manipulating BGP tables and nexthop based on a multitude of criteria. K Stanislav Rost To: nanog(a)merit.edu <stanrost@lcs cc: .mit.edu> Subject: Aggregate traffic management Sent by: owner-nanog@m erit.edu 01/28/2003 04:59 PM Dear NANOGers, I have a very hands-on question: Suppose I am a network operator for a decent-sized ISP, and I decide that I want to "divide" aggregate traffic flowing through a router toward some destination, in order to then send some of it through one route and the remainder through another route. Thus, I desire to enforce some traffic engineering decision. How would I be able to accomplish this "division"? What technologies (even if vendor-specific) would I use? I can think of some methods like prefix-matching classification and ECMP, but I am still not sure exactly how the latter works in practice (at the router level) and how one may set them up to achieve such load-sharing. Thank you for your expertise and lore, -- Stanislav Rost <stanrost(a)lcs.mit.edu> Laboratory for Computer Science, MIT

1 0

RE: Dropouts since Saturday 1/25/03 only affecting web traffic?
by Todd A. Blank 29 Jan '03

29 Jan '03

I am seeing this as well, but only from a few hosts on a single network. I have contacted their NOC and asked them to "knock" it off - no pun intended... Could be some nimda infected boxes or whatever. Firewalls are stopping it, but it is annoying to wade through the logs. Todd -----Original Message----- From: Al Rowland [mailto:alan_r1@corp.earthlink.net] Sent: Wednesday, January 29, 2003 10:31 AM To: nanog(a)merit.edu Subject: RE: Dropouts since Saturday 1/25/03 only affecting web traffic? A single point of consumer data. I haven't checked by home router logs since Monday night but I was seeing a pattern of significant incoming port 80 traffic (I'm not running any services) over the last week or so, similar to increased 1433/1434 traffic before Saturday's flurry. Best regards, ______________________________ Al Rowland > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Sean Donelan > Sent: Tuesday, January 28, 2003 9:46 PM > To: nanog(a)merit.edu > Subject: Dropouts since Saturday 1/25/03 only affecting web traffic? > > > > According to Matrix Systems (http://average.miq.net/Weekly/markR.html) > there have been two additional dropouts of global Web > reachability on January 26 and January 28. These dropouts > have been for few hours or so, but nearly as large as we saw > from the SQL worm. However it doesn't seem to affect other > network services, as measured by Matrix. Just the measured > web servers. The most recent was tonight from 3-5pm and > again from 5-7pm EST (http://average.miq.net/) > > Any ideas what is causing them? Measurement artifact? Are > you seeing something strange on your networks about that time? > > >

1 0

Re: Aggregate traffic management
by Kyle C. Bacon 29 Jan '03

29 Jan '03

Take a look at a product called "Path Control" by RouteScience. http://www.routescience.com/ I have seen their product in action and it is very slick. Does exactly what you want, plus a whole lot more and does it transparently (so if it fails you aren't SOL) via manipulating BGP tables and nexthop based on a multitude of criteria. K Stanislav Rost To: nanog(a)merit.edu <stanrost@lcs cc: .mit.edu> Subject: Aggregate traffic management Sent by: owner-nanog@m erit.edu 01/28/2003 04:59 PM Dear NANOGers, I have a very hands-on question: Suppose I am a network operator for a decent-sized ISP, and I decide that I want to "divide" aggregate traffic flowing through a router toward some destination, in order to then send some of it through one route and the remainder through another route. Thus, I desire to enforce some traffic engineering decision. How would I be able to accomplish this "division"? What technologies (even if vendor-specific) would I use? I can think of some methods like prefix-matching classification and ECMP, but I am still not sure exactly how the latter works in practice (at the router level) and how one may set them up to achieve such load-sharing. Thank you for your expertise and lore, -- Stanislav Rost <stanrost(a)lcs.mit.edu> Laboratory for Computer Science, MIT

2 1

Arbor Networks
by c johnson 29 Jan '03

29 Jan '03

Has anyone had experiences with Arbor Networks Peakflow DOS and Traffic products? If so could you share your experiences, whitepapers, evaluations, etc. off list? I am interested in the generalized view of the effectiveness of the product as well as any enhancement requests that operators may have for either product. Thanks _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

Re: What could have been done differently?
by Michael.Dillon＠radianz.com 29 Jan '03

29 Jan '03

> His main thesis was basically that every > OS in common use today, from Windows to UNIX variants, has a fundamental > flaw in the way privileges and permissions are handled - the concept of > superuser/administrator. He argued instead that OSes should be redesigned to > implement the principle of least privilege from the ground up, down to the > architecture they run on. OpenSSH's PrivSep (now making its way into other > daemons in the OpenBSD tree) is a step in the right direction. Capability-based systems like EROS-OS are a way of addressing this issue. Have a look at http://www.eros-os.org/ If you only read one article then pick this summary from IEEE Software magazine http://www.eros-os.org/papers/IEEE-Software-Jan-2002.pdf The slammer worm made its way into some very unexpected places. It seems that in many organizations, once the UDP packet made its way to one MS-SQL server through one hole, it then acquired all the privileges of the IP address that supposedly belonged to a database server. Since traffic from the database server was considered to be trustworthy, it was able to easily reach and infect many more internal MS-SQL servers that were on internal networks unconnected to the Internet. In other words, there were MS-SQL servers acting as Application Layer Gateways to transport the worm into protected networks. The random nature of the addresses chosen by the worm virtually guaranteed that every single network path in the world containing MS-SQL servers would be infected. --Michael Dillon

1 0