July 2002 - Test - lists.nanog.org

Re: Internet vulnerabilities
by Paul Vixie 04 Jul '02

04 Jul '02

> Is this the anycast based on MSDP ? no.

1 0

Re: Internet vulnerabilities
by Miquel van Smoorenburg 04 Jul '02

04 Jul '02

In article <cistron.20020704210707.GS99199(a)overlord.e-gerbil.net>, Richard A Steenbergen <ras(a)e-gerbil.net> wrote: >Besides, if someone actually did get the IOS code (laugh) You'd be surprised.. >AND manage to >compile images out of that cruft Ah, so you *have* seen it ;) Mike.

1 0

RE: Internet vulnerabilities
by jnelson 04 Jul '02

04 Jul '02

Ah... "More info ?" When all else fails RTFM. Thanks (non-disgruntled DE?), J -----Original Message----- From: Richard E. Perlotto II [mailto:rperlott@cisco.com] Sent: Thursday, July 04, 2002 3:28 PM To: 'jnelson'; 'batz'; 'Jason Lewis' Cc: nanog(a)merit.edu Subject: RE: Internet vulnerabilities Actually all the Cisco images have a MD5 hash included on the download page. You can check all of your images verses what is on the web. The 12.2.8T train also has a built in MD5 checksum for validation. We are doing what we can to help. Richard > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of jnelson > Sent: Thursday, July 04, 2002 12:47 PM > To: 'batz'; 'Jason Lewis' > Cc: nanog(a)merit.edu > Subject: RE: Internet vulnerabilities > > > How about this: > ISP X had its tftp server compromised by a wily hacker who evaded > tripwire and covered his track well, uploaded some cracked Cisco code > (the current release for their GSRs). This code was designed to corrupt > the directories and shut down the router at date XX:XX:XX. Each of these > affected GSRs, 7-five new roll-outs and 2 upgrades--went down at the > same time (save one who's time was no set correctly). Each site had to > driven to, flashcards replaced. ISP X severely crippled for 6 hours. The > hacker could have gone the extra leg to have the tftp server expunge the > backup configs at the same time--extra couple hours--but did not. > > We all download code from Cisco/Juniper/Bay in good faith... when's the > last time you saw a signature attached to any of those? Most security > breeches happen from within anyway. A disgruntled DE.... > > Just a wicked thought. > j > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > batz > Sent: Thursday, July 04, 2002 2:17 PM > To: Jason Lewis > Cc: nanog(a)merit.edu > Subject: Re: Internet vulnerabilities > > > On Thu, 4 Jul 2002, Jason Lewis wrote: > >:What are the real threats to the global Internet? > > I realize this seems like nitpicking, but asking what the real risks > are > might be a more useful question. The reason I mention this is because > the > washington post report the other day about threats to SCADA systems was > blown out of proportion, because it equated the seriousness of the > threats > with their associated risks. Yes, most ASN.1 implementations have > serious > vulnerabilities, welcome to 1988. > > The ASN.1 vulnerabilities being talked about right now are serious > threats, > but lower risk than say, millions of unpatched IIS and apache servers, > public exploits and a worm on the loose. Application level > vulnerabilities > that have to be patched on a host by host basis, cause a greater risk > than > say, SNMP vulnerabilities that can be filtered at the gateway, which > protects from opportunistic external attacks. > > When you talk about threats to the global Internet, there are hundreds > of > equally serious vulnerabilities of varying risk. Also, the "global > Internet" > has many different meanings. It can mean "the ability to send and > recieve > packets on layer 3" or "people being able to conduct business > electronically, > with some reasonable expectation of the confidentiality, integrity and > reliability of their transactions." > > So, it all depends on what you mean by the Internet:) I think this is > an extremely important discussion to have on the list, I just think > it should be framed in terms of real risks, root causes, and > potential solutions. > > >:I am looking for anything that might be a potential attack point. I > don't >:want to start a flame war, but any interesting or even way out there > idea >:is welcome. >: >:Is it feasible that a coordinated attack could shutdown the entire net? > I >:am not talking DDoS. What if someone actually had the skills to > disrupt >:BGP on a widescale? > > Once you start thinking about the Internet from a security perspective, > you realize there is no "entire net" subject to the sum of its parts in > any practical sense. It is a network of networks that serves a continuum > > of interests, bounded by economics, and driven by porn. ;) > > The attack point is anywhere you think will do the most harm to the > people you dislike. If you just want to break something, find serious, > easy to exploit, security design limitations in BGP, MPLS, BIND and > drive a major global backbone like UUNet into insolvency. > > ..What? Oh ...Too late. > > -- > batz >

1 0

RE: Waiver of IP and AS Number Transfer Fees
by jnelson 04 Jul '02

04 Jul '02

