- NANOG - lists.nanog.org

RE: ISPs as content-police or method-police
by Roeland Meyer 20 Nov '00

20 Nov '00

> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Monday, November 20, 2000 1:34 PM > > On Mon, 20 Nov 2000 13:16:00 PST, Roeland Meyer > <rmeyer(a)mhsc.com> said: > > We have enough problems from DOS attacks originating from the script > > kiddies, we don't need DOS attacks from our upstreams > > (uncontracted/unrequested port filtering). > > The two are inversely related. How? Denial of service because of script-kiddie activity is indistinguishable from denial of service because the transit provider is arbitrarily blocking those ports, or has firewalled my systems "for my own good", without my permission. DoS is DoS.

1 0

question regarding traffic type
by Rajesh Talpade 20 Nov '00

20 Nov '00

Hi Folks Would someone be able to point me to newer data on distribution of traffic types over backbone or access links (e.g. Web, email, RTP, DNS, etc) ? Thanks a bunch. Rajesh. -- Rajesh R. Talpade rrt(a)research.telcordia.com 973 829-4261 Senior Research Scientist, Telcordia Technologies

1 0

Re: [eggnog] Re: NANOG isn't NANOG anymore
by Steve Sobol 20 Nov '00

20 Nov '00

jamie rishaw wrote: > let us register eggnog.org. > immediately. Already registered, June 2000. Unfortunately, so is eggnog.net. -- Steve Sobol, BOFH, President 888.480.4NET 866.DSL.EXPRESS 216.619.2NET North Shore Technologies Corporation http://NorthShoreTechnologies.net JustTheNet/JustTheNet EXPRESS DSL (ISP Services) http://JustThe.net mailto:sjsobol@NorthShoreTechnologies.net Proud resident of Cleveland, Ohio

3 2

RE: BGP testing?
by Lane Patterson 20 Nov '00

20 Nov '00

QARobot has good full BGP conformance testing and a language called QBOL that gives you scripting control. But it's not a line-rate oriented product, for that you'd want RouterTester or Ixia. Since the QOSnetics acquisition, they've been gradually migrating functionality from QArobot to RouterTester. Take a look at Ixia www.ixiacom.com as well, they also have BGP4 emulation software. -Lane > -----Original Message----- > From: Dave Parkin [mailto:parkin@icrf.icnet.uk] > Sent: Sunday, November 19, 2000 2:15 PM > To: Irwin Lazar > Cc: nanog(a)merit.edu > Subject: RE: BGP testing? > > > > QOSnetics was acquired by HP last year: > http://www.hp.com/pressrel/sep99/20sep99h.htm and is now part > of Agilent. > Seems the 'QA Robot' is the result: > http://advanced.comms.agilent.com/qarobot/ > > Dave > > > -----Original Message----- > > From: owner-nanog(a)merit.edu > [mailto:owner-nanog@merit.edu]On Behalf Of > > Irwin Lazar > > Sent: 18 November 2000 14:54 > > To: 'Timothy Brown'; 'nanog(a)merit.edu' > > Subject: RE: BGP testing? > > > > > > > > Have a look at > http://www.networkmagazine.com/article/DCM20000510S0017 > > > > It is a lab test performed by the old "Data Communications" > > magazine on the > > Juniper M40. In it, they detail how they used a tool from > QOSnetics that > > was capable of generating up 520,000 unique routes (with a > /22 prefix). > > > > Irwin > > > > ------ > > Irwin Lazar, Senior Consultant > > The Burton Group - www.tbg.com > > ilazar(a)tbg.com > > 703-742-9659 (office) > > 703-402-4119(cell) > > The Ultimate Resource For Network Architects > > > > > > > -----Original Message----- > > > From: Timothy Brown [mailto:tcb@ga.prestige.net] > > > Sent: Friday, November 17, 2000 7:17 PM > > > To: nanog(a)merit.edu > > > Subject: BGP testing? > > > > > > > > > > > > Hey folks, > > > > > > Does anyone have a script or a series thereof to do > > > large-scale BGP testing? > > > I'm looking for scripts that will generate and nail down > > > several hundred > > > networks of varying sizes, and/or fake peering relationships > > > with a similar > > > purpose, and/or do things that don't meet the BGP protocol > > > standards, etc. > > > > > > Thanks for any responses. > > > > > > Tim > > > > > > > > > >

1 0

RE: ISPs as content-police or method-police
by Roeland Meyer 20 Nov '00

20 Nov '00

