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.
I did read the report but I just have a couple of observations/questions.
- 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
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
> - 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
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