- Test - lists.nanog.org

Re: RADB & RRs
by rs＠seastrom.com 16 May '02

16 May '02

Ralph Doncaster <ralph(a)istop.com> writes: > I've been registering my routes in ARIN's RR, only to find that nobody > uses it. ;-( > Do any of the RRs mirrored by the RADB offer free maintainer-IDs? www.altdb.net / db-admin(a)altdb.net / auto-dbm(a)altdb.net the usual drill. ---Rob

1 0

RADB & RRs
by Ralph Doncaster 16 May '02

16 May '02

I've been registering my routes in ARIN's RR, only to find that nobody uses it. ;-( Do any of the RRs mirrored by the RADB offer free maintainer-IDs? Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.

2 1

CPE/OC12 Question
by Sonya Blake 16 May '02

16 May '02

What kind of OC12 CPE devices (routers) are people using out there? Initially for Internet connectivity, but probably would need to do advance features, i.e. BGP, etc. Thanks in advance! Sonya Blake Engineer BellSouth.net sblake(a)arch.bellsouth.net

3 2

Arbor Networks DoS defense product
by Sean Donelan 16 May '02

16 May '02

Telus has gone first, and announced it is using Arbor's products across its backbone network. http://www.eweek.com/article/0,3658,s=720&a=26867,00.asp People have been trying the products for a while. Does Arbor Networks really have an answer to DoS, or does it still need a little longer in the oven.

8 14

Re: Arbor Networks DoS defense product
by Clayton Fiske 16 May '02

16 May '02

On Wed, May 15, 2002 at 06:04:40PM -0700, PJ wrote: > Sorry for not including nanog in the reply. What about MAPS? They > routinely scan netblocks without consent. Does this tool > differenciate between local and non-local scanning? Scanning is The tool in question may not even exist yet. There is no preset definition of how it has to work. Perhaps it can be evolved enough to where it only triggers when an exploit is attempted, rather than just on a TCP connection. > still not a crime and it will still do nothing to deter anyone with > hostile intentions. This is just a bandaid to avoid taking proper > security precautions. I can take all the proper security precautions and it doesn't stop third party network A from being exploited and later used to attack me. The point of this is that it will help identify a specific host which is scanning many blocks belonging to many different networks. If they hit several landmines in my network, I might be concerned. If they hit landmines in my network and 6 others to which I have no affiliation, the net as a whole might want to know about it. I don't think anyone said this was intended to take the place of security on their own networks. But I don't see how that aspect makes this a bad tool on its own either way. -c

3 3

(fwd) Re: Arbor Networks DoS defense product
by PJ 16 May '02

16 May '02

Forgot to include nanog ----- Forwarded message from PJ <briareos(a)otherlands.net> ----- > Date: Wed, 15 May 2002 17:50:01 -0700 > From: PJ <briareos(a)otherlands.net> > Subject: Re: Arbor Networks DoS defense product > To: Clayton Fiske <clay(a)bloomcounty.org> > Message-ID: <20020516005001.GB2107(a)elvander.otherlands.net> > Reply-To: PJ <briareos(a)otherlands.net> > User-Agent: Mutt/1.3.25i > > On Wed, 15 May 2002, Clayton Fiske wrote: > > > > > On Wed, May 15, 2002 at 05:22:39PM -0700, PJ wrote: > > > Are you now operating under the premise that scans != anything but the > > > prelude to an attack? Sorry if I missed it earlier in the thread, but > > > I would hate to think any legitimate scanning of a network or host > > > would result in a false positive. Even more, I would hate to see the > > > advocation of a hostile reaction to what, so far, is not considered a > > > crime. > > > > So you can think of a perfectly legitimate reason to scan someone else's > > netblocks on specific TCP ports? > > > > -c > > > > > > Has no one ever tested firewall rules from external networks? The > fact remains is that a scan != an attack. > > PJ > > -- > The worst thing one can do is not to try, to be aware of what one > wants and not give in to it, to spend years in silent hurt wondering > if something could have materialized -- and never knowing. > -- David Viscott

1 0

Re: Arbor Networks DoS defense product
by Dan Hollis 15 May '02

15 May '02

On Wed, 15 May 2002, Chris Parker wrote: > That's fine until the first person spoofs a scan from 'www.cisco.com' > or 'a.root-servers.net' and *poof* it's now automagically unreachable. Only tcp connections with full handshake would be counted. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

1 0

Re: Arbor Networks DoS defense product
by Dan Hollis 15 May '02

15 May '02

On 15 May 2002, Johannes B. Ullrich wrote: > See http://www.dshield.org/block.txt ;-). We are about 24hrs away from > getting a BGP test feed up. Error Sorry, the page could not be found. Click HERE to return to the DShield.org homepage. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

2 1

The Art of Peering : The Peering Playbook
by William B. Norton 15 May '02

15 May '02

Hi all - Folks were talking about Traffic Ratios, Depeering, etc. that reminded me I should probably thank everyone for contributing to the "Tactical Peering" white paper which has now been renamed "The Art of Peering : The Peering Playbook". Thanks to the feedback from folks on this list and at RIPE and the Gigabit Peering Forum I have released version 1.0 of this document and it is available to anyone who would like a copy. Send me e-mail at wbn(a)equinix.com with the Subject: Art of Peering and I'll send it back directly, or alternatively you can get it from the Equinix web site. In this paper I asked the Peering Coordinators the question "What do you do if noone answers your peering request at peering@<ispdomain>.net ? What are the 'Tricks of the Trade' that distinguish seasoned Peering Coordinators from newbies?" The Summary (below) does the best job of highlighting the techniques detailed in the paper: Summary We have presented 19 peering maneuvers that the Peering Coordinator Community have effectively used to obtain peering. 1) The Direct Approach uses peering@<ispdomain>.net , phone calls, face to face meetings, or some such direct interaction to establish peering. 2) The Transit with Peering Migration tactic leverages an internal advocate to buy transit with a contractual migration to peering at a later time. 3) The End Run Tactic minimizes the need for transit by enticing a direct relationship with the target ISP's largest traffic volume customers. 4) In Europe the Dual Transit/Peering separates the peering traffic from the transit traffic using separate interface cards and/or routers. 5) Purchasing Transit Only from Large Tier 2 ISPs is an approach to reduce the risk of being a customer of a potential peer on the road to Tier 1 status. 6) Paid Peering as a maneuver is positioned by some as a stepping stone to peering for those who don't immediately meet the peering prerequisites. 7) In the Partial Transit tactic, the routes learned at an exchange point are exchanged with the peer for a price slightly higher than transport costs. 8) The Chicken tactic involves de-peering in order to make the other peer adjust the peering relationship. 9) In the Traffic Manipulation tactic, ISPs or content players force traffic along the network path that makes peering appear more cost effective. 10) The Bluff maneuver is simply overstating future traffic volumes or performance issues to make peering appear more attractive. 11) The Wide Scale Open Peering Policy as a tactic signals to the Peering Coordinator Community the willingness to peer and therefore increases the likelihood of being contacted for peering by other ISPs. 12) The Massive Colo Build tactic seeks to meet the collocation prerequisites of as many ISPs as possible by building POPs into as many exchange points as possible. 13) The Aggressive Traffic Buildup tactic increases the traffic volume by large scale market and therefore traffic capture to make peering more attractive. 14) Friendship-based Peering leverages contacts in the industry to speed along and obtain peering where the process may not be in place for a peering. 15) The Spam Peering Requests tactic is a specific case of the Wide Scale Open Peering tactic using the exchange point contact lists to initiate peering. 16) Purchasing Legacy Peering provides an immediate set of peering partners. 17) The Bait and Switch tactic leverages a large corporate identity to obtain peering even though ultimately only a small subset or unrelated set of routes are actually announced. 18) The False Peering Outage tactic involves deceiving an ill-equipped NOC into believing a non-existing peering session is down. 19) The Leverage Broader Business Arrangement takes advantage of other aspects of the relationship between two companies to obtain peering in exchange for something else. Thanks again for your help! If there are questions or comments I'd love to hear them; I fully expect this document (like the other white papers) to evolve over time. Bill --------------------------------------------------------------------------------------------------------------- William B. Norton <wbn(a)equinix.com> 650.315.8635 Co-Founder and Chief Technical Liaison Equinix, Inc.

