- NANOG - lists.nanog.org

attacking DDOS using BGP communities?
by Saku Ytti 22 Oct '02

22 Oct '02

How feasible would these ideas be? 1) Signaling unwanted traffic. You would set community which would just inform that you are receiving unwanted traffic. This way responsible AS# with statistical netflow could easily automaticly search for these networks and report to NOC if both there is increased traffic to them and community is on. -would it be affective at all? Could your netflow parser use it easily? +wouldn't need big changes 2) 'TTL' community. You would have ~10 communities representing how many AS hops until route should not be advertised anymore. If you would experience DOS you'd start from TTL 1 and increase until DOS flow starts again, with any luck you would end up having very limited amount of AS# to communicate with in hopes of fixing their anti-spoofing filters and to catch malicious party. -just think about the amount of route-maps :> -you would need to flap the network possible 10 times == damped +some idea who to contact w/o co-operation of NOCs (can be hard) +wins you time, often DOS is over before you've reached 3rd AS number to ask where the traffic is originating. 3) 'null route' community. This would only be useful if it would mean that you are also accepting more spesific annoucement, preferally even /32. Most people are propably crying about the idea already, but if you plan it wisely with prefix-limit setting it might not be suicide. Just remember that all downstream prefix-limit+your prefices must be smaller than what your upstream has set for prefix-limit, if this is not done then your downstreams can effectively trigger your upstream prefix-limit killing your connectivity. How AS handles the 'null route' community could vary, others set next-hop to null0 other might set it to analyzer tool. Just that it shouldn't reach the other end anymore. -the obvious: explosion of global bgp routing table (no, not nececcarily) +effective, you'd instantly free your link from any DOS traffic to given destination. -- ++ytti

3 2

Congestion at SBC/AADS NAP?
by John Kristoff 22 Oct '02

22 Oct '02

Has anyone seen what may be ATM level congestion at the Chicago NAP recently? ...or have you seen it in the recent past? We're having trouble pinpointing a problem, which may have been occurring for a long time, but just now really beginning to affect us significantly. We are seeing latency on certain peer sessions go through the roof (often more so in one direction than the other) and cannot (at least not yet) attribute it to hardware/link issues or problems with our edge device. Thanks for any insight, John

1 0

Re: root servers DDoS
by matthew-l＠itconsult.co.uk 21 Oct '02

21 Oct '02

On Tue, 22 Oct 2002, Petri Helenius wrote: > Anyone have insight into the (seemingly) DoS attack on root-servers > which started around 20 UTC and widened to more servers on 20:35 UTC? > > Not that it�s causing any serious operational problems but slows down > things a lot. We have automated monitoring on the root servers and have been seeing exactly the same thing from the UK, from multiple locations, starting from the same time. Best wishes, Matthew

1 0

root servers DDoS
by Petri Helenius 21 Oct '02

21 Oct '02

Anyone have insight into the (seemingly) DoS attack on root-servers which started around 20 UTC and widened to more servers on 20:35 UTC? Not that it´s causing any serious operational problems but slows down things a lot. Pete

5 6

Re: The power of water
by Crist J. Clark 21 Oct '02

21 Oct '02

On Sun, Oct 20, 2002 at 12:22:50 -0400, Howard C. Berkowitz wrote, > 3. Consider putting data centers not in the ground floor on the basement, > but not too high either. Sean, I believe, knows the specific NFPA rule, > but IIRC you can't have a UPS with acid electrolyte above the third floor. > So, you can put a data center on the 2nd floor and both allow the UPS > and have a place for the water to drain. This is not at all my area of expertise, but I'm curious, why does does the UPS need to be on the same floor with the data center racks at all? -- Crist J. Clark | cjclark(a)alum.mit.edu | cjclark(a)jhu.edu http://people.freebsd.org/~cjc/ | cjc(a)freebsd.org

2 1

Re: Input requested for second edition of "Firewalls and Internet Security"
by Sean Donelan 21 Oct '02

21 Oct '02

What are the current thoughts about firewalls and Internet security. The problem is the complexity level of trying to maintain those perimeters, DMZs and firewalls is increasing. Massive firewall complexes with swiss-cheese rules, and huge network perimeters with numerous external access points are very difficult to manage. Although many of the oldest firewall creators have long pointed out the limitations of firewalls, currently practicing security consultants rely mostly on Internet security designs with firewalls, DMZs and defining perimeters. This may be partly because some security consulting firms are also VARs for firewall vendors; but I don't think its that simple. Currently my favorite summary of the issues, and one potential alternate security design is Network Security Credo T. Gray, et al University of Washington http://staff.washington.edu/gray/papers/credo.html What may be more interesting to NANOG is what should be the model Internet security architecture for public network operators? How do you define a security perimeter? Should ISPs install firewalls at every external Internet connection? Is there a different between carrier-grade security and enterprise-grade network security requirements? Is the Orange Book really dead?

3 3

Re: future transit prices
by Paul Vixie 21 Oct '02

21 Oct '02

