Re: Alpha test of MAE filtering capability

["Jeff Young" <young () mci net>]

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

- - - - - - - - - - - - - - - - -