Hey, I'll be the first to laugh it up about some of ARIN's oldschool GM-style practices, but let's not knock the staff there... I've had nothing but good experiences with the front-liners (billing and support). And I believe your cry has been heard and this clean-up and the template revision are merely portions of their restructuring. -j -----Original Message----- From: Tom Thomas [mailto:tom.thomas@i-nap.co.uk] Sent: Wednesday, July 03, 2002 9:32 PM To: m.hallgren(a)free.fr; deepak(a)ai.net; jnelson; nanog(a)merit.edu Subject: RE: Waiver of IP and AS Number Transfer Fees Michael its simple ARIN is staffed by a bunch of people who have no concept of business or reality. There reality is based on outmoded ideals enforced on them, so no wonder people do not want to go through the abuse of dealing with them. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Michael Hallgren Sent: Wednesday, July 03, 2002 4:34 PM To: deepak(a)ai.net; jnelson; nanog(a)merit.edu Subject: RE: Waiver of IP and AS Number Transfer Fees >Please correct me if I am wrong. This is not allowing the practice of >selling IPs or ASes, I've never really come around to fully understand the notion (more and more common, it seems) of _selling_ such..? (Maybe I'm an idealist :) > but it encourages those of us who have acquired other >companies to consolidate all the registrations under a single NIC handle >(for example) to reduce the total number of contacts floating out there? > >Is my understanding accurate? > I would hope so, in a general perspective. mh >Thanks, > >DJ

1 0

Updated bogon list
by Rob Thomas 04 Jul '02

04 Jul '02

Hi, NANOGers. For those of you who don't already know... 221/8 has been allocated to APNIC, effective July 2002. It hasn't yet appeared in the routing table based on my nine eBGP feeds. My bogon templates have been modified accordingly: http://www.cymru.com/Documents/bogon-list.html Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

Re: Sprint peering policy
by Rizzo Frank 04 Jul '02

04 Jul '02

Gordon Cook wrote: > I don't post here much Any chance of changing that? After listening to endless banter from Ralph Doncaster, I'd welcome of your latest interview with Bill St. Arnaud and Wade Hong on CANET*3.1415927. Pretty please with a plastic figurine of the delectable Ms. Jane on top? > Finally I'd like to ask a question in return. I am trying to look at > what will grow up on the ashes of the current industry collapse. Larger large players, more basement web hosters. > Fiber to the home is beginning to appear in a few > isolated areas. It will disappear just as quickly. Has, in some places. A few years back, VC's were wooed by the concept. They didn't know what the heck it was, nor did they care, so long as those pitching it (who knew even less about it, for the most part) kept dropping buzzards such as "broadband" and "fiber" over and over. Now's the wake-up call. It just isn't cost-effective, which might explain why every company offering FTTH services in the States is either f'd, soon-to-be f'd, or abandoned the plans in favor of something more viable like cable. Whatever happened to WINfirst? > Are there folk with adequate > routes and connectivity that would undertake to form a network that > might be independent of the current internet core back bone of what > (112,000 routes?) on top of which sit the half dozen or so Tier one > players that peer primarily with each other and demand transit $$$ > from everyone else? Web and email stay on the legacy backbone...new > services migrate to a backbone with a cost structure unencumbered by > the tier one oligopolists? No. > PS. Anyone interested in trekking in Nepal in October please let me > know off list. eg http://cookreport.com/everest.shtm When? I'm handnig out summaries of the Cook Report at the Princeton-Harvard game on the 26th. Then it's off to Shanghai to crash the ICANN meeting. Then Eugene to lobby for macro-allocations and true financial disclosure/accountability at the ARIN conference. Beginning of the month works best. I've been benching 300 and tracing Broadwing cross-country fiber routes by foot in preparation, hopefully you'll be able to keep up! Have any other internet luminaries expressed an interest in going? Frank "Proud to be an American" Rizzo PS: I had a bet with my boss: how many of you are watching fireworks tonight? Mail me privately and I'll post a summary to the list.

1 0

FW: Waiver of IP and AS Number Transfer Fees
by jnelson 03 Jul '02

03 Jul '02

TWiMC: No doubt most with the responsibility of doing so received this statement, but.... OWN 'M IF YOU GOT 'M--clean up the databases (Unfortunately for me I just paid a $250 on June 27th--lucky me.) j -----Original Message----- From: owner-arin-announce(a)arin.net [mailto:owner-arin-announce@arin.net] On Behalf Of Member Services Sent: Tuesday, July 02, 2002 3:59 PM To: arin-announce(a)arin.net Subject: Waiver of IP and AS Number Transfer Fees At the ARIN IX Member's Meeting there was consensus expressed that transfer fees should be waived as a means of encouraging subscribers to participate in database cleanup. The database cleanup effort is a part of the database conversion project. There was overwhelming support for such a waiver for the remainder of the fiscal year. During its June 5 meeting the ARIN Board of Trustees approved a motion to waive the fees for the transfer of AS Numbers and IP addresses for the period extending from July 1, 2002 through December 31, 2002. The Board meeting minutes can be viewed at: http://www.arin.net/library/minutes/bot/bot06052002.html ARIN Member Services

