- NANOG - lists.nanog.org

PMTU and Broken Servers
by Leo Bicknell 13 May '03

13 May '03

I've recently had the pleasure of troubleshooting a problem I don't normally have to deal with, and the results don't quite make sense to me. I'm hoping someone can enlighten me as to what is going on. A diagram: server---internet---fw---tunnelbox1----tunnelbox2----user The tunnel between the tunnelboxes is a lower (1480) MTU. Originally the user couldn't access some servers, turns out the firewall was filtering ICMP Can't Fragment messages, preventing PMTU from working in the server->user direction (tunnelbox1 would generate Can't Fragement, firewall would filter). That's been corrected. Going to a server I control I see good PMTU in both directions between the server and the user. However, there are still a number of web servers for popular sites that behave just like the firewall was still filtering Can't Fragments. The theory is that the servers are behind a firewall/load balancer that is filtering them on the server side -- but I find it slightly (emphasis on the slightly) that someone would turn on PMTU discovery, and then filter it out right in front of the boxes where they turned it on. Also, it seems to me most DSL users are behind PPPoE links with lower MTU, and should get hit by the same problem. The temporary hack is to have tunnelbox1 clear the DF bit on all incoming packets, which just causes the packets to get fragmented going down the tunnel. A minor performance hit, but it works. This is a new problem to me, but I'm sure people have run into it before. Are the servers really that broken (PMTU enabled, ICMP Can't Fragement filtered)? Does the head end box of DSL services generally do something to work around this (ie, clear the DF bit)? Am I just being an idiot and missing something obvious? -- Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

7 10

RE: PMTU and Broken Servers
by Russell, David 13 May '03

13 May '03

You should keep in mind that Cisco routers have a limit on the number of ICMP messages they will originate per second. (My mind fails me as to whether it is 3 or 30). So you might lose a few ICMPs because of this. David -----Original Message----- From: Stephen J. Wilcox To: Curtis Maurand Cc: Leo Bicknell; nanog(a)merit.edu Sent: 5/12/03 10:49 AM Subject: Re: PMTU and Broken Servers You mean theres routers which get a large packet and silently drop it rather than return an icmp? Curious as to know which vendors? (read fundementally broken!) Steve On Mon, 12 May 2003, Curtis Maurand wrote: > > > I've had the problem before. Not all routers handle PMTU correctly. > > Curtis > > On Thu, 8 May 2003, Leo Bicknell wrote: > > > > > I've recently had the pleasure of troubleshooting a problem I don't > > normally have to deal with, and the results don't quite make sense > > to me. I'm hoping someone can enlighten me as to what is going on. > > A diagram: > > > > server---internet---fw---tunnelbox1----tunnelbox2----user > > > > The tunnel between the tunnelboxes is a lower (1480) MTU. Originally > > the user couldn't access some servers, turns out the firewall was > > filtering ICMP Can't Fragment messages, preventing PMTU from working > > in the server->user direction (tunnelbox1 would generate Can't > > Fragement, firewall would filter). > > > > That's been corrected. Going to a server I control I see good PMTU > > in both directions between the server and the user. However, there > > are still a number of web servers for popular sites that behave > > just like the firewall was still filtering Can't Fragments. The > > theory is that the servers are behind a firewall/load balancer that > > is filtering them on the server side -- but I find it slightly > > (emphasis on the slightly) that someone would turn on PMTU discovery, > > and then filter it out right in front of the boxes where they turned > > it on. Also, it seems to me most DSL users are behind PPPoE links > > with lower MTU, and should get hit by the same problem. > > > > The temporary hack is to have tunnelbox1 clear the DF bit on all > > incoming packets, which just causes the packets to get fragmented > > going down the tunnel. A minor performance hit, but it works. > > > > This is a new problem to me, but I'm sure people have run into it > > before. Are the servers really that broken (PMTU enabled, ICMP > > Can't Fragement filtered)? Does the head end box of DSL services > > generally do something to work around this (ie, clear the DF bit)? > > Am I just being an idiot and missing something obvious? > > > > > > Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ThruPoint, Inc.

