June 1999 - Test - lists.nanog.org

new list telco-outages
by Jared Mauch 27 Jun '99

27 Jun '99

I've created a new mailing list that can either be cc:'ed to nanog, etc.. but can be used for telco outages that you encounter, such as fiber cuts, switch failures, etc.. to get on the list: send e-mail to telco-outages-request(a)puck.nether.net with a subject of subscribe to post to it, send a message to telco-outages(a)puck.nether.net - Jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. | "Waste Management Consultant"

1 0

RE: ARIN Public Policy Meetings
by Mohler, Jeff 27 Jun '99

27 Jun '99

Kim: I just spoke with Wael in our traffic engineering group, who I Emailed and CC'd you earlier. People who are no longer in his group or associated with the IP project reported a series of incorrect information on how they were dealing with ARIN and the feedback they were recieving. Mostly, the -real- problems were NDA agreements between the legal departments about who's document should be used..etc, and that was communicated to our engineering dept. as 'they said no' AND in as many words to sum up the whole project. Wael's group is also no longer connected with any ARIN dealings with the company, and yet another layer of middle-management has taken this over again. BUT, I will be more than happy to call you Monday 10a your time, and discuss with you..and our new leader of the ARIN project here at Williams. I am more than willing to eat the crow Ive laid out before me, and apologise to the NANOG community and ARIN.

2 1

ARIN Difficulties
by Geoff Mohler 27 Jun '99

27 Jun '99

Who do you go to, when you've spent a year detailing everything ARIN wants when you ask for address space, then they decide to flush an installed and operating $2B business plan "just because".

8 7

Re: Internet failures over the next 3 years
by Sean Donelan 26 Jun '99

26 Jun '99

jerry(a)freeside.fc.NET (Jeremy Porter) writes: >Largely we don't see conflicts of an actual prefix being announced >by hostile parties, where there isn't a technical parent/child >delegation relationship. The badness of such an event probably >is why. Big events like MAI 7007, Qwest reannouncing 3561, and so forth are noticed. But mis-announcing just a few /24 (out of a /19) or one /16 (out of a /15) don't make headlines. Nevertheless, it does happen on a regular basis. Most of the time it does appear to be a configuration error, which may explain why 'classfull' networks boundaries are the most likely places to have problems. For example, a few weeks ago I posted about the FCC's network prefix being announced by a tiny provider. A more interesting one was at one point during the war over Kosovo, a major backbone had a /16 of its network redirected through Macedonia Telecom. Why go through the trouble of installing a sniffer at mae-east, when you can just redirect the route through a more convient tapping spot. The traffic still flowed, just via a scenic route. Unfortunately, there are no good tools for the first level support people when confronted with an insane route. When reporting a problem, you will generally get back a response it "worked" for them. The next response is "that's how the Internet works," or "that's what the customer requested." As far as the first-level support is concerned, if ping or traceroute works, there is no problem. After a few days of escalating the problem, someone will eventually discover a configuration error, and fix it. Note: the bell-heads haven't solved this problem either. Insane routes also occur in the telephone system. Trying to explain to an operator why even though the call goes through, it is going to the wrong place, is hard to do. >Its good to have the tools in place and the technology understood >in the event its need, but to some extent just having the tools >is enough (MAPS-smurf/spam). > >I suppose when someone finds a quick and dirty hack to remotely >cause BGP sessions to flap between providers on private peering or >public peering points, the "trust everyone" model will have to >examined again. Largely I feel it would result in ingress filtering >much like smurf attacks have with directed broadcast. Since most of BGP route problems appear to be configuration mistakes by operators, more wide-spread double checking of announcements would help. Obviously a more sophisticated, malicious person or tool could get around a simple check. BGP vulnerablilties have been well covered in other forums. But until there is a big problem, I agree with your assessment. BGP passwords offer some protection against one particular type of impersonation attack. Anti-spoofing and access-lists help against other types of attack. Denial of service attacks are a bit harder to protect against. Transitive trust is a tough one unless we can all agree on some source to trust when there is a conflict. Note: I don't think the bell-heads have really solved this one either. If local number portability ever takes off, the net-heads are going to have a remarkable sense of deja vu. And don't get me started on SS7 'security.' -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Ameritech Fiber Cut
by Jared Mauch 25 Jun '99

25 Jun '99

There is currently an Ameritech fiber cut between Flat Rock, MI and Monroe, MI causing loss of service for dialtone, inbound long distance, and dedicated services in the area. There currently is no ETR. - jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. | "Waste Management Consultant"

1 1

Re: smtp CAR (another use for CAR)
by Jared Mauch 25 Jun '99

25 Jun '99