3 3

AS path fugliness?
by Mike Lewinski 03 Jul '02

03 Jul '02

Anyone else receiving huge as-path (more than 125) causing these: Jul 3 08:23:06 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 08:23:46 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 270 Jul 3 08:27:45 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 274 Jul 3 08:31:59 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 08:41:02 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 08:41:43 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 270 Jul 3 08:57:56 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 09:04:04 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 09:10:01 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 Jul 3 09:10:52 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 270 Jul 3 09:17:40 MDT: %BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath, requested size 268 (per http://www.cisco.com/warp/public/459/35.shtml ) It started just after local Qwest routes apparently recovered from some kind of nose-dive. We're still sorting through the tables trying to find out who, thus far longest I've found is about 20. Mike

5 8

Re: Network Security Requirements draft
by George Jones 03 Jul '02

03 Jul '02

"sd" == Sean Donelan <sean(a)donelan.com> writes: sd> On 18 Jun 2002, George Jones wrote: >> We (UUNET) have an internal document that we've been using for a few >> years as the basis for tests of security features of equipment to be >> connected to our backbone. We're interested in making it public so >> that it can be improved and so that others can use it. You can view >> the current draft at: sd> Its a nice draft. One issue, not with the draft, but in general on sd> network security is the lack of a transit network security architecture sd> description. The issue of how to deal with IP source routing in this sd> draft is what reminded me of this. sd> Most network security architectures are based on the internal, perimeter, sd> external network model. Bad traffic is blocked by the permiter network sd> and never allowed to pass into the internal network. But in a public sd> service provider network traffic is separated along the data, control, sd> management model. Maintaining the separation between data, control and sd> management under all conditions is the challenge. Right. Thanks. That helps clarify the actual requirement. I was headed there > 2.1.2 Enforce Use Of Management Interfaces > > Requirement It MUST be possible to configure the device such that all > management may only be done via specific management interfaces. This > requirement SHALL NOT be satisfied using a filtering mechanism on > non-management interfaces alone, since filters do not guarantee > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > separation of management and non-management traffic > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ but had not formulated it that cleanly. The actual requirement is separation of data flow and management. OOB is just one way of achieving that (that we happen to use). I'll think it over and reword. sd> Rather than disabling IP Source Route as a global setting, I think you sd> want to scrutinize traffic passing between data and control or management sd> layers. Such as to a routing process or management interface. A source sd> routed packet in the data layer just takes an unusual path through the sd> network, but becomes a security risk if it hops into the control or sd> management layer. It would be nice to enable/block source routing (and sd> strip other IP options) on a per interface basis and drop packets with sd> unexpected options at any control or management interface. I think the general requirement here is ability to accept/reject options per/interface. Once that's in place people can decide for themselves if they want source routing (or other options). I will work on rewording. Since I announced the document here, I've added: 2.3.4 Ability To Control Service Bindings Requirement The device MUST provide a means that allows the user to specify the bindings used for all listening services. It MUST support binding to a list of net-blocks and SHOULD support configuration of binding services to particular interfaces. Justification This greatly reduces the need for complex filters. It reduces the number of ports listening, and thus the number of potential avenues of attack. It insures that only traffic arriving from legitimate addresses and/or on designated interfaces can access services on the device. Implementation The default configuration as displayed by Display All Configuration Settings should list all interfaces and all potential services along with the ports they listen to, the addresses they listen to and the interfaces they bind to. These should all be made configurable. Warnings None This would allow, for instance, SSH to be bound *only* to a loopback interface. Combine this with the ability to disable options and do filtering the loopback and I think we're getting close to an acceptable way to do device management, even in-band. Thanks, -- George M. Jones | Most important ideas are uninteresting. Most interesting CISSP,CCNA,JAPH | ideas are unimportant. Not every problem has a good UUNET | solutions. Every solution have side effects. Network Security | Quoted from Dan Geer george(a)uu.net, 2002 PGP = AB33 0916 F91E E58C B023 C768 351C 57E5 271E 69DC

1 0

Re: European packet loss average increasing
by Michael.Dillon＠radianz.com 03 Jul '02

03 Jul '02

>My non-scientific measurements (i.e. pings to well known european >sites) show an increase in packet loss to about 6%, the 10 day >average previously was less than 1%. That is similar to what the Internet Traffic Report for Europe shows at this URL http://www.internettrafficreport.com/cgi-bin/tr_graphpage.pl?score/7/Europe For those who don't know, Ebone had a policy of zero packet loss on the network 99.5% of the time and we managed to exceed this on almost all of our links. In other words, the graph of packet loss was a horizontal line with the occasional small blip. The major change in the traffic report graphs is that packet loss is six times greater after the Ebone shutdown. There was also a dip in traffic levels that partially corrected itself. Presumably the bottom of the dip represents convergence and the lack of a full recovery is partly due to organizations that were not multihomed and who had not yet found alternate providers. --Michael Dillon ex-Ebone

2 1