Has PSI been assigned network 1?

Tue Apr 18 22:43:14 UTC 1995

In message <199504181640.LAA16368 at freeside.fc.net>, Jeremy Porter writes:
> >
> >In message <199504172244.RAA29471 at freeside.fc.net>, 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 1.0.0.0/8 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 prs at isi.edu,
requests to prs-request at isi.edu.  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 http://www.ripe.net and
http://www.ra.net/rrinfo.html.

> 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.

Curtis