- Test - lists.nanog.org

RE: Non-Portable ip blocks become portable (was - Can a Customer take their IP's with them? )
by Michel Py 30 Jun '04

30 Jun '04

> William Leibzon wrote: > Not an ARIN example but when KPNQwest went out of business, > the situation was as you desribe and it would have been > difficult to everybody to quickly renumber so their PA > assigned customer ip blocks with assistance of RIPE became > PI blocks (at least this is how I understood it, people in > europe can correct me if this is not right). So the > precidents do exist, but they involve having RIR take over > the block. You forget to mention something here: people knew. Even if you were stupid there's no way (if you were a KPNQwest customer) that you could have missed there were in trouble. But that's only for starters: when they did fold, a very large part of the staff continued to operate the network with no pay for days to keep customers up. Kudos to ex-KPNQwest network dudes. So, your ISP has been in financial trouble for a while. For the last two weeks the only reason you were up is because some dedicated people kept the network running on life support on their own time and money. If you begin your renumbering effort by the time you lose connectivity, you deserve to go out of business. Same applies to AS25653: if they're stupid enough to sign a contract that basically say they can be kicked out within 45 days _and_ not prepared to move out within 45 days or so, they're too stupid to be in the ISP business. Period. I have plenty of customers that are "locked-in" with IP addresses. Their upstream does not leverage the fact that they do indeed hold the customer by the balls, because said customer a) pay their bills and b) do not spam. Michel.

1 0

Fwd: Please stop sending me emails
by David Barak 30 Jun '04

30 Jun '04

<rant> I've gotta say - this is a new one for me. I'm used to hearing about low signal/noise ratios, and the inevitable off-topic griping, but I wasn't expecting that someone who is actually subscribed to a list such as this one would have such idiot-ware enabled... -David Barak -Fully RFC 1925 Compliant- --- Jason Silverglate <jason(a)pwebtech.com> wrote: > Date: Tue, 29 Jun 2004 22:44:34 -0400 > From: "Jason Silverglate" <jason(a)pwebtech.com> > To: thegameiam(a)yahoo.com > Subject: Please stop sending me emails > > **** THIS IS AN AUTOMATIC REPLY **** > > Your e-mail message to me (see below) was not > delivered. I > am no longer accepting mail from your address. > > This extreme measure was most likely taken in > response > to unsolicited or unwanted e-mail from you. If you > were > attempting to market a commercial product or service > to me, > then please note that I am absolutely not interested > in > it. I take a dim view of any form of UCE, and on > principle > refuse to patronize any business that resorts to > this > tactic. > <spanish version of above (I assume, cause I don't speak spanish) snipped> > This email account is protected by: > Active Spam Killer (ASK) V2.4.1 - (C) 2001-2002 by > Marco Paganini > For more information visit > http://www.paganini.net/ask > > --- Original Message Follows --- <discussion regarding observers/observed snipped> ===== David Barak -fully RFC 1925 compliant- __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

2 1

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

30 Jun '04

> > 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. > > It's easy to blame the user, and usually they deserve it, even if they're > innocent this time they're guilty of something else. But if software is > created in such a way that regular users manage to screw up consistently, > maybe the software can be improved rather than the user chastised? we're just not communicating here. prescriptive statements ("can be improved?") are inappropriate unless somebody's asking for your advice. in this case i think it's safe to say that software vendors don't care what we think about this topic and they have their own plans. same thing for sean's and chris's employers. see padlipsky for the best description to date on prescriptive vs. descriptive in the networking field. what matters isn't what folks ought to do, but what they will do and are doing, or won't do, etc. > ... If people do the wrong thing, by all means let them suffer the > consequences so they may think twice about doing it again. What > worries me is the potential for hurting innocent bystanders, or even > active subversion of these mechanisms. I mean, what better way to DoS > someone than have them put on a blacklist? in the medium and long term, no arbitrary blacklist will have global or lasting effect. you don't need to take this effect into consideration, it's a marginal corner case at best, and a distraction. > I think the one true way is to be found somewhere between the extremes > of controlling every little thing a customer does and not doing anything. ah. you're pining for what are now thought of as "the good old days", eh? when reasonable people wanted to do reasonable things and needed help from vendors and suppliers, and unreasonable people hadn't discovered "the net" yet and were still making money the old fashioned way (bilking little old ladies out of their life savings, etc). i have bad news and worse news. the bad news is, there's no going back. the worse news is, as carole king so aptly sang, "THESE ARE the good old days". > But the real issue is that this is even necessary. The biggest problem > we have with IP is that it doesn't provide for a way for a receiver to > avoid having to receiving unwanted packets. It would be extremely > useful if we could fix that. you realize that the virtual circuit X.25/TP4 people are laughing their asses off as they read those words, don't you?

