- Test - lists.nanog.org

FYI: ANSI Standard Proposal: A Baseline of Security Requirements for the Management Plane
by Barry Raveendran Greene 04 Dec '02

04 Dec '02

Note: The "baseline" draft is at: ftp://ftp.t1.org/pub/ballots/current/lb1117.pdf ------------------------------------------------------------- November 18, 2002 TO: Members of Accredited Standards Committee T1 - Telecommunications Members of Technical Subcommittee T1M1 SUBJECT: T1 Letter Ballot T1 LB 1117 Dear Members: Enclosed for your action, please find the following T1 Letter Ballot voting form: - T1 LB 1117, Draft Proposed American National Standard - Operations, Administration, Maintenance, and Provisioning Security Requirements for the Public Telecommunications Network: A Baseline of Security Requirements for the Management Plane ** NOTE: The Letter Ballot notifications for LB 1112 thru LB 1120 are being sent separately and comprise this mailing. Please note that the closing date of this T1 Letter Ballot is January 06, 2003 *** You should send your response and must send any corresponding comments on this letter ballot to t1ballot(a)atis.org. If you have any questions, please contact Steve Barclay at sbarclay(a)atis.org. *** Your earliest response to this letter ballot is appreciated. ADDITIONAL INFORMATION: THE DOCUMENT ASSOCIATED WITH THIS LETTER BALLOT IS NOW AVAILABLE FROM THE T1 HOMEPAGE in the "Current" Letter Ballots directory. To obtain a copy of lb1117.pdf go to: WWW: http://www.t1.org/html/ballots.htm (Current Letter Ballots) FTP: ftp://ftp.t1.org/pub/ballots/current/lb1117.pdf ----------------------------------------------------------------- ACCREDITED STANDARDS COMMITTEE T1-TELECOMMUNICATIONS LETTER BALLOT **-- ACTION REQUESTED --** REPLY TO: ATIS Letter Ballot Number: LB 1117 T1 Secretariat Document Number: T1M1.5/2002-125R2 1200 G St., NW, Suite 500 Date: 11/18/03 Washington, DC 20005 Ballot Period: 6 Weeks FAX: 202.347.7125 Ballot Closes: 01/06/03 EM: t1ballot(a)atis.org Authorized By: T1M1 Distributed By: T1 Secretariat Subject: Draft Proposed American National Standard - Operations, Administration, Maintenance, and Provisioning Security Requirements for the Public Telecommunications Network: A Baseline of Security Requirements for the Management Plane Statement: The T1M1 members at its November 2002 plenary approved this dpANS for letter ballot. Please note: Due to an interest category imbalance at the time of this letter ballot, weighted voting of a .53 value applies to the manufacturing interest group. Additionally, due to the upcoming holiday season and its impact on work schedules, this letter ballot period has been extended at the request of the T1M1 Chairman. Question: Do you approve this draft proposed American National Standard for submittal to ANSI for approval as an American National Standard? Ballot: YES ____ NO ____ (Comments Required) Ballot: YES ____ (w/ comments) ABSTAIN ____ (w/ reasons) ABSTAIN ____ (IF VOTING "NO, WILL VOTE CHANGE TO "YES" IF THE ATTACHED CHANGES ARE MADE?) YES ____ NO ____ Signature ___________________________ Principal___ Alternate___ Organization ____________________________________ DATE_________ Telephone #: __________________________ See ANSI's PATENT POLICY (under the Committee T1 Letter Ballots section)

1 0

RE: Operational Issues with 69.0.0.0/8...
by Todd A. Blank 03 Dec '02

03 Dec '02

