- Test - lists.nanog.org

AMS-IX problems
by Iljitsch van Beijnum 23 Oct '02

23 Oct '02

There seem to be large scale problems at the AMS-IX. BGP sessions with peers keep oscillating. Since their own addresses keep jumping all over the place, it is not possible to reach anyone over the AMS-IX tech list. I have disabled all AMS-IX peerings for the networks I manage, and I suggest everyone who is present there looks in to doing the same. Iljitsch van Beijnum

5 6

Fwd: IETF Call for Nominations
by RJ Atkinson 22 Oct '02

22 Oct '02

Operators who are involved in IETF should consider providing input (good/bad/other) to the IETF Nomcom -- since that is the best way to affect the future makeup of the IESG and IAB. Details below. Cheers, Ran Begin forwarded message: > From: Phil Roberts <PRoberts(a)MEGISTO.com> > Date: Mon Oct 21, 2002 16:54:44 America/Montreal > To: all-ietf(a)ietf.org > Subject: Call for Nominations > Message-Id: <200210212054.QAA15190(a)ietf.org> > > The 2002-2003 Nominations Committee is now > soliciting nominations for the open > slots on the IESG and IAB. > > Please take the time, even if it is > only a few moments, to send us your > thoughts. > > Members of the community are encouraged to > nominate candidates for any of the positions > which are up for re-filling: > > IESG Terms ending in March, 2003: > Harald Alvestrand IETF Chair > Scott Bradner Transport > Randy Bush Operations & Management > Patrik Faltstrom Applications > Thomas Narten Internet > Bill Fenner Routing > Jeff Schiller Security > > IAB Terms ending in March, 2003: > Ran Atkinson > Rob Austein > Fred Baker > Steve Deering > Sally Floyd > Geoff Huston > > Members of the community are encouraged to contact the nomcom > confidentially > 1) to nominate someone for any of these positions (please provide the > email > address of any nominee), > 2) to provide input relating to potential candidates, or > 3) to provide comments regarding the past performance of incumbents. > All of this information will be considered during the deliberations of > the nominating committee and will be held in confidence by the > nominating > committee. > > We emphasize that comments sent to the nominations committee will be > kept > in confidence. As noted in RFC 2727 "all deliberations and supporting > information that relates to specific nominees, candidates, and > confirmed > candidates are confidential." > > Self-nominations are accepted. The deadline for nominations is midnight > Friday, November 22, 2002. Early input is desirable so that candidates > may be interviewed during the Atlanta IETF meeting. > > The members of the NomCom can be contacted individually at the > addresses > below or collectively at nomcom(a)ietf.org <mailto:nomcom@ietf.org>. > Additionally, the members of > the NomCom will be identified at the IETF by a small orange dot > on their name tags. People are encouraged to take advantage of the > opportunity to talk to the members of the NomCom about nominations > and other issues related to the IAB and IESG membership. > > The 2002-2003 Nominations Committee > Edward Lewis <edlewis(a)arin.net <mailto:edlewis@arin.net>> > Alec Brusilovsky <abrusilovsky(a)lucent.com > <mailto:abrusilovsky@lucent.com>> > Michael Richardson <mcr(a)sandelman.ca <mailto:mcr@sandelman.ca>> > Eva Jonsson <eva.jonsson(a)utfors.se <mailto:eva.jonsson@utfors.se>> > Stephen Trowbridge <sjtrowbridge(a)lucent.com > <mailto:sjtrowbridge@lucent.com>> > Frank Alfano <falfano(a)lucent.com <mailto:falfano@lucent.com>> > Thomas Kurien <kurien(a)lucent.com <mailto:kurien@lucent.com>> > Dennis Beard <beardd(a)nortelnetworks.com > <mailto:beardd@nortelnetworks.com>> > Richard Draves <richdr(a)microsoft.com <mailto:richdr@microsoft.com>> > Eva Gustafsson <eva.gustafsson(a)ericsson.com > <mailto:eva.gustafsson@ericsson.com>> > > Non-voting members: > Phil Roberts <proberts(a)megito.com <mailto:proberts@megito.com>> (chair) > Allison Mankin <mankin(a)psg.com <mailto:mankin@psg.com>> (IESG liaison) > Eric Rescorla <ekr(a)rtfm.com <mailto:ekr@rtfm.com>> (IAB liaison) > Theodore Ts'o <tytso(a)mit.edu <mailto:tytso@mit.edu>> (previous nomcom > chair) > > The role of non-voting members (from RFC 2727): > > "The nominations committee comprises at least a non-voting Chair, > 10 voting volunteers, and 3 non-voting liaisons. The sitting IAB > and IESG members each appoint a non-voting liaison to the nominating > committee from their current membership who are not sitting in an > open position. The Chair of the prior year's nominating committee > also serves as a non-voting liaison.

2 1

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