3 4

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

30 Jun '04

>>> william(at)elan.net wrote: >>> I've suspicions this maybe Pegasus Web Technologies (AS25653), >> Michel Py wrote: >> Good catch William! > Dan Hollis wrote: > This pegasus? http://www.spews.org/html/S2649.html Yeah. Michel.

1 0

Can a Customer take their IP's with them? (Court says yes!)
by Alex Rubenstein 29 Jun '04

29 Jun '04

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.

19 25

BGP list of phishing sites?
by Scott Call 29 Jun '04

29 Jun '04

Happy Sunday nanogers... I was doing some follow up reading on the "js.scob.trojan", the latest "hole big enough to drive a truck through" exploit for Internet Explorer. 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. Thanks -Scott

10 12

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

29 Jun '04

> So you think it's futile to try to get software vendors to improve their > products. I suppose I can go along with that to a certain degree. But how > can you expect end-users to work around the brokenness in the software they > use? This seems both unfair and futile. at my aforementioned sister's house, i did it by buying an off-the-shelf $99 firewall and a $79 copy of suse-9 and spending an afternoon showing her how to use them. i guess the general form of the answer is "tell people to get some tech support rather than believing what their vendors say." i'm not an expert on d-link firewalls, or on linux, but i know enough to know that running MSIE and Outlook and not having a firewall was her problem. > Einstein taught as that even the simple act of observation influences our > surroundings. Wouldn't it make sense to try to leverage this influence such > that the future is shaped more to our liking, however small the change may > be? as sad as this is, the best way to accomplish that is by heaping public scorn and ridicule on sean's and chris's employers every time they whine about how folks are widely blackholing their customers. you won't convince sbc or mci, but you might convince a lurker or two. > >> But the real issue is that this is even necessary. The biggest problem > >> we have with IP is that it doesn't provide for a way for a receiver to > >> avoid having to receiving unwanted packets. It would be extremely > >> useful if we could fix that. > > > you realize that the virtual circuit X.25/TP4 people are laughing their > > asses off as they read those words, don't you? > > It's easy to laugh if you don't have a world wide network to run. i once had the honour of taking over a network dave rand had built, which became an unprofitable dot-bomb on my watch. ouch! but it wasn't because we refused to take money from spammers, or because we disconnected folks pre-emptively when they violated their AUP. so, that's not what i meant. if you want to put enough intelligence into the network so that "a receiver" can "avoid having to receive unwanted packets" then you'll need to decide how to throttle flow solicitations or else those flow solicitations will become the new form of spam and ddos. this will require state, not just in your hosts and upstream router and provider, but globally, end to end. and if you do that you'll have bitten into the rotten apple of circuit switching and x.25 and atm that the IP folks have been saying all these years wouldn't scale and wasn't necessary. and so, the people on the other side (the losing side, in my opinion) of that argument will laugh their asses off, whether they have a world wide network to run, or not.

1 0

RE: Attn MCI/UUNet - Massive abuse from your network
by Ben Browning 29 Jun '04

29 Jun '04

At 04:00 PM 6/24/2004, Hannigan, Martin wrote: > > >On Thu, 24 Jun 2004, Ben Browning wrote: > > this discussion anyways, is access to the internet. When the > > actions of a > > downstream damage that product(IE more and more networks > > nullroute UUNet > > traffic), > >[ Operations content: ] Do you know of any ISP's null routing AS701? ISPs? Not of the top of my head. I know several businesses who have, and a great many people who have blocked UUNet space from sending them email, either by using SPEWS, the SBL, or mci.blackholes.us . ~Ben --- Ben Browning <benb(a)theriver.com> The River Internet Access Co. WA Operations Manager 1-877-88-RIVER http://www.theriver.com

7 10

Re: Teaching/developing troubleshooting skills
by John Neiberger 29 Jun '04

29 Jun '04

>It's also important that one avoid: > >* The faulty assumption there is but one problem >* Incorrectly-formed causal relationships (NANOG-L has some > examples of these) >* Making too many changes in one iteration >* Attempting to tackle a system with more unknowns than are > absolutely necessary. These words should be hanging on a wall in every IT department. You wouldn't believe how many times I've had to gently correct someone because of these mistakes, particularly the first two. John --

4 3

duplicate emails?
by Stephen J. Wilcox 29 Jun '04

29 Jun '04

