June 2004 - Test - lists.nanog.org

Re: BGP list of phishing sites?
by Paul Vixie 29 Jun '04

29 Jun '04

> meanwhile your sister has the hassle of getting southwest to send that > fax, or changing her travel plans. i'm sure glad you're not running my > isp. if i were running your isp, paying customers would get to choose.

1 0

RE: Strange behavior of Catalyst4006
by Greg Schwimer 29 Jun '04

29 Jun '04

Some things you can look into: > firewall interface(10.10.1.122/30). > ip route 192.168.5.0 255.255.255.0 10.10.1.124 Is that the firewall interface is 10.10.1.122, or is it 10.10.1.124? 10.10.1.122 is a host address in the 10.10.1.120/30 subnet. 10.10.1.124 is a /30 network. Either way, you're dealing with two different subnets. Oddly, it's working sometimes. > At the very begining all system works fine. After sometime they said they could not acces their email/web/dns > server from host outside their company's network... We restart ( shut; noshut) the fastethernet interface on Catalyst4006, > and then servers' network access recovered. > Sounds suspiciously like an IP conflict or some MAC weirdness with the firewall's or 4006's IP. Is the connection between the 4006 and the customer's firewall a basic crossover, or does the customer have a hub/switch on their side? Assuming the subnetting statement I've made above is based on erroneous info, check your arp cache/mac table when it *is* working. Write down the MAC for the customer's firewall. When it stops working, check the arp cache/mac table again. Compare the MACs to be sure they're the same. Just for giggles, clear the arp cache and see if that fixes it. If that doesn't, clear the entry from the cam table. Good luck... Greg Schwimer

3 2

RE: The use of .0/.255 addresses.
by Chris Ranch 29 Jun '04

29 Jun '04

I see traffic from this last IP address octet all the time from prefixes of length less than /24. Use of these host id's when the prefix length is greater than or equal to /24 is illegal. So if that's your case, I'd suggest not doing it. If that's not the case, look for over-zealous or incorrect filters in the path. I saw this situation once before. There was a border ingress filter with a typo in it... Chris > Various people I've asked about this have said they wouldn't > use the .0 > or .255 addresses themselves, though couldn't present any > concrete info > about why not; my experience above would seem to suggest a > reason not to > use them.

6 5

RE: Strange behavior of Catalyst4006
by Joe Shen 29 Jun '04

29 Jun '04

2 1

Re: BGP list of phishing sites?
by dlr＠bungi.com 29 Jun '04

29 Jun '04

[In the message entitled "Re: BGP list of phishing sites?" on Jun 28, 18:43, Simon Lockhart writes:] > > On Mon Jun 28, 2004 at 04:47:21PM +0000, Paul Vixie wrote: > > if it's easier for you to BGP-blackhole these bad sources and the only > > reason you don't is because you think it would be unfair, then you're > > part of the problem and you're helping to make the problem worse. > > It's wholy unfair to the innocent parties affected by the blacklisting. > i.e. the collateral damage. > > Say a phising site is "hosted" by geocities. Should geocities IP addresses > be added to the blacklist? > None of this would be an issue, if abuse desks were: 1. Responsive 2. Responsible 3. Empowered 4. Accountable Today, they are none of the above. If any of you out there think that isn't the case with your network, please let me know. I'll be happy to provide you with the spam from your network over the last 24 hours (or 24 days, or 24 months, or whatever other period you like). Blackholing is simply a way to draw immediate, and unmistakable attention to a problem, instead of sweeping it under the carpet. The problem is going to get worse before it gets better, much as it pains me to say that. Let's look at ways that it can be made better. A BGP feed, or other real time distribution method, can be used to let your abuse desk know that there is a problem, and to address it faster. It can be abused for this purpose as well, so it's important for *whatever* method is used to be run by responsible, accountable people. Think about it. Please. --

2 1

RE: BGP list of phishing sites?
by matthew.ford＠bt.com 29 Jun '04

29 Jun '04

