April 2003 - Test - lists.nanog.org

Trends in network operator security
by Sean Donelan 30 Dec '03

30 Dec '03

Its 2003 and everyone is making their predictions. What trends are network operators seeing for Internet security? Old favorites Buffer overflows Distributed Denial of Service Poor passwords (cisco/sanfran) Poorly coded systems Blame the user for not protecting poorly coded systems Trends Attack the network (why? because we can) Proxy relay hiding (its not just for SMTP anymore) Combo Bot/Trojan/Worms Embedded software "upgrades" Any other trends network operators are seeing?

2 2

AT&T NYC
by Bryan Heitman 04 Sep '03

04 Sep '03

Anyone seeing any problems with ATT in new york? Best regards, Bryan Heitman Interland, Inc.

10 11

chep snmp temperature sensors
by Alex Rubenstein 25 Jun '03

25 Jun '03

I've searched the archives, and didn't see anything current. I am looking for a small, cheap, simply device, that can measure temp and be polled via SNMP. POE would be a plus. Any pointers? -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

8 8

Usage of ISP Proxys and DNS resolvers
by Maximillian Dornseif 25 May '03

25 May '03

I like to get an estimate if the percentage of users 1. Using their Providers HTTP-Proxy to surf the web 2. Using their Providers DNS-Servers/recursive resolvers to resolve DNS queries Background: I'm writing a research paper on government mandated web filtering in germany (see http://www.politechbot.com/p-03983.html for an overview on the matter). Basically the government want's censorship done by blocking IP-Addresses, faking DNS entries or doing filtering at http-proxy level. Trying to determine the effect of this approaches on the average user it is important to know how many users would be affected by this measures. I guess: * Users with leased lines usually do not use the providers proxy * Dial-in/DSL users with use a provider supplied setup-tool usually don't change the preset staying with using the Proxy. * Big Customers with many users might run their own DNS resolver * Most other users use their ISPs DNS resolver I would be most grateful if someone could provide me with actual numbers on this or at least an educated guess. If you think there is a better place to look for this numbers I would be most grateful if you point me there. If you wish reply directly to me - I will post a summary. Best Regards Max Dornseif -- Maximillian Dornseif - http://md.hudora.de/ - ars longa, vita brevis! Dipl. Jur., Ph.D. Candidate (Computercrime) at the University of Bonn Lawschool, Germany

3 3

Using Policy Routing to stop DoS attacks
by Christian Liendo 12 May '03

12 May '03

Looking for advice. I am sorry if this was discussed before, but I cannot seem to find this. I want to use source routing as a way to stop a DoS rather than use access-lists. In other words, lets say I know the source IP (range of IPs) of an attack and they do not change. If the destination stays the same I can easily null route the destination, but what if the destination constantly changes. So I have to work based on the source IP. Depending on the router and the code, if I implement an access-list then the CPU utilization shoots through the roof. What I would like to try and do is use source routing to route that traffic to null. I figured it would be easier on the router than an access-list. Has anyone else tried this successfully on ciscos and junipers? Is it easier on the CPU than access-lists? Is there a link I cannot find on cisco or google? Thanks Christian Liendo

8 12

Market-based address allocation
by Bill Nickless 12 May '03

12 May '03