Some of this is beginning to clear up. The Cable and Wireless stuff seems to be working now. Still, when we source from the 69.0.0.0/8 CIDR, traffic can't go (http) to the following destinations: www.ocas.com www.lavalife.com www.indofilms.com The first two are on AT&T and AT&T Canada. The last one is on allegiance internet. Any insight would be much appreciated. We are sure this is affecting access to other destinations when using 69.0.0.0/8 as a source - we just haven't found them all yet... Thanks, Todd A. Blank 614.207.5853 -----Original Message----- From: Martin J. Levy [mailto:mahtin@mahtin.com] Sent: Monday, December 02, 2002 2:17 PM To: Todd A. Blank; jfeger(a)feger.net Cc: nanog(a)merit.edu Subject: Re: Operational Issues with 69.0.0.0/8... Todd, If this helps. Do something like the following... telnet route-views.oregon-ix.net > /tmp/file term len 0 sh ip bgp 69.0.0.0 255.0.0.0 l quit cut -c62-2000 < /tmp/file | awk '{print $1}' | sort -n | uniq -c | more ...your commands will vary. You will see plenty of routes within 69/8. A closer look with show that around 121 routes are seen in the 69/8 range via most of the feeds into Oregon. There is one big exception... 69.4.64.0/20 ... it shows up via AS-2548 (Digex) and the other feeds, but it's the only route within 69/8 that shows up via AS-2548. This is valuable information. It does not mean there is filtering within AS-2548, but I would recommend you contact them to further this investigation. BTW: This is exactly what Oregon is great for! It shows up issues like this with ease. Thanks! Martin --------------------------- At 01:47 PM 12/2/2002 -0500, Todd A. Blank wrote: >Thanks for the reply, James. > >I wish I could tell you the answer. We see traffic passing through some >of the routers (transit), but on each network, or their downstreams >there seem to be different devices filtering. Sometimes it is a border >or peering router. In other cases, it has been access devices, such as >firewalls. > >One we resolved this morning (with some help from the good folks at >ARIN) was a downstream provider from one of these transit providers that >was filtering in their devices as well. > >I am just trying to raise general awareness that the 69.0.0.0/8 block is >assigned and out there in use, and to get people to re-examine their >filters, access lists, etc. > >You help and response is appreciated. > >Sincerely, > >Todd A. Blank >614.207.5853 > >-----Original Message----- >From: Feger, James [mailto:jfeger@feger.net] >Sent: Monday, December 02, 2002 1:35 PM >To: Todd A. Blank >Subject: Re: Operational Issues with 69.0.0.0/8... > >When you say 'Networks involved' do you mean those providers are >blocking >the traffic, or you see these networks in the transit? > >Thanks, >James > > >On Mon, 2 Dec 2002, Todd A. Blank wrote: > >> >> To all concerned: >> >> We have been assigned a CIDR of 69.1.192.0/19. >> >> We have had numerous problems getting traffic through to various >destinations. >> >> We are finding that many routers are still filtering 69.0.0.0/8. >> >> This block used to be restricted, but was assigned by IANA to ARIN in >August of 2002. >> >> If anyone is still filtering this block in their routers, please >remove the filters! >> >> Here are some of the destinations that are not reachable if your >source is anywhere in the 69.0.0.0/8 CIDR: >> >> www.cplink2.com >> www.ocas.com >> www.indofilms.com >> www.lavalife.com >> >> >> Some of the Networks involved are Cable and Wireless, Allegiance >Internet and AT&T. >> >> Thank you, >> >> Todd A. Blank >> IPOutlet LLC >> 614.207.5853 >>

1 0

Details on CareGroup incident
by Stephen Sprunk 03 Dec '02

03 Dec '02

To quote Dr. Halamka: > I hope that my approval enables [Cisco] to share more with the press > so that everyone understands that our issues were purely architectural > and not related to Cisco products or Cisco engineers. So, now that I have it in writing, here's what I'll share: The Topology There are three campuses, each with several phyiscal sites, connected to each other with 8 different FEC and OC3 LANE links -- all L2. Each campus had several core switches depending on the number of buildings, again connected redundantly within the campus with FEC and/or OC3 LANE L2 links, plus dozens of access switches with redundant L2 uplinks to various core switches. Many protocols were in use, including non-routeable protocols like NetBEUI and SNA. How did this mess occur? "The CareGroup network grew organically due to the BIDMC merger, PACS installation, East to West movement of clinical services, Libby sale and changing CareGroup environment." In short, the network was growing very quickly due to business changes and was never redesigned to cope with the much larger scale and new application requirements. This resulted in the previously-mentioned 10+ hop STP, which spanned across multiple sites and multiple adminitrative zones. CareGroup had recently gone through a network audit by a third party which listed most/all of the potential problems in this design and suggested solutions. The outage occurred before CareGroup had an opportunity to act on these recommendations. The Outage The trigger for the outage was the addition of a new high-bandwidth application which somehow interfered with the proper operation of STP. Even after this application was removed, STP could not reconverge due to the default 7-hop limit. During troubleshooting, Cisco inserted L3 hops at logical boundaries, breaking the STP into more manageable chunks. Most of these smaller chunks were still unstable, so Cisco removed all redundant links in each area, verified stability, and then reintroduced redundant links one-by-one to troubleshoot potential problems. As you can imagine, this takes a long time, and was done with Cisco staff on site travelling to each building and wiring closet to make the necessary changes. Going Forward The new design calls for one pair of distribution L3 switches per building, with L3 GE links in a full mesh between all distribution switches in a campus, and between specific switches at each campus. STP will be confined to the access L2 switches. All non-IP traffic will be removed or isolated. In the meantime, CareGroup will be performing small-scare hardware and link upgrades to improve resiliency within each campus, and will install computers with dial-up connections to the datacenter in key locations so that they will have minimal connectivity if another LAN event occurs. Strict change control will be implemented with Cisco approvals. Conclusion As I alluded to before, this is not a story of equipment failure or STP's inherent scaling problems. It's a story of a business which didn't or couldn't adapt the network to the business needs -- even though everyone saw the train coming at them. The lesson here isn't to review your network design, but to review how your business handles growth and/or known problems. S

