March 2004 - Test - lists.nanog.org

Discussion Group: Web Based tool for tracking circuits
by Marius Strom 08 Mar '04

08 Mar '04

Hrm, sent several hours ago and still hasn't had nanog. Resending in-case it got snarfed by hungry routers on the intarweb. ----- Forwarded message from Marius Strom <marius(a)marius.org> ----- Date: Mon, 8 Mar 2004 16:36:14 -0600 From: Marius Strom <marius(a)marius.org> To: nanog(a)merit.edu Subject: Discussion Group: Web Based tool for tracking circuits Mail-Followup-To: nanog(a)merit.edu Ok, I've created a "carrier-neutral" mailing list on yahoogroups to house people who are interested in such a system. Interested developers and such should subscribe to cktid(a)yahoogroups.com. We can start discussions on what's out there, how to integrate things, possibly create a sourceforge project, etc. It seems everyone wants one, but no one's got one completed (other than Excel spreadsheets). On Mon, 08 Mar 2004, william(at)elan.net wrote: > Several commercial ip allocation systems exist (cost thousands, I came > across couple of them but did not keep list). The closest opensource on > this is freeipdb (http://www.freeipdb.org) but its not very feature-rich. > The IRM project (which I've never heard about until I just demod it right > now), comes much closer to what maybe needed and it does seem like it can > be converted to serve ISP allocation needs somewhat easily and is quite > extensible for shared enviroments, but in any case, such project needs to > be done right, i.e.: > 1. Creating mail list and first discussing and list of goals and features > we want in this system. > 2. Looking at existing project to see which can feets best or parts of which > of which projects can possible be combined together > 2. Creating sourceforge (or other) project and assiging features to be > implemented to developers. > Etc. > > If others are interested lets get together to work on it. I'm willing to > help in possible support for rwhois server or automated swips to arin and > some other back-end support where I have some experience I'm guessing > that at least half a dozen people need to get involved and be willing to > spend some of their time (perhaps 10 hours/month) for this to come through > and most need to be php web developers if IRM is to be used as origin. > > If I receive favorable response privately about it and enough people are > willing to spend their time on it, I'll let you know about what the project > development webpage would be (i.e. sourceforge most likely) ----- End forwarded message ----- -- /-------------------------------------------------> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-------------| Mike Andrews |-------------------->

1 0

[Fwd: [alex@yuriev.com] Confirmation of your message requested]
by Laurence F. Sheldon, Jr. 08 Mar '04

08 Mar '04

quote Your message to <alex(a)yuriev.com> was intercepted by an automated spam reduction system based on TMDA. This happened because your address has not been previously verified as one used by a human, as opposite to a bloody idiot-spammer. In order to reduce the amount of junk mail received by <alex(a)yuriev.com>, only messages from verified addresses are released for delivery. unquote If you are not going to accept mail from me, do not send mail to me. Do no spam mw with this crap in any case.

3 4

TELUS contact?
by Adam Clark 08 Mar '04

08 Mar '04

Does anyone know of a Network admin contact at Telus? Have been trying to reach them for a week, but have had no human response. Thanks, -- Adam Clark

1 0

[ralden@ralden.com: FW: Web Based tool for tracking circuits]
by Marius Strom 08 Mar '04

08 Mar '04

----- Forwarded message from "Roland H. Alden" <ralden(a)ralden.com> ----- Date: Mon, 8 Mar 2004 10:04:13 -0800 From: "Roland H. Alden" <ralden(a)ralden.com> To: Marius Strom <marius(a)marius.org> Subject: FW: Web Based tool for tracking circuits Return-Path: ralden(a)ralden.com I guess I'm not allowed to post but here is something I sent for your info. -----Original Message----- From: Roland H. Alden Sent: Monday, March 08, 2004 8:37 AM To: nanog(a)merit.edu Subject: RE: Web Based tool for tracking circuits > If there is, let me know. I started to work on one a couple > of years ago, I could dust off the project. Same here. I haven't got time to dust off my project but I would gladly contribute what I have to someone else; basically a complex SQL schema with some queries, constraints and triggers done and/or partially baked. My model was as follows: A location hierarchy tunable to whatever resolution was of interest; i.e., City:Facility:Floor:Rack etc. A very complex model for pieces of equipment; i.e. chassis, blades within chassis, physical ports on blades. Ports themselves are modeled with data about their connectors (i.e., RJ45 male/female, DB9 male/female, etc.). A model of special "ports" which are status indicators like LEDs, what their exact equipment labeling is, and what colors and what not they might normally be. I.e., information of value when walking some remote hands through a troubleshooting procedure. A model for port-specific configuration so that the database can "know" that port x13 on such an such an ethernet switch is connected to VLAN 3, etc. A model for what ports should be physically connected to what ports. A necessary list of cables can then be generated automatically; connector specs and unique cable ID's are generated. A database of common connectors and their "opposite sex" is part of the model. The system does not take advantage of any understanding of how far apart ports are to suggest a cable length, but once a cable table is generated that can be added by hand so that the information is captured. A "fanout" cable model accomodates single cables that connect more than two ports. A power model that records how much heat is generated by each device and how much power of what flavor it consumes. A circuit model similar to the cable model (port:circuit:port) but accomodates "tunnels" such as a ds1 inside a ds3, or a VPN tunnel. A "noc contact" record can be associated with a particular circuit and the contractual details of a circuit (such as SLA) can also be recorded. A unique circuit ID is generated and a vendor's circuit ID can be recorded as well. Equipment configurations (and history of them) is stored within each item of equipment. However, there is no sophisticated linkage or syntax checking between the equipment model and the configuration and there is no way to automatically push a configuration to its equipment. Documents such as PDF files of equipment manuals or contracts can be attached to various items like equipment records, circuit records, etc. However this does require "blob" support and in my implementation is all MSFT specific code. A somewhat badly implemented fine-grained security model so that various views show only the rows a person was allowed to see and/or edit. My notion was that the system would be used across handoff boundaries but I didn't exactly get that far. FWIW. ----- End forwarded message ----- -- /-------------------------------------------------> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-------------| Mike Andrews |-------------------->

1 0

Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
by Paul Vixie 08 Mar '04

08 Mar '04

> After all these years, perhaps its time to re-examine the assumptions. it's always fun and useful to re-example assumptions. for example, anyone who assumes that because the attacks they happen to see, or the attacks they hear about lately, don't use spoofed source addresses -- that spoofing is no longer a problem, needs to re-examine that assumption. for one thing, spoofed sources could be occurring outside local viewing. for another thing, spoofed sources could be "plan B" when other attacks aren't effective. the last thing is, this is war. information warfare. the enemy knows us better than we know them, and their cost of failure is drastically lower than our cost of failure. don't be lulled into some kind of false sense of security by the fact that YOU are not seeing spoofed packets TODAY. let's close the doors we CAN close, and give attackers fewer options.

12 30

FCC Internet Policy WG to hold VoIP 911/E911 summit on March 18th, 2004
by John Curran 08 Mar '04

08 Mar '04

<http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-243851A1.pdf> "On Thursday, March 18, 2004, the FCC¹s Internet Policy Working Group (IPWG) will hold the first in a series of a ³Solutions Summits² at which leaders in government and industry can discuss creative ways to address policy issues that arise as communications services move to Internet-based platforms. The initial meeting will focus on 911/E911 issues, and on the particular challenges and opportunities created for emergency services in expanding 911/E911 access to VoIP users and increasing the use of IP technologies in emergency services networks" This will be one of the first public discussions of 911/E911 issues for VoIP which includes both public safety and US telecomm regulatory officials. /John PS. My apologizes to those folks whose SMS or RJE gateways were hung up by my earlier mime-formatted version of this email... Nationalistic, 7-bit, discard-the-encoding-and-be-PINE-friendly used above instead.

1 0

Re: Source address validation (was Re: UUNet Offer New Protection
by Gregory Hicks 08 Mar '04

08 Mar '04

> From: Paul Vixie <vixie(a)vix.com> > Date: 08 Mar 2004 06:35:16 +0000 > > > ken(a)kdmd.net (Ken Diliberto) writes: > [...snip...] > > > > We're now blocking all SMTP traffic leaving the campus from non-blessed > > sources (read mail servers). The first day doing this we had comments > > about less junk mail traffic. We block traffic we consider harmful that > > shouldn't leave the campus. We're trying to do our part. > > > > Any suggestions how we can do better? > > yes. contact the nanog program committee so you can come to san francisco > and tell the rest of us how you did it -- both in the ones and zeros, and > in the dollars and cents. Paul: This is MY take and not Ken's... Firewall: block port 25 from all internal hosts except those 'recognized' as mail servers. For a user or department to get a mail server set up and 'recognized', they probably have to go through some sort of "qualification" and scanning process to ensure that the mail host is configured correctly... Going to San Francisco is still a good idea though. Regards, Gregory Hicks > -- > Paul Vixie --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks(a)cadence.com I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." - Benjamin Franklin "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

1 0

RE: UUNet Offer New Protection Against DDoS
by Terranson, Alif 08 Mar '04

08 Mar '04

As long as we're doing "Me Too"... Savvis has had prefix:666 for around 18 months as well. Alif Terranson OpSec Engineering Manager Operations Security Department Savvis Communications Corporation (314) 628-7602 Voice (314) 208-2306 Pager (618) 558-5854 Cell > -----Original Message----- > From: Michael Hallgren [mailto:m.hallgren@free.fr] > Sent: Wednesday, March 03, 2004 3:45 PM > To: nanog(a)merit.edu > Subject: RE: UUNet Offer New Protection Against DDoS > > > > > > > Global Crossing has this, already in production. > > Idem, Teleglobe, > > mh > > > I was on the phone with Qwest yesterday & this was one of > > this things I asked about. Qwest indicated they are going to > > deploy this shortly. (i.e., send routes tagged with a > > community which they will set to null) > > > > > > James Edwards > > Routing and Security > > jamesh(a)cybermesa.com > > At the Santa Fe Office: Internet at Cyber Mesa Store hours: > > 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965 > > > > > > > > >

13 27

Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
by Paul Vixie 07 Mar '04

07 Mar '04

> ... > buying screen doors for igloos may not be the best use of resources. uRPF > doesn't actually prevent any attacks. actually, it would. universal uRPF would stop some attacks, and it would remove a "plan B" option for some attack-flowcharts. i would *much* rather play defense without facing this latent weapon available to the offense. > Would you rather ISPs spend money to > 1. Deploying S-BGP? > 2. Deploying uRPF? > 3. Respond to incident reports? "yes." and i can remember being sick and tired of competing (on price, no less) against providers who couldn't/wouldn't do #2 or #3. i'm out of the isp business at the moment, but the "race to the bottom" mentality is still a pain in my hindquarters, both present and remembered.

4 5

layered security for the modern Internet
by E.B. Dreger 07 Mar '04

07 Mar '04

Looking at last week's NANOG posts: SAV... 30% of spam from h4x0r3d boxen... bagle... It seems the original definition and ideology of layered security are outdated. Layered security now means: * Do nothing at a given layer if the problem can be solved, or partially solved, at another layer; * If a problem cannot be completely solved at a given layer, do nothing at that layer; * Approach the problem by arguing on NANOG over who has the most representative analogy. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist(a)brics.com -or- alfra(a)intc.net -or- curbjmp(a)intc.net Sending mail to spambait addresses is a great way to get blocked.

2 2