On Fri, Jun 25, 1999 at 03:01:00PM -0400, Daniel Senie wrote: > Jared Mauch wrote: > > > > This has been my great use for CAR (since icmp, etc.. CAR'ing).. > > > > If you are a dialup provider (or have dial ports), and CAR > > smtp from those networks down to 8kb/sec across your entire network > > to your upstreams, etc.. that are not going to your smtp server(s), > > or people you share dial pools with smtp servers, you can reduce the amount > > of third party relaying that occurs in your network. > > Those who implement this should also advertise this policy, as with any > restrictive policy. That way, folks who rely on services you're > throttling to death can avoid your networks. I'm only using this on our dialup pools, not the rest of our network space, so we don't affect any dedicated customers. This obviously means I have to maintain the access-list. > > We've had great success with it here, as we had someone > > (ab)using our online signup by signing up at 3am, dialing in, then > > sending a few hundreds of thousands of third-party relay spam messages. > > > > What I did: > > > > rate-limit output access-group 163 8000 8000 8000 conform-action set-prec-transmit 7 exceed-action drop > > > > on our upstream links, where acl 163 was a many line acl including > > all our dialup pools. > > > > permit tcp 10.10.10.0 0.0.0.127 any eq smtp > > > > etc.. > > > > You'll find you get matches against the access-list > > for people using remote servers, but if you get complaints, > > tell them to use your mail server.. > > > > We use this as an alternative (currently) to the per-port > > filters you can stick into dialup NASes for restricting smtp > > to a set of a few servers, etc.. > > Nice denial of service for the rest of your customers. You just need one > spammer doing their thing in the middle of the night, and any person > with a legitimate reason to be using a remote SMTP server is screwed. > Very sweet. They're not screwed, it'll work, but not fast. If I wanted to deny it, I can build the appropriate ACL for that. I've not heard a single complaint from a customer, and our spam complaints have gone down that our abuse group deals with. It's an alternative to just totally denying remote smtp, and allows us to track the people and shut them off and track them, etc.. so we can hand their info off to people who want to sue for theft of service. - Jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. | "Waste Management Consultant"

1 0

Re: Cisco TAC KRAP !!
by TOO MUCH 25 Jun '99

25 Jun '99

First of all, NANOG is the appropriate place to discuss such a topic. It is safe to say that the majority of us use Cisco somewhere in our network. When NONOG subscribers are courageous enough to share some of their ideas or portions of their config paragraphs they apprear to be from a Cisco config file. If there is a noticeable problem with service, we should all be aware of it. _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

1 0

Re: Cisco TAC KRAP !!
by Rubens Kuhl Jr. 25 Jun '99

25 Jun '99

I would not say that a message from a web-mail service which includes X-Originating-IP in the message headers is anonymous. Going back to the original message, viewing the headers and checking rwhois... hummm, let's call it "exercise to the reader". Rubens Kuhl Jr. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Alex Bligh Sent: Friday, June 25, 1999 2:25 PM To: TOO MUCH Cc: Stephen Sprunk; nanog(a)merit.edu Subject: Re: Cisco TAC KRAP !! >From a non-cisco internal point of view, when I have a problem with Cisco TAC's performance which happens occassionally, I contact my account manager and/or our contact in Cisco Service. Whilst I can't say they've fixed everything 100% of the time, they are far more likely to do something than whinging anonymously on NANOG. Every call desk has their rogue idiots. Another part of my company runs several desks- when people complain, we identify the individuals and try & get it fixed. In order to do this they'll need your name, and the rep's name. On a final note (and no I don't take their shilling) Cisco's TAC is the best of any large-scale hardware vendor I've ever used. Still. Despite foibles. If you a lot worse, you should have tried Ascend Europe (which has possibly improved since a year ago when we dumped all their kit - this being one of the main reasons). The cynic in my wonders why this is posted anonymously. Just what have you got to hide? Not working for a competitor or market researcher per chance? -- Alex Bligh GX Networks (formerly Xara Networks)

1 0

smtp CAR (another use for CAR)
by Jared Mauch 25 Jun '99

25 Jun '99

This has been my great use for CAR (since icmp, etc.. CAR'ing).. If you are a dialup provider (or have dial ports), and CAR smtp from those networks down to 8kb/sec across your entire network to your upstreams, etc.. that are not going to your smtp server(s), or people you share dial pools with smtp servers, you can reduce the amount of third party relaying that occurs in your network. We've had great success with it here, as we had someone (ab)using our online signup by signing up at 3am, dialing in, then sending a few hundreds of thousands of third-party relay spam messages. What I did: rate-limit output access-group 163 8000 8000 8000 conform-action set-prec-transmit 7 exceed-action drop on our upstream links, where acl 163 was a many line acl including all our dialup pools. permit tcp 10.10.10.0 0.0.0.127 any eq smtp etc.. You'll find you get matches against the access-list for people using remote servers, but if you get complaints, tell them to use your mail server.. We use this as an alternative (currently) to the per-port filters you can stick into dialup NASes for restricting smtp to a set of a few servers, etc.. - Jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. | "Waste Management Consultant"

1 0

This is not good news.
by Henry R. Linneweh 25 Jun '99

25 Jun '99

Betsy Hart: Shadowy group is taking control of Internet! http://www.azstarnet.com/public/dnews/0623CV2.html Imposition of taxes and other power plays. Seems like history repeating itself and setting a dangerous precedent. Taxation of the network and making US citizens bare the brunt of the cost is UNACCEPTABLE PERIOD. Increasing rates to ISP's and backbone providers is and reverse method of taxation on the consumer in the end for government benefit, UNACCEPTABLE PERIOD. Henry

6 5