2 1

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

XO issues resolved
by alex＠yuriev.com 12 May '03

12 May '03

Thank you to everyone from XO who responded - the issue had been resolved. Thanks again, Alex

1 0

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

earth to XO
by alex＠yuriev.com 12 May '03

12 May '03

Earth to XO... Earth to XO... Anyone from XO that actually knows how to look at the tickets opened 3 days ago, knows the concept "if i do not know how to do it, i should escalate it", and understands that it is not a good business sense to simply ignore 100M customers, please get in touch with me off the list? Thanks, Alex

2 1

SMSX.EXE - DoS Trojan
by Eden Akhavi 12 May '03

12 May '03

This may be a little OT, but we had some complaints from our customers who complained about saturated connections. We tracked it down to being a trojan (smsx.exe) that was sitting in their system32 directory. I stripped some of the ASCII from the file: PUSH <target> <port> <secs> = A push flooder t& NOTICE %s :TCP <target> <port> <secs> = A syn flooder ¶ NOTICE %s :UDP <target> <port> <secs> = A udp flooder ¶ NOTICE %s :MCON <target> <port> <num> <secs> <holdtime> = A connectbomb flooder ¶ ¼' NOTICE %s :DUMP <target> <port> <num> <secs> <holdtime> = dumps the evilbufs to a port ´& NOTICE %s :MCLONE <target> <port> <num> <secs> <holdtime> = connects to irc and dumps the evilbufs NOTICE %s :NICK <nick> = Changes the nick of the client NOTICE %s :DISABLE <pass> = Disables all packeting from this client The program connects to sd.ubersource.net (218.145.53.103) port 6667 (IRC) joins a channel called #REDARMY password :kalashnikov. And there it seems to wait for comments like PUSH TCP UDP as above. I am not sure of the delivery mechanism to get it onto the customers PC but it is certainly an issue. We have blocked access to sd.ubersource.net for now to see if the problems disappear. Regards Eden

1 0

Fwd: hijacked block - 160.116.0.0/16 [20030512-240-UPDATE]
by ddragon＠hushmail.com 12 May '03

12 May '03

If anyone else has information on 157.156/16, please submit it following the instructions below. Ticket #: 20030512-240 Status: Ticket Created Thank you for your message. A ticket has been opened with the tracking number listed below. We may not be able to respond to each message received, however we will analyze and take appropriate action if there is a violation of our Acceptable Use Guidelines by an MFN customer. Always address abuse issues only to "abuse(a)mfn.com". For future abuse concerns, we request the following: General UCE - Spam complaint - Copy of the original email with full headers intact - A traceroute would be beneficial - Do not include any WHOIS information - Please do not alter the subject line - Please do not include comments, personal feelings and quotes Hacking / Probing / Scanning - Text Log of intrusion including date, time, time zone, IP address (source and destination), port number - Logs should be within 48 hours of the incident - Brief description of intrusion - Our system will not accept attachments or MIME encoded documents Threats / Harassment - Contact your local authorities first with the following information: 1. Log of data including date, time, time zone, IP address 2. Brief but factual description of the incident 3. Any factual documentation such as exact email received or url of the post. Illegal material - Examples include: 1. Child Pornography 2. Phish Sites - credit card - personal information scams 3. Copyright or Trademark Infringement 4. Sites containing Trojan or Dialer Programs - Please include the exact URL or IP address of the site - Do not include WHOIS information Copyright Infringement - Trademark Issues - Complaints must be in accordance with the Digital Millennium Copyright Act (DMCA) and should include: 1. Exact URL(s) of the violating material 2. Statement of good faith belief 3. Declaration or perjury statement By supplying the information requested above, you can help increase the speed and efficiency by which issues are handled. Reports older than 3 days may not be investigated. Thank you in advance for your assistance, Policy Enforcement Division Metromedia Fiber Network ------=_Part_25787_23322757.1052749397917-- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427

1 0

hijacked block - 160.116.0.0/16
by ddragon＠hushmail.com 12 May '03

