- NANOG - lists.nanog.org

Blocking SPAM at the source?
by Michael Dillon 31 Jan '97

31 Jan '97

>From inet-access On Fri, 31 Jan 1997, Scott Hazen Mueller wrote: > One way to fix this would be for the sites that own large dialin pools to > firewall their dialins so that they can only do SMTP to their own servers. Is anyone doing this like IBM Advantis, InternetMCI, AT&T Worldnet, etc? If not, why not? Michael Dillon - Internet & ISP Consulting Memra Software Inc. - Fax: +1-250-546-3049 http://www.memra.com - E-mail: michael(a)memra.com

1 0

Re: "portability" of IP Addresses
by Eric Sobocinski 31 Jan '97

31 Jan '97

On Thu, 30 Jan 1997 at 21:09 MST, Pete Kruckenberg <pete(a)inquo.net> wrote: > > On Thu, 30 Jan 1997, Alan Hannan wrote: > > [...] > > Can a provider forbid their customer from announcing allocated > > networks to another provider? Yes. This is the discretion of the provider. Few forbid it completely, but it does happen. More likely you'll see a list of conditions that must be met before this is allowed, perhaps even including a small additional fee to cover the added administrative headaches. > > Assume the following situation: > > ------------------------------ > > > > ISP A gets customer C to sign an agreement for service. ISP A > > allocates network A.B.C.0/20 to customer C. A.B.C.0/20 is a > > subnet of CIDR block A.B.0.0/16, allocated to ISP A by our friends > > at the InterNIC as a non-portable address space. > [...] > > So, customer C goes to ISP B, and says, I'd like to buy service > > from you, and announce network A.B.C.0/20 to you. > > I would think that ISP A would be all for it, since as soon as ISP B > starts announcing the /20, all in-bound traffic will come through ISP B > and relieve some of ISP A's bandwidth. Since ISP A is announcing a /16, > the /20 announced by ISP B would take precedence, being a more specific > route. Why exactly do you think this makes ISP A happy? Most likely the link to ISP B is a link that ISP A would have preferred to sell themselves. And to "relieve some of ISP A's bandwidth" doesn't make ISP A any happier since they have to engineer for that bandwidth anyway for those cases where ISP B fails. Ok, I'll allow that some ISPs get charged by the packet by their upstream provider and thus would have slightly lower overall costs as ISP A under this scenario. I'd be surprised if that difference offsets added costs elsewhere in the average case. > I would think that ISP A would not have much to stand on from a legal > standpoint: > - your contract does not prevent you from buying service from another > provider (I'm assuming this), Probably true, but not necessarily so. There's nothing illegal about an exclusive contract. > and (I further assume) it does not > prohibit you from letting another ISP announce those routes This is a stretch. Chances are that your contract does not specify anything about announcing routes to third parties, but since the larger block was initially assigned to ISP A, it reasonably follows that ISP A can regulate those blocks through separate policy so long as your contract does not say otherwise. Even so, many (most?) contracts these days make sure by proclaiming that addresses assigned by the ISP are not the property of the customer and that the ISP retains some level of control. > - as it stands now (and will until ARIN changes it), ISP A does not > actually *own* an IP addresses, and there is at least one RFC that > makes this pretty clear, as well as several InterNIC policies This is true, but neither do you the customer. > - neither you nor ISP B are prohibiting ISP A from fulfilling their > obligations to you or the rest of your customers by announcing the > /20 separately > - the announcement of the /20 does not cost ISP A anything extra, nor > does it increase any contractual requirements for ISP A In an ideal, well-informed world, these latter two would be true. But they're not. The number of possible problems with external routes multiplies with multiple announcements. Then, when those problems do occur, ISP A and ISP B must both work at fixing things. If ISP B is cooperative, coordination still requires extra time and effort. If ISP B is not cooperative, ISP A either spends much more time trying to troubleshoot ISP B's part, or ISP A gets a black eye when ISP B screws up, or both. As more ISPs learn this, more are writing provisions for it into their contracts. > This is a pretty gray area, though, but I think you have a pretty good > chance to be able to contest what ISP A says. That probably won't make > them go out of their way for you in the future, though. That may or may not be true. An professionally-run ISP is happy to explain the logic behind their policies and work with you to find an adequate solution to your requirements. Questioning their initial ideas might yield better solutions, but forcing your solution over their objections is likely to yield a solution that doesn't fit your ISP's architecture and thus doesn't serve you well. And that WILL make them annoyed with you as well. > Pete Kruckenberg > pete(a)inquo.net Eric Sobocinski sobo(a)merit.net

3 2

Re: Alpha test of MAE filtering capability
by Vince Fuller 31 Jan '97

31 Jan '97

