                     --=] National Security Anarchists [=--
                          --=] Volume I, Issue II [=--
                        --=] Date Release: 06/23/91 [=--


                             == NSA Introduction ==

   Welcome to the second release of NSA newsletter.  We have gotten quite a
   response from our first newsletter, hope you get as much as a orgasm off
   this one.  Now let's get serious...

-------------------------------------------------------------------------------
Table of Contents

 Section    Contents
---------  --------------------------------------------------
   2.0      NSA Introduction
   2.1      Table of Contents
   2.2      5ESS Switch, Software Release Retrofit Procedures
   2.3      Trunk Port Capacity Provisioning for COs
   2.4      ATM Research
   2.5      Teleos: New Access Server Enhancements
   2.6      SunOS /bin/mail Vulnerability/Credit: Sun/Os
   2.7      NSA Information

-------------------------------------------------------------------------------

                     --=] National Security Anarchists [=--
                          --=] Volume I, Issue II [=--
                               --=] Presents [=--

                               == 5ESS Switch ==
                   == Software Release Retrofit Procedures ==
                       == 5E4 to 5E5 Software Releases ==
                             == AT&T 235-105-244 ==


   GENERAL

   This addendum supplements AT&T 235-105-244, Issue 1.03.  It is to be
   placed at the beginning of the manual.  The information included in
   this addendum will be incorporated into the next regular update of the
   manual.

   This addendum is issued to provide changes which have become apparent
   since the last issue of the manual.

   CHANGES TO MANUAL

   Page 5-88, Step (replace)

   3. The following step may be performedin teleprocessing offices to provide
      backup AMA data in the vent that data from the final teleprocessing
      session is lost or mutilated at the host collector.  In performing this
      step, the time interval from now to the system initialization is
      increased by the amount of time required to generate the AMA tape.

      Caution: All AMA data recorded between the final AMA teleprocessing
               session and the initialization will be lost.  Although the
               following step will hlpe ensure the integrity of previously
               recorded AMA data, the amount of AMA data that will be lost at
               initialization time may increase by the amount of AMA data
               recorded during the aforementioned time interval.

      a. For offices that use teleprocessing, an optional manual AMA tape
         writing session to dump secondary AMA blocks can be performed at this
         time (AT&T 235-105-210, Procedure 3.19).  This tape should be saved
         for backup purposes.


   Page 5-89, Step 5a (replace)

    a.  Single-stream office - enter message:

        MSG   OP:AMA:DISK;

        Response:  REPT AMA DISK SUMMARY FOR STREAM STx
                        DISK IS CURRENTLY xx% FULL
                        NUMBER OF PRIMARY AMA BLOCKS IN USE
                        IS APPROXIMATELY: xx

        Comment :  Due to design constraints, there may be a small amount of
                   primary AMA data in use on disk at this point.

                   To read the remaining primary AMA records;, start another
                   AMA teleprocessing or tape session (repeat Step 2).

                   To minimize the loss of AMA records, continue to initiate
                   AMA sessions until the number of primary blocks in use
                   (given by OP:AMA:DISK) reaches an acceptable level given
                   call traffic.


   Page 5-93, Step 4 (replace)

   4. Note 1: If ONTCs are ACTIVE MAJOR/MINOR (that is, duplex) on MCC Page
              1209, uses S as the application parameter (to preserve stable
              calls).  If ONTCs are not duplex, use R sa the application
              parameter.

      Note 2: At this time, CU 1 contains 3 circuit packs that are not
              compatible with the 5E4 software release currently cycling in the
              AM. When CU 1 is forced on-line during the following initalizing
              sequence, the switch will immediately go into a DMERT Level 3
              recovery.  It is essential that the AM boot (42-S-54) be
              performed immediately after forcing CU 1 on-line.

   To perform the initialization, enter the following commands on the EAI Page:

   a. To force CU 1 on-line, enter:

      CMD                 11  Force CU 1 on-line, switch goes into level 3
                              recovery
      Force CU 1? (y/n)   y   Force CU 1 on-line after "y" is entered

   b. To set the apllication parameter, enter the following commands on the EAI
      Page:

      CMD                 42    Sets application parameter mode
      PARAMETER:        S or R  S saves stable calls; R does not

      WARNING: Verify thateither S or R apperas (and is backlighted) to the
               right of the APPL PARMA field on the EAI Page before proceeding.
               If the S or R is not present and backlighted, reenter the 42 and
               S/R commands again before proceeding to the boot.

   c. To perform the initialization, enter the following commands on the EAI
      Page:

      CMD                 54  Full AM boot on new software release
      Boot? (y/n)          y  Boot begins after "y" is entered


   Page 5-94, Section 5.6.7.1 (add after the last sentence)

   As the AM recovers, ovserve the ROP for Asserts.  If any Assers are
   received, analyze them using the Asserts Manual (AT&T 235-600-500).


   Page 5-98, section 5.610.1 (replace)

    1. To verify that AMA is recording properly, enter message:

       MSG   OP:AMA:STATUS;

       Response:  REPT AMA STATUS FOR STREAM STx

                      SEGMENT                STATUS
                    -----------            ----------
                        1                    xxxxx
                        2                    xxxxx
                        3                    xxxxx

                   LAST TIME DISK WRITER WROTE TO DISK hh:mm YY/MM

       Comment: Save the ROP output for use in the next step.

       Note: The percent full (number records) of each of the three SEGMENTS
             will demonstrate the loading of AMA records in the SDS.  Each time
             the SEGMENT gets full, the disk writer writes that particular
             SEGMENT to disk.  The value of the segment has been written to
             disk after the boot.

        a. Enter the following message:

           MSG   OP:AMA:MAPS;

           Response:  REPT AMA DISK MAPS FOR STREAM ST1
                        WRITE PARTITION x READ PARTITION x
                        PARTITION x DISK MAP:
                         FPO:xx  LPO:xx    FPS:xx   LPS:xx
                         FSO:xx  LSO:xx    FSS:xx   LSS:xx
                         FBO:xx  LBO:xx    FBS:XX   LBS:XX
                           .       .         .        .
                           .       .         .        .
                           .       .         .        .
                           .       .         .        .

    2. Re-enter the message:

       MSG   OP:AMA:STATUS;

       Response:  REPT AMA STATUS FOR STREAM STx

                      SEGMENT                STATUS
                    -----------            ----------
                        1                    xxxxx
                        2                    xxxxx
                        3                    xxxxx

                   LAST TIME DISK WRITER WROTE TO DISK hh:mm YY/MM


        a. Enter the following message:

           MSG   OP:AMA:MAPS;

           Response:  REPT AMA DISK MAPS FOR STREAM ST1
                        WRITE PARTITION x READ PARTITION x
                        PARTITION x DISK MAP:
                         FPO:xx  LPO:xx    FPS:xx   LPS:xx
                         FSO:xx  LSO:xx    FSS:xx   LSS:xx
                         FBO:xx  LBO:xx    FBS:XX   LBS:XX
                           .       .         .        .
                           .       .         .        .
                           .       .         .        .
                           .       .         .        .


    3. Note: The amount of time it will take to verify AMA recording depends on
             the amount of traffic on the switch.  If your office has light
             traffic, you should continue with the steps in this manual and
             return to Step 2 (above) 10 minutes until you are satisfied that
             AMA is recording properly.

             Compare the OP:AMA:STATUS output from Step 1 with the
             OP:AMA:STATUS output from Step 2.

             The amount of AMA recorded depends on the amount of traffic on the
             switch.

             To verify that AMA is writing to a segment, compare the percent
             full (number records) of the segments from Steps 1 and 2.  These
             should increase with traffic on the switch.

             When one segment fills, it should be written to disk and a new
             segmentwill begin to fill.  To verify that AMA has written to
             disk, check the LAST TIME DISK WRITER WROTE TO DISK - this value
             should not be 00:00 00/00.

             You can also verify the AMA has been written to disk by comparing
             the output of the OP:AMA:MAPS commands issued in Steps 1a and 2a.
             The second line of the output from the OP:AMA:MAPS gives a number
             after WRITE PARTITION.  Below this are listed the various
             partitions available.  Locate that partition corresponding  to the
             write partition number.  Within this report are values for LPO and
             LPS.  Thse values should increase when AMA is written to disk.

             If AMA has successfully written to disk and is writing into a new
             segment , AMA is recording properly.  If AMA is recording
             properly, proceed to the next section.

             If AMA is being recorded in one SEGMENT, but has not written to
             disk, proceed to the next section but continue to monitor AMA.  To
             continue the monitoring, reenter the OP:AMA:STATUS message evey 10
             minutes until the AMA successfully writes to disk.

             If all SEGMENTS still indicate EMPTY, seek techinal assistance.

             Caution: If at any time you are unsure that AMA is recorind
             properly, do not hesitate to seek technical assistance.


   Page 5-140, Table 5-5

   The first number under the PTN column should read 0 instead of 1.


   Page 5-148, Table 5-12

   The first number under the PTN column should read 0 instead of 1.

-------------------------------------------------------------------------------

                     --=] National Security Anarchists [=--
                          --=] Volume I, Issue II [=--
                               --=] Presents [=--

                      == Traffic Engineering Guidelines ==
                 == Trunk Port Capacity Provisioning for COs ==
                             == EG-TFE-91.010.00 ==


     EXECUTIVE OVERVIEW:

     This guideline provides standards for provisioning trunk capacity (analog
     and digital) in the central office switch.  This capacity consists of the
     forecasted amounts of trunks which terminate on the swithc, sas well as
     some quantity, method , to provide for unidentified, unforecasted
     requirements.  The intent is to ensure the trunk capacity for central
     office switches is engineered to cover the core engineering time frame, in
     such a manner as to meet the unexpected customer demand and/or deployment
     of unforeseen pari gain devices by GTE.

     The existing PCM process authorizes engineering for forecasted switch
     terminations to accommodate the message trunk forecast, the special
     services forecsat, and pair gain host/remote links (future).  This
     guideline provides instructions for the engineering of unforecasted
     miscellaneous switch terminations with COE core job/projects.


     GENERAL DISCUSSION:

     Competition is pushing GTE to respond to the customer on a shorter time
     interval.  In order to accomplish this, they must position GTE to allow
     for rapid Trunk service provisioning.  The availability of central office
     Trunk Terminations through controlled engineering for 5-10% unforeseen
     demand will ensure their ability to succesfully respond to customer demands
     in a timely manner.  The time required from customer request to
     determination of equipment required, ordering, installing, testing is not
     acceptable and is a contributing factor to GTE's loss of customer base.
     Proper provisioning of trunk circuits in the right exchanges is essential
     to responding to customers' needs.

     Agreements are imminent which will provide for planned future pair gain
     devices on the PCM by Planning.  Existing links for pair gain devices will
     be in the POTS/TTE trunk forecast.  Therefore, margin for these links are
     not provided via this process guideline.

     This guideline does not provide margin for the message circuit trunk
     forecast trunks.  The trunk forecasters will not build margin into the
     groups which they manage by the TTE program.  In other words, existing or
     imminent processes provide for switch terminations to accommodate TTE
     forecast and H/R links.

     Planning has concurred with their proposal to provide 5-10% margin for
     trunk terminations in electronic switches.  The decision on the precise
     amount of margin to be order should be made by the Traffic Engineer.  This
     decision will be based on familiarity with the specific wire center and
     service demands which have been experienced over the past several years,
     along with knowledge of the specific switch configuration.  Switches in
     remote, slow growth areas would obviously requirrreless margin than
     switches in metropolitan, high growth areas.  Tandem or class 4/5 switches
     may require larger margins due to the unpredictability of IXC demand.


     GUIDELINE INSTRUCTION:

     The existing PCM process authorizes engineering for forecasted switch
     terminations to accommodate the message trunk forecast, the special
     services forecast, and pair gain host/remote links (future).  This
     guideline provides instructions for the engineering of unforecasted
     miscellaneous switch terminations with COE core job/projects.

     Every core job/project should provision to accommodate unforeseen demand
     for central office trunk terminations in addition to the
     forecasted/projected requirements of the engineering period.  The
     unforeseen demand for trunk terminations will typically be engineered at
     5% margin for rural offices and 10% margin for metropolitan offices.
     Traffic Engineering of more than 10% Trunk Terminations margin will
     require Planning review/approval.

     Services that comprise unforeseen demand are:

         o DID   (on COE Forecast as lump sum)

         o WATS  (when served on trunks)

         o Switched HI CAPS/Switched Data (DTI resources) (This is to be
           forecasted by Market Forecasting as part of the CAF/SAL forecast.)

         o MISC. (analog and/or DTI)

     The central office switch common equipment capacity must be engineered to
     carry both forecasted and unforeseen demand traffic as if all trunks were
     incarry both forecasted and unforeseen demand traffic as if all trunks
     were in service by the end of the core period.  Twenty-four CCS per trunk
     should be used to properly provision the switch's capacity.  Application
     as two-way split fifty percent incoming and fifty percent outgoing is
     recommended unless that traffic engineer knows of local considerations
     which warrant a different application.

     When the engineer has determined the margin for the unforeseen demand, two
     important decisions need to be evaluated: A) exact trunk or T1 quantities,
     and B) associated CCS loads.

     A.  Trunk quantities - The exact number of margin trunks to be added
                            should be based on the TOGEN calculation of
                            required trunking and associated frames.  Both
                            analog and digital margin should be provided
                            (unless a digital switch as been provision with no
                            analog trunks for DID).  Margin trunks should be
                            calculated to fill frames where possible, and
                            consideration should also be given to the TCU
                            layout of the office.

     Note:  In all cases, when digital technology is the switch type, the
            analog trunk frames should be wired so card slots are available
            when shortages occur.  Digital trunk FIUs can hold two QSIC cards
            each, which provides four T1 saaapc lines.  Currently they have to
            pay right-to-use fees whenever a DTFIU is installed.  GTE is
            working to implement TRU fees paid as QSIC cards are installed.
            Once that is the case there will be value to not installing the
            QSIC cards, leaving slots open until they are needed.

     Example 1:  Metropolitan GTD-5 office requires 200 T1 spans for
                 forecasted/known trunking requirements.

                 200 T1 = 25 DTFIU

                  20 T1 - Recommended margin at 10%

                 220 T1 = 27.5 DTFIU

                 Recommendation - Provide 224 T1s to completely fill 28 DTFIUs.
                                  Analyze TCU/FIU layout to assess impact on
                                  TCU requirements. The DTFIU may be eliminated
                                  if it requires an additional TCU.

     Note:  It is understood this example is representative of a "typical"
            metropoloitan office.  Engineering judgement, based on specific
            site characteristics, may require more than 10% to be budgeted and
            installed (with proper approval by Palnning).

     Example 2:  Rural GTD-5 office requires 30 T1 spans for forecasted/known
                 trunking requirements.

                 30 T1 = 3.75 DTFIU

                  2 T1 - Recommended margin at 5%

                 32 T1 = 4.0 DTFIU

                 Recommendation - Analyze TCU/FIU layout.  If the fifth DTFIU
                                  can be built into existing TCU, then provide,
                                  if the fifth DTFIU would require another TCU,
                                  do not provide.

     B.  CCS loads - Once the trunk quantities have been determined, a margin
         trunk group should be built into the trunk summary.  A CCS load of 24
         CCS/trunk should be associated with these margin trunks so that common
         equipment wil be calculated to include these trunks (specific impact
         will be on TPC processors, MF receivers, and registers in the GTD-5
         technology).

     If additional TCUs and/or Digital Trunk FIus are required in the GTD5, or
     additional Switch Modules are requires in the 5ESS, or more than 10%
     margin is required, then Planning must review and provide
     authorization/funding.

