- NANOG - lists.nanog.org

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

Conference - Preventing the Internet Meltdown
by Hank Nussbacher 29 Jun '04

29 Jun '04

http://www.pfir.org/meltdown -Hank

3 2

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

29 Jun '04

> william(at)elan.net > I've suspicions this maybe Pegasus Web Technologies (AS25653), Good catch William!

2 1

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

29 Jun '04

Why would the other side(new provider) violate ARIN policy and route the space? The court order doesn't apply to ARIN, or the new provider. I'd say it would be a violation of the agreement, but I'm not a lawyer. Just a thought. -M -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Brad Passwaters > Sent: Tuesday, June 29, 2004 12:02 PM > To: Matthew Crocker > Cc: nanog(a)nanog.org > Subject: Re: Can a Customer take their IP's with them? (Court > says yes!) > > > > On Tue, 29 Jun 2004 11:45:40 -0400, Matthew Crocker > <matthew(a)crocker.com> wrote: > > > > The TRO is irrelevant, The courts made the wrong decision, > did anyone > > actually think they would have a clue? > > > > Here is the solution: > > Perhaps before proposing a solution we should make sure that > all the facts > are in evidence. I might suggest since at least some of the > legal documents > are available to you at the url below you take time to read them. > > http://www.e-gerbil.net/ras/nac-case/ > > Its not clear at all that what the courts are proposing is > that the customer be > allowed to keep the addresses forever, just that they have > adequate time > for an orderly move. Its also not clear that NAC won't > receive comensatation > for use of their resources. I think those people who have > done service provider > moves realize that without the help of their old service provider > their life could > well be hellish. If the requirements for the lack of IP > portability are indeed > purely technical and not some effort to hold onto customers > then service > providers have a duty to make almost any reasonable effort to > make the > transition as painless as possible > > -- > > Brad Passwaters > ------------------------------------------ > brad.passwaters(a)gmail.com >

8 8

Re: Can a customer take their IPs with them? (Court says yes!)
by Paul Robinson 29 Jun '04

29 Jun '04

In an attempt to add a little more light than heat to this issue, let me add my .02 Euros. I am not a lawyer although I've had to defend myself in court a few times, so I do know a few things. This is a temporary restraining order. These are commonly issued "ex parte" meaning at the request of one of the parties and may even be done where the other party did not even show up or was given notice. The purpose is to "preserve the status quo." The court apparently - from the description of the TRO - issued it verbatim as the plaintiff filed it. I doubt the court even knew what half the terms on the order meant. I had trouble and I'm somewhat familiar with Internet networking. In the case at hand, it may be that the contract with the provider could in theory have allowed immediate repossession of the IP address space which was loaned to them in the event they changed providers. In which case, if the company that has the particular IP space, allowing them to have their address range "snatched away" from them immediately would constitute irreparable harm, since it can take up to a week for an address change to propagate throughout the Internet. A Temporary Restraining Order is intended to keep things as they are at the time it was issued, until such time as a court has the opportunity to hear evidence and to make a decision. Generally they are issued subject to the following conclusions: 1. The party asking for the order (the plaintiff, here) is quite likely to suffer irreparable harm if the relief requested by the order is not granted. 2. The party to whom the order is issued against (the defendant, here) either will not suffer harm as a result of the order or the amount of harm is minor or substantially less than that which would occur to the other party if the order isn't granted.. There are additional conditions involved, but these are the two most important. Here, allowing the customer to keep the number on a temporary basis while the court decides the issue does not necessarily harm the defending ISP and failing to do so would probably be devastating to the customer. Now, to the extent the customer has other options (such as using the number block which they have been assigned directly) will provide the court with a reasonable solution as to why the TRO should be dissolved after the customer has some reasonable time to correct the problem, e.g. to renumber their systems and advertise the new routes to the various routers and DNS systems might require, say 7-10 days. Also, if the contract between the company and the ISP provides them sufficient protection to allow them the time necessary to renumber and reroute then the need for the TRO becomes moot. However, if the contract was silent on this point or explicitly allowed immediate repossession then the TRO may have been a valid issue in order to preserve the status quo for the time being until the issue can be sorted out. This is the basic reason such decisions are issued, so that things can remain as they are until the court can figure out who is entitled to relief. It does not necessarily mean the customer will win or even has a valid cause of action, it just simply means that it is less catastrophic to the ISP to require they not "yank" the IP addresses from the customer than it would be to allow them to do so, pending the outcome of the actual trial on the merits of the issues involved. Please excuse me if this is obvious, but I thought it might help. -- Paul Robinson "Above all else... We shall go on..." "...And continue!" "If the lessons of history teach us anything it is that nobody learns the lessons that history teaches us." -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/P d-(-)>-- s+:+++ a+ C++ UL--->$ P+ L+>$ !E W++>$ N++ !o !K-- w+>--$ O->- !M-- !V- PS+++>$ PE !Y !PGP t> !5 !X !R tv+ b++++(++++)>++++ DI() D++>++ G> e> h+(+)>$ r> y+**(+) ------END GEEK CODE BLOCK------

1 0

RE: Can a customer take IP's with them?
by Fergie (Paul Ferguson) 29 Jun '04

29 Jun '04

Bravo. - ferg -- "Ray Plzak" <plzak(a)arin.net> wrote: I have assigned the ARIN General Counsel, who is an experienced litigator, the task to review and prepare the necessary filings to either intervene formally in the New Jersey case, or as an amicus. ARIN will be striving to educate the court to understand more accurately the legal and policy issues involved. Raymond A. Plzak President & CEO -- "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

BTW, in which state did this occur? Any additional pointers? Thanks, - ferg -- Alex Rubenstein <alex(a)nac.net> wrote: 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. [...] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

7 8

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

29 Jun '04

"Fergie (Paul Ferguson)" <fergdawg(a)netzero.net> wrote: > 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. No, this is not about taking a phone number. This is about a someone moving to a new apartment in a different part of town, and asking the court to force the owner of the old house to reassign the old street address to him. --Johnny

5 5