January 1999 - Test - lists.nanog.org

MCI/CW Security
by James Rishaw 19 Jan '99

19 Jan '99

What a laugh.. We were just smurfed from what appears to be an MCI router as a relay.. Their voice menu at 888-860-3382 says: "If you are reporting a security issue please fill out an incident report on our web page at security(a)cw.net under 'Report an incident' " ^^^^^^^^ ^^^^^^^^^^^^^^^ Eh ??? With the lack of voice menu clue, I went to http://www.security.cw.net and found a form.. assigned ticket number "18".. makes me feel really good, to have a global company assign me a two-digit ticket.. but hey.. Is it just me ? -- jamie rishaw (efnet:gavroche) American Information Systems, Inc. jamie at ais dot net infrastructure engineering

3 2

Re: NSI does it again
by Patrick Greenwell 19 Jan '99

19 Jan '99

On Tue, 19 Jan 1999, Keith McCallion wrote: > On Tue, 19 Jan 1999, Patrick Greenwell wrote: > > > It seems that NSI, without informing anyone decided to remove the Status > > line from Whois lookups. Just a heads up.... > > Ugh! They better at least send a notice to the customer. We have customers > who don't pay for their domain names and wonder why it isn't working -- > being able to see a Domain Status: On Hold gave us the answer. We've lost > that ability? Yes and no. You can still get this information by doing a "dig" for the domain on one of the root servers. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com (tinc) \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

1 0

Re: NSI does it again
by Harold Willison 19 Jan '99

19 Jan '99

hmm.. does this mean you can no longer do a search on the words ON HOLD? This is probably just a way to shoo away the speculators. At 12:38 PM 1/19/99 -0800, you wrote: > >It seems that NSI, without informing anyone decided to remove the Status >line from Whois lookups. Just a heads up.... > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com > (tinc) >\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Harold Willison AGIS Network Engineering | * Senior Network Engineer 313-730-5151 * | noc(a)agis.net 313-730-1130 x-5649 | | harold(a)agis.net 24 hours a day, 7 days a week | | <bold><italic> <underline>http://www.agis.net</underline></italic></bold> |<bold><italic> </italic></bold>\*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

2 1

Re: Incompetance abounds at the InterNIC
by John M. Brown 19 Jan '99

19 Jan '99

My only problem with Pay Up Front is that some customers are going to be dead beat about paying us. I would want to make sure that there was some recourse to collecting our money or having the domain placed on hold until fees are paid. The only way that I can see doing that now is to register the domain under our name and then transfer it later once we get paid. Way to much work. Another way is to take the abusers to court and nail them. Make the penalty to high and they will leave. just my $.002 worth at 3am in the morning with US West blowing up Cascade switches At 11:22 PM 1/18/99 -0600, Edward S. Marshall wrote: >On Mon, 18 Jan 1999, Daniel Senie wrote: >> Actually, at this point I'd be happy to supply a credit card or a funded >> InterNIC account number along with applications. Money up front may well >> be the only way to clobber speculators. > >Hammer. Nail. Head. >BANG< > >Attack the root of the problem: people have made a market of domain >speculation. Raise the stakes for them, and you'll find that they'll be >more inclined to make a living some other way. The current model costs >them absolutely -nothing-, a zero-cost marketplace for speculators. > >I have -no- problem with a "payment up front" requirement. I'd hope that >anyone serious about doing real domain management would be willing to pay >in advance. > >-- >Edward S. Marshall <emarshal(a)logic.net> [ What goes up, must come down. ] >http://www.logic.net/~emarshal/ [ Ask any system administrator. ] > > Linux labyrinth 2.2.0-pre7-ac6 #2 Sun Jan 17 14:41:45 CST 1999 i586 unknown > 11:15pm up 1 day, 7:50, 4 users, load average: 0.03, 0.02, 0.00 >

3 2

Draft NANOG agenda
by Susan R. Harris 19 Jan '99

19 Jan '99

