- Test - lists.nanog.org

Re: Fw: Administrivia: ORBS
by Paul Vixie 19 Jan '00

19 Jan '00

> Perhaps AboveNet would openly submit to testing by someone independent > of ORBS who would agree not to release the detailed results (except to > AboveNet) but who would check the validity of ORBS claims and provide a > summary report. ORBS would of course have to be allowed to review the > validity of the tests done. ORBS has made no claims that there are open relays inside Abovenet. They are preemptively scanning Abovenet's address space IN CASE THERE ARE ANY relays, either belonging to Abovenet, or belonging to an Abovenet customer. > In this case AboveNet is a transport provider and in my opinion they're > risking their status as a network carrier to be filtering in they way > they are. (Not that I know anything about carrier rights! :-). Right, like you said, YANAL. Abovenet also runs the MAPS RBL in BGP mode, and this hasn't hurt their status that I can tell from here. > Your own filtering of your own network when your own hosts are involved > is a much different scenario. It *is* Abovenet's own network. They sell transit to other people via their own network, but that doesn't change the ownership of Abovenet's network to somehow not include Abovenet. If you think Abovenet doesn't have the right to refuse service to anyone, then your property ethics are the same as any spammer's. And if Abovenet loses customers because they don't allow ORBS to probe them, then that's a matter for Abovenet's customers to decide. (MIBH uses the old Partan/Doran "maximum prefix length" filters on our BGP input side, which means we can't reach various nets who break up a /20 into a lot of discontiguous /24's each singly homed by a different transit provider. Do we, also, risk "losing our carrier status" because we exercise control over what routes and what traffic we carry?) > Finally can we please stop using the incorrect term "port scanner" here? > ORBS does not "scan" and it most certainly doesn't scan arbitrary ports. They are looking for port 25 on all addresses within /16'. You call it what you want, I'll call it a port scanner. -- Paul Vixie <vixie(a)mibh.net> >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart

4 4

Take Advantage .....
by kkgjfj6uur3d＠aol.com 18 Jan '00

18 Jan '00

INTERNATIONAL DRIVER'S LICENSE Need a new driver's license? Too many points or other trouble? Want a license that can never be suspended or revoked? Want ID for nightclubs or hotel check-in? Avoid tickets, fines, and mandatory driver's education. Protect your privacy, and hide your identity. The United Nations gave you the privilege to drive freely throughout the world! (Convention on International Road Traffic of September 19, 1949 & World Court Decision, The Hague, Netherlands, January 21, 1958) Take advantage of your rights. Order a valid International Driver's License that can never be suspended or revoked. Confidentiality assured. CALL NOW!!! 1-937-586-9313 rem- nypd55(a)angelfire.com

1 0

Re: Fw: Administrivia: ORBS
by Michael Shields 18 Jan '00

18 Jan '00

In article <Pine.LNX.4.10.10001152253220.17784-100000(a)pimlico.magmom.net>, Patrick Evans <pre(a)pre.org> wrote: > The only thing we can do which allows all of our customers to send > mail out with their address as the From: header, and not force them to > use our dialup service (if we had one) is to run a completely open > relay. I don't understand why you ca'n't allow relaying only for people with an envelope sender that has one of your customer's domains. -- Shields.

3 2

Re: ICMP rate limiting on EGRESS (Warning, operational contentinside)
by Paul Ferguson 18 Jan '00

18 Jan '00

At 11:26 AM 01/18/2000 +1030, Glen Turner wrote: > > This is the principle reason to encourage everyone to implement > > RFC2267-style filtering. :-/ > >It would be nice if this shipped "on" by default in a particular >major vendor's products. This would at least take care of the >clueless majority, and would force all ISPs to address the issue. > >It is only the router vendors and routing code authors that can >*force* source address checking throughout the Internet. Most >users will simply install it during a normal software update. Well, we don't _force_ anyone to use amything, but we do have a little knob called "Unicast RPF". I'll leave it to the rest of the of the readership to discuss it's merits (or perhaps move the dicussion to the cisco-nsp list instead). Cheers, - paul

1 0

Need @home and Mae-West Help
by Derrick Bennett 18 Jan '00

18 Jan '00

First my appologies to the list. I hate to reach people this way but the truth is it works very well. I need someone from @home or @work's NOC or management staff to contact me off list ASAP. My attempts to escalate an issue via tickets has failed and most of my contacts voicemail boxes are full. There is a peering point congestion problem at Mae-West that is killing bandwidth during peak times and we have not been able to get any resolution to the issue. Thank you. Sincerely, Derrick Bennett

2 1

Re: Fw: Administrivia: ORBS
by Brian Dickson 18 Jan '00

18 Jan '00

