September 2000 - Test - lists.nanog.org

Re: NANOG 20 River Rafting *unofficial* Trip
by Nanog20＠aol.com 27 Sep '00

27 Sep '00

In a message dated 9/27/00 12:08:55 AM Eastern Daylight Time, aaronm(a)toothpick.net writes: > Ron, > > What time is this event? Itinerary is availabe at Keyword...err... I mean from the main rafting info URL. :-) <A HREF="http://nanog.aol.com/nanog-raft.htm">WHITEWATER RAFTING TRIP</A> <A HREF="http://nanog.aol.com/raft-itin.htm">ITINERARY FOR SATURDAY 21ST OCTOBER</A> cheers! -ron

1 0

Re: NANOG 20 River Rafting *unofficial* Trip
by Sean Donelan 27 Sep '00

27 Sep '00

> http://nanog.aol.com/nanog-raft.htm Wow, this is awesome. Not even AOL's strategic partners have a subdomain under AOL.COM. Or even AOL wasn't brave enough to say "AOL Keyword: NANOG" :-) The rafting trip looks cool too.

3 2

Re: netscan.org update
by John Fraizer 27 Sep '00

27 Sep '00

On Tue, 26 Sep 2000, Todd Lyons wrote: > John Fraizer wrote: > > > Liken it to the Gas company driving up and down your street with a sniffer > > looking for leaks (SMURF amps) and someone walking up to every house in > > But do you not consider this the equivalent of using a lighter as the > sniffer? > -- > Blue skies... Cannonball http://www.mrball.net > * People are more violently opposed to fur than leather because * > * it's safer to harrass rich women than motorcycle gangs. * > "Well M'am... It looks like your new stove is all set. Just one more check. [click] [click] <BOOM!> OOPS... Sorry bout that. We forgot to set the 'no LP directed-explosion' command on your stove. We'll get that fixed right up." Sorry... I couldn't resist. I do understand where you may draw that conclusion however. Testing for the presence of gas (smurf amplifiers) with a sniffer (single ICMP echo-request scan) is NOT the same as simply throwing a match at the gas main (waiting for an attack). So, the simple answer to your question is no. --- John Fraizer EnterZone, Inc

1 0

NANOG 20 River Rafting *unofficial* Trip
by Nanog20＠aol.com 27 Sep '00

27 Sep '00

AOL Inc is hosting an "unofficial" social event for those of you arriving early in Washington DC for NANOG 20. What: White water rafting on the Shenandoah River URL: <A HREF="http://nanog.aol.com/nanog-raft.htm"> http://nanog.aol.com/nanog-raft.htm</A> How much: $25 to secure a seat When: Saturday, October 21st Where: We will pick up and return you at the Renaissance Hotel. Who: The first 40 respondents via fax. You must complete the waiver form and size information for wet suits. Please see URL for additional directions and information. See you there! Ron da Silva America Online, Inc.

2 1

Web page for DNSSEC workshop
by Edward Lewis 26 Sep '00

26 Sep '00

Sorry for not announcing this sooner. There is a web page with information regarding registration a DNSSEC workshop to be held in conjunction with NANOG 20 (a day later and close by). I was giving those who asked early access to sign up, and a few did. In case you haven't seen this, here is information on the workshop. http://www.nanog.org/mtg-0010/dnssec.html -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis(a)tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer.

1 0

FW: netscan.org update
by Roeland M.J. Meyer 26 Sep '00

26 Sep '00

> > Simpler than what you suggest is to read RFC 2644, then turn off > > directed broadcasts in routers being deployed, and making the > > default be > > DISABLED on new routers. > > I agree. But, for some reason, that isn't working as well as > it should. BTW, one feature that has been enabled for years > is a default ingress filter that blocks inbound packets that > have a source addr from inside the net-block (obviously wrong > or an attack). Because bcast addrs values are configuration > dependent, it is not possible to use such a generic filter. > However, it should be possible to build dynamic bcast > scanning into a router such that it scans the internal net > for bcast addrs and subsequently ingress filters all packets > to those source addrs that do not originate on the local > netblock. This will not solve the immediate problem with > existing routers. But, that same method can be used to scan > the /24 and auto-generate the required filter statements for > the firewall. The upstream can run it the other way, for the > client, except that they would be egress filtering. This > method requires no in-addr.arpa edits. > > > I'd rather see sites spend their time on that rather than > > adding INADDR entries to their domains. Remember that > delegations to other > > organizations (i.e. clients of ISPs) are able to subdivide networks > > further, and that won't be apparent to the ISP. > > Agreed, that's why I also wrote about dynamic bcast discovery methods. > > In case anyone missed my point, using BGP blackholing becomes > anti-social behavior when more surgical techniques are > available. Moreso when such techniques aren't even explored > before implementing the blackhole method. > > MAPS has only gained a modicum of acceptability because more > socially acceptable methods were tried and subsequently > failed. Moreover, they have been shown to not even be > feasible. This is NOT the case with the smurf-amp problem. I, > for one, am NOT convinced that sufficient thought has been > directed at more socially acceptable alternative solutions. >

1 0

RE: netscan.org update
by Roeland M.J. Meyer 26 Sep '00

26 Sep '00

> From: Troy Davis [mailto:troy@nack.net] > Sent: Tuesday, September 26, 2000 9:49 AM > > On Tue, 26 Sep 2000, Roeland M.J. Meyer <rmeyer(a)MHSC.com> wrote: > > > I know that all of you are aware of this. Granted, each subsequently > > smaller subnet also limits the maximum number of hosts that > will respond > > to the smurf trigger. The point is that, the web-site ONLY > tests 0 and > > Actually, that's often not the case. Through NAT and other modern > marvels, it's possible to have massively overpopulated netblocks that > all respond. The largest amplifier we've found yet was 170,000x (on > a class C). Thank you Troy, However my point remains.