> my sister called me last night to tell me that she was unable > to receive > mail from southwest airlines, and that her e-ticket was in > limbo for some > flight somewhere. i checked and sure enough southwest > airlines has sent > me three or messages per day that i don't want, for most days > out of the > last six months. since neither southwest nor their ISP was willing to > take any responsibility for this unwanted e-mail, i > blackholed them, and > i guess that means they'll have to fax that e-ticket. or > something. it's > not my problem. meanwhile your sister has the hassle of getting southwest to send that fax, or changing her travel plans. i'm sure glad you're not running my isp. --mat

1 0

RE: Strange behavior of Catalyst4006
by Pendergrass, Greg 29 Jun '04

29 Jun '04

Hi Joe, It would be good to know the type (and software version) of firewall as it could be the firewall and not the switch that's the problem. For instance, there's a known bug with checkpoint and NAT where automatic arp entries "disappear". If you can ping it all from the catalyst but not from the rest of your network it could be that you have a problem with your dynamic routing protocols, or with a device connected to the catalyst. Check your adjacent routers, do you have a valid route to the catalyst for the 192.168.5.7 subnet? What does a traceroute show from your NOC? -GP -----Original Message----- From: Joe Shen [mailto:jshen@spymac.com] Sent: 29 June 2004 02:01 To: nanog(a)merit.edu Subject: Strange behavior of Catalyst4006 Hi, We met a strange problem with Catalyst 4006 when provideing leased line service to one of our customers. Catalyst4006 ------------ Customer's firewall ---------------Customer's Intranet The customer is allocated a Class C address block 192.168.5/24. And , they connect their network to our network by using a firewall. The Interface on Cata4006 is set up as "no switchport", and inter-connecting subnet is configured between Cata4006 and firewall interface(10.10.1.122/30). Static route is used on Catalyst4006 to designate route to customer's intranet address. ( ip route 192.168.5.0 255.255.255.0 10.10.1.124 ). Customer setup their email server at 192.168.5.7, dns server at 192.168.5.1, web server at 192.168.5.9. At the very begining all system works fine. After sometime they said they could not acces their email/web/dns server from host outside their company's network. But, when we telnet to Cata4006, we could 'ping' 192.168.5.7, but if we move to host in NOC ping failed all the time. ( ping to server is allowed on firewall). At the same time, their intranet host could access our network. We restart ( shut; noshut) the fastethernet interface on Catalyst4006, and then servers' network access recovered. The phenomon comes up frequently, and our customer said this is a bug with catalyst4006. But, to my understanding, if this is a bug to catos, it should not only affact only three servers. But, why it could be solved by restart catalyst interface? Would you please do some help? ( I attach system info below) Joe Shen ======================-= 4006#sh version Cisco Internetwork Operating System Software IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-IS-M), Version 12.1(12c)EW1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Thu 24- Oct-02 23:05 by eaarmas Image text-base: 0x00000000, data-base: 0x00CA7368 ROM: 12.1(12r)EW Dagobah Revision 63, Swamp Revision 24 4006-wulin uptime is 41 weeks, 12 hours, 34 minutes System returned to ROM by power-on System restarted at 05:40:46 RPC Mon Sep 15 2003 System image file is "bootflash:cat4000-is-mz.121-12c.EW1.bin" cisco WS-C4006 (XPC8245) processor (revision 5) with 524288K bytes of memory. Processor board ID FOX05200BRH Last reset from PowerUp 144 FastEthernet/IEEE 802.3 interface(s) 2 Gigabit Ethernet/IEEE 802.3 interface(s) 403K bytes of non- volatile configuration memory. Configuration register is 0x2102 4006# 4006-wulin#sh run int f4/41 Building configuration... Current configuration : 141 bytes ! interface FastEthernet4/41 no switchport ip address 10.10.1.213 255.255.255.252 duplex full speed 100 end 4006# =============================================== ---- Cool Things Happen When Mac Users Meet! Join the community in Boston this July: www.macworldexpo.com Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No. 3802001 This e-mail is for the addressee(s) only. If you are not an addressee, you must not distribute, disclose, copy, use or rely on this e-mail or its contents, and you must immediately notify the sender and delete this e-mail and all copies from your system. Any unauthorised use may be unlawful. The information contained in this e-mail is confidential and may also be legally privileged.