> > These days I've been unable to find any justifiable need for an > > unprotected relay of any sort whatsoever. > > We do domain hosting and mail redirection (among other things), but we > don't do dialup. [...] When they want to send mail out, > they have to do it through their IAP's mail server. As much as it's a small hassle, any user stuck behind a horrible IAP, what about setting the SMTP to the *recipient's* MX host. Since this would be local delivery, would it not be accepted, regardless of source? (The hassle is, of course, changing SMTP for each receipient domain...) > POP before SMTP is a crufty hack, IMNSHO, and SMTP auth isn't > implemented to enough of an extent that I'd be comfortable running it. It is crufty, and also crafty. A horrible, but most importantly, effective, kludge. Nearly everyone I've talked to eventually came up with this. It's not the only solution, however, to your particular requirement. Assuming your SMTP gateway is suitably configurable (eg some variant of sendmail or some equally extensible package), you could easily enough set up special rules, on a relay-only box: Call the box "relay.yourdomain.com". Users who use it, configure their outgoing id as "user.name.with.dots.cryptpw(a)hosted-domain.com". Your ruleset for relay, is to strip the ".cryptpw", do RADIUS-auth on the result with the encrypted password. Iff it passes, relay the mail. (You want it to be used only for this purpose, and only with this mechanism, for greatest likelyhood of avoiding screw-ups.) A simple web interface, with password protection, can give out the cryptpw value, or any other "cookie"-type equivalent. Since your box, relay.yourdomain.com is the SMTP, and rewrites the headers, the "cryptpw" value isn't stored anywhere, and except for routers and any sniffers on broadcast domains (Ethernet or FDDI hubs), nothing will see the packets with this magic value - which is user-specific, to boot. > Anyone who says there's absolutely no reason to run an open relay is > talking absolute codswallop - as with every situation like this it > requires a reasoned political decision at the site in question. Open, in this case, is absolute, but there is no absolute closed, only various shades of grey. Any political decision, if made by a reasoning entity, has some chance of being trumped by an adequate technical solution. The only question is what the technical solution costs. I've given it for free; if you use it, please attribute it to me. :-) > We don't use ORBS, either - Alex Rudnev has it spot on, to my mind. MAPS has both the RBL and RSS - both reasonable alternatives to ORBS. Highly recommended. -- Brian Dickson, Email: briand(a)teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com

2 1

None
by Brad S. Dreisbach 17 Jan '00

17 Jan '00

If anyone on this list works for @home could you please contact me off list. thanks, -brad

1 0

CEF Load balancing...
by Alex Rubenstein 17 Jan '00

17 Jan '00

Question (kinda operational).. I've been looking/asking around, but have yet been able to get the same answer twice to the following question: How many links can you have in parallel when using CEF load-sharing per-packet? Another words, we currently have a site that has four DS1s load balanced, in parallel (terminating in the same router on each end). Can you add a [5th|6th|7th|8th] ? Before you answer "BUY A DS3!", this is located in a rural area that a) really doesn't (easily) even have DS3 capabilites, and b) isn't cost effective to have a DS3 as it is about 15 times the cost of a DS1. Thanks for any insight!

11 14

Re: ICMP rate limiting on EGRESS (Warning, operational content inside)
by Sean Donelan 17 Jan '00

17 Jan '00

On Mon, 17 January 2000, bmanning(a)vacation.karoshi.com wrote: > Source routing and connection based services are creaping into > the Internet, slowly but surely. Both are a far cry from the > destination forwarding and connectionless service that I grew > up with. Yes, but as far as I know, none of the new services rely on the ability to spoof the source address outside of local (perhaps VPN extended) network. Even old services such as roaming and redirector applications have switched to using tunnels instead of spoofed source addresses. Are there any real-world applications which have no alternative but to use spoofed source addresses on the Internet at large? Or is this a case, if we had thought about it, we would have prohibited it at the start; but now its in the wild we don't know how to get it back in the barn.

3 4

ICMP rate limiting on EGRESS (Warning, operational content inside)
by Alex Bligh 17 Jan '00

17 Jan '00

It is reasonably well acknowledge that ratelimiting ICMP on *ingress* to your network can be a good thing to do, if you have available resources to do it. How about players rate-limiting ICMP on *egress* of the network over public exchange points. I have been on the wrong end of several smurfs over 100Mb/s over MAE-East & West, as, I'm sure have others. Whenever anyone is smurfed like this, I presume their port blocks, and anyone sending them data has head of line blocking. Which means, in effect, anyone peering with anyone who is being (sufficiently smurfed) will experience packet loss to *other* peers. By rate-limiting ICMP on output (to perhaps 3 or 4 times its nowmal value which here is 4 times 1% of normal traffic levels), then if one of your peers is being smurfed, you help save HoL blocking occurring. If your peer blocks these on ingress, it won't help - the packets will still get switched. >From what I am (unscientifically) seeing, packet loss over the MAE is spikey and can go through periodicity of badness not dissimilar to the length of such DoS attacks. I am not, of course, suggesting that this will solve all the MAE's problems. If the Gigaswitches could give even an approximation of total traffic that was ICMP, and see if peaks in this correspond to peaks in packet loss between routers on the MAE (not just across the switch fabric), we could even attempt to measure this. Is this a good idea? -- Alex Bligh GX Networks (formerly Xara Networks)

6 5