1 0

Re: Networking in Africa...
by David Charlap 03 Dec '02

03 Dec '02

David Schwartz wrote: > > If you want to do this, your notification has to be explicit. I suggest, > "You have no privacy here. Everything you are doing is being logged." Notice > that when you tell people the truth, it starts looking less like what you > wanted to do in the first place. Well, that makes it sound like you are a pervert that enjoys reading everybody else's e-mail. The language can be a bit better than that. You're right, you should say that all outgoing web forms are intercepted and recorded. But you can add additional statements to the extent that you won't be reading through that information unless it's part of following up on complaints of abuse, or at the request of law enforcement. I'm not trying to establish rules carved in stone, and I'm not trying to play lawyer. I was trying to attempt a possible solution to the problem of these spams coming from anonymous-access terminals in public places via web-based mail systems. Since web-mail doesn't have a fixed protocol to filter/monitor, you have to take a different approach. You can't block all possible vectors, since that would essentially block all traffic. One possibility is monitoring and logging in order to preserving evidence for possible future investigations. Yes it may be seen as invasive, but what other choice is there if your network is routinely being abused by felons? So far, I haven't seen anybody else post even a vague idea of a solution to this problem. Of course, as a network operator, you don't have to care - you can just cut off the service of any cafe owner who can't figure out a solution on his own. -- David

1 0

Fwd: Re: Networking in Africa...
by Hank Nussbacher 03 Dec '02

03 Dec '02

> > > i don't know if I've ever actually received 1 of those spam messages from > > > a host inside Nigeria > > > > wow, i seem to get several per day. would you like some, i can setup an > exploder > > for some of my spam if anyones interested? ;) > >and they're all actually sent/relayed through a host in Nigeria? my first >few were, none that I received after that were. alot from south africa, >and a few other parts, but no more from Nigeria Interestingly enough, I got the following today from a Cybercafe in Nigeria that I had blocked: >Thanks for the prompt response to the problem with our IP address. >I have alreday instructed all staff to be more vigilant and we are going >through the list of people who came around that time on saturday to track >down who sent this email. >I am in the process of buying a cybercafe management software which allows >the administrator to look at diffrent PCs and see what people are doing so >that if we spot things like this we will stop it. >Furthermore, I have instructed my team to program the webcams to take >snapshot of the shop every 20 minutes so that we can see who was in the shop >at what time. >I have also made sure we have notices put up in the cafe to say we do not >tolerate email spamming and anybody caught will be reported to the >autorities for appropriate action >However, I must stress that this is a cybercafe where 100% of people who >come there use web based email and there is no software or mechanism to stop >spamming from web based emails. You can see from the mail that was sent that >the person put a web based email address as the return address. Therefore I >cannot guarantee that this will not happen again , I can only put measures >in place to deter people. If there is any software you know about that would >prevent this or mechanism please let me know and I will put it in place >immediately >I am surprised however that there is no responsibility placed on providers >of web based emails who are in the best position to filter out and prevent >such emails from being delivered. >I hope all the measures highlighted above will be enough for you to go to >the ISP to reactivate our blocked IP > >cheers >Adeyinka So what exactly do people do in regards to Web spam? I block tcp/80 but would like to hear what others are doing. Regards, Hank

5 4

Networking in Africa...
by Eric Gauthier 03 Dec '02

03 Dec '02

Hello, A friend of mine is working on one of the committees for next years Supercomputing conference and noticed that, in the past, they'd had participants from most continents but none from Africa. Does anyone know of a good organization/group/etc which we could spam with our conference notice and request for participation? Thanks! Eric :) PS: For those who are curious, here's part of the write-up for the SC Global portion of next years Supercomputing conference: > SC Global is the multi-national and multi-cultural meeting place for > communication and discussion of ideas relating to high-end computing and > communications and their impact on science and society. SC Global 2003 > will be the second time we've held such an event; we have the > opportunity to build on the successes of SC Global 2001, and to learn > from its challenges. > > SC Global will include several Showcase events featuring art, music, > dance, and other innovative uses of advanced collaboration technologies. > In addition, SC Global will be an important extension of SC 2003's > high-quality technical program. For example, papers presented in SC > Global will meet the same high standards as those in the regular > Technical Papers sessions.