someone wrote, in response to my piece this morning... > Can you explain more about why you think transit prices will return to > the $200-$300/mbps. I've been quoted $40/mbps on a 50mbps commit > (95th%) ... which I think is pretty much as low as it's going to get. > I can understand prices going back up near $100/mbps over time, but > >$200 is much more than I'm expecting. the way i think about this is that somebody has to carry the traffic to wherever it's got to go. with a "top tier" of huge networks, the pricing model gets smoother in two ways: (1) the distance insensitivity in sales has a larger set of costs to average against; and (2) cost per bit-kilom goes down as pipe size goes up. however, the cost per bit per second of switching these is relatively constant over time (people, rent, depreciation or lease of equipment). a non-top tier provider who wants to get into the game will not be able to make money at market prices until they fill their network to a certain crossover point. (and if you buy your pipes too small you can't get there at all, and if you buy them too large then you can never fill the whole thing.) a lot of networks, both top-tier and non-top-tier, have been selling transit without being able to determine their costs other than at a very gross level. the thought seems to have been, we have to charge what the market will bear, and hope we're the last ones standing. but i think we, as an industry, have pretty much burned all the cash we'll be able to burn in that way. when i look at the ingredients: worldwide presence (peering points, pops, whatever) worldwide L1/L2 costs between pops staff (engineering, operations, management, sales, marketing, etc) capital (for all those pops) rent (of things that aren't pops, like HQ offices) marketing, legal, travel, other goo and so on it looks to me like you could run an OC48 backbone at 60% capacity and make a sustained single digit NPM selling at $250/Mbit average, or you could do an OC192 backbone at 60% capacity and single digit margins at maybe $175/Mbit. perhaps an OC768 backbone running at 60% will be able to make single digit NPM at $100/Mbit, but i'm really reaching on that one. doing it for less involves either (a) not knowing your costs yet, or (b) buying market share, or (c) cost containment strategies like using assets that have been recently through the cleansing ritual of bankruptcy, or (d) selling ahead of usage like getting 100Mbit/sec commits from a lot of 20Mbit/sec customers. none of those things lasts forever. > Regardless of which of us is right, I guess I'm still pretty safe if I > lock in todays rates for multiple years. oh yeah, oh yeah, oh yeah.

4 3

Re: Input requested for second edition of "Firewalls and Internet Security"
by martin＠atsec.com 21 Oct '02

21 Oct '02

Sean Donelan <sean(a)donelan.com> schrieb am Sun, 20 Oct 2002 17:13:54 -0400 (EDT): > > What are the current thoughts about firewalls and Internet security. Re. firewalls, i.e. perimeter security: Most of our enterprise customers have problems defining what their perimeter actually is. Some of them do not have a perimeter any more, in the classical physical sense; wireless applications - not just WLAN, but also the fact that everybody here has a mobile phone and thus a potential 64k+ connection out of the soft core - have made perimeter a very fuzzy concept. Thus, perimeter security - firewalls - is a necessary part of the whole, but falls perilously short of being an overall security solution. For network operators, I believe it easier to define what your perimeter is. One problem is that it is so big and so difficult to control; the other is, once you have it, what does this actually mean? As a carrier, - you have your own security needs / policies - each of your customers has security needs / policies and these do not necessarily overlap fully, so knowing your own perimeter may not be so useful in finding a security solution. Some carriers I know have started completely "virtualizing" their networks (using MPLS or whatever) to offer each customer their own security domain. For customer, read large customers, or a set of customers with a similar set of security requirements, e.g. dialup users. Then you would need a perimeter control device (firewall) only where security domains intersect. This could be one way to go, though it (I believe) does not scale well. Another way could be to fall back to host security completely, and when in doubt treat any network as hostile. I see some aggressively growing companies doing this, because with a flurry of international investments and disinvestments, they have long last lost any sense of what is internal and external. This is obviously time-consuming in systems administration, and could possibly lead to a recurrence of phenomena like the Internet worm in the old times (i.e. one single vulnerability opens up 10e6 victims immediately, something firewalls were supposed to cure back then). So, personally I am just as confused as 10 years ago, just on a much higher level :-) Just my 2 (euro)cents, Martin -- atsec information security, http://www.atsec.com

1 0

Bogon network search tool
by Pascal Gloor 19 Oct '02

19 Oct '02

Hi all, I've made some tools which may be interesting for some of you. the facts: I'm running the SwiNOG/FRnOG RouteServer and I maintain a database with those routes AND the oregon-ix routes in it. that's almost over 6'000'000 routes ;-) now to the tool, based on RFC1918, IANA IPv4 Assignements, Rob Thomas (thanks Rob) and on weird netmasks (0-7 and 30-32) I fetch those routes out of my DB every 2 hours and put them in another DB which is 'searchable'. I keep 30 days datas. go and have a look: http://zebra.swinog.ch/wwwbin/bogonet (SwiNOG web) or http://mogwai.frnog.org/wwwbin/bogonet (FRnOG web) As it's still in beta, I would appreciate feedback with comments/ideas/flames/chocolate/$$$ ... ;p regards, Pascal

1 0

Juniper and Foundry l2/l3 core plus mpls
by jack ardent 18 Oct '02

18 Oct '02

Greetings Nanog, My company is currently evaluating both Foundry (netiron line) and Juniper (m160 and t320) devices to use in a high speed l2/l3 core with l2 mpls. Core speeds will start at oc48 (ospf and fully meshed ibgp core, full internet routes, peering, customer routes, etc) but needs to scale to oc192. Dense Gige is also a requirement. I of course have both companies data and testimonials but thought I would go to some actual network operators to get opinions on one or the other as a preference. I have heard some negative things about one of the above vendors ability to handle a lot of routes in less than stable conditions, bad optics, mpls was also brought into question as an issue. Much appreciated. --------------------------------- Do you Yahoo!? Faith Hill - Exclusive Performances, Videos, & more faith.yahoo.com

2 1