- NANOG - lists.nanog.org

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

09 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

Email Security Poll Results
by Jon R. Kibler 07 Mar '04

07 Mar '04

Hello all, We had 39 responses to the poll. The results follow the signature paragraph. A few words of explanation about the results. 1) For the Yes-No questions, most answers were either YES or NO. However, a few of the results were something like "yes, but not encrypted zips." For the "yes-but" answers, I counted them as a "half of a yes." 2) For the AV engines, the percentages add up to >100% because many users said they ran multiple AV engines. 3) For frequency of AV signature updates, several responded something like "update daily or as new updates become available." For answers that said they updated on a regular frequency plus more often when necessary, the frequency was counted as appropriate, plus it was also counted in the "other, plus as announced" category. A few observations and comments: 1) Subscribers to the DShield and NANOG mailing lists contributed answers. This means the answers are biased (originating from the "security aware" group of users) and probably do not reflect the general state of email security. 2) It was refreshing to find that everyone claimed to be updating their AV signatures on a regular basis. It would be interesting to know how many average users and small businesses update on such a regular basis. 3) Personally, I found it very surprising how many organizations depended solely upon their end users to perform AV screening, that none was being performed organization-wide. I was also surprised at how many organizations permit executable content to be sent by email. I hope that everyone finds these results interesting and they are put to good use! Jon Kibler -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 Please respond YES (Y), NO (N), or Not Applicable (N/A): -------------------------------------------------------- Does your organization perform any screening of email attachments? 72% YES Does your organization perform A-V checks on all email attachments? 85% YES Does your organization perform any checks on email attachment file type? 62% YES Does your organization allow users to receive executable content attachments? 49% YES Does your organization allow users to receive zip file or similar compressed attachments? 90% YES Does your organization allow users to receive MS Office and similar type files that may contain macro viruses? 95% YES Does your organization allow users to receive embedded or attached HTML email? 99% YES Does your organization allow users to receive active content attachments, such as HTML with <SCRIPT> tags? 80% YES Please respond as appropriate: ------------------------------ What AV engine do you use to screen email attachments (Symantec, NAI, FProtect, Trend, ClamAV, etc)? Symantec 53% McAfee 16% ClamAV 16% Trend 16% Kaspersky 8% AVG 8% Sophos 5% Other 5% Fsecure 3% How often does your organization update its AV signatures? every 2 hrs or more often 16% every 4 hrs 8% every 8 hrs 8% every 12 hrs 5% daily 58% only as announced 5% other, plus as announced 16% ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

3 2