North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Has PSI been assigned network 1?

  • From: Curtis Villamizar
  • Date: Tue Apr 18 19:29:50 1995

In message <[email protected]>, Jeremy Porter writes:
> >
> >In message <[email protected]>, Jeremy Porter writes:
> >> 
> >> Pretty bad, we a single DOS machine can hose Internet routing tables
> >> all across the globe.
> >>...
> >> Name: system.sysDescr.0
> >> OCTET STRING- (ascii):	80486 DOS 6.20.Windows 3.10 Enhanced Mode.NetMa
> nage SNMP 4.256
> >
> >
> >Didn't hose our routing.  We consider this a matter of routing hygene.
> >If your going to do full routing you've got to be protected or be very
> >sure about who you are peering with.  :-)
> Well, if you are peering with PSI, or anyone else that trusts the
> Ascend's RIP packets, then you are trusting any end user that
> calls up their terminal server.  

We don't trust our peers.  We only accept routes which they are
registered as providing transit for in the PRDB.  When the RADB is in
use, unless PSI has a route object for in the RADB, we still
won't trust them when they try to pass us 1/8.

> Is there more info on the PRS WG's efforts available somewhere?

The BOF was held at Danvers.  The mailing list is [email protected],
requests to [email protected]  In a nutshell, it is an attempt to
bring RIPE-181 and related documents into the IETF process and make
some extensions to the policy description capabilities to accommodate
some current needs.  Also take a look at and

> A more difficult problem is where a small site is being incorrectly
> announced, and this can be a major security issue.  If someone were
> to exploit this problem, they could signficantly impact the whole net.
> And with source routing they could theortically re-route specific
> IP data streams, without completely interrupting service.

Hey... no kidding.  :-)  You may not be the first to have noticed this.

We do not accept arbitrary routes from our direct customers and don't
accept arbirary routes from our peers.

> This could have a much large impact than even packet sniffers have had
> in the past.

Good thing we use kerberos.

> These problems with regards to route filtering at source and destination
> become even more critical as more people realize the
> true nature of these problems there will come along some people
> that will exploit these holes.

Just preferring routes from on place over another doesn't help since a
more specific route always overrides a less specific.