hypothetically, if mci enters into an agreement with MAE E/W to allow a list of mac header addresses to have access to our port on a gigaswitch, what reason is there for MAE E/W to share that list with anyone else?

Hypothetically, if MCI enters into an agreement with MFS to purchase a connection to a particular port of a GIGAswitch, what reason is there for MFS to share that port assignment with anyone else? See http://www.mfsdatanet.com/MAE/west.map.html with data like: Ames-Giga/2 198.32.136.12 mae-west.SanFrancisco.mci.net Certainly this data gives away *some* private information, but having that knowledge is often very useful when one discovers bizarre layer two problems. For instance, being able to ascertain that there is no packet loss from you to all devices on the same switch, and n% packet loss to all devices on another switch, without having to requests that MFS diagnose the apparent L3 problem, is very useful.

if there is no peering arrangement between two networks you could assume that the the mac header of one network's interface isn't on the list, right?

You could make that assumption, or perhaps that those two networks choose not to appear at that locality. You could also determine that information by sending a loose source-routed packet with a low ttl and watching where the time exceeded message comes from. Are there good operational reasons to make this data publically available? Do they outweigh the perceived privacy issues? It seems to me that there is no change in the "information leak" than is present in the status quo, and application of interconnect filtering is likely to cause a particular set of problems, some of which are obvious now ("A is on B's list and B is not on A's"), and some of which are perhaps a little more complicated (interactions with broadcast or multicast traffic, subtle distinctions in the way the GIGAswitch forwards frames to ports with filtering enabled, etc., etc.) wherein having this information would be valuable. --jhawk

maybe i'm dense when it comes to things operational, you'd have to ask our noc as they probably have an opinion :-), but i can't imagine why our noc would want to troubleshoot someone elses connectivity problem. i would think that whatever the problem being diagnosed, the noc involved would be the noc of the network which is black-holing traffic or being black-holed and would therefore know about any filtering present. i think that it's our duty to keep a good list of mac addr's on our filter if we choose to filter and to inform those networks with whom we have peering arrangements of the existence of that filter. that way, if the one of our peers changes hardware and does not keep the same mac layer address, we can change the filter to include them. i haven't heard a case against filtering yet (third party routing, etc.) that didn't fall into the category of things that filtering is supposed to prevent. if filtering goes into place and you're doing something non-standard at one of the interconnects, either come clean with the parties involved or... Jeff Young young@mci.net

Subject: Re: Alpha test of MAE filtering capability To: young@mci.net (Jeff Young) Date: Tue, 4 Feb 1997 09:13:45 -0500 (EST) Cc: nanog@merit.edu, feldman@mfsdatanet.com

...

hypothetically, if mci enters into an agreement with MAE E/W to allow a list of mac header addresses to have access to our port on a gigaswitch, what reason is there for MAE E/W to share that list with anyone else?

Hypothetically, if MCI enters into an agreement with MFS to purchase a connection to a particular port of a GIGAswitch, what reason is there for MFS to share that port assignment with anyone else?

See http://www.mfsdatanet.com/MAE/west.map.html with data like:

Ames-Giga/2 198.32.136.12 mae-west.SanFrancisco.mci.net

Certainly this data gives away *some* private information, but having that knowledge is often very useful when one discovers bizarre layer two problems. For instance, being able to ascertain that there is no packet loss from you to all devices on the same switch, and n% packet loss to all devices on another switch, without having to requests that MFS diagnose the apparent L3 problem, is very useful.

...

if there is no peering arrangement between two networks you could assume that the the mac header of one network's interface isn't on the list, right?

You could make that assumption, or perhaps that those two networks choose not to appear at that locality. You could also determine that information by sending a loose source-routed packet with a low ttl and watching where the time exceeded message comes from.

Are there good operational reasons to make this data publically available? Do they outweigh the perceived privacy issues?

It seems to me that there is no change in the "information leak" than is present in the status quo, and application of interconnect filtering is likely to cause a particular set of problems, some of which are obvious now ("A is on B's list and B is not on A's"), and some of which are perhaps a little more complicated (interactions with broadcast or multicast traffic, subtle distinctions in the way the GIGAswitch forwards frames to ports with filtering enabled, etc., etc.) wherein having this information would be valuable.

--jhawk

Jeff, Initially, I thought that you were right, but on second thought I see a problem. If a peer of yours is giving someone third party routes, this filtering will blackhole traffic. While your peer should not be giving these routes with your router as the next hop, it will happen and we need a way to debug it.

Direct peering - use next-hop-self. May be problematic in that it will load your FDDI more (esp problematic if you've got a NetEdged FDDI bridge thing). RA peering - this is a bit more of an issue. Suppose A gives/sells some routes to B through the RA including those of C who B peers with through the RA. A doesn't peer with C. The RA will send C's routes to A with a next hop of C's router and they'll presumably be black holed. Obviously the simple solution in this case is for A and B not to be so ridiculous and direct peer or use a serial lead or something, but I wonder if there are other less obvious problems. One of the nasty things about filtering is that a non-obvious RA misconfiguration might lead to blackholing, possibly hurting other networks than the one responsible for the misconfig. Maybe gated can be hacked to always return the next hop of intermediate peer (B here). Mmmm... Tool for configuring filtering straight from the RA anyone? Alex Bligh Xara Networks

Erik

...

...

I din't see an answer on this one....

...

---------- From: Andrew Partan[SMTP:asp@partan.com] Sent: Saturday, February 01, 1997 10:55 PM To: feldman@mfst.com Cc: nanog@merit.edu Subject: Re: Alpha test of MAE filtering capability

...

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.

Are you going to post the list of permitted/denied addresses?

Operationally it would be *very* useful to know what addresses are blocked. --asp@partan.com (Andrew Partan)