I think that this is the wrong approach. Better to monitor it, prove that it happened, and remove offenders from the IXP's altogether. The IXP contracts should include just such a provision. I don't disagree. Do you have tools for reliably detecting unacceptable default route usage? Until those tools are available and until IXP's agree to police their interconnects, the MAC filtering approach is the only real solution available. Your fellow IXP members are deserving of your trust, until they show that they aren't, and the paternalistic "let's remove the temptation" approach is just offensive. This is a nice thought, entirely approprate for a more cooperative Internet of an earlier age. Unfortunately, today it would seem that "better fences make better neighbors" is a far more practical philosophy. --Vince

2 1

LAST CALL
by Pam Ciesla 31 Jan '97

31 Jan '97

For the February 10 & 11 NANOG Meeting held in San Francisco. Last day for registration is Friday, January 31. To advoid delays at the meeting please send in form of payment ASAP. Thanks Pam Ciesla

2 1

"portability" of IP Addresses
by alan＠mindvision.com 31 Jan '97

31 Jan '97

Greetings: I am curious for perspectives on the use of non portable IP addresses for multi-homing. Can a provider forbid their customer from announcing allocated networks to another provider? Assume the following situation: ------------------------------ ISP A gets customer C to sign an agreement for service. ISP A allocates network A.B.C.0/20 to customer C. A.B.C.0/20 is a subnet of CIDR block A.B.0.0/16, allocated to ISP A by our friends at the InterNIC as a non-portable address space. It should be obvious that customer C is locked in for Y years, and is paying D dollars per year. Ok. With me so far? :-) So, customer C goes to ISP B, and says, I'd like to buy service from you, and announce network A.B.C.0/20 to you. Customer C informs ISP A, for niceties, and ISP A informs them that they cannot do this. If Customer C wants to announce routes to both ISP A and ISP B they must renumber. (source of IP Addresses for renumbering is left to your imagination, ISP A, B, or direct from InterNIC.) Can ISP A enforce this decree? I realize it depends upon the contract, but let's assume the contract doesn't specify. I would think that ISP A would not mind Customer C announcing the network to ISP B, but would make it clear that if Customer C stops the relationship with ISP A, then ISP A would reclaim the address space. Is this intelligent use of IP Address space, draconian practices to discourage multihoming, or probably a miscommunication? -alan -- Alan Hannan email: alan(a)mindvision.com.

3 2

Re: Alpha test of MAE filtering capability
by Chris A. Icide 31 Jan '97

31 Jan '97

