145 lines
8.1 KiB
Plaintext
145 lines
8.1 KiB
Plaintext
Unauthorised Access UK 0636-708063 10pm-7am 12oo/24oo
|
|
|
|
DDN - The Defense Data Network
|
|
|
|
The Department of Defense started the major networking scene in the US in
|
|
the late '70s and early 80s. Their first baby was ARPANET (Advanced
|
|
Research Projects Agency NETwork). It was just a development system to see
|
|
how feasible a national computer network would be and to help facillitate
|
|
information transfer between defense researchers (and some university
|
|
projects). The world of InterNET has grown up around that existing
|
|
foundation to become one of the most (THE most?) used network in the world
|
|
as researchers in other nations found they also needed access to
|
|
counterparts around the nation to exchange knowledge and ideas. Well to end
|
|
this simple history I will get back to the DDN and its workings (what little
|
|
I do really know of them) and it structure.
|
|
|
|
The DoD (Dept of Defense) has been maintaining its own separate networks
|
|
ever since ARPANET became a success and was "gobbled up" by the growing
|
|
InterNET structure. The DoD wanted to be able to secure its important work
|
|
and research and to do so it needed to be isolated from the existing
|
|
infrastructure. They decided that a somewhat free flow of information would
|
|
be necessary between constituents and that some kind of framework similar to
|
|
Internet would be beneficial but that access to their systems would have to
|
|
be limited by means more secure than anything available on the public
|
|
Internet system. They developed MILNET for this specific purpose (to carry
|
|
unclassified data traffic between defense contractors and researchers).
|
|
|
|
Beyond MILNET there were also been establish three other military nets under
|
|
the auspices of the Defense Secure NETwork (DSNET). The three were DSNET1
|
|
for Secret data, DSNET2 for Top Secret data, and DSNET3 for special Top
|
|
Secret data (probably weapons systems and plans, and ELINT/SIGINT systems --
|
|
but that is only a guess). These three each had a separate communications
|
|
hub including local and widearea nets. The 3 DSNETS have been combined (are
|
|
being combined) in a unified DISNET (Defense Integrated Security NETwork).
|
|
|
|
The Defense Communication Agency (DCA) was put in charge of maintaining the
|
|
backbones of the defense networks (except ARPANET which is primarily used by
|
|
the R&D community and is maintained by DARPA and is not really associated
|
|
with DDN) as part of the Defense Communication System (DCS). All DDN Nets
|
|
are not part (officially) of InterNET because of the security risks
|
|
involved.
|
|
|
|
The restructuring of DDN into DISNET is a continually evolving project
|
|
(especially in the area of Defense Messaging System - which I know little
|
|
about at this time and WOULD LIKE TO SEE MORE INFO about if anyone knows
|
|
about it ), but I will explain its structure as presently laid out...
|
|
|
|
"(1) Security architecture should include a well-defined set of network
|
|
security services offered to subscribers"
|
|
Services:
|
|
CONFIDENTIALITY:
|
|
1.Mandatory Confidentiality - protects classified data using DDN
|
|
rule based security
|
|
2.Discretionary Confid. - identity based (Need-to-Know) security
|
|
3.Traffic Flow Confid. - protects against disclosure by observing
|
|
\ characteristics of data flow
|
|
\_____See the encrypthion and communities descriptions below for
|
|
more on this.
|
|
|
|
DATA INTEGRITY - protects against (OR ATLEAST TRYS TO DETECT) unauthorized
|
|
changes of data
|
|
|
|
IDENTIFICATION, AUTHENTICATION, AND ACCESS CONTROL : *
|
|
1.Identification- standard name for each system entity (just like
|
|
every net.
|
|
2.Authentication- ensures that a stated identity is correct (HOW???)
|
|
3.Access Control- limits system resources to a correctly identified
|
|
system
|
|
|
|
"(2) Subscribers should not pay for or be hampered by unneedded security"
|
|
^\______ Interesting...who does pay for un-needed security then?!?
|
|
|
|
""(4) Subscribers should share responsibility for security where appro-
|
|
priate" <----<<<< COULD THIS BE A MAJOR DOWNFALL?? Hmm...
|
|
* - As for I,A, and AC(above) These services are subscriber respons-
|
|
ibility except for major communities and subcommunities.
|
|
|
|
STRUCTURE OF THE DDN :
|
|
The primary elements are computers called switches which communicate
|
|
via inter-switch trunks.(DCA owns the switches and leases most trunks)
|
|
|
|
Each subscriber connects to DDN as a HOST or a TERMINAL. DDN serves hosts
|
|
at the OSI (Open Systems Interconnect) network level; the Host - Switch
|
|
interface is the standard X.25 (CCITT). Many of the hosts are gateways to
|
|
other nets (mainly LANs) and the number of gateways is increasing.
|
|
|
|
Special Hosts:
|
|
Montitor Centers (MC) : they manage the switches, trunks, and other
|
|
special hosts.
|
|
Name Server hosts - they translate the addresses of the other hosts
|
|
|
|
Terminal Access Controllers (TACs) - more limited DDN service. Instead
|
|
of a direct Host-to-Switch connection you can connect to a
|
|
TAC (via dial-up) and be addressed as a terminal by DDN
|
|
through TAC. TAC uses TELNET protocol so terminal can
|
|
communicate with a second DDN Host as if directly connected.
|
|
|
|
TAC Access Control Systems (TACACS) - prompt user to login at a TAC
|
|
|
|
Priority Access:
|
|
All DDN switches can handle data packets according to 4 level hierarchy
|
|
system. precedence lavels are assigned to hosts and terminals by the Joint
|
|
Chiefs of Staff. To my knowledge this hasn't been implemented yet.
|
|
|
|
Host to Host Encryption:
|
|
DISNET uses a end-to-end encryption system (E3) called BLACKER. These are
|
|
installed on each host-to-switch path of all hosts including TACs . These
|
|
BLACKER front end devices (BFEs) encrypt all data packets but leave the X.25
|
|
header unencrypted for the backbone to use. The BLACKER system includes a
|
|
Key Distribut-ion Center (KDC) and Access Control Center (ACC) hosts.
|
|
BLACKER is a Class A1 System (under the Trusted Computer System Evaluation
|
|
Criteria / "Orange Book"), and it will be able to prevent a community MC
|
|
from communicating with other MCs in other communities; this will not happen
|
|
for a while and the MC sites will still have a terminal through a TAC
|
|
directly to a switch without going through BFE.
|
|
|
|
Bridges between Nets:
|
|
The plan calls for limited gateways between MILNET and DISNET to allow
|
|
unclassified data traffic (in the form of store-and-forward electronic mail
|
|
in both directions). Data entering DISNET from MILNET will be identified as
|
|
such by the bridge.
|
|
The DDN plans forbid a subscriber from connecting to both MILNET and DISNET
|
|
and also forbids DoD system to connect both to a DDN segment and to a
|
|
segment that does not conform to DDN security structure.
|
|
|
|
Other Stuff:
|
|
To insure that every subscriber system can exercise discretionary access
|
|
control over its resources through DDN, and of DDN resources via the
|
|
subscriber system, DDN requires that all subscribers be TCSEC Class C2
|
|
secure. By september '92 any non-complying system will need OSD and JCS
|
|
waivers or DCA can remove them from the Net.
|
|
|
|
DDN plans to segregate subscribers according to whether or not they meet the
|
|
TCSEC C2 requirement. Conforming systems comprise a Trusted Subcommunity
|
|
within each security level. Within this subcommunity hosts can freely
|
|
communicate. NonConforming systems with waivers will form Closed
|
|
Communities within each level. Direct net communications between
|
|
subcommunities will be prevented by switching logic in MILNET and by BLACKER
|
|
in DISNET except over trusted bridges.
|
|
|
|
|
|
|
|
Downloaded From P-80 Systems 304-744-2253
|
|
|