> From: Ben Browning [mailto:benb@oz.net] > Sent: Monday, November 20, 2000 9:17 AM > The point is this: 137-139 are used for NetBIOS and Samba, > neither of which > are secure (or even supported by their vendors, AFAIK) for > use out on the > Internet. I think we can all agree that anyone using them in that > situation, shouldn't be. No, we cannot all agree to that. I cannot condone anyone else applying their ideology, by force or default, on someone else, unless specifically requested. As a downstream customer, the backbone is nearly unreachable from a services perspective. If CERFNET started to do port-filtering then the only means I (I assume that everyone here has sufficient clue to find my upstream) have to change that is to either sue CERFNET or start looking for an ISP that has a different backbone provider. CERFNET tech support will not even talk to second or third level customers. In essence, it eliminates the secondary re-seller market from contention. You risk getting sued, not only from the downstream customer, but your own downstream as well. The ONLY one that should be even dreaming about doing something like this is the direct upstream to the leaf nodes, and then ONLY with permission. Otherwise, no ports should ever be filtered by any transit provider. By God, we PAY for open pipes and there are standard remedies when we don't get what we pay for.

2 1

RE: ISPs as content-police or method-police
by Christian Kuhtz 20 Nov '00

20 Nov '00

> >What doesn't make sense in that argument is why you couldn't just > simply upsell the customer to a managed fw solution etc > >if that's the concern. > > This doesn't work for a consumer broadband ISP, > where the customers won't be upsold to anything and > the average consumer just expects the network to be "safe". Hmm. I disagree, and consumers with those expectations would be advised to read their service agreements which they signed and accepted closely. > >Educate them, and let them decide based on the education they received. > > Education does not work for a consumer ISP, > whether broadband or dialup, due to scaling limits. > Might or might not work for a lease-line business ISP. Sure it does. Depends on what you consider education. I wasn't referring to a two hour class, but the type of discussion a sales rep has with their customer when you sign up for service. Doesn't a regular cable sales rep offer you HBO, Showtime etc packages when you sign up? Why not offer you a no-charge filter service? (granted, I said upsell in my first post, perhaps that was the wrong term). I do not believe that by default, opt-out filtering is a good practice for an ISP. > >Well, again, I don't believe in 'censoring' traffic by default. > > My perspective isn't about philosophy, but rather what > is practical and sensible from a business perspective. Quit splitting hairs. I do not believe that by default, opt-out filtering is a practical and sensible from a business perspective for an ISP. You may disagree, this is a free country last time I checked. > >I wouldn't be so sure, particularly because of the legal exposure... > > The major consumer broadband ISPs have already > discovered that their legal exposure would be higher > if they did not filter a small number of protocols, > than it is with filtering that small number of protocols, > which is the current common case with consumer broadband > ISPs today. Pointers, background please. And how is that sold and presented to the customer? What sort of legal ramifications have been discovered? How is the tech support role addressed? > >> And as has been pointed out, you can ALWAYS punch a hole > >> in the filter for customers who like to live risky, > >> or they can find other ways to tunnel their packets. > > > >At SP scale? Think again. > > Filtering by default and punching holes upon request > works fine for Media-One's cable modem service in the US > Northeast, so that approach CAN work fine at a large-sized > service provider scale (they are an existence proof). Oh yeah? While I happen to use MediaOne (because I can't get anything else where I live) and it seems to work most of the time, it is damn near impossible to find anyone who has a clue about anything (or cares) thru the tech support channels. And I don't consider spending 1.5hrs+ on hold to speak with a junior tech support person an accessible alternative. I do know from my fw at home that no filtering whatsoever is done. In fact, the service agreement clearly states that you're basically on your own. If this is available (and accessible) in the northeast, consider yourself *very* fortunate. If MediaOne (or my employer if I were be able to get DSL) were to start filtering traffic and gave me no reasonable way to opt-out or customize, I would probably be a very dissatisfied customer. Currently, some of these support channels only work well if you don't need support. > Different service providers might well make different > business decisions, but lets not confuse a business decision > with what is/isn't technically feasible. They aren't the > same thing. I don't think I said anything to that affect. Further, a less presumptious stance would be appreciated. I do believe that an opt-in approach is the better one, rather than opt-out. Cheers, Chris -- Christian Kuhtz <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."

1 0

RE: Operational impact of filtering SMB/NETBIOS traffic?
by Mathew Butler 20 Nov '00

20 Nov '00