At 07:49 PM 1/30/97 -0500, Matthew E. Pearson wrote: > >Or you could just your the RADB Route Servers like a reasonable ISP :) > > Dear Mr. Pearson, I just noticed a message right before this from Stan Barber, directing people to a search engine for NANOG notes. I suggest that you hop on that site and search from something like "default route", "peering" (which ought to be fun to read anyway), and maybe "peering abuse" or something like that. In fact, you may want to browse through the entire site, and become familiar with the last NANOG before you go jumping around and sticking your foot in your mouth. However, you are most likely a busy person, so I'll graciously pass on my thoughts (having attended the most recent NANOG meeting in A2), concerning Mr. Feldman's announcement. During that NANOG, concern was expressed over the ease of abusing the exchange point by pointing a default route at any member of that exchange point. Obviously this only works on an exchange point where any entity can reach any other entity whether or not a peering agreement exists (a feature pointed out by our friends at the ATM NAP's). The solution that Mr. Feldman allows us to at least eliminate possible abuse from non peers. If a peer chooses to commit such abuse, one can just terminate the peering session, a stiff penalty in our current times (considering the increasing difficulty of obtaining valuable peering agreements), and add that entities IP address to the above mentioned filter list on the exhange point switch. We, who were recently a victim of such abuse, will definately use this feature as soon as it is made available. Thank you for your patience while reading my take (and this is only my take) on this subject. Hope to see you at the next NANOG on Feb 10th & 11th. Chris A. Icide Nap.Net, L.L.C.

3 3

Re: Just from curiosity.... (fwd)
by Josh Gilliam 31 Jan '97

31 Jan '97

traceroute (the original), which is maintained by Lawrence Berkeley National Laboratory, already supports this and can be obtained from ftp://ftp.ee.lbl.gov/traceroute-1.4a4.tar.Z (Jan 7 1997). Josh Gilliam -- soil(a)quick.net On Wed, 29 Jan 1997 17:20:30 +0000 (GMT), in message <199701291720.RAA18152(a)alice.wonderland.org>, Peter Galbavy wrote: > This change (and any other new ICMP messages) might be worth incorporating > into the standard traceroute... > > Forwarded message: > > From owner-nanog(a)merit.edu Sat Jan 18 19:35:50 1997 > > Date: Sat, 18 Jan 1997 08:55:31 -0700 (MST) > > From: Ehud Gavron <GAVRON(a)ACES.COM> > > Subject: Re: Just from curiosity.... > > In-reply-to: "Your message dated Fri, 17 Jan 1997 18:21:36 -0500" > > <199701172321.SAA22758(a)widderhen.reston.mci.net> > > To: roy alcala <roy(a)mci.net> > > Cc: Brian Tackett <cym(a)acrux.net>, nanog(a)merit.edu, > > Rob Barron <rbarron(a)acrux.net>, GAVRON(a)ACES.COM > > Message-id: <01IECPNYCFYC8WXTGM(a)ACES.COM> > > Organization: ACES Research Inc. > > MIME-version: 1.0 > > Content-type: TEXT/PLAIN; CHARSET=US-ASCII > > References: <Pine.GSO.3.93.970117162448.21258A-100000@pluto> > > Sender: owner-nanog(a)merit.edu > > > > ftp://ftp.aces.com/software/traceroute/traceroute_new.c > > ftp://ftp.aces.com/software/traceroute/0_readme.txt > > > > This BETA version incorporates two new changes: > > 1: It will show a !A for administratively-prohibited packets (see below) > > 2: It will allow modification of a line terminator from standard <LF> > > to anything else, allowing, for instance, dynamic access from > > web browsers (see www.opus1.com/www/traceroute.html) > > > > Feel free to test. > > > > Ehud > > > > > > > > > > >You see this behavior because your traceroute program does not > > >understand the ICMP "administratively prohibited" (ICMP type 3, code > > >13 - defined in RFC 1812) messages being sent back to it from > > >cpe1.reston.mci.net. > > > > >Cisco routers typically return ICMP messages of this nature to the > > >source of traffic which is being blocked by a traffic-filtering > > >ACL on the Cisco router. > > > > > > > - roy - > > > > > ------------------------------------------------------------------------- > > >| roy alcala | MCI | > > >| IP Development | 2100 Reston Parkway | > > >| roy(a)mci.net | Reston, Virginia 22091 | > > >| beep-roy(a)mci.net (pager) | (703) 715-7425 | > > >| (800) SKY-PAGE PIN 1633689 | (703) 715-7066 FAX | > > > ------------------------------------------------------------------------- > > > > >> > > >> > > >>Anyone have any insights on what causes the following interesting data > > >>from a traceroute? > > >> > > >>10 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 39 ms 36 ms 38 ms > > >>11 * cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 36 ms * > > >>12 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 38 ms * * > > >>13 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 41 ms * * > > >>14 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 194 ms * * > > >>15 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 36 ms * * > > >>16 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 36 ms * 37 ms > > >>17 * cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 37 ms * > > >>18 cpe1-fddi4-0.Reston.mci.net (204.70.176.102) 37 ms * 35 ms > > >> > > > > > -- > Peter Galbavy > @ Home in Wonderland > http://www.wonderland.org/ http://www.whirl-y-gig.org.uk/ http://www.demon.net > Be remembered not for your final destination, but for your journey. >

1 0

Re: Alpha test of MAE filtering capability
by Matthew E. Pearson 31 Jan '97

31 Jan '97

At 05:59 PM 1/30/97 -0800, Robert Bowman wrote: >But any reasonable ISP realizes that by using the RADB servers is wonderful, >but does not come close to preventing an: >ip route 0.0.0.0 0.0.0.0 <innocent ISP> > >But I presume this solution does. This is true... If indeed that is what this solution handles.. ------------------------------------------------- Matthew E. Pearson Vice President of Development Games-Online Inc. http://www.games-online.com

1 0

Re: Alpha test of MAE filtering capability
by Sean Donelan 31 Jan '97

31 Jan '97

>But any reasonable ISP realizes that by using the RADB servers is wonderful, >but does not come close to preventing an: >ip route 0.0.0.0 0.0.0.0 <innocent ISP> Nor can the route servers tell when someone/something blocks packets down at the layer 2 level. Since the route servers are now being paid by the exchange point operators, maybe there is a chance the two could be coordinated. Or at least checked for conflicts? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Alpha test of MAE filtering capability
by Matthew E. Pearson 31 Jan '97

31 Jan '97

At 03:51 PM 1/30/97 -0800, Steve Feldman wrote: >In response to requests from several customers for a filtering solution >at MAE EAST and MAE WEST, MFS WorldCom is developing an automated >system to enable ISPs to control traffic destined for their own routers >and networks. > >ISPs using this service will be able to specify, by IP address, which >MAE-attached routers they wish to accept or block traffic from. > Or you could just your the RADB Route Servers like a reasonable ISP :) ------------------------------------------------- Matthew E. Pearson Vice President of Development Games-Online Inc. http://www.games-online.com

2 1