1 0

RE: Can a customer take IP's with them?
by Michel Py 29 Jun '04

29 Jun '04

>> Michel Py wrote: >> In short: drop the monkey on ARIN's back. The issue that >> non-portable blocks are indeed non-portable is ARIN's to >> deal with, and partly why we are giving money to them. > Patrick W Gilmore wrote: > I wonder why ARIN, or even more importantly, ICANN has > not jumped all over this. Seems to me if IP space is not > "owned" or something close to it by ICANN, they have lost > a cornerstone of their power. Indeed, or there's something else we don't know about. >> b) _do_ announce the specific block routed to null0 >> (ARIN has delegated this space to you, if you want to >> announce unallocated parts of it to a blackhole it's >> nobody's business to tell you that you can't). > DO NOT DO THIS. The TRO specifically prohibits him > from doing these types of things. Breaking the TRO > will have immediate and detrimental impact on Alex > and NAC.Net. That remains to be seen, especially if the authority issuing the TRO has no jurisdiction over BGP routing. If you find an attorney that wants your money (easy enough) and a judge who is stupid enough to issue a TRO that I can't wear a green sock and a red sock, I will nevertheless keep wearing a green sock and a red sock and the detrimental consequences are going to be for the bozo that issued the TRO if they try to enforce it and not for me. Judges can be suspended or removed and states can be sued, to. > See my previous post re: liquor & the next NANOG.... Do you own a winery or something :-) > Alex Rubenstein > c) In regards to the tail-end of your mail, what you > propose (the temporary reassignment of space to an > ex-customer) is in (as I interpret ARIN policy) direct > contradiction and violation of ARIN policy. If this > policy were to stand, what prevents cable modem users, > or dialup users, or webhosting customers, the right to > ask to take their /32 with them? Exactly, I have one IP address with SBC (formerly Pacific Bell) at home, I'm too lazy to renumber my tunnels if I switch ISPs, so I'm going to require SBC to allow my one IP to be routed somewhere else? Ridiculous. By the way Alex, have you given some thoughts to suing the company that announces parts of your block? Should not be too difficult, if it's not portable and assigned to you. We all like customers that bring lawsuits with them, don't we? And what's the block in question so we can WHOIS it? Michel.

1 0

Re: Can a Customer take their IP's with them? (Court says yes!)
by Sabri Berisha 29 Jun '04

29 Jun '04

On Tue, Jun 29, 2004 at 09:43:41AM +0200, Florian Weimer wrote: Hi, > > As for the netblock: I just did a quick scan and here is what I found: > > > > 64.21.0.0/17 *[BGP/170] 3d 17:52:24, MED 64, localpref 210 > > AS path: 6320 8001 I > > > > 64.21.1.0/24 *[BGP/170] 3d 17:52:49, localpref 100 > > AS path: 3356 3561 6347 25702 I > > I don't think it's this one: > > route: 64.21.1.0/24 > origin: AS8001 I don't see this netblock originating from AS8001 anywhere, and I am rather curious which netblock it does concern. Does anyone know? :) -- Sabri, "I route, therefore you are" Bescherm de digitale burgerrechten: http://www.bof.nl/donateur.html

1 0

RE: Can a Customer take their IP's with them? (Court says yes!)
by Michel Py 29 Jun '04

29 Jun '04