2 1

RE: netscan.org update
by Roeland M.J. Meyer 26 Sep '00

26 Sep '00

> From: John Fraizer [mailto:nanog@EnterZone.Net] > Sent: Tuesday, September 26, 2000 9:43 AM > > On Tue, 26 Sep 2000, Roeland M.J. Meyer wrote: > > > Defense is a lot less socially antagonistic than offensively BGP > > black-holing antire IP-blocks (which can get you seriously sued) and > > creating more outages than we already have to suffer through. > > Roeland, > > The last time I checked, AS65535 (picked for obvious reasons) does not > have a transit contract in place with my company and as such, has > absolutely NO grounds to sue me if we choose to blackhole > routes to them > at our borders. > > No transit contract -- no guaranteed transit. It's just that simple. The operative would that I used was "can" and not "will". However, you don't discount my statement about blackholing creating artificial outages. I am proposing a more surgical response to the smurf threat. One that in no way creates outages and may be more socially acceptable. You also missed the point that a IP-block can pass the netscan.org test and STILL be a smurf amp via it's subnets. The subnet bcast addrs aren't hard to find.

1 0

RE: netscan.org update
by Roeland M.J. Meyer 26 Sep '00

26 Sep '00

> From: Daniel Senie [mailto:dts@senie.com] > Sent: Tuesday, September 26, 2000 8:45 AM > "Henry R. Linneweh" wrote: > > John; > > "The SMURF problem is years old. People who don't look for > this on their > > own networks and prevent it before it starts are AS MUCH if > not MORE a > > part of the problem as the script kiddies". > > Implementing RFC 2827 (ingress filtering) and RFC 2644 (disabling > directed broadcast) is more than just a nice idea. These are > both BCPs, > since they both represent methods for limiting damage to the Internet. I've been following this thread since the first time it came around. In the last round, the point was made that 0 and 255 weren't the ONLY b'cast addrs in a /24. In fact they aren't, over here (MHSC.NET) Our /24 is so sub-netted. In fact, one can have up to 64 b'cast addrs in a /24. I know that all of you are aware of this. Granted, each subsequently smaller subnet also limits the maximum number of hosts that will respond to the smurf trigger. The point is that, the web-site ONLY tests 0 and 255 and y'all are discussing filtering on ONLY those values. This is inadequate for what you are trying to do. A /25 can still yield 127 host respnses and a /26 will yield 63 host responses, and so on... Discovering these b'cast addrs isn't difficult either and I'm sure that the script-kiddees already have a means to do so. Had I the time, I could write the code, the algorithm is trivial. The last time this came around I suggested a means that would work. It involves making entries in your in-addr.arpa file that lables each base and b'cast addr. As an example, I have done this to my own file and have been maintaining it for years. Once put in place, it is simple to maintain. Generally, subnet assignments don't change that much (scale = years). The upstream should filter any and all packets going to those addrs, at the gateway. This can be made a part of the contract, with downstreams that manage their own IP and DNS space (like MHSC does). I've actually considered a script that reads the ARPA file and generates ipchains commenads to automagically put the proper filters in place. Again, it isn't that hard. The specific file I am talking about is "175.108.199.inaddr.arpa", dig at your local BIND for the auth server NS1.MHSC.NET. Base addrs are labeld "base" and b'cast are labeled "bcast" (duh). There are various means to implement this, I can think of 1-2 others without really trying. The point is that, if you're going to do this, do it right. Defense is a lot less socially antagonistic than offensively BGP black-holing antire IP-blocks (which can get you seriously sued) and creating more outages than we already have to suffer through.

3 2

HR 4445 Reciprocal Compensation (fwd)
by multics＠ruserved.com 26 Sep '00

26 Sep '00

I've been thinking about this and I think the CLECS and ISP's might be benefitted by the passing of this. I think this bill will do more to hurt the ILECS then help them in the long run. One of the things blocking CLECS from offering local dial tone for residential service is the reciprical compensation. The single biggest item contributing to it is internet dialup. As an example of what I mean: AT&T had been heavily advertizing to get people to select AT&T for local dialtone in my area. The ads all say unlimited, but the fine print limits this to 75 hours a month. I would suspect the limit is due to the amount of usage from modem users dialing into the internet. If this bill passes, I suspect AT&T will take advantage of that and ammend their ads to 75 hours, intenet dialup unlimited. Why should someone who spends alot of online hours on the internet even consider AT&T with the 75 hours/month limit? Once this bill passes, any company interested in offering local dialtone wil no longer have to worry about internet connect time causing large reciprical compensation. I suspect AT&T and other CLECS who are providing or interested in providing local dialtone to residential customers are backing this bill. The short term result may be bad for any CLEC depending on the income, but those that are looking to providde local phone service will find this a great benefit and as a result this is more likely to lead to local dialtone competition against the ILEC. Which will lead to lower costs for phone lines ;) As best I can see, the ILECs tend to be the more incompetent competitors and maybe they will finally put themselves out of business with this encouragement to their compitition. If I had the money, I'd start some planning now to put up my own CO's and lay my own copper/fibre/etc for providing local services. -- Richard Shetron multics(a)ruserved.com multics(a)acm.rpi.edu NO UCE What is the Meaning of Life? There is no meaning, It's just a consequence of complex carbon based chemistry; don't worry about it The Super 76, "Free Aspirin and Tender Sympathy", Las Vegas Strip.

6 5