- NANOG - lists.nanog.org

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

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

29 Jun '04

Regardless, this is not a telephony issue ("Can I take my cell number with me?"), as the courts as seem disposed to diagnose these days, but rather, a technical one insofar as the IP routing table efficiency. "Friends of the court" won't work here unless the technical implications are presented in pablum form, methinks. This is indeed a technical, as well as as an engineering issue (before someone starts yelling about this thread being off-topic). FWIW, and pssing into the wind, the U.S. Courts need a real dose of reality anyways WRT attempting to legislate chaos. My $.02, - ferg -- "william(at)elan.net" <william(a)elan.net> wrote: What you really should try is to have ARIN provide "friend of the court" brief and to explain to judge policies and rules in regards to ip space, so you need to have your laywer get in touch with ARIN's lawyer. You can probably even force them to provide a statement or testimony (if they don't volunterily) as part of discovery process. P.S. You might as well provide name of the customer now. Since its gone through court, its all now public info (i.e. TRO) anyway. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

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

29 Jun '04

Of course, this is only possible with NAT at the customer edge. Otherwise, it expands the size of the global routing system exponentially. - ferg -- Alex Rubenstein <alex(a)nac.net> wrote: 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. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

Strange behavior of Catalyst4006
by Joe Shen 29 Jun '04

29 Jun '04

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

3 2

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

28 Jun '04

warning. this is about humans rather than about IOS configs. hit D now. > >> Also, an "easy fix" like this may lower the pressure on the parties > >> who are really responsible for allowing this to happen: the makers > >> of insecure software / insecure operational procedures (banks!) and > >> gullible users. > > > actually, a bgp feed of this kind tends to supply the "missing > > causal vector" whereby someone who does something sloppy or bad ends > > up suffering for it. > > ??? I don't understand? the root cause of network abuse is humans and human behaviour, not hardware or software or corporations or corporate behaviour. if most people weren't sheep-like, they would pay some attention to the results of their actions and inactions. actions like buying something from a spammer or clicking the "unsubscribe me" button in spam mail, or running microsoft outlook. inactions like not installing patches that microsoft has supplied free of charge over the years. inactions like leaving their cable/DSL pee cee up 24x7 and never wondering why the activity light on their modem flickers constantly. but the vast majority of humanity is and has always been sheep-like. while i could talk about certain election victories and other meatspace examples, that would be even more off-topic than we already are, so let's just put it like this: if you want people to notice the results of their actions and inactions, then they have to be brought into the equation. don't let worms be symbiotic, make them host-killing parasites, and that will make the host bodies sit up and take notice. this trick works every time. > > ... the internet is very survivable and the necessary traffic always > > finds a way to get through. fixing layer >7 problems by denying > > layer 3 service has indeed proven to be the only way to get remote > > CEO's to care (or notice). > > Still, anti-spam blacklists are pretty much universally applied inside > SMTP implementations these days. So if 3828747.dhcp.bigcable.com is > blacklisted because it sources spam, people subscribing to the > blacklist will no longer receive spam from that host, but the host is > still capable of interacting with the net in general and the blacklist > users in particular over a host of other protocols. i'm trying to figure out why you think it's in your best interest to limit the impact of your defensive activities, or to limit the impact of sheep-like behaviour on the sheep-like humans who own these infected hosts. in psycho- babble the term would best apply to your proposal is "enabler". why do you want to enable this kind of sheep-like behaviour? what's in it for you? if you think it'll leave more pee cee's online and able to access your shopping cart system that's one thing. but if you think you're somehow helping the owners of these pee cees you're wrong. and you are in fact hurting yourself, and the rest of us, every time you choose to be an "enabler" rather than letting these people stew in their own sheep-like juices. 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. > ... > My position is that end-user networks should decide for themselves if > this is something they want, but it would be wrong for transit > networks to make these decisions for all their customers, especially > as they seem to be growing more and more impervious to incoming email > or phone support requests that require knowledge of the proper order > of the letters "I" and "P". thanks for explaining your position, and very clearly i might add. we're not so different -- i think "decide for themselves" is the right meme. but where we differ is on the questions of ownership and responsibility. every network has to take responsibility for the traffic is spews, and cannot just say "take it up with my customer" since they're getting paid to make the spew possible. and every network has to be able to say "this shall not pass!" concerning traffic that does not match their "AUP", and the only recourse their customers can have is to sign up with a different network. naturally, sean's and chris's employers don't see it that way at all, and prefer to take no responsibility and exercise no control, except where revenue is concerned.

6 5

RE: BGP list of phishing sites?
by Smith, Donald 28 Jun '04

28 Jun '04

I agree phishing bgp feed would disrupt the ip address to all ISP's that listened to the bgp server involved. I was addressing a specific issue with listening to such a server and that is the loss of control issue. Sorry if that wasn't clear. So would ISP's block an phishing site if it was proven to be a phishing site and reported by their customers? Donald.Smith(a)qwest.com GCIA pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC Brian Kernighan jokingly named it the Uniplexed Information and Computing System (UNICS) as a pun on MULTICS. > -----Original Message----- > From: Stephen J. Wilcox [mailto:steve@telecomplete.co.uk] > Sent: Monday, June 28, 2004 2:58 PM > To: Smith, Donald > Cc: Scott Call; nanog(a)nanog.org > Subject: RE: BGP list of phishing sites? > > > Hi Donald, > the bogon feed is not supposed to be causing any form of > disruption, the > purpose of a phishing bgp feed is to disrupt the IP address.. > thats a major > difference and has a lot of implications. > > Steve > > On Mon, 28 Jun 2004, Smith, Donald wrote: > > > Some are making this too hard. > > Of the lists I know of they only blackhole KNOWN active > attacking or > > victim sites (bot controllers, know malware download locations etc) > > not porn/kiddie porn/pr/choose-who-you-hate-sites ... clients > > (infected > > pc's) > > are usually not included but could make it on the list given enough > > attacks. > > It does mean giving up some control of your network which may not be > > acceptable to some ISP's. > > Its not much different then listening to an automated bogon feed. > > > > > > Donald.Smith(a)qwest.com GCIA > > pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC > > Brian Kernighan jokingly named it the Uniplexed Information and > > Computing System (UNICS) as a pun on MULTICS. > > > > > -----Original Message----- > > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > > > Behalf Of Stephen J. Wilcox > > > Sent: Monday, June 28, 2004 11:56 AM > > > To: Scott Call > > > Cc: nanog(a)nanog.org > > > Subject: Re: BGP list of phishing sites? > > > > > > > > > > > > On Sun, 27 Jun 2004, Scott Call wrote: > > > > > > > On the the things the article mentioned is that ISP/NSPs > > > are shutting > > > > off > > > > access to the web site in russia where the malware is being > > > downloaded > > > > from. > > > > > > > > Now we've done this in the past when a known target of > a DDOS was > > > > upcoming > > > > or a known website hosted part of a malware package, and it > > > is fairly > > > > effective in stopping the problems. > > > > > > > > So what I was curious about is would there be interest in a > > > BGP feed > > > > (like > > > > the DNSBLs used to be) to null route known malicious sites > > > like that? > > > > > > > > Obviously, both operational guidelines, and trust of > the operator > > > > would > > > > have to be established, but I was thinking it might be > > > useful for a few > > > > purposes: > > > > > > > > 1> IP addresses of well known sources of malicious code > (like in > > > > 1> the > > > > example above) > > > > 2> DDOS mitigation (ISP/NSP can request a null route of a > > > prefix which > > > > will save the "Internet at large" as well as the NSP from > > > the traffic > > > > flood > > > > 3> etc > > > > > > > > Since the purpose of this list would be to identify and > > > mitigate large > > > > scale threats, things like spammers, etc would be outside > > > of it's charter. > > > > > > > > If anyone things this is a good (or bad) idea, please > let me know. > > > > Obviously it's not fully cooked yet, but I wanted to throw > > > it out there. > > > > > > Personally - bad. > > > > > > So what do you want to include in this list.. phishing? But > > > why not add bot C&C, > > > bot clients, spam sources, child porn, warez sites. Or if you > > > live in a censored > > > region add foreign political sites, any porn, or other > > > messages deemed bad. > > > > > > Who maintains the feed, who checks the sites before adding > > > them, who checks them > > > before removing them. > > > > > > What if the URL is a subdir of a major website such as > > > aol.com or ebay.com or angelfire.com ... what if the URL is a > > > subdir of a minor site, such as yours or > > > mine? > > > > > > What if there is some other dispute over a null'ed IP, > > > suppose they win, can > > > they be compensated? > > > > > > Does this mean the banks and folks dont have to continue to > > > remove these threats now if the ISP does it? Does it mean the > > > bank can sue you if you fail to do it? > > > > > > What if you leak the feed at your borders, I may not want to > > > take this from you and now I'm accidentally null routing it > > > to you. Should you leak this to downstream ASNs? Should you > > > insist your Tier1 provides it and leaks it to you?.. > > > just you or all customers? > > > > > > What if someone mistypes an IP and accidentally nulls > > > something real bad(TM)? > > > What if someone compromises the feeder and injects prefixes > > > maliciously? > > > > > > What about when the phishers adapt and start changing DNS to > > > point to different IPs quickly, will the system react > > > quicker? Does that mean you apply less checks > > > in order to get the null route out quicker? Is it just /32s > > > or does it need to > > > be larger prefixes in the future? Are there other ways > > > conceivable to beat such > > > a system if it became widespread (compare to spammer tactics) > > > > > > What if this list gets to be large? Do we want huge amounts > > > of /32s in our > > > internal routing tables? > > > > > > What if the feeder becomes a focus of attacks by those > > > wishing to carry out > > > phishing or other illegal activities? This has certainly > > > become a hazard with > > > spam RBLs. > > > > > > > > > Any other thoughts? > > > > > > Steve > > > > > > > > > > > > >

2 1

RE: BGP list of phishing sites?
by Smith, Donald 28 Jun '04

28 Jun '04

Some are making this too hard. Of the lists I know of they only blackhole KNOWN active attacking or victim sites (bot controllers, know malware download locations etc) not porn/kiddie porn/pr/choose-who-you-hate-sites ... clients (infected pc's) are usually not included but could make it on the list given enough attacks. It does mean giving up some control of your network which may not be acceptable to some ISP's. Its not much different then listening to an automated bogon feed. Donald.Smith(a)qwest.com GCIA pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC Brian Kernighan jokingly named it the Uniplexed Information and Computing System (UNICS) as a pun on MULTICS. > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Stephen J. Wilcox > Sent: Monday, June 28, 2004 11:56 AM > To: Scott Call > Cc: nanog(a)nanog.org > Subject: Re: BGP list of phishing sites? > > > > On Sun, 27 Jun 2004, Scott Call wrote: > > > On the the things the article mentioned is that ISP/NSPs > are shutting > > off > > access to the web site in russia where the malware is being > downloaded > > from. > > > > Now we've done this in the past when a known target of a DDOS was > > upcoming > > or a known website hosted part of a malware package, and it > is fairly > > effective in stopping the problems. > > > > So what I was curious about is would there be interest in a > BGP feed > > (like > > the DNSBLs used to be) to null route known malicious sites > like that? > > > > Obviously, both operational guidelines, and trust of the operator > > would > > have to be established, but I was thinking it might be > useful for a few > > purposes: > > > > 1> IP addresses of well known sources of malicious code (like in the > > example above) > > 2> DDOS mitigation (ISP/NSP can request a null route of a > prefix which > > will save the "Internet at large" as well as the NSP from > the traffic > > flood > > 3> etc > > > > Since the purpose of this list would be to identify and > mitigate large > > scale threats, things like spammers, etc would be outside > of it's charter. > > > > If anyone things this is a good (or bad) idea, please let me know. > > Obviously it's not fully cooked yet, but I wanted to throw > it out there. > > Personally - bad. > > So what do you want to include in this list.. phishing? But > why not add bot C&C, > bot clients, spam sources, child porn, warez sites. Or if you > live in a censored > region add foreign political sites, any porn, or other > messages deemed bad. > > Who maintains the feed, who checks the sites before adding > them, who checks them > before removing them. > > What if the URL is a subdir of a major website such as > aol.com or ebay.com or angelfire.com ... what if the URL is a > subdir of a minor site, such as yours or > mine? > > What if there is some other dispute over a null'ed IP, > suppose they win, can > they be compensated? > > Does this mean the banks and folks dont have to continue to > remove these threats now if the ISP does it? Does it mean the > bank can sue you if you fail to do it? > > What if you leak the feed at your borders, I may not want to > take this from you and now I'm accidentally null routing it > to you. Should you leak this to downstream ASNs? Should you > insist your Tier1 provides it and leaks it to you?.. > just you or all customers? > > What if someone mistypes an IP and accidentally nulls > something real bad(TM)? > What if someone compromises the feeder and injects prefixes > maliciously? > > What about when the phishers adapt and start changing DNS to > point to different IPs quickly, will the system react > quicker? Does that mean you apply less checks > in order to get the null route out quicker? Is it just /32s > or does it need to > be larger prefixes in the future? Are there other ways > conceivable to beat such > a system if it became widespread (compare to spammer tactics) > > What if this list gets to be large? Do we want huge amounts > of /32s in our > internal routing tables? > > What if the feeder becomes a focus of attacks by those > wishing to carry out > phishing or other illegal activities? This has certainly > become a hazard with > spam RBLs. > > > Any other thoughts? > > Steve > > >

2 1

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

28 Jun '04

> > It's wholy unfair to the innocent parties affected by the blacklisting. > > i.e. the collateral damage. maybe so. but it'll happen anyway, because victims often have no recourse that won't inflict collateral damage. the aggregate microscopic damage of this kind is becoming measurable and "statistically interesting". > > Say a phising site is "hosted" by geocities. Should geocities IP > > addresses be added to the blacklist? > > > > What if it made it onto an akamaized service? Should all of akamai > > be blacklisted? you're using terms like "unfair" and "innocent" and "should" in ways that lead me to wonder if we're having two different conversations here. the internet has no government, no constitution, no laws, no rights, no police, no courts. don't talk about fairness or innocence, and don't talk about what should be done. instead, talk about what is being done and what will be done by the amorphous unreachable undefinable blob called "the internet user base." if the cost:benefit is right for an endsystem to blackhole akamai or geocities then they will do it, no matter how unfair anybody else thinks it is, or how innocent other people think akamai/geocities might be, and no matter how much you or anybody may think that something different "should" be done. welcome to the "dog-eat-dog phase." spammers and phishers don't care about what's fair or who's innocent. sean's and chris's employers certainly don't want to be lectured to about what others think "should" be done. the end result is that victims are caring less and less about false positives or collateral damage -- nobody wants to be the last one to stop caring, since the other name for that person is "rube" (or sometimes "dupe".) while i've been keen to criticize sean's and chris's employers here, i do it for entertainment value (my own, and the lurkers who occasionally tell me i owe them a new keyboard because i was unexpectedly funny) and not because i think sean or chris or their employers are wondering what i think they "should" do. > ... > a) IP address that happen to have $nasty at one end of them; or > b) IP address for whom no abuse desk even gives a response (even > "we know, go away") when informed of $nasty. > ... > Seems to me (b) is, in general, a lot more reasonable than (a) > particularly where there is very likely >1 administrative zone per IP > address (for example HTTP/1.1). It also better satisfies Paul's > criterion of being more likely to engender better behaviour (read: > responsibility of network work operators for downstream traffic) if > behaviour of the reporter is proportionate & targeted. 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. as a victim, i can't let it be my problem. if someone wants their traffic to be accepted then they'll have to maintain a good reputation, which will in the future be automated in various ways including webs of trust/guaranty, forfeitable deposits, micropayments, and "living in better neighborhoods". in that way e-space will catch up to meat-space. > WRT "apply greater sanctions", it is possible of course, though perhaps > neither desirable nor scalable, to filter at layer>3 all sites on given IPs > to minimize collateral damage. See > http://www.theregister.co.uk/2004/06/07/bt_cleanfeed_analysis/ collateral damage is irrelevant now. minimizing it makes the problem worse, maximizing it just costs you in lawyer payments, it's every endsystem for itself now. john gilmore warned me that i was hastening this day when i started the first RBL. i didn't consider it avoidable, then or now. we were both right.

1 0

Sprint-Savvis outage Las Vegas
by Philip Lavine 28 Jun '04

28 Jun '04

Has anybody seen an interuption in service in Las Vegas with Sprint or Savvis __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

1 0