What about asking the police to check the judge for drug abuse? There's more than enough evidence. Or argue that someone with an IQ below zero should not be a judge, but this might fail as most of them are former attorneys; I have more respect for common criminals than I have for most attorneys: they share the same goal (getting all my money) but at least the criminals don't BS me telling they're my friend. My $0.02: The most important part of all is to ask ARIN a written opinion on what to do WRT complying with the TRO. Since you do _not_ own your own netblocks (ARIN leases them you only as long as you're a good Shepard) and ARIN might eventually take them away from you if you don't follow their procedures, you don't want to put your entire business in jeopardy by committing in writing to anything that violates the agreement you have with ARIN. This alone is a good enough reason not to comply with the TRO. In short: drop the monkey on ARIN's back. The issue that non-portable blocks are indeed non-portable is ARIN's to deal with, and partly why we are giving money to them. Misc: a) If not already done, do pull the plug on the customer right away (no amount of money is worth dealing with jerks that take you to court for no reason). b) _do_ announce the specific block routed to null0 (ARIN has delegated this space to you, if you want to announce unallocated parts of it to a blackhole it's nobody's business to tell you that you can't). c) Ask your upstream to do b) explaining why, they might understand. d) Contact people that blacklist blocks and get it blacklisted there. e) Counter-sue the customer for frivolous lawsuit and anything else you can find. It might be useful to post details such as the legal documents and what the actual address of the block in question is so we blacklist it. If the situation is as you describe I think that lots of operators won't have a problem blacklisting the block. When the jerk is out of business because a) their block is blacklisted everywhere and b) nobody wants their business and can't pay stupid attorneys anymore your problem is solved. Michel. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Alex Rubenstein Sent: Monday, June 28, 2004 8:24 PM To: nanog(a)nanog.org Subject: Can a Customer take their IP's with them? (Court says yes!) Please read -- this is lengthy, and important to the industry as a whole. We ask for, and solicit, comments, letters of support, etc., for our position. We are looking for people to take a position on this, and come forward, perhaps even to provide an affidavit or certification. Something along the lines of a 'friend of the court' brief, or even comments as to why we are wrong. Read on. There has been a Temporary Restraining Order (TRO) issued by state court that customers may take non-portable IP space with them when they leave their provider. Important to realize: THIS TEMPORARY RESTRAINING ORDER HAS BEEN GRANTED, AND IS CURRENTLY IN EFFECT. THIS IS NOT SOMETHING THAT COULD HAPPEN, THIS IS SOMETHING THAT HAS HAPPENED. THERE IS AN ABILITY TO DISSOLVE IT, AND THAT IS WHAT WE ARE TRYING TO DO. This is a matter is of great importance to the entire Internet community. This type of precedent is very dangerous. If this ruling is upheld it has the potential to disrupt routing throughout the Internet, and change practices of business for any Internet Service Provider. In the TRO, the specific language that is enforced is as follows: "NAC shall permit CUSTOMER to continue utilization through any carrier or carriers of CUSTOMER's choice of any IP addresses that were utilized by, through or on behalf of CUSTOMER under the April 2003 Agreement during the term thereof (the "Prior CUSTOMER Addresses") and shall not interfere in any way with the use of the Prior CUSTOMER Addresses, including, but not limited to: (i) by reassignment of IP address space to any customer; aggregation and/or BGP announcement modifications, (ii) by directly or indirectly causing the occurrence of superseding or conflicting BGP Global Routing Table entries; filters and/or access lists, and/or (iii) by directly or indirectly causing reduced prioritization or access to and/or from the Prior CUSTOMER Addresses, (c) provide CUSTOMER with a Letter of Authorization (LOA) within seven (7) days of CUSTOMER's written request for same to the email address/ticket system (network(a)nac.net) and (d) permit announcement of the Prior CUSTOMER Addresses to any carrier, IP transit or IP peering network." We believe this order to be in direct violation of ARIN policy and the standard contract that is signed by every entity that is given an allocation of IP space. The ARIN contract strictly states that the IP space is NOT property of the ISP and can not be sold or transferred. The IP blocks in question in this case are very clearly defined as non-portable space by ARIN. Section 9 of ARIN's standard Service Agreement clearly states: "9. NO PROPERTY RIGHTS. Applicant acknowledges and agrees that the numbering resources are not property (real, personal or intellectual) and that Applicant shall not acquire any property rights in or to any numbering resources by virtue of this Agreement or otherwise. Applicant further agrees that it will not attempt, directly or indirectly, to obtain or assert any trademark, service mark, copyright or any other form of property rights in any numbering resources in the United States or any other country." [ Full ARIN agreement http://www.arin.net/library/agreements/rsa.pdf ] Further, it is important to realize that this CUSTOMER has already gotten allocations from ARIN over 15 months ago, and has chosen not to renumber out of NAC IP space. They have asserted that ARIN did not supply them with IP space fast enough to allow them to renumber. Since they have gotten allocations from ARIN, we are confident they have signed ARIN's RSA as well, and are aware of the above point (9). If this ruling stands and a new precedent is set, any customer of any carrier would be allowed to take their IP space with them when they leave just because it is not convenient for them to renumber. That could be a single static IP address for a dial-up customer or many thousands of addresses for a web hosting company. This could mean that if you want to revoke the address space of a spammer customer, that the court could allow the customer to simply take the space with them and deny you as the carrier (and ARIN) their rights to control the space as you (and ARIN) see fit. REMEMBER, THE INTERNET USED TO BE BASED UPON PORTABLE IP SPACE, AND IS NO LONGER FOR SEVERAL TECHNICAL REASONS. It is important to understand that this is not a situation where a customer is being forced to leave on short notice. NAC has not revoked the IP space of the customer. This is a situation where a customer is exercising their option not to renew their services and is leaving voluntarily. In addition the customer in question was granted their own IP space OVER A YEAR AGO and simply chose not to renumber their entire network. The key issue is that they want to take the space with them AFTER they leave NAC and are NO LONGER A CUSTOMER. Why this TRO is bad for the Internet: 1. It undermines ARIN's entire contract and authority to assign IP space. 2. It means that once IP addresses have been assigned / SWIP'ed to a Customer that the Customer may now have the right to continued use of those addresses even if the customer leaves the service of the Provider. In other words the right of the Provider to maintain control and use of the address space assigned to his network, is to now be subject to the Customer going to a State Court and getting an Order to take such space with them. Instead of the Addresses being allocated by delegated authority of the Department of Commerce and ARIN they become useable by anyone who convinces a Judge that they have a need for the addresses. It appears the Customer can keep the addresses for as long as it pleases the State Court and as long as the Customer can judicially hijack the space. The tragic part of this is that the Court which issues the Order does not even have to hear expert testimony. So the Court can issue such Order without fully understanding the Internet Technology that is affected or the havoc it could cause in National and International Communications. 3. Significant potential for routing havoc as pieces of non-portable blocks of space are no longer controlled by the entity that has the assignment from ARIN, but by the end user customer for as long as that customer wants to use them. If the customer was causing a routing problem by improper routing confirmation the carrier would lose their authority to revoke or limit the use of the IP space to protect the stability of the carrier's network. In other words, court-compelled LOAs are a 'bad thing.' 4. Because the IP space is still assigned to the carrier, the carrier would potentially be responsible to continue to respond to all SPAM and hacking complaints, DMCA violations, and all other forms of abuse. All of this abuse responsibility and liability would continue with no recourse to revoke or limit IP space of that customer and no ability to receive financial compensation for that task. This is not a theoretical problem, in the case of this customer we have received numerous abuse complaints throughout their history as a customer. While they have generally resolved these issues, it still is a real cost for us to handle. This is something that has the potential to create a massive burden for the carrier. 5. It would fundamentally change the long standing policy that the carrier that has the IP space assigned to them has the right to assign and revoke the IP space as it sees fit, and that the customer has no rights to the IP space other then the rights that the carrier gives them (through a delegation from ARIN). 6. If the customer is being DDOSed, or attacked (perhaps they may even instigate it purposely), and then stops announcing the more specific routes, the attack when then flow to us, the innocent bystander. Essentially, the customer could cause a DDOS for which I will then be billed for. This type of thing has been known to happen in the past (but not with this CUSTOMER). As you can see, this TRO has widespread effects, and is something that everyone in the industry could be affected by. If this precedent is set, you will soon have everyone acting as if IP's are property, and something that they are entitled to. I ask for input from everyone in the community on this. We don't think we're crazy, but want to make sure.

3 2