20 33

OT (was RE: Networking in Africa...)
by Martin, Christian 03 Dec '02

03 Dec '02

Folks, > judging any continent on a single country is extremely closed-minded. As this conversation is becoming. Please, this petty discussion is drifting pretty far offtopic. chris >

1 0

Re: Networking in Africa...
by Robbie Honerkamp 03 Dec '02

03 Dec '02

alex(a)yuriev.com wrote: > Try finding some IP connectivity while in Nigeria. You would be > hard-pressed, even if you are willing to pay enormous $$. Having worked and lived in Nigeria while consulting with several ISPs there, I can assure you this is incorrect. In large cities such as Lagos, you can't stand on the street and spit without hitting an Internet cafe, many of which are open 24-hours-a-day (419ers never sleep). $15 will get you all night (11pm - 7am) access in an air conditioned cafe with their own fast VSAT connection. I am _not_ joking- there are thousands of Internet cafes throughout Lagos State on almost every street. Many smaller towns in all parts of the country will often have at least one Internet cafe around. To answer your satellite comment, most ISPs have their own VSAT connections, though others go through local upstreams such as NITEL and GS Telecom (which eventually load the traffic onto their own satellite link). Many Internet cafes have set up their own VSATs as well, as many of the local ISPs can be unreliable and/or overpriced. Robbie -- Robbie Honerkamp ISP consultant- have-laptop-will-travel robbie(a)shorty.com

3 2

MSRFCs versus RFCs?
by joej＠Rocknyou.com 03 Dec '02

03 Dec '02

Happy Thanksgiving all! While I don't think I'll get a response to this question over the holidays, I thought I'd at least present it for response post Thanksgiving. I have a site that (along with others) has decided to use MSExchange as their SMTP hub. One of the problems I am seeing with this is that the current configuration allows for any inbound domain traffic. In otherwords, the exchange server seems to allow emails destin for any domain, then sends a None Delivery Report to the "Mail From" party. My argument is that there lies an exploit with this senario. In otherwords (and those of you that probably know where I am going with this just skip ahead) If I send an email to JoeSmo(a)domain.com and spoof the Mail From as Victim(a)innocentdomain.com to an Exchange Server setup in this manor, the Exchange server will bounce an email to the Victim(a)innoccentdomain.com. While this is all fine and dandy, if a person(s) decides to use this as a mailbomb method and exploit this, its rather simple to do. So, in short I am aguing that 1> Mail destine for a domain not handled should be 550 Denied. 2> None Delivery Reports should only be sent for Domains Handled. 3> That a Firewall should not be doing Domain checking for SMTP What I am at a loss for is RFCs that explicitly state this, that is NDR for other domains, and accepting for other domains. Perhaps I missed something or one of them. Anyone have to deal with this situation? Any suggestions on how to argue this? Am I perhaps missing something? Does Bill Gates feel that "Monopoly is just a game, I want the world!" Just kidding. Thanks in advance, and again Happy Thanksgiving! -Joe

3 2

Re: Risk of Internet collapse grows
by Michael.Dillon＠radianz.com 03 Dec '02

03 Dec '02

> > How much of this research is based on marketing maps on the ISPs' web sites, > > versus actual maps of the networks in question? Most "tier 1" ISPs won't > > even let their vendors see the latter. > last year we *measured* isp maps as part of a research project called > rocketfuel and found that the marketing maps can differ significantly from > the real ones quite a bit because of lack-of-detail, outdated-ness, or > optimistic-projections. a paper describing the methodology and the maps > themselves can be found off: > http://www.cs.washington.edu/research/networking/rocketfuel/ Something is wrong here... You are claiming that your maps are *MORE* correct than the ISP maps!? I don't think so. I had a look at your map of Ebone Europe through the browse button on your website. This displayed a messy meshy network that connected all the major cities of Europe. However, in fact, Ebone's network was a nice clean ringed network connecting all the major cities of Europe. It's true that Ebone's marketing map had some innacuracies but it still more or less showed the same network of sub-rings hanging off of a core ring. I just don't see how an outside probe can determine the true topology of a network. If a researcher wants to do analysis of real network topologies they either need to get the real maps from the ISPs in question or else they need to ally themselves with someone like Telegeography who have this information for at least some ISPs. --Michael Dillon

5 4