-------------------------------------------------------------------------------

                     --=] National Security Anarchists [=--
                          --=] Volume I, Issue II [=--
                               --=] Presents [=--

                               == ATM Research ==
                             == GTE Project 552 ==


        Asynchronous transfer mode (ATM) has been standardized as the target
      transfer mode for B-ISDN.  It is believed to be a highly flexible
      switching and multiplexing technique capable of supporting a wide range
      of broadband and narrowband services.  Although the conceptual view of
      ATM seems attractive, the feasibility of ATM in practice is uncertain for
      real-time services such as full-motion video, especially under the
      assumption that some degree of statistical multiplexing is desirable
      within the ATM network.  The objective of this project was to evaluate
      the technical feasibility and complexity of ATM for the delivery of four
      full-motion video services:  television distribution, video-on-demand,
      videoconferencing, and videotelephony.  The intra-LATA transport of these
      video services over and end-to-end ATM network with a standard B-ISDN/ATM
      interface was investigated.

        The approach was based on a top-down view of the scenario at three
      levels: services, network, and switching.  At the service level, the four
      types of video services and their related end-toend network transport
      requirements were characterized.  The effects of cell losses and cell
      delays on video quality were investigated.  At the network level,
      alternative service topologies were compared to find the preferred
      topology for deployment of each service (see Figure 552-1).  The network
      management and control issues were examined and traffic control methods
      were proposed.  At the switch level, the performance and drawbacks of
      proposed ATM switch architectures were evaluated for the purpose of
      switching full-motion video (see Figure 552-2).  Finally, the end-to-end
      transport requirements were related to the curretn state of ATM
      techonology to draw conclusions about the technical feasibility of each
      video service.



                                     Source
                             ________/    \_________
                            /                       \
                           /                         \
                          /                           \
                         /                             \
                End Office/Base Unit          End Office/Base Unit
                    /        \                    /       \
                   /   . .    \                  /   . .   \
                  /            \                /           \
                 /              \              /             \
               BERLU          BERLU          BERLU         BERLU
                / \            / \            / \           / \
               /   \          /   \          /   \         /   \<- Individualy
              / . . \        / . . \        / . . \       / . . \  Switched
    BISDN ------^-^
    Loops


     Figure 552-1: Preferred service topology for television distribution
                   services.  This topology minimizes the use of network
                   resources, ensures fast response to channel switching, and
                   mitigates ATM transport impairments.



     ____ _______ _________________ _______ _________________ _______ ____
       . |  8x8  | .             . |  8x8  | .             . |  8x8  | .
       . |  SRM  | .             . |  SRM  | .             . |  SRM  | .
     __._|_______|_.___       ___._|_______|_.___       ___._|_______|_.__
                       \     /                   \     /
                        \   /                     \   /
              .          \ /            .          \ /            .
          (8) .           X         (8) .           X         (8) .
              .          / \            .          / \            .
                        /   \                     /   \
     ____ _______ _____/     \_____ _______ _____/     \_____ _______ ____
       . |  8x8  | .             . |  8x8  | .             . |  8x8  | .
       . |  SRM  | .             . |  SRM  | .             . |  SRM  | .
     __._|_______|_._____________._|_______|_._____________._|_______|_.__




     Figure 552-2: A multistage self-routing fabric used in the Fujitsu
                   FETEX-150 ATM switch.  Large ATM switches will be required
                   in order to offer enhanced video services to a large
                   customer base.



     Television Distribution - Among the four video services studied, TV
                               distribution services appear to be the most
                               feasible, but large-scale multicast ATM switches
                               will be required.  A network architecture that
                               allows switching as close to the customer as
                               possible is desirable.

     Videoconferencing       - Network management and control issues are
                               complex; the design, development, and deployment
                               of network suitable for videoconferencing will
                               be a major technical challenge in order to
                               guarantee quality of service interms of cell
                               delay/jitter and loss rate.

     Videotelephony          - For ubiquitous service, the complexity of
                               network level problems (e.g., traffic control,
                               network management) will be significant. Large
                               ATM switches will be required.

     Video-on-Demand         - For true point-to-point VOD, a robust ATM
                               backbone with processing capability for
                               mid-calling signaling will be required. At
                               present, such a network is not feasible,
                               although B-ISDN should have this capability. An
                               area-wide offering is feasible using "local"
                               video gateways installed at either the access
                               nodes or in remote units.

     Overall, it was concluded that ATM techonology is not yet ready for its
     role as a unified means of transport for B-ISDN.  Tha main obstacles lie
     in the areas of network traffic control and the development of large-scale
     switching systems.  Without effective solutions to these problems, any
     ubiquitous offernign of on-demand, full-motion video services on a public
     ATM network is not feasible in the near future.

-------------------------------------------------------------------------------

                     --=] National Security Anarchists [=--
                          --=] Volume I, Issue II [=--
                               --=] Presents [=--

                  == Teleos: New Access Server Enhancements ==


   Multi-Point Token Ring LAN Bridging provides a unique and cost-effective
   solution for customers that need to link multiple LAN sites only on an
   "as-needed" basis, with the speed (dynamic bandwidth) but without the
   incovneience and expense of T1 leased lines.  A Token Ring Interface United
   (TRIU) provides a 4 Megabit-per-second, IBM Token Ring Network-compliant
   interface which supports connections to the AS/400 and other IBM and non-IBM
   hosts, front-end processors and communication controllers that support Token
   Ring source routing.

   The multi-point feature dynamically establishes bridged connections between
   up to 32 remote locations.  The bridged channel is transparent to higher
   layer protocols on the private Token Ring Network.  The IAP6000 Access
   Server supports 56Kbps, 64 Kbps, 384 Kbps (H0) 1,472 Mbps (H10) and even n x
   64 Kbps capability.  For instance, a corporate user, for a given
   application, can "bundle" 4 x 64 Kbps B channels yielding 256 Kbps of
   bandwidth between locations.  H0 channels can be concatenated in this
   similar fashion.  Up to 32 B cahnnel bridge connections may be established
   dynamically, on a call-by-call basis, per single TRIU.  A total of eight
   TRIUs can be supported in a IAP6000 twenty-slot system.

   Fractional T1 support using intergrated access allows the user to permanetly
   assing channels in 64, 384 or 1,472 Kbps increments for heavy usage
   applications.  The user now has the option of defining that a certain amount
   of bandwidth over a single, intergrated network connection be "fixed" (or
   dedicated) for a particular application use.  With private line services
   over the same Primary Rate Interface access line.  For instance, users can
   create hybrid networks and use both switched and private line tariffs to
   optimize their network costs.

   Transparent autoconnect automatically sets up a switched digital call
   providing, in effect, virtual dedicated badnwidth on demand for users who
   cannot justify the costs of private lines.  The IAP6000 Access Server can be
   programmed through the system console to dial a specific remote location and
   leave the connection active.  In this mode, the call is monitored and if for
   any reason the connection is dropped, the IAP6000 Access Server
   automatically re-establishes the call.

   Dynamic event steram reproting enables the IAP6000 Access Server to relay
   network information it recieves from the public switched network to an
   adjunct information processor (PC, mini, mainframe).  The event steram link
   is a 9600 Kpbs, asynchronous, RS-232 interface.  Information provided over
   the D channel, and reported, includes: Calling Party Number Information;
   Called Party Number Infomration; Time and Date of the Call, and Call
   Type (Voice,Data).  Event stream reporting allows the IAP6000 Access Server
   to share ISDN D-channel network intelligence with non-ISDN CPE so customized
   applications such as call screening, call routing (dealer locator),
   automatic call back (for abandoned or busy calls) and secure dial-back
   services for comptuer access can be implemented.

-------------------------------------------------------------------------------

                     --=] National Security Anarchists [=--
                          --=] Volume I, Issue II [=--
                               --=] Presents [=--

                      == SunOS /bin/mail Vulnerability ==
                   == Sun/Os MicroSystem Security Bulletin =
                            == Re/Edited Version ==


============================================================================
System Versions : 4.03, 4.1, 4.11
Architectures   : Sun3, Sun3x, Sun4, Sun4c, Sun4/490_4.1_PSR_A
Obsoleted by    : System V Release 4
Synopsis        : /bin/mail can be caused to invoke a root shell if given
                  the proper arguments.
============================================================================


   Synopsis Description:

   /bin/mail is the local delivery agent for sendmail.  In
   some particular instance, /bin/mail parse its argument incorrectly
   and therefore, mail are being drop into the bit bucket.

   If there are users that has "f" has the second character, you might want
   to try the following: (substitute "af" with anyuser with "f" as second
   character)

   From any machine except mailhost:

   /bin/lib/sendmail -t -v <<END
   From: anyuser
   to: anyuser
   Subject: test
   Cc: af          <-- substitute any username with second character as "f"
   test

   END

   When the mail arrived on mailhost, sendmail process will invoke
   /bin/mail with the following argument "/bin/mail -r anyuser -d af
   anyuser".  Now you are in trouble.  The following are different
   scenarios for /bin/mail.

   [1] /bin/mail -r anyuser -d af  <mailmessages            fine
   [2] /bin/mail -r anyuser -d anyone af ... <mailmessages  fine
   [3] /bin/mail -r anyuser -d af anyone ... <mailmessages  Ah a Bug

    In Case 3, /bin/mail thinks that you want to read mail instead of
    delivering mail.  Therefore, mail messages is lost.

    Now this probably won't work on most Internet Sun/Os Unix systems.  But ah
    this works just dandy on direct dail ups and other networks.  So go out
    and practice your molestations.

------------------------------------------------------------------------------

                          National Security Anarchists
                     "Plagurism is the Basis of Creativity"

                                 ##  ## ###### ######
                                ### ## ##     ##  ##
                               ###### ###### ######
                              ## ###     ## ##  ##
                             ##  ## ###### ##  ##

-------------------------------------------------------------------------------
                          National Security Anarchists
                     "Plagurism is the Basis of Creativity"
                              All Rights Reserved
        Any modifications to this text file is a violation of copyright
                                  - (c) 1991 -
--------------------------------------------------------------------------------



