March 2003 - Test - lists.nanog.org

Re: [Re: 69/8...this sucks -- Centralizing filtering..]
by Joshua Smith 10 Mar '03

10 Mar '03

interesting idea, enable it by default, with the option to turn it off (i hope)... my-big-fat-router# conf t my-big-fat-router(config)# no ip clueless Joe Abley <jabley(a)isc.org> wrote: > > > On Monday, Mar 10, 2003, at 10:54 Canada/Eastern, Haesu wrote: > > >> Since most service providers should be thinking about a sink hole > >> network > >> for security auditing (and backscatter), why not have ONE place > >> where you > >> advertise all unreachable, or better yet -- a default (ie everything > >> NOT > >> learned through BGP peers), and just forward the packets to a bit > >> bucket.. > >> Which is better than an access list since, now we are forwarding > >> packets > >> instead of sending them to a CPU to increase router load. > >> > >> I don't think ARIN can help the situation. ISPs just need to remove > >> the > >> access lists from each router in the network and centralize them. > > > > I totally agree with you. However, as always, centralized systems, > > while > > ease management and scalability, everything becomes a trust issue and a > > single point of failure or source of problems... > > I can think of two organisations which could probably take care of a > good chunk of the problem, if people were prepared to leave it up to > them. The routing system is already largely dependent on the > interoperability of bugs produced by these people, and so arguably no > additional trust would be required. > > One organisation has a name starting with "j", and the other starts > with "c". > > > Joe > "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

RE: 69/8...this sucks -- Centralizing filtering..
by Mark Segal 10 Mar '03

10 Mar '03

> -----Original Message----- > From: Haesu [mailto:haesu@towardex.com] > > I totally agree with you. However, as always, centralized > systems, while ease management and scalability, everything > becomes a trust issue and a single point of failure or source > of problems... Single point of failure? Not sure I agree with you.. What happens if your sink hole disapears? Your filtering goes out.. O no.. Please not that. Hardley think that is even a reason for a noc to page you... :). Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570

2 1

RE: 69/8...this sucks -- Centralizing filtering..
by Mark Segal 10 Mar '03

10 Mar '03

> From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] > > The problem with only a default: Think when a rogue ISP > decides to advertise an unused netblock and utilize that IP > space for malicious purposes. A route exists... do we trust it? But that kinda filtering should be done at BGP route ingress by, you, or the transit provider of choice. I'm not suggesting that a default is the only way. It just happens to be a good lazy way for the people who can't seem to find the time to check the IANA web page at least once a quarter.. :). Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570

1 0

RE: Abstract of proposed Internet Draft for Best Current Practic e (please comment)
by Dr. Jeffrey Race 10 Mar '03

10 Mar '03

On Mon, 10 Mar 2003 09:11:31 -0500, Cutler, James R wrote: >Implies that a simple "j'accuse" is enough to create a denial of service. I >prefer the US to Napoleonic codes, where an accusation is insufficient to >prove guilt. Please read the details in the text. It is all spelt out there. Jeffrey Race

3 2

Re: Building Cited for Housing Fuel Tanks Catches Fire [NYT]
by Michael.Dillon＠radianz.com 10 Mar '03

10 Mar '03

> > An electrical fire broke out in the basement of an office tower > > in TriBeCa yesterday, four months after building inspectors said > > they had discovered illegal diesel fuel tanks installed on the > > upper floors of the tower. > basement. roof. what is it i am not getting here? osama bin > elevator? the ratcheting (rat sh<bleep>ing?) up of the american > press hysteria? Diesel fuel from a leaky roof tank will eventually drip down to the basement. Heat from a basement fire will eventually rise up to the roof and cause diesel fuel tanks to explode. In any case, this problem should be solved by the city government in a large city. It is a fact that large cities are large telecomm hubs. It is a fact that large telecomm hubs need guaranteed power supplies. It is a fact that the individual players in telecomm want to be located near each other in large cities (same building, same block). The solution to this whole mess is for the city government to run a special power utility that operates a pair of safe and highly secure diesel power generating plants which provide dual entrance service to telecomm hotels in a specific area of the city. That way folks can install equipment with no batteries and no generators because they are getting triply redundant and diverse power (utility, and 2 city diesel generation plants). We eliminate the dangers of hydrogen fumes and exploding batteries and flammable diesel. BTW, has anyone done any studies of heat generation in routers and switches to identify which bits of the hardware generate the most heat (i.e. consume the most power) and which functions generate the most heat? Maybe there are opportunities for dramatically reducing power consumption by changing the way we configure our networks. --Michael Dillon

3 2

Re: 69/8...this sucks
by Michael.Dillon＠radianz.com 10 Mar '03

10 Mar '03

