Internet failures over the next 3 years

Jeremy Porter jerry at
Wed Jun 23 04:32:29 UTC 1999

In message <E10wZgr-0001ri-00 at>, Alex Bligh writes:
>The issue is not how you authenticate an individual neighbor,
>but how you differentially authenticate the data sent
>from that peer.
>That authentication can be deployed manually (we trust
>that peer entirely so won't filter them down to we require manual
>prefix-list updates from that peer), but it is difficult
>to do manually. IRR based filtering has well known problems.
>There have been a number of suggestions for in-band (i.e.
>within BGP or at least within router) authentication.
>I have not yet seen one with no disadvantages. This is
>not a dissimilar problem to the Usenet2 authenticated
>news issue - it's not generally the direct peer that's
>the problem, it's some of the articles/routes they
>receive indirectly, and mistakenly trust.
>Alex Bligh
>GX Networks (formerly Xara Networks)

This is exactly the problem, the generally deployed security models
today are not any better than "trust no one" or "trust anyone".
The registriest would seem a good idea, but only of limited utility when
not everyone trusts them.  The regional IP registries operate routing
registries so in theory, since no provider I know of has gone on record
saying so, those registries should be authoratative for the "owner" of a 
prefix.  Of course if large groups of providers trust the registry
to maintain the data accurately and honestly, that gives those registries
substantial technical control over routing policy.  (I.e. would be the
the same as dropping a prefix of the registry or delegated provider
dropped the in-addr.arpas.

Largely we don't see conflicts of an actual prefix being announced
by hostile parties, where there isn't a technical parent/child
delegation relationship.  The badness of such an event probably
is why.

The operator community has seemed fairly responsive to real operational
problems, and unresponsive to issues that don't have technical merit.

Its good to have the tools in place and the technology understood
in the event its need, but to some extent just having the tools
is enough (MAPS-smurf/spam).

I suppose when someone finds a quick and dirty hack to remotely
cause BGP sessions to flap between providers on private peering or
public peering points, the "trust everyone" model will have to
examined again.  Largely I feel it would result in ingress filtering
much like smurf attacks have with directed broadcast.

I mean, with the way smurf attacks used to be, I'd never expect to
see a notice from UUnet indicating that one of my customers address
space was operating as a smurf amp, with 4 whole hosts at 256k.  Heck
I wasn't even sure for a long while, if I'd even be able to get anyone
at UUnet security on the phone during a smurf attack.

Actually I see that as the largest reliablity problem, is that
these attacks are not tracked down, and the offenders are never corrected,
because you cannot get in touch with an actual human in the security
department during the 15minutes to 4 hours of an attack.
Even providers that know better. (You know who you are.)

--- jerry at
Insync Internet, Inc.          | Freeside Communications, Inc.
5555 San Felipe, Suite 700     | PO BOX 80315 Austin, Tx 78708
713-407-7000                   | 512-458-9810          |

More information about the NANOG mailing list