January 1997 - Test - lists.nanog.org

Alpha test of MAE filtering capability
by Steve Feldman 02 Feb '97

02 Feb '97

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. On Monday, February 17th, MFS WorldCom will begin live alpha trials of this capability at MAE WEST with a small set of providers who have agreed to help us test this service option. We expect to extend the trial to MAE EAST shortly after and will notify you of the exact date. This means participating ISPs can begin filtering traffic to their routers at their discretion once the alpha period has started. Assuming the trial proceeds as expected, MFS WorldCom plans to introduce filtering as a new service option later in 1997. Please contact mae-info(a)mfst.com if you have any questions or concerns about the MAE filtering service. Steve Feldman

2 1

Re: Alpha test of MAE filtering capability
by Vince Fuller 01 Feb '97

01 Feb '97

Entirely agreed. On the other hand I have what is turning out to be a unique (here) point of view about this. I don't want to prevent this kind of theft -- I want to discover it, and remove perpetrators from any IXP where they try it. I don't want to block it. I want to ensure that it is never tried twice. I appear to be in the minority wrt this view. This is a great idea. But do you have any idea how much expert engineer time is involved in tracking down theft of this sort? Most of our employers would much rather spend that resource on tackling the big problems. If you can get the tools (simply having the IXP switch keep a port-to-port traffic matrix would help a lot...), I suspect you'd find a lot of converts to your "minority" view - many would prefer to expose and ostracize the perpatrators of these thefts instead of ignoring them. --Vince

3 2

RE: Alpha test of MAE filtering capability
by Chris A. Icide 01 Feb '97

01 Feb '97

---------- From: Paul A Vixie[SMTP:paul@vix.com] But let me turn it around. With no means of detection, why do we suspect that it's a problem? That is, why doesn't the cause for suspicion also work as a means of detection? Well, here is the way I found mine. We keep usage information on all of our router ports, and one day, my FDDI interface to an exchange point jumps by 10Mbps. I haven't added any customers, and going back to examine my traffic patterns for customer ports, I have no cooinciding traffic increase. However, I do show this increase mainly passing from one Exchange point to the other. After isolation all traffic sources that would have created such a jump in traffic, I come up with a big goose egg. So, my next step was to log some flows from the router at the exchange point, and after pouring through quite a few flows, I begin to see traffic from an entity that my company has absolutely no relationship with. This all takes quite a bit of time. I would not want to judge anyone with partial data. Meanwhile bandwidth paid for by my customers, and engineered based upon my customer's needs is being chewed up. My customers are affected. I would prefer to prevent such events from affecting my customers, who I think would agree with this method. IMHO, as long as money is involved, and as long as someone thinks that they have a chance of getting away with something, they will try it. Chris

7 6

so are we talking product opportunity here?
by Paul A Vixie 01 Feb '97

01 Feb '97

An Alpha and NNSTAT and GateD running as part of a DAS ring that otherwise just has an NSP router and a GIGAswitch port, with a lot of hand tuning to notice "bad" flows, would definitely help discover "unintended transit" situations. Surely there's got to be someone on this list who wants to tackle the opportunity to build and sell such a box.

2 1

Re: Alpha test of MAE filtering capability
by Tony Li 01 Feb '97

01 Feb '97

Entirely agreed. On the other hand I have what is turning out to be a unique (here) point of view about this. I don't want to prevent this kind of theft -- I want to discover it, and remove perpetrators from any IXP where they try it. I don't want to block it. I want to ensure that it is never tried twice. I appear to be in the minority wrt this view. Locks keep honest people honest. Tony

2 1

Re: Alpha test of MAE filtering capability
by salo＠msc.edu 31 Jan '97

31 Jan '97

Entirely agreed. On the other hand I have what is turning out to be a unique (here) point of view about this. I don't want to prevent this kind of theft -- I want to discover it, and remove perpetrators from any IXP where they try it. I don't want to block it. I want to ensure that it is never tried twice. I appear to be in the minority wrt this view. This sounds like a line of reasoning that would argue against filtering in routers: "I don't want to prevent [this activity, whatever it might be] -- I want to discover it..." What sort of filters do you put in your routers? -tjs

1 0

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