This host appears to be resending nanog posts? : Received: from e500smtp01.nga.mil(164.214.6.120) by relay5.nga.mil via smap (V5.5) id xma020150; Tue, 29 Jun 04 10:25:13 -0400 Originally received yesterday sometime... ---------- Forwarded message ---------- Return-path: <MAILER-DAEMON(a)relay5.nga.mil> Envelope-to: steve(a)telecomplete.net Delivery-date: Tue, 29 Jun 2004 14:25:46 +0000 Received: from exim by mx-0.telecomplete.net with spam-scanned (Exim 4.22) id 1BfJYP-00065u-Li for steve(a)telecomplete.net; Tue, 29 Jun 2004 14:25:46 +0000 Received: from exim by mx-0.telecomplete.net with scanned-ok (Exim 4.22) id 1BfJYP-00065h-1o for steve(a)telecomplete.net; Tue, 29 Jun 2004 14:25:45 +0000 Received: from relay5.nga.mil ([164.214.4.61]) by mx-0.telecomplete.net with esmtp (Exim 4.22) id 1BfJYO-00065C-6w for steve(a)telecomplete.co.uk; Tue, 29 Jun 2004 14:25:44 +0000 Received: by relay5.nga.mil; id KAA20159; Tue, 29 Jun 2004 10:25:38 -0400 (EDT) Received: from e500smtp01.nga.mil(164.214.6.120) by relay5.nga.mil via smap (V5.5) id xma020150; Tue, 29 Jun 04 10:25:13 -0400 Received: from relay2.nga.mil(164.214.6.52) by e1000smtp2.nima.mil via csmap id 78e94c8c_c949_11d8_9cac_0002b3c81b76_16242; Mon, 28 Jun 2004 17:24:00 -0400 (EDT) Received: by relay2.nga.mil; id RAA13558; Mon, 28 Jun 2004 17:22:36 -0400 (EDT) Received: from trapdoor.merit.edu(198.108.1.26) by relay2.nga.mil via smap (V5.5) id xma010754; Mon, 28 Jun 04 17:14:29 -0400 Received: by trapdoor.merit.edu (Postfix) id 6C1A091277; Mon, 28 Jun 2004 17:12:33 -0400 (EDT) Delivered-To: nanog-outgoing(a)trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3590491285; Mon, 28 Jun 2004 17:12:33 -0400 (EDT) Delivered-To: nanog(a)trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AB5D91277 for <nanog(a)trapdoor.merit.edu>; Mon, 28 Jun 2004 17:12:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 568C759D1B; Mon, 28 Jun 2004 17:12:26 -0400 (EDT) Delivered-To: nanog(a)nanog.org Received: from uswgco34.uswest.com (uswgco34.uswest.com [199.168.32.123]) by segue.merit.edu (Postfix) with ESMTP id 21E1559C56 for <nanog(a)nanog.org>; Mon, 28 Jun 2004 17:12:26 -0400 (EDT) Received: from egate-ne2.uswc.uswest.com (egate-ne2.uswc.uswest.com [151.117.64.200]) by uswgco34.uswest.com (8/8) with ESMTP id i5SLCLSu006141; Mon, 28 Jun 2004 15:12:21 -0600 (MDT) Received: from ITDENE2KSM02.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-ne2.uswc.uswest.com (8.12.10/8.12.10) with ESMTP id i5SLCKCx008243; Mon, 28 Jun 2004 16:12:20 -0500 (CDT) Received: from itdene2km08.AD.QINTRA.COM ([10.1.4.107]) by ITDENE2KSM02.AD.QINTRA.COM with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Jun 2004 15:12:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: BGP list of phishing sites? Date: Mon, 28 Jun 2004 15:12:12 -0600 Message-ID: <9921AB57EA49D242A076864C5F473D3C650089(a)itdene2km08.AD.QINTRA.COM> Thread-Topic: BGP list of phishing sites? Thread-Index: AcRdUpLPcFNCkm3pQvC9Iiw2DaWELgAAelTA From: "Smith, Donald" <Donald.Smith(a)qwest.com> To: "Stephen J. Wilcox" <steve(a)telecomplete.co.uk> Cc: "Scott Call" <scall(a)devolution.com>, <nanog(a)nanog.org> X-OriginalArrivalTime: 28 Jun 2004 21:12:20.0544 (UTC) FILETIME=[9965D400:01C45D54] Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog X-Virus-Scanned: by Telecomplete X-Spam-Checker-Version: Telecomplete X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00=-4.9 autolearn=no 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 > > > > > > > > > > > > >

1 1