Telco's write best practices for packet switching networks

Mailman List Mirror (Read Only)
1

### On Mon, 11 Mar 2002 04:49:46 -0500 (EST), Sean Donelan
### <sean@donelan.com> casually decided to expound upon Vadim Antonov
### <avg@exigengroup.com> the following thoughts about "Re: Telco's write
### best practices for packet switching networks":

My simple question is why do exchange point prefixes or backbone
network prefixes need to be announced to peers or customers?

This has been something which has bugged me ever since I connected
a router to mae-east.

I think the main justification one could use (and I don't necessarily agree
with this) is to aide in troubleshooting. Announcing the space may make it
easier for multiple parties to troubleshoot through their backbone. On the
flipside of this argument of course is why not filter that space to only
your NOCs and engineers? Now the counter-argument to that might be that
the space starts to add up in terms of bloating ACLs and such. One could go
back and forth on this all day I suppose including arguments for and against
troubleshooting from production devices vs troubleshooting from a backend
system.

Another reason mae-east was announced at least historically may have been to
help support activities such as the Routing Arbiter Project. I know from
experience that due to the nature of how they were positioned within
exchange points, the routeservers needed to be reachable by Merit personnel.
However, the proper solution there should have been for only Merit's primary
transit provider to carry those routes and possibly filter as much as
possible the space except to Merit.

There were workable solutions even back then. I think we all just chose the
path of least resistance because it was easier and the risk factours were
perceived to be low. We all know that was a false assumption. I remember
the first smurf attack against mae-east and how it knocked out quite a few
peers.

2

Yep, I understand. History is never as neat as we would like. It
may have been suitable in the past. Is it time to change?

I'm not suggesting RFC1918 space for internal backbone routers and IXPs,
but not announcing your internal-only nets would (slightly) increase the
difficulty of attacking the core. It doesn't even require ISPs to agree
on a best practice. A provider can choose to implement it themselves
to protect their own core network.

Perhaps the attacks on core routers aren't bad enough to justify such
a drastic step yet. I get conflicting signals from engineers still
working. Some say they see attacks all the time, others say they've
never seen one on their core routers.

3

On the downside -- this is yet another instance of conflict between
research and operations. Being able to address the (core) routers
directly is an important capability researchers use for tasks like
topology discovery and path/routing characterization. Of course, if
researchers can talk to the routers, so can the attackers .....

  -- Ratul

4

Just because routing protocols use addressing or protocols which are not globally routable doesn't mean that core routers can't be addressed directly. IS-IS neighbours use NSAP addressing and OSI transport to exchange routing information, for example, but traceroute still works.

Joe