January 1998 - Test - lists.nanog.org

International Internet Connectivity
by George McCormick 05 Jan '98

05 Jan '98

I would be extremely appreciative if someone could explain to me how US ISPs and backbone operators address their international connectivity requirements: o How is their traffic routed? o How do peering relationships work and where do they take place? o Who pays whom for international transport(undersea cable and/or satellite) and services? Sincerely, George McCormick CSMG Cambridge, Massachusetts 617-864-0022

2 1

Request for State of the Internet Volunteers
by William B. Norton 05 Jan '98

05 Jan '98

Hi all - At the last couple of NANOGs I asked the audience if they were interested in another State of the Internet presentation set as we had done back in Washington, D.C. (NANOG 7) and the answer was a resounding yes. So, I am sending this request to the nanog list asking for: 3 volunteers from the ISP community, 3 volunteers from the Exchange Point community, and 3 volunteers that could reflect the current end-user community Internet experience. As we did the first time, each will be asked to give a 10 minute 3-4 slide talk answering the following three questions: 1) What are the top three most pressing problems you face? 2) What is the topology of your backbone or Exchange Point, or end-user, how are you connected? 3) What quantitative data do you have to share to show these problems? The hope is that we can identify a couple of common problems to the NANOG community that can be addressed by the router vendors, software or OS developers, ISP community itself, Exchange Point Operators, TelCos, Facilities Providers, etc. If you would like to volunteer to speak in this segment of the NANOG meeting, please e-mail me a paragraph that will give me an idea of the answers to the above 3 questions. If you have slides or web pointers that would be wonderful. Please send this to wbn(a)merit.edu with "State of the Internet Volunteer" in the subject field. Those speaking at NANOG 12 will of course get in free and receive the limited edition versions of the NANOG 12 speaker T-shirts ;-) Thanks, Bill -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 764-9430

1 0

Re: route ingress
by Vadim Antonov 05 Jan '98

05 Jan '98

Are there any pointers? Thanks! --vadim > The only real solution is strong cryptographical authentication of > the ownership of routing prefixes. For some reason i do not see > any serious work in that direction being done. Actually, it is being done. It's not ready for implementation yet. Tony

4 3

ATM --> HSSI
by andrew khoo 05 Jan '98

05 Jan '98

what box can i use to convert PacBell ATM (for PacBell NAP) into HSSI? ============================================================== andrew khoo - rebel leader aus: +61-2-9223-2777 Ourworld Global Network, Australia usa: +1-415-902-8820 ============================================================== -- We Bite (tm) --

5 4

RE: aggregation tool
by Dave Van Allen 05 Jan '98

05 Jan '98

Jared, Avi Freedman <freedman(a)netaxs.com> had begun work on an aggregate evaluator some time back. A quick look at http://www.routes.netaxs.com/ shows it has not seen new work since April of 1996. I think your idea is very worthwhile - perhaps Avi can share some of his experiences with you. Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions -----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Friday, January 02, 1998 3:23 PM To: nanog(a)merit.edu Subject: aggregation tool How many backbone NSP's would use a bgp aggreation tool that was setup similar to the route-views.oregon-ix.net or route-server.cerf.net that you would be able to do queries on to say "what might I not be aggregating correctly?" I'm working on such a tool that would be able to speak eBGP to a router (multihop or otherwise) and give this information. I've noticed a few providers that have /16's that announce each specific /24 or almost each one also, this would also make it possible to generate lists of folks that clog the routing table. I've sent e-mail to some of these folks today... Please direct responses directly to me if you're interested, or if you have something useful on this topic for *everyone* on nanog, include them also. - Jared -- ----------------- jared(a)puck.nether.net - Nether Network ------------------ CICNet/IAGNet/QUALnet/NetherNet - finger jared(a)puck.nether.net for pgp key

2 1

Re: ATM --> HSSI
by Eric Kozowski 05 Jan '98

05 Jan '98

At 04:14 AM 1/6/98 +1100, andrew khoo wrote: >what box can i use to convert PacBell ATM (for PacBell NAP) into HSSI? > kentrox adsu -- they supposedly work now.

1 0

Re: Things to do to make the network better
by Pete Ashdown 05 Jan '98

05 Jan '98

Owen DeLong said once upon a time: >> I will also point out that many of the recent "smurf" attacks and >> similar problems people are having on the net would be gone if people >> would just carefully filter internal/external addresses on their >> border machines, that is, prevent packets claiming to be from "inside" >> networks from coming in from the "outside", and prevent packets >> claiming to be from "outside" networks from going out from the >> "inside". The latter will stop your network from *ever* being the >> source of a wide variety of packet forgery attacks, and is necessary >> to being a good network citizen. The former will stop your network >> from being the subject of a wide variety fo packet forgery attacks, >> and is necessary to make your customers even remotely safe on the net. Expecting everyone else to do the right thing is the wrong way to solve the problem. 99% of everyone else will always do the easiest thing, which is nothing. >That's great if you're a downstream provider with no transit customers. >However, when you become a transit provider, it becomes much more difficult >to determine inside vs. outside, since you're more in the middle between >two "outsides" that pass traffic through you. Use customer configurable filters. There is no excuse for becoming less responsible as you grow larger.

1 0

Re: Whoa; the 3 network?
by rja＠corp.home.net 05 Jan '98

05 Jan '98

GE was the original party that was allocated Net 3, directly back when IP began. Your statements to the contrary were inaccurate. Regards, Ran

1 0

Re: Denial of Service Attacks disguised as Spam...
by gary flynn 05 Jan '98

05 Jan '98

> From: Dean Anderson <dean(a)av8.com> > Subject: Re: Denial of Service Attacks disguised as Spam... > > >many respects, he is forging his identity and I cannot imagine that > >forgery is legal. > > The ability to send anonymous email will probably remain protected. Also, > the legal beagles I know tell me it is perfectly legal to use an alias as > long as it is not done for fraudulent purposes. Ah, but sooner or later, we're going to have fairly universal certificate based authentication of some type ( IPSEC and/or application layer ). Then it will be a simple manner of refusing unauthenticated connections as policy or desires dictate. Someone may be able to send anonymous mail but nobody will have to read it :) The low level stuff will provide the ability to reliably trace packet level attacks and perhaps make decisions at the router level. The higher level stuff will provide the ability to implement authorization rules at the application or server level. You want to deliver mail to my mail server, you better tell me who you are. You want to send packets through my router, you best be authenticated in some way. Gary Flynn Network Analyst James Madison University

1 0

Re: Things to do to make the network better
by owen＠DeLong.SJ.CA.US 05 Jan '98

05 Jan '98

> I will also point out that many of the recent "smurf" attacks and > similar problems people are having on the net would be gone if people > would just carefully filter internal/external addresses on their > border machines, that is, prevent packets claiming to be from "inside" > networks from coming in from the "outside", and prevent packets > claiming to be from "outside" networks from going out from the > "inside". The latter will stop your network from *ever* being the > source of a wide variety of packet forgery attacks, and is necessary > to being a good network citizen. The former will stop your network > from being the subject of a wide variety fo packet forgery attacks, > and is necessary to make your customers even remotely safe on the net. That's great if you're a downstream provider with no transit customers. However, when you become a transit provider, it becomes much more difficult to determine inside vs. outside, since you're more in the middle between two "outsides" that pass traffic through you. Owen

3 2