Internet failures over the next 3 years
I've been hearing bits and pieces of this report for a few months. It finally showed up on the web Monday. Network Group - An Examination of the NS/EP Implications of Internet Technologies - June 1999 <http://www.ncs.gov/nstac/NSTACReports.html> Its not as bad as I heard. It is definitely written from the bell-head perspective. If it didn't have the compulsive need to compare the Internet to the switched voice network, it would be a better report. I think the report does make a mistake in assuming the government is the source of all NS/EP information. I suspect if you did a survey of all the three-letter government agencies about how they obtained their information and updated anti-virus programs on their super-secret networks for the Melissa and Explorer.ZIP, most of them downloaded the fixes from the vendor web sites just like the rest of us. If they waited for the Black Helicopter (or FedEx) to deliver their 'secure' media they were vulnerable longer since the last several outbreaks occurred on a Friday afternoon or weekend and the fix showed up the following business day. Ignoring the NS/EP part of the report, the operational issues remain. The report does cover most of the major Internet operational vulnerabilities: - The distributed, informal nature of Internet management - The domain name system (DNS) - Critical Internet control software and systems - Procedural errors I'm sure each of us would define the problems a bit differently, but before we get hung up on what "is" is, does anyone care to address the issues as raised? Although you can't put this into your Cisco config, I think this is about as on-topic as we can get for this list. But I would request you at least read the report before responding. Its about 100 pages, and covers a lot of ground. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
I did read the report but I just have a couple of observations/questions. On Tue, 22 Jun 1999, Sean Donelan wrote:
- The distributed, informal nature of Internet management
Well this should be fixed once Worldcom and Bell Atlantic finish their buying sprees and then one of them buys the other.. ;)
- The domain name system (DNS)
Does this report take into account the new security initiatives that Paul talked about at the last NANOG? I certainly didn't read anything that would indicate that it did. That would seem to go a ways towards reducing the huge accident waiting to happen now known as DNS...
- Critical Internet control software and systems
I am not a router vendor, but it seems that adding some sort of auth key to BGP (similar to the auth system of OSPF) wouldn't be all that difficult. You could specify a key for each peer.
- Procedural errors
As more and more of router/device configuration are automated, I would expect to see fewer and less impacting human errors. Just my half a cent.. ;) Tim ============================================================= | Timothy M. Wolfe | Wireless Internet = Get Some | | Chief Network Engineer | 1.800.338.2629 tim@clipper.net | | ClipperNet Corporation | http://www.clipper.net/services/ | =============================================================
- Critical Internet control software and systems
I am not a router vendor, but it seems that adding some sort of auth key to BGP (similar to the auth system of OSPF) wouldn't be all that difficult. You could specify a key for each peer.
In the spirit of Randy Bush: mae-east1#conf t mae-east1(config)#router bgp nnnn mae-east1(config-router)#neighb 1.1.1.1 pass ? <0-7> Encryption type (0 to disable encryption, 7 for proprietary) LINE The password 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)
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
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.
Nor should you expect one without disadvantages. There is a clear tradeoff here between the quality of the authentication and the computational complexity. Some leadership is needed in the ISP community to put a stake in the ground and at least experiment with one of the alternatives. Tony
On Tue, 22 Jun 1999, Tim Wolfe wrote:
- Critical Internet control software and systems
I am not a router vendor, but it seems that adding some sort of auth key to BGP (similar to the auth system of OSPF) wouldn't be all that difficult. You could specify a key for each peer.
There is already a option in the BGP OPEN message to add authentication on a BGP session. However, the RFC doesn't specify an authenitcation method to use. Of course securing the level 4 BGP session without securing the underlying TCP session is a weakness, so there is a proposal to implement an MD5 TCP authentication method. Does anyone know the status of this proposal? Andrew --- Andrew Lange UUNET - Ann Arbor alange@ans.net
There is already a option in the BGP OPEN message to add authentication on a BGP session. However, the RFC doesn't specify an authenitcation method to use. Of course securing the level 4 BGP session without securing the underlying TCP session is a weakness, so there is a proposal to implement an MD5 TCP authentication method. Does anyone know the status of this proposal?
Please see RFC 2385. There are multiple (interoperable) implementations. All you have to do is turn it on.... Tony
- Critical Internet control software and systems
I am not a router vendor, but it seems that adding some sort of auth key to BGP (similar to the auth system of OSPF) wouldn't be all that difficult. You could specify a key for each peer.
FYI: mae-public(config-router)#neigh 192.41.177.1 password ? <0-7> Encryption type (0 to disable encryption, 7 for proprietary) LINE The password I am not sure how many people use it though. Deepak Jain AiNET
participants (7)
-
Alex Bligh -
Andrew Lange -
Deepak Jain -
Jeremy Porter -
Sean Donelan -
Tim Wolfe -
Tony Li