As a thought experiment, think of how the IPv4 addressing situation (bogon advertisements, allocations, explosion of routing table sizes, etc) would be different if the IP community treated IP addresses as a commodity. The value of an IP address is primarily in its uniqueness. Advertising an address to another network says "send me packets if the destination address matches my advertisement." But a set of addresses (an aggregate) also has value. The larger the set of addresses, the greater the value. For example, a /15 should end up being more valuable than a pair of /16s, because routing to addresses in the /15 is cheaper than routing to addresses in both of the /16s. Let's stipulate some economic conditions and see where it leads: - The price of Internet service should be based on more than bandwidth: the customer should also pay a surcharge for the number of prefixes advertised. This would be handled recursively: Tier 3 providers would have to pay for the number of prefixes they advertise to Tier 2 providers. Tier 1 provider peering settlement agreements would include provisions for the number of prefixes carried. - Internet address registries should simply do registration. Just as real estate ownership is registered, so should IP address space. A recurring fee per registration is the traditional way to maintain such registries, whether they be automobiles or parcels of land. Failure to maintain registration would eventually lead to the address block being auctioned. - Internet address blocks should be considered property, subject to existing property rights and practices. Owners of address blocks should be able to sell them or put them up as collateral on a loan. Markets for address blocks should be established and encouraged. How might these conditions help solve the problems of address space exhaustion and the size of the default-free zone routing tables? Some observers have speculated that the IPv4 address space exhaustion crisis has been manufactured to encourage migration to IPv6. This is close to being an "unknowable" or "non-falsifiable" theory, which is to say it's like religious belief or wondering who shot JFK. But clearly today it's impossible to put a monetary value on migration to IPv6 from IPv4. If my existing IPv4 address space had tangible value, I could make a business decision whether to deploy IPv6 and sell my IPv4 address blocks on the open market. In fact, the sale of IPv4 address blocks could help _finance_ my transition to IPv6. I believe I've heard Randy Bush suggest publicly (my paraphrase) that organizations that multi-home create costs for everyone running their networks without a default to an upstream. This is because the benefits accrue to the multi-homed organization, but the costs accrue to the default-free network operators. (Randy, feel free to correct me if I've misunderstood your statement!) A well-understood way to allocate/recover costs is to assign a price to those activities that create those costs. The more directly the price is tied to the costs, the more likely it is that people will behave in such a way that the costs will be covered. For a while, various ISPs refused to route address blocks smaller than the allocations from the registries. This was a good first approximation, but it had several problems: Addresses from the "traditional B space" were less valuable than address blocks from the "traditional C space", because the size of the smallest routable aggregate was different in those two spaces. This had the perverse effect of making smaller aggregates (those out of C space) more attractive than larger aggregates (those out of B space). The size of an organization's address space was directly tied to the ability of the organization to multi-home that address space. The idea seemed to be that larger organizations are more likely to desire multi-homing. There may be an overall correlation to support that idea, but correlation doesn't imply causation. Portable address space is valuable to organizations for reasons other than multi-homing for reliability. The freedom to move between service providers without the pain of renumbering has significant value. It is reasonable for organizations to have to pay some sort of premium for that freedom, since the cost of that freedom is borne by all default-free network operators. Again, if that premium is high enough, in some cases it can provide a compelling financial business case to go to the trouble of renumbering. OK Bill, this is great, but how would we get there from here? Looking at history, there are several ways to attach property rights to things that have formerly been held in common. Whatever process is used, it should be carefully considered to try and avoid unintended consequences. Flag days are probably out; a phased transition plan should be involved. There is a correlation between the amount of IPv4 address space an organization (institution, government, corporation, etc) has allocated and the amount of time they've been active in the Internet community. How strong is that correlation? Hard to say, but it's there. I see that as partial justification for allowing existing IPv4 address space holders to keep their address space through the transition--even if it means they end up with a "windfall" asset. Not every society in the world subscribes to the same concept of property rights and free markets as in the West. That probably argues for some allocation of IPv4 address space on a national basis, so that the local society's mechanism of resource allocations can be leveraged. Some address space should also be allocated in the public interest. But each situation is different and may have different answers. For example: should address space be given for free to primary education institutions? If so, should they be able to sell their allocations and use ISP-supplied aggregatable addresses, with the sale proceeds funding some term of bandwidth service from that ISP? (I would argue in the affirmative, trusting the school boards to do what makes sense in their local situation.) To conclude: I doubt this is going to happen anytime soon, if at all. But I think it makes sense to at least discuss the alternatives--if for no other reason than to understand why we're doing things the way we are. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless(a)mcs.anl.gov

17 44

Class "B" IP BLOCK
by John Immel 03 May '03

03 May '03

Dear Nanog, I have a class "B" IP block of addresses (IP 143.170.0.0 - 143.170.255.255) for sale / lease and two questions for the group: 1) Are there any resources for buying / selling IP address? 2) Is anyone in the group interested in making an offer? I understand ARIN has made it difficult to sell IP addresses. We have fixed this problem by creating a corporation whose only asset is the block of IP addresses. Sincerely, John Immel isp(a)jimmel.com 617-869-8326 _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