Ah, but here's the rub: Is there anything, from a business standpoint (read: contracts), that says that you have the right, much less the obligation, to make 'security' decisions for the customer? If not, you're opening your company up to massive lawsuits. It's a -very- touchy subject -- but I, as a customer, want exclusive right to make filtering decisions over what goes from my network to the peering point, where the other backbone providers can choose their own policy. The reason for this is so that, if necessary, I can run any protocol I have a need to run over all circuits that I have that are connected to the same ISP. If it is shown that my network is relaying spam traffic, or is otherwise abusing the precepts of "Maintain Control Over What Flows In To And Out Of Your Network", only -then- would I think that control should be exercised by the NSP, and only then to the extent necessary to stop the abuse. And a hefty fine should be imposed on my company in that circumstance. Or are you thinking that the only clueful people in the network world exist at the NSPs? -Mat Butler -----Original Message----- From: Shawn McMahon [mailto:smcmahon@eiv.com] Sent: Sunday, November 19, 2000 4:53 AM To: nanog(a)merit.edu Subject: Re: Operational impact of filtering SMB/NETBIOS traffic? On Sat, Nov 18, 2000 at 08:19:12PM -0800, Roeland Meyer wrote: > > because we want shares. You are considering killing off a whole bunch of > legitimate use because some are too brain-dead to not have unintentional > shares on the internet? There are other issues with Microsoft's networking protocols than just unintentional shares. It leaks potentially lethal information like a sieve. Letting it willy-nilly through your firewalls is an invitation to have compromised hosts on your network. It should be filtered by default, and only un-filtered by request; and that with the understanding that if it even looks like you might be owned, you get cut off until there's an explanation.

3 2

anyone awake at gridnet/wcom/uunet?
by Dan Hollis 20 Nov '00

20 Nov '00

The lights are on but nobody's home? I tried the gridnet contact addresses published on http://www.grid.net/support/ as well as the rfc ones. ----- Transcript of session follows ----- ... while talking to skar.gridnet.com.: >>> RCPT To:<postmaster(a)grid.net> <<< 550 Relaying is prohibited 550 <postmaster(a)grid.net>... User unknown >>> RCPT To:<abuse(a)grid.net> <<< 550 Relaying is prohibited 550 <abuse(a)grid.net>... User unknown ... while talking to skar.gridnet.com.: >>> RCPT To:<support(a)ao.wcom.net> <<< 550 Relaying is prohibited 550 <support(a)ao.wcom.net>... User unknown >>> RCPT To:<ncc(a)ao.wcom.net> <<< 550 Relaying is prohibited 550 <ncc(a)ao.wcom.net>... User unknown Can someone get gridnet to fix their broken servers before I null route all gridnet traffic. -Dan

1 0

Re: Operational impact of filtering SMB/NETBIOS traffic?
by Mike Johnson 20 Nov '00

20 Nov '00

I've been reading this thread, and from the get go I've been wondering why an ISP would consider filtering SMB, SSH, telnet, or any other well used protocol. I suppose I'm under the opinion that an ISP should let their customers shoot themselves in the foot. I'm not employed by an ISP. I don't pass customer traffic across my network. I don't really have much of a network (though, if all goes well, it'll get larger). However, I would get annoyed if an ISP filtered some of my traffic that I considered legitimate, even if it is some micky-mouse, insecure protocol. If I want filtering, I'll call the ISP and ask for that service, for which they should charge. Otherwise, I'll go and buy my own firewall. They can be quite inexpensive and easy to use, even for non-network folk. It's difficult enough to debug network issues without having my ISPs mucking with which protocols they're going to allow. In the end, this sort of security should be up to me. If I don't like my feet, I should be allowed to add some additional metal, if I so choose. I guess I don't understand the argument and why an ISP would want to filter SMB (quality of the protocol aside). Mike -- Mike Johnson Network Engineer / iSun Networks, Inc. Morrisville, NC All opinions are mine, not those of my employer

5 5

RE: Operational impact of filtering SMB/NETBIOS traffic?
by Richard Welty 20 Nov '00

20 Nov '00

Ethan Butterfield [mailto:primus@veris.org] wrote: > From: Jim Mercer <jim(a)reptiles.org> > > as i understand it, ipsec doesn't use ports. > Yes and no. IPSec uses UDP port 500 for the ISAKMP key > exchange and the > tunnel setup, but all other traffic is IP Protocol 50 (ESP) > or 51 (AH). > Most firewalls I've seen block wierd (i.e., just about > everything that's > not standard TCP or IP Protocol 1 (ICMP)) by default, or at > least flag it > as strange. interestingly enough, ICSA firewall certification requires port 500 (ISAKMP) to be closed, so in theory, you cannot have an ICSA Firewall that also does standards conforming IPSec. there is a loophole, however. ICSA will let you off the hook if your manuals explain how to turn off port 500 in your IPSec capable firewall (or firewall capable IPSec box.) richard

1 0