In message <E10wZgr-0001ri-00@sapphire.noc.gxn.net>, 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@fc.net Insync Internet, Inc. | Freeside Communications, Inc. 5555 San Felipe, Suite 700 | PO BOX 80315 Austin, Tx 78708 713-407-7000 | 512-458-9810 http://www.insync.net | http://www.fc.net