14 16

Re: Question about 223/8
by Michael.Dillon＠radianz.com 03 May '03

03 May '03

>The reason I ask is that I was perusing RFC 3330 and noted that it >specifically stated that the basis for the reservation of >223.255.255.0/24 no longer applied and that the block was subject to >future allocation to a RIR. Yet there was an argument about it. The argument was because it wasn't clear what the original basis was for the reservation nor was it clear how things had changed. Imagine you have a device that uses lots of addresses but considers them to be sequential numbers rather than bit patterns. For instance, this device could be configured with a starting number and then dole out sequential numbers to connections based on that starting number. This is how a lot of terminal servers work. Imagine that you give the terminal server a number like 223.255.255.200 as the starting number to assign to dialup connections and that terminal server has a 32 port card installed. Then one day an engineer installs a second 32 port card. The terminal server continues to function just fine until one day when it tries to assign 223.255.255.255 to an incoming call followed by assigning 224.0.0.0 to the next call. Suddenly you have all kinds of wierdness breaking out with mysterious broadcast traffic and multicast traffic coming from the device. But it only happens for short bursts during the busiest times of the day. What the heck is going on!? Could you debug that? Would you want to debug that? Maybe that's why 223.255.255/24 should be forever reserved. --Michael Dillon

3 2

Re: The in-your-face hijacking example, was: Re: Who is announcing bogons?
by Hank Nussbacher 03 May '03

03 May '03

At 06:09 AM 30-04-03 +0000, Christopher L. Morrow wrote: >That may be true, but what does a provider do when they are presented with >written 'authority to use address space' from a customer? Certianly if the >customer provides 'proper' documentation that the ip space is available >for them to route, and that they have authority from the 'owner' to do >this... what is an ISP to do? Aside from route the blocks? A very valid question and one that all too few ISPs handle. How many ISPs have as part of their implementation/provisioning process an item called "check IP address space against IRRs"? I would suggest that written proof of ownership is not enough and that part of the legal framework each ISP has customers complete that it state something to the effect "IP address space and ASNs announced by the customer must be properly registered in one of the online IRRs such as ARIN, RADB, APNIC or RIPE and must reflect the name of the organization placing the request." -Hank

16 20

Re: Who is announcing bogons?
by Paul Vixie 01 May '03

01 May '03

> > the fun part is watching the bgp announce/withdraws in unallocated space. > > (no matter what microsoft may have learned from their survey, most isp's > > don't seem to care which prefixes their bgp-speaking customers advertise.) > > So which ISPs are confused? Bogon's don't spontaneously occur in BGP. > Some ASN must originate them, and ASNs must pass them to other ASNs. > BGP helpfully includes the ASNs in the path. geoff huston is the only person i know who's making formal progress on that question. i know from some zebra log files that iana's unallocated space gets advertised from time to time, then withdrawn. presumably an attack was launched during the announcement but i don't have any data showing this. > What should be done about ASNs which repeatedly announce false or > unauthorized routes? apparently, nothing. to the extent that peering is by agreement, the majority of such agreements now in force do not require the other party to route-filter their customers. which is funny, since they tend to drone on endlessly about the importance of a 24x7 NOC, which in operational practice, matters lots less. (btw, anybody signed a peering agreement which requires an abuse@ mailbox yet?)

5 11