> According to ARIN's whois server, there are 95 subdelegations for > NET-69-0-0-0-0...we're the 95th. Clearly this problem is going to get a lot worse before it gets better. And since most network operators are not on NANOG or USENET or any other mailing list, there are really only two means of contact. Either every affected party probes the net, identifies misconfigured networks and contacts them one by one using email, phone and letters. Or we use the press to make the problem and solution widely visible. In either case, I think it would be a mistake to just fix the immediate problem of a few ISPs needed full reachability from 69/8 space. Since we have to put the effort into this problem, let's try to fix the general problem, not just a small part of it. The general problem is that ever large numbers of devices are getting IPv4 address ranges hard-coded into their configurations with no process in place for reviewing and changing those configurations. These devices are not just routers but also firewalls and application servers. In order to solve the general problem we need to make it easy for people to review and change their configurations. This is not a lot different from the problems that DNS solved. When you configure a device with a domain name, the device will dynamically review and update the IP address that it uses for communication. No human intervention is necessary. Essentially, what we need is something that provides a capability similar to DNS except that it works for IP address ranges, not for individual IP addresses. This is where ARIN comes in. Because ARIN has the top-level authority for IP address ranges in North America, they are the *ONLY* organization that can authoritatively identify who an IP address range is delegated to. I have suggested that ARIN should set up an LDAP server to publish the delegation of all their IP address space updated on a daily basis. And that organizations which sub-delegate space, i.e. ISPs, should also run LDAP servers as part of a delegation hierarchy similar to DNS. This type of referral LDAP is part of the IETF standard and has been implemented by most LDAP software vendors. Because LDAP is a widespread technology that is used in the enterprise for identification and authentication, there is a high likelihood that the suppliers of firewalls and application servers will build in support for querying the ARIN delegation hierarchy. > I realize ARIN can't guarantee global routability of IP space, but should > they continue to give out IP blocks they absolutely know are not fully > routable on the internet today? ISPs make addresses routable. ARIN is not an ISP. ARIN members are ISPs. ARIN does not compete with its members. Therefore, ARIN should focus on the problem of how to publish authoritative data about which IP addresses should be routable. The appropriate technology combined with the appropriate publicity will create demand from enterprise network admins which will drive all ISPs and device vendors to fix the problem. If anyone wants to discuss this further, then I suggest that the upcoming ARIN meeting in Memphis is the ideal venue to do so. --Michael Dillon

2 1

RE: 923 Mbps across the Ocean ...
by Pete Templin 10 Mar '03

10 Mar '03

-----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com] Sent: Friday, March 07, 2003 3:58 PM To: David G. Andersen Cc: Mikael Abrahamsson; nanog(a)nanog.org Subject: Re: 923 Mbps across the Ocean ... BTW, when I did VLBI for the Navy, we used to move literally tons of tapes around the world per month and achieved sustained bandwidths > 1 Gbps, albeit with FED-EX, not routers. Does this take into account the delay from encapsulating the tapes into a FED-EX packet and assigning the appropriate layer 1 header, then the queueing delays experienced while awaiting an open buffer on the next FED-EX truck? Pete Templin IP Network Engineer TexLink Communications (210) 892-4183 pete.templin(a)texlink.com

2 1

RE: Abstract of proposed Internet Draft for Best Current Practic e (please comment)
by Cutler, James R 10 Mar '03

10 Mar '03

"Well-managed.......profitably....." leaves out a lot of companies. Also >>is there a forthcoming section on criterium for demonstrating >>reformation by the sp and/or 'offending' user? > >The criterion is stated: no more complaints Implies that a simple "j'accuse" is enough to create a denial of service. I prefer the US to Napoleonic codes, where an accusation is insufficient to prove guilt. - James R. Cutler, EDS 800 Tower Drive, Troy, MI 48098 248-265-7514 james.cutler(a)eds.com -----Original Message----- From: Peter Galbavy [mailto:peter.galbavy@knowtion.net] Sent: Friday, March 07, 2003 9:06 AM To: Dr. Jeffrey Race Cc: nanog(a)merit.edu Subject: Re: Abstract of proposed Internet Draft for Best Current Practice (please comment) quote: > Well-managed, ethical members of the internet industry already conduct > their businesses, successfully and profitably, according to the > principles specified in the Practice. The proposed Practice simply > aims to raise the entire industry to the level of today's best > players. I object to this wording; even without reading *any* other part of your document, I am already very cautious about it's contents simply because of the implication of your statement above. This is very much one of those political "you're either with us or against us" declarations. So - if you don't so it 'our way' then you must be unethical and badly-managed. At least. Peter

1 0

UK ISPs not cooperating with law enforcement
by Sean Donelan 10 Mar '03

10 Mar '03

