Pretty bad, we a single DOS machine can hose Internet routing tables all across the globe. ------------------------------------------ snmpwalk 1.1.1.1 public Name: system.sysDescr.0 OCTET STRING- (ascii): 80486 DOS 6.20.Windows 3.10 Enhanced Mode.NetMan age SNMP 4.256 Name: system.sysObjectID.0 OBJECT IDENTIFIER: .iso.org.dod.internet.private.enterprises.233 Name: system.sysUpTime.0 Timeticks: (610689) 1:41:46 Name: system.4.0 Variable has bad type Name: system.5.0 Variable has bad type Name: system.6.0 Variable has bad type Name: system.7.0 Variable has bad type Name: interfaces.ifNumber.0 INTEGER: 1 Name: interfaces.ifTable.ifEntry.ifIndex.1 INTEGER: 1 Name: interfaces.ifTable.ifEntry.ifDescr.1 OCTET STRING- (ascii): InterRamp-PPP -- ---------------------------------------------------------------------------- | Jeremy Porter (512)-339-6094 Freeside Communications, Inc. info@fc.net | | jerry@fc.net (512)-339-4466 (data) P.O. Box 530264 Austin, TX 78753 | ----------------------------------------------------------------------------

In message <199504172244.RAA29471@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.NetManage 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. Someone pointed out to me in private email that at least Telebit has addressed the problem of PPP negotiated IPs. I would think that, just because someone has invested in bad hardware doesn't excuse the rest of the net from suffering as a result. It wouldn't take much effort to select a major DNS machine say, ns.psi.net or mabye a root name server, or better yet a router at MAE-East, to seriously hose large sections of the net.

Fortunately this doesn't have any operational impact. There have been incidents in the past where major legitimate destinations were accidentally announced by small sites hosing a good portion of the global Internet for hours at a time. Particularly memorable was a 3 continent routing loop involving a bogus route to 140.222 that took nearly half a day for some providers to fix and affected most traffic from some of the providers affected. These get noticed.

Again- A goal of the PRS WG is to make it possible to quite painlessly isolate such problems, at least localizing the problem. Another goals in to make it easier to determine when aggregation (or proxy aggregation) can be preformed without detrimental effects on routing. Based on some earlier mail, this might have some immediate application as well.

Curtis

Is there more info on the PRS WG's efforts available somewhere? 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. This could have a much large impact than even packet sniffers have had in the past. 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. -- ---------------------------------------------------------------------------- | Jeremy Porter (512)-339-6094 Freeside Communications, Inc. info@fc.net | | jerry@fc.net (512)-339-4466 (data) P.O. Box 530264 Austin, TX 78753 | ----------------------------------------------------------------------------

Ascend assures me that the IP address negotiation can be turned off in atleast their 4.4 software release and that this feature has been available for some time.

Well, if it is, it isn't documented anywhere I can find. Then again that's about par for Ascend's documentation. Also note, there are important functional differences between "4.4" on the different models of Ascend boxes, i.e. p50, p400, and Max. -- ---------------------------------------------------------------------------- | Jeremy Porter (512)-339-6094 Freeside Communications, Inc. info@fc.net | | jerry@fc.net (512)-339-4466 (data) P.O. Box 530264 Austin, TX 78753 | ----------------------------------------------------------------------------

The BOF was held at Danvers. The mailing list is prs@isi.edu, requests to prs-request@isi.edu.

This should be rps@isi.edu, and rps-request@isi.edu. elliot

On Tue, 18 Apr 1995, Curtis Villamizar wrote:

...

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

The BOF was held at Danvers. The mailing list is prs@isi.edu, requests to prs-request@isi.edu. In a nutshell, it is an attempt to bring RIPE-181 and related documents into the IETF process and make

actually, i believe the name of the WG (to be?) is RPS instead of PRS for Routing Policy System. :) hence, you need to send list requests to rps-request@isi.edu dsc