1 0

RE: Arbor Networks DoS defense product
by Cheung, Rick 15 May '02

15 May '02

Is it common practice to place your own equipment at the ISP? My thought is that if we are able to have our own routers at the ISP, we'd be in a better position to mitigate the effects of a DDOS. As long as the stream of traffic does not adversely affect our routers from performing properly at the ISP, we can then mitigate the effects through access-lists, QOS, etc. That is if the attack is not too distributed, where the source IPs with the highest amount of syn traffic for example can be easily identified. Rick Cheung NPI IT Wan Team, CCNP -----Original Message----- From: Pete Kruckenberg [mailto:pete@kruckenberg.com] Sent: Wednesday, May 15, 2002 2:15 AM To: nanog(a)merit.edu Subject: Re: Arbor Networks DoS defense product On Wed, 15 May 2002, Rubens Kuhl Jr. wrote: > If and when > (a) customers don't get exemption for attack traffic > (b) the DoS traffic occurs more than 5% (or 1 - your percentile level) of > the month per customer circuit > (c) the DoS increases bytes transferred like large ICMP packet flood; this > is not the case for all DoS traffic, which can be a bunch of small packets > that actually decreases traffic These might apply to noticeable DoS attacks that occur as specific events. But how much (D)DoS traffic goes unnoticed by the average customer because it's too tough to detect or defend against? The 10% I've measured on my network is primarily reflected DDoS (reflected off my customers, to off-net targets), which is not trivial to detect or defend against. Pete.

1 0