It difficult to tell from the article whether UK ISPs are refusing to cooperate with lawful requests from UK police, or if UK police are trying to get ISPs to give information without proper authorization. http://www.computerweekly.com/articles/article.asp?liArticleID=119873

8 8

Re: 923Mbits/s across the ocean
by Cottrell, Les 10 Mar '03

10 Mar '03

I am not normally on this list but someone kindly gave me copies of some of the email concerning the Internet2 Land Speed record. So I have joined the list. As one of the PIs of the record, I thought it might be useful to comment on a few interesting items I have seen, and no I am not trying to flame anybody: "Give em a million dollars, plus fiber from here to anywhere and let me muck with the TCP algorith, and I can move a GigE worth of traffic too - Dave" You are modest in your budgetary request. Just the Cisco router (GSR 12406) we had on free loan listed at close to a million dollars, and the OC192 links just from Sunnyvale to Chicago would have cost what was left of the million/per month. We used a stock TCP (Linux kernel TCP). We did however, use jumbo frames (9000Byte MTUs). In response Richard A Steenbergen we are not "now living in a tropical foreign country, with lots and lots of drugs and women" but then the weather in California is great today. "What am I missing here, theres OC48=2.4Gb, OC192=10Gb ..." We were running host to host (end-to-end) with a single stream with common off the shelf equipment, there are not too many (I think none) > 1GE host NICs available today that are in production (e.g. without signing a non-disclosure agreement). "Production commercial networks ... Blow away these speeds on a regular basis". See the above remark about end-to-end application to application, single stream. "So, you turn down/off all the parts of TCP that allow you to share bandwidth ..." We did not mess with the TCP stack, it was stock off the shelf. "... Mention that "Internet speed records" are measured in terabit-meters/sec." You are correct, this is important, but reporters want a sound bite and typically only focus on one thing at a time. I will make sure next time I talk to a reporter to emphasize this. Maybe we can get some mileage out of Petabmps (Peta bit metres per second) sounds "What kind of production environment needs a single TCP stream of data at 1Gbits/s over a 150ms latency link?" Today High Energy Particle Physics needs hundreds of Megabits/s between California and Europe (Lyon, Padova and Oxford) to deliver data on a timely basis form an experiment site at SLAC to regional computer sites in Europe. Today on production acadmeic networks (with sustainable rates of 100 to a few hundred Mbits/s) it takes about a day to transmit just over a Tbyte of data which just about keeps up with the data rates. The data generation rates are doubling / year so within 1-3 years we will be needing speeds like in the record on a production basis. We needed to ensure we can achieve the needed rates, and whether we can do it with off the shelf hardware, how the hosts and OS' need configuring, how to tune the TCP stack or how newer stacks perform, what are the requirements for jumbo frames etc. Besides High Energy Physics other sciences are beginning to grapple with how to repliacte large databases across the globe, such sciences include radio-astronmoy, human genome, global weather, seismic ... The spud gun is interesting, given the distances, probably a 747 freightliner packed with DST tapes or disks is a better idea. Assuming we fill the 747 with say 50 Gbps tapes (disks would probably be better), then if it takes 10 hours to fly from San Francisco (BTW Sunnyvale is near San Francisco not near LA as one person talking about retiring to better weather might lead one to believe) the bandwidth is about 2-4 Tbits/s. However, this ignores the reality of labelling, writing the tapes, removing from silo robot, pocaking, getting to airport, loading, unloading, getting through customs etc. In reality the latency is really closer to 2 weeks. Even worse if there is an error (heads not aligned etc.) then the the retry latency is long and the effort involved considerable. Also the network solution lends itself much better to automation, in our case we saved a couple of full time equivalent people at the sending site to distribute the data on a regular basis to our collaborator sites in France, UK and Italy. The remarks about window size and buffer are interesting also. It is true large windows are needed. To approach 1Gbits/s we require 40MByte windows. If this is going to be a problem, then we need to raise question like this soon and figure out how to address (add more memory, use other protocols etc.). In practice to approcah 2.5Gbits/s requires 120MByte windows. I am quite happy to concede that this does not need to be about some jocks beating a record. I do think it is important to catch the public's attention to why high speeds are important, that they are achievable today application to application (it would also be useful to estimate when such speeds are available to universities, large companies, small companies, the home etc.), and for techies it is important to start to understand the challenges the high speeds raise, e.g. cpu and router memories, bugs in TCP, OS, application etc., new TCP stacks, new (possibly UDP based) protocols such as tsunami, need for 64 bit counters in monitoring, effects of the NIC card, jumbo requirements etc., and what is needed to address them. Also to try and put it in meaningful terms (such as 2 full length DVD movies in a minute, that could also increase the "cease and desist" legal messages shipped ;-)) is important. Hope that helps, and thanks to you guys in the NANOG for providing todays high speed networks.

6 6