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