12 May '03

>And you can see previous affiliation to advistechsa.com (remember >my >previous post that VMX INC block 157.156.0.0/16 that is probably >supposed >to be Lucent block now? Well vmxnetworks was their upstream!). >Spews has a lot of info on that gang: >http://www.spews.org/html/S367.html >http://www.spews.org/html/S2425.html (publicom!) Here we are, over a week after this being pointed out on the NANOG list, and Cogent continues to let them advertise this netblock illegally. Since they are incapable of filtering themselves, could someone from MFN (their upstream) step up to the plate and put down some prefix-lists or null routes or them? Any Cogent peers reading this list? >Besides that it seems publicom which is possibly same as networktron >has long history of spamming and ip block hijacking back from 1999 >http://groups.google.com/groups?q=networldtron > >Networldtron is the company for which most of the ip blocks which >I listed >as announced by AS8143 are swipped to at ARIN database. Their main >domain >networldtron.net is now expired and inactive (if you do whois on >it you'll >find connection to publicom yet again). But ntwt.net is active and >has >been taken over by company called Naronda with domain naronda.com >- be on >the lookout for such a client who maybe spammer and hijacker! Or maybe AS 8143 has no connection to Advisetech at all. In today's global economy, it's common to have an ASN from a defunct company in Florida, and IP space from Lucent Technologies, Mansfield MA, a PO box in ZA, a company with IP's in New York but a domain in Beverly Hills, VE, and HT all routed to servers in NYC (do a traceroute). What's a few million SMTP connections between friends? Yeah, hats off to XO's abuse department. Keep up the good work guys. Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427

1 0

DMCA Violation?
by Christopher J. Wolff 12 May '03

12 May '03

Hello, Has anyone seen a copy of the following email? Furthermore, has it been determined which ISP services create a legal or equitable liability for the ISP? God help us if providing transport to an FTP site counts as one of the offending services. I guess it's time to turn on NBAR at the edge routers. This is clearly Big Brother at it's finest and a prime example of John Stuart Mill's "Tyranny of the Majority." I apply Mill's logic here because I doubt that the anti-DMCA crowd is packing the halls of Congress with the rabid fervor that the pro-DMCA crowd has. I hope that this is not the case! Respectfully yours, Christopher Wolff, CIO Broadband Labs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Re: Unauthorized Use of Universal Motion Pictures Notice ID: 123456 5/7/2003 Dear Sir or Madam: Universal City Studios Productions LLLP and its affiliated companies (collectively, "Universal") are the exclusive owners of copyrights in many motion pictures, including the motion pictures listed below. It has come to our attention that <<ISP Name>> is the service provider for the IP address listed below, from which unauthorized copying and distribution (downloading, uploading, file serving, file "swapping" or other similar activities) of Universals motion picture(s) listed below is taking place. We believe that the Internet access of the user engaging in this infringement is provided by <<ISP Name>> or a downstream service provider who purchases this connectivity from <<ISP Name>>. This unauthorized copying and distribution constitutes copyright infringement under Section 106 of the U.S. Copyright Act . Depending upon the type of service <<ISP Name>> is providing to this IP address, it may have legal and/or equitable liability if it does not expeditiously remove or disable access to the motion picture(s) listed below, or if it fails to implement a policy that provides for termination of subscribers who are repeat infringers (see, 17 U.S.C. §512). Despite the above, Universal believes that the entire Internet community benefits when these matters are resolved cooperatively. We urge you to take immediate action to stop this infringing activity and inform us of the results of your actions. We appreciate your efforts toward this common goal. The undersigned has a good faith belief that use of the motion pictures in the manner described herein is not authorized by Universal, its agent or the law. The information contained in this notification is accurate. Under penalty of perjury, the undersigned is authorized to act on behalf of Universal with respect to this matter. Please be advised that this letter is not and is not intended to be a complete statement of the facts or law as they may pertain to this matter or of Universals positions, rights or remedies, legal or equitable, all of which are specifically reserved. Very truly yours, <<Snipped>>

15 23