Greetings - here's a draft of the agenda for next week's meeting. ------------------------------------- Sunday, Jan. 31 - Afternoon Tutorials ------------------------------------- 1:00-2:50 p.m. BGP 101: BGP Concepts Made Easy (Howard Berkowitz) 3:10-5:00 p.m. BGP 102: A Mid-Sized Network Configuration Case Study (Avi Freedman, Net Access) Monday, Feb. 1 -------------- 9:00 a.m. Welcome, Introductions, Future Meetings (Craig Labovitz, Merit) 9:15 a.m. Routing Scalability in Backbone Networks (Enke Chen, Cisco) 9:45 a.m. Multiprotocol Label Switching: Progress in the IETF from an ISP Perspective Curtis Villamizar, ANS, moderator Paul Doolan, Ennovate Networks Tony Li, Juniper Networks Yakov Rekhter, Cisco 10:45 a.m. BREAK 11:00 a.m. Deploying Inter-Domain Multicast Routing (Dino Farinacci, Cisco) 11:45 a.m. A Modest Proposal for Quenching Smurf Amplifiers (Avi Freedman, Net Access) 12:00 p.m. LUNCH 1:30 p.m. Academic NGI Networking: What's the Difference Between Internet2, Abilene, and the vBNS? Paul Love, Internet2, moderator Guy Almes, Internet2 Jerry Sobieski, Abilene John Jamison, MCI/vBNS 2:30 p.m. ARIN Update (Kim Hubbard, ARIN) 2:45 p.m. InterNIC Update (Mark Kosters, InterNIC) 3:15 p.m. BREAK 3:30 p.m. A Novel Use of Distributed Directory Service (Bill Manning, ISI) 3:45 p.m. Network Failure Analysis (Craig Labovitz, Merit) 4:15 p.m. RED Analysis for Congested Network Core and Customer Egress (Bradley Reynolds, QualNet) Monday Evening BOFs ------------------- 7:30-8:30 p.m. Switch Migration and Renumbering at the Chicago NAP (Andrew Schmidt, AADS) 7:30-9:00 p.m. Cflowd Configuration (Daniel McRobb, CAIDA) 9:00-10:30 p.m. Modem Wholesaling in Today's Marketplace: Vendor Approaches and Solutions (Marie Hattar, Nortel) 9:00-10:30 p.m. Managing Filters and Traffic Shaping in Complex Networks (Pete Kruckenberg, inQuo) Tuesday, Feb. 2 --------------- 9:00 a.m. The Ins and Outs of Layer 4+ Switching (Shirish Sataye, Alteon) 9:45 a.m. Cflowd Update (Daniel McRobb, Cooperative Association for Internet Data Analysis (CAIDA) 10:30 a.m. BREAK 10:45 a.m. Internet Engineering Curriculum (Evi Nemeth, CAIDA) 11:00 a.m. IRcache Web Proxy Bake-Off (Duane Wessels, University of California, San Diego) 11:15 a.m. International Exchange Points: Growth and Trends (Bill Manning, ISI) 11:30 a.m. Setting Up a Local Exchange in Denver: Why Haven't More Providers Joined? (Trent Hein, XOR) 11:45 a.m. Closing Remarks (Craig Labovitz, Merit) ------------------------------------------------------------------------- Susan R. Harris, Ph.D. Merit Network, Inc. Phone: 734.936.2100 srh(a)merit.edu Senior Science Writer Fax: 734.647.3185 -------------------------------------------------------------------------

1 0

RE: MCI/CW Security
by Scott McGrath 19 Jan '99

19 Jan '99

Sorry about the the last message got a little click happy... Or the ticket# field has only 16 bits.... > -----Original Message----- > From: TTSG [SMTP:ttsg@ttsg.com] > Sent: Tuesday, January 19, 1999 3:44 PM > To: nanog(a)merit.edu > Subject: Re: MCI/CW Security > > Hi, > > Nope, not just you. I had a human tell me the same thing, and being > less than happy about it I let him know that web addresses don't have "@" > in it (Ok, they can, but thats another story). > > I was assigned ticket #15. I guess they don't have much security > problems. > > They were good to initially follow it up (However, NEVER received > the > confirmation email I was told I should get) but after that.....Nada. > > Tuc/TTSG > > > > > > > Eh ??? > > > > > > With the lack of voice menu clue, I went to > http://www.security.cw.net > > > and found a form.. assigned ticket number "18".. makes me feel really > > > good, to have a global company assign me a two-digit ticket.. but > hey.. > > > > > > Is it just me ? > > > > > > > > > ====================================================================== > > Derek J. Balling | "Bill Gates is a monocle and a white > > dredd(a)megacity.org | fluffy cat from being a villain in the > > http://www.megacity.org/ | next Bond film." - Dennis Miller > > ====================================================================== > >

1 0

RE: MCI/CW Security
by Scott McGrath 19 Jan '99

19 Jan '99

> -----Original Message----- > From: TTSG [SMTP:ttsg@ttsg.com] > Sent: Tuesday, January 19, 1999 3:44 PM > To: nanog(a)merit.edu > Subject: Re: MCI/CW Security > > Hi, > > Nope, not just you. I had a human tell me the same thing, and being > less than happy about it I let him know that web addresses don't have "@" > in it (Ok, they can, but thats another story). > > I was assigned ticket #15. I guess they don't have much security > problems. > > They were good to initially follow it up (However, NEVER received > the > confirmation email I was told I should get) but after that.....Nada. > > Tuc/TTSG > > > > > > > Eh ??? > > > > > > With the lack of voice menu clue, I went to > http://www.security.cw.net > > > and found a form.. assigned ticket number "18".. makes me feel really > > > good, to have a global company assign me a two-digit ticket.. but > hey.. > > > > > > Is it just me ? > > > > > > > > > ====================================================================== > > Derek J. Balling | "Bill Gates is a monocle and a white > > dredd(a)megacity.org | fluffy cat from being a villain in the > > http://www.megacity.org/ | next Bond film." - Dennis Miller > > ====================================================================== > >

1 0

Re: MCI/CW Security
by TTSG 19 Jan '99

19 Jan '99

Hi, Nope, not just you. I had a human tell me the same thing, and being less than happy about it I let him know that web addresses don't have "@" in it (Ok, they can, but thats another story). I was assigned ticket #15. I guess they don't have much security problems. They were good to initially follow it up (However, NEVER received the confirmation email I was told I should get) but after that.....Nada. Tuc/TTSG > > > > Eh ??? > > > > With the lack of voice menu clue, I went to http://www.security.cw.net > > and found a form.. assigned ticket number "18".. makes me feel really > > good, to have a global company assign me a two-digit ticket.. but hey.. > > > > Is it just me ? > > > > ====================================================================== > Derek J. Balling | "Bill Gates is a monocle and a white > dredd(a)megacity.org | fluffy cat from being a villain in the > http://www.megacity.org/ | next Bond film." - Dennis Miller > ====================================================================== >

1 0

RE: ATM Switch Interoperability Fixed!
by Webb, Tremayne 19 Jan '99

19 Jan '99

It appears that the FORE ASX1000 switches and Ascend Switches do some manipulation of the settings you give them. The Ascend switches allocate [SCR (in cells)] * 1.35 as your CAC (Connection Admission Control) and leaves the PCR untouched. The ASX1000 allocates it as [SCR (in cells)] * 1.75 and leaves the PCR untouched. We recalculated the SCRs to equal out and this solved the problem. ~~~~~~~~~~~~~~~~~~~~~~~~~ Trey Webb Sr. NOC Engineer BA Global Networks, Inc. 703-295-4407 ~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Alex Bligh [mailto:amb@gxn.net] Sent: Tuesday, January 19, 1999 12:08 PM To: Steve Murray Cc: Martin, Christian; danny(a)qwest.net; nanog(a)merit.edu Subject: Re: ATM Switch Interoperability Steve, Formula looks great (interesting). However certainly (Cisco) AIP's don't traffic shape sufficiently accurately for (Cisco) BPX's not to cause the occassional discard. I figured Lightstreams might be the same. In our case the relevant supplier changed CDVT and it fixed this. -- Alex Bligh GX Networks (formerly Xara Networks)

1 0

Re: RE: ATM Switch Interoperability
by Steve Murray 19 Jan '99

19 Jan '99

Here is the function for the relationship of Burst Tolerance BT (time) and Maximum Burst Size MBS (a number of cells). Most switches allow you to set the MBS and then they calculate the BT based on this function. Definitions: Ts = 1/SCR, Tr = 1/PCR, ts = BT MBS = | 1 + ((CDVT + ts) / (Ts - Tr)) | where |x| stands for the largest integer less than x. for Tr > 1 and CDVT > Tr -1. This function is based on using a unit of micro-seconds for each variable. The corresponding function is used to calculate the maximum burst size B (a number of cells) on the PCR policing: B = | 1 + ((CDVT) / (Tr - 1)) | For Tr > 1 where |x| stands for the largest integer less than x. CDVT must be greater than Tr - 1. This function is also based on units of micro-seconds. It breaks down if Tr < 1 microsecond. At that point a smaller unit of time would need to be subtracted from Tr instead of 1 microsecond. This only matters with very large PVCs with a PCR of over 1000000 cells per second. These values for MBS and CDVT are usually defaulted for the user and the same default applies no matter what the SCR and PCR values are. Some ATM providers set the CDVT and MBS very low and adjust up if problems like you are observing appear. If the lightstream does traffic shape properly this should not be an issue. If you do have traffic shaping on the lighstream you could set the PCR=SCR. You will lose a small amount of burst but will be able to sustain at SCR. The bursts do not really buy you a large amount of extra traffic anyway (unless CDVT and MBS are set high) they are really just there to allow for variations in accuracy of policing between devices. Steve Murray MCI Worldcom steve.murray(a)wcom.com >>> "Martin, Christian" <CMartin(a)mercury.balink.com> 01/15 9:19 PM >>> >We have it matched to the policing policy of the Network Provider. By >increasing the CDVT, we gain some bucket depth, but we are only MUXing 5 >VCCs over one VP. There shouldn't be too much clumping, espescially >considering the load on the switches(low). One thing is interesting, >though: The far end (customers) are all running over DS3 using HEC >delineation. > >A curiosity: Given the parameters below for the contract, particularly >the MBS and CDVT, does it appear that we are being cheated? From my >understanding of the UNI 3.1 spec, the MBS should be adjustable >according to SCR/PCR, given the fact that CDVT is defined as the same >for both SCR and PCR buckets. > >One obstacle that myself and my colleagues have not been able to >overcome is the use (aside from bucket calculation) of the Burst >Tolerance. It is obviously proportional to the MBS, but again, it >appears as if a contract specifying a PCR/SCR of 100000/50000 cells per >sec, should have a higher MBS than a 10000/5000 cell/sec contract. > >Any insights? > >Chris -

2 1