Security at Line Speed Workshop Internet by liaoqinmei


									Security at Line Speed Workshop
Workshop Findings and Report
2003 November 08
Version: 1.1

The Security at Line Speed Workshop was held 11-13 August 2003
in Chicago, IL. The workshop was a working meeting attended by
a limited number of invited participants. The goal of the workshop
was to disseminate information on problems, discuss potential
solutions and identify areas requiring additional research. This
document summarizes the workshop’s discussions that covered
both technical and non-technical issues. Current practices and
known problems are identified and explained through case studies.
Known barriers are addressed through suggestions and a proposed
research agenda.
Security at Line Speed Workshop Report                                                                                   November 2003

Security at Line Speed Workshop
- Workshop Findings and Report
Version: 1.10 (final), 2003 November 08

Executive Summary ........................................................................................................................ 3
1: Introduction ................................................................................................................................ 4
   1.1: Framing Network Security and Performance...................................................................... 4
   1.2: Nature of the Research and Education Community ............................................................ 5
   1.3: Tradeoffs and Tensions....................................................................................................... 6
   1.4: Trends, Patterns and Predictions......................................................................................... 6
2: Technologies .............................................................................................................................. 8
   2.1: Network Based Technologies ............................................................................................. 9
   2.2: Host Based Technologies.................................................................................................. 12
3: Approaches............................................................................................................................... 14
   3.1: Host Scanning ................................................................................................................... 14
   3.2: Host Based Intrusion Detection ........................................................................................ 15
   3.3: Perimeter (Stateful) Firewalls ........................................................................................... 16
4: Case Studies/Examples ............................................................................................................ 18
   4.1: Case #1: Generic Academic Case ..................................................................................... 18
   4.2: Case #2: Novel Academic Alternative.............................................................................. 19
   4.3: Case #3: LBNL and Bro.................................................................................................... 21
   4.4: Case #4: Lightly Authenticated Wireless Network........................................................... 22
   4.5: Case #5: Denial of Service................................................................................................ 23
   4.6: Case #6: Network Auditing at Carnegie Mellon............................................................... 24
   4.7: Potential Case Topics........................................................................................................ 26
4: Non-Technical Issues ............................................................................................................... 26
5: Planning for High Performance Security ................................................................................. 27
   5.1: Research Agenda .............................................................................................................. 28
6: Conclusion................................................................................................................................ 29
Appendix 01: Security at Line Speed Workshop ......................................................................... 31
Appendix 02: S@LS 2003: Attendees.......................................................................................... 31
Appendix 03: Additional Comments from Participants ............................................................... 32
Appendix 04: Tradeoffs and Tensions Described ........................................................................ 33
Appendix 05: Non-Technical Issues and Recommendations ....................................................... 35
Appendix 06: Research Agenda ................................................................................................... 38
   06-1. Network Directed Solutions............................................................................................ 38
   06-2: Host Directed Solutions.................................................................................................. 39
   06-3: Research Agenda: Management Directed Solutions ...................................................... 40
   06-4: Research Agenda: Field Leadership ............................................................................... 41
Appendix 07: Version History...................................................................................................... 41

Page 2 of 41                                                                                filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                              November 2003

Executive Summary
“2003 may mark a turning point in the viability of networking as we have known it.”
       - Terry Gray, University of Washington
It is increasingly difficult to couple the performance requirements of advanced applications with
the necessities of prudent network security. It has always been a challenge to realize high-
performance from the mesh of systems, software, local connections and national backbones that
compose the typical advanced, computational environments that much of the research community
uses. Now, with increases in network threats over the last several months, the defensive security
actions that many enterprises must take offer several depressing prospects.
- First, these actions significantly compound the problem of delivering high performance
     networking, where high performance represents a broad set of needs including bandwidth,
     latency, multi-protocol support, and port agility.
- Secondly, the defensive actions, while somewhat effective in the short-term, may be
     ultimately doomed themselves, as new technologies could render them ineffective.
- Thirdly, the increased complexity of networks will make troubleshooting more difficult.
- Lastly, and perhaps most profoundly, they undermine the basic principles of the Internet,
     including end-to-end transparency and open access, and so may stifle the innovation that has
     characterized the network to date.

Solutions exist, but they are not easy
There are good steps for campuses and national research facilities to take that will support some
advanced applications. There are network architectures and technologies that are useful, though
their value to individual campuses depends on local conditions as diverse as traffic loads and
distribution of academic departments on campuses. There are steps that the research community
can take to adapt their protocols and approaches to better fit the realities of the current level of
security threats. The use of layered authentication and authorization services offer new
opportunities for security. The traditional benefits of education and awareness, mixed with
appropriate policies, remain; we have had a number of recently teachable moments. Taken
together, they can do much.

But they may not be sufficient.
Applied security research, well anchored in the realities of performance issues and network
constraints, could significantly advance the future options available. Some of those alternatives
may present their own challenges in deployment, in expense, a need for a flag day, management
integration, etc. The investment in research and deployment may need to be considerable.

The future open networks will require new research
The consensus of the workshop was that the state of networking is at a crossroads. If no action is
taken, we will continue to see attacks, experience pain and create barriers that will eventually
hinder the ability for the network to support the original goal of the Internet. Open networks
capable of supporting a variety of users and uses are possible, but will require research. This
paper identifies research areas that will begin to address the problem.

- Security At Line Speed Workshop Participants, 2003 October

Page 3 of 41                                                    filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                              November 2003

1: Introduction
The Security at Line Speed Workshop (S@LS) was held 12-13 August 2003 in Chicago, Illinois
through an NSF grant (ANI-0310414) and with the support of Indiana University, Internet2, the
Massachusetts Institute of Technology and the University of Washington. S@LS’s goal was to
disseminate information on problems and solutions regarding the intersection of security and
advanced, high-performance networking (additional information about the workshop and
attendees is available in Appendix 1 and Appendix 2). Our concern here is to identify ways in
which technologies can support transparency at line speed, identify effective implementation
practices, outline relevant research topics and note non-technical aspects important to security.
This document captures topics discussed during the workshop and is designed to act as a
foundation allowing future work to respond to the dynamic and rapid changes in the field. Many
of the ideas in this paper are still up for debate between intelligent, rational individuals. We will
identify this type of impasse with the abbreviation “JSO,” or “jury still out.” We hope to
investigate these issues more thoroughly in subsequent versions. The appendices cover related
subject matter and delve deeper into specific topics.
The ongoing Security at Line Speed Project hopes to maintain this document to reflect changing
needs and pressures. The most recent version of the website will be made available on the
Internet2 website at: <>. We hope you find this document useful.
To submit contributions to it, please send them to <> for review.

1.1: Framing Network Security and Performance
One could argue that security and performance are competing aspects of networking. Improving
security often degrades performance; improving performance often degrades security. These
generalizations often mask sloppy implementations or hide details. To clarify, we explain what
we mean when these terms are used in this document.
We define performance against several standards. The first are a set of hard metrics. Latency,
loss, jitter and throughput are all easily measurable and results can easily be compared. End-to-
end clarity is harder to measure, but can be described as a connection between host machines that
does not introduce any impediments to the listed metrics allowing connections to take full
advantage of the connection without blocked ports, throttled bandwidth connections,
opaque/obscured IP ranges.
Measuring security metrics is more difficult. Unlike performance metrics, security metrics are
Boolean- or at least discrete. Further, a given security measure may suddenly lose its
effectiveness. It is difficult to identify any metric that would measure security other than “it has
not yet failed.” However, we can describe fundamental threats that encompass a majority of
security issues:
- Information Leakage: Access to data by unauthorized persons
- Integrity Violation: The destruction, modification, or falsification of data
- Illegitimate Use: Access to resources (processing cycles, storage, or network transmission
    capacity) by unauthorized persons
- Denial of Service: Preventing legitimate users from accessing resources
The metrics for performance and security are orthogonal. They cannot be compared to one
another directly. However, we can determine the way the two interact through the following
1- what general security approaches minimizes negative impact on performance?
2- what general performance approaches minimize negative impact on security?

Page 4 of 41                                                    filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                            November 2003

The technical approaches outlined in this document address the above questions from host and
network focused solutions. The Network Based Technologies and Host Based Technologies
tables in Section 2 further divide solutions into a four-step security lifecycle: prevention,
detection, reaction and analysis.

1.2: Nature of the Research and Education Community
During the workshop, participants identified a variety of fundamental principles about users in the
research and education (R&E) community, user needs, resources and technology. Some are
contradictory or support competing views, highlighting the tradeoffs and tensions inherent in all
complex systems. These views are summarized below.
        Users and uses are distinctive
        - Broad set of roles, such as faculty, staff, students, alumni, and prospective students,
           with different needs and permissions
        - Distinctive and challenging privacy requirements, including freedom of expression
           and of access to library open stacks
        - Conflicting needs and roles of users, systems administrators and network operators.
        Research and education network management is different than traditional
        corporate network management
        - Corporations are often top-down monocultures while R&E organizations encourage
           autonomous and diverse business units with differing needs. Policies favoring
           security at the expense of innovation are problematic for R&E organizations.
        - Host management is usually highly distributed and/or autonomous, leading to
           inconsistent patch levels, security settings etc.
        - We need to worry about traffic from the “outside” headed into campus networks as
           well as traffic originating from the “inside” of campuses
        - R&E organizations can be thought of as a "University of a Thousand Years"
           accumulating needs and technologies over their entire lifespan. They must
           accommodate much larger variety of technologies, activities and applications than in
               - Networked X-ray machines, spectrometers, coke machines, and embedded
                    operating systems in specialized equipment
               - Custom and outdated systems
               - Anonymous access to information (e.g., libraries)
        - There are legitimate and distinctive needs for novel network applications
        - Inter-realm collaborations predominate and create wide-area networking
        Resources are limited, needs are legion
        - When resources are limited, they must be applied in a manner that reflects priorities
        - Security measures needed to prevent the crippling of entire networks may constrain
           the ability to accommodate advanced users
        We have many types of mobility requirements:
        - Our users typically use several machines a day
        - Our machines often serve many different users per day
        - Users move their machines between networks (e.g., campus and home)
The understood danger is that if these principles are not acknowledged, progress will be limited
as politics, rather than sound technical reasoning, will drive policies and other decisions. The
drive for general campus security must take a multi-faceted approach.

Page 5 of 41                                                  filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                            November 2003

1.3: Tradeoffs and Tensions
The principles outlined above frame a set of tradeoffs and decisions that must be made when
creating a network. The tradeoffs are fully described in Appendix 04: Tradeoffs and Tensions,
and are summarized here:
- Security vs. Performance: Prioritizing effort (Security, performance and money)
- Deny/Allow vs. Allow/Deny: Supporting varieties of users
- Central vs. End User Management
- Unauthenticated vs. Authenticated Access to Network
- False Positives vs. False Negatives: Controlling metrics, volume and noise
- Host vs. Border Security
- Server vs. Client: Supporting servers in a client-centric environment
Imagine a large, active, network environment consisting of several departments. A vast majority
of users do not have the desire to maintain or optimize systems for performance and security.
Thus, a fundamental decision for the network as a whole is if the network will support an open
disposition via Allow/Deny rules or if a central body will attempt to protect the majority of users
from known attacks by implementing Deny/Allow rules. The importance of this decision is a
function of the policy enforcement point; implementing Deny/Allow can frustrate users by
obscuring networks. Increasing numbers of users desire the ability to control their anonymity and
privacy. Users desire to operate in an autonomous, protected network environment, separate from
the risks “out there” while being able to fully utilize the resources that exist “out there.”
This decision brings up the discussion of how much network and host administration should be
controlled centrally and how much should be pushed to departments and then to end-users.
Central management can come in the form of authenticated network access, desktop management,
enterprise-wide security settings, etc. Or, end users can take the onus of maintaining machines
that will not aversely impact other users. In either case, the need for capable tools that are
straightforward to implement and use is critical. In either scenario, some form of central control
is needed, if for no other role than policing.
Centralized management can describe campus-, department- or group-centric efforts.
Independent of the actual size, administrators will need tools that effectively address problems.
Currently, some (IDS, IPS) tools have problems with false negatives and false positives as well as
the inability to effectively control the volume of alarms that are generated.
Once these issues are addressed, there is the final question of prioritization. What solutions and
user groups should be given priority? A large network will have users who assume that others are
addressing security. These users will more easily notice security disruptions than performance
bottlenecks. However, this type of campus will have departments running demanding
applications. One group might have bulk data-transfer needs that will saturate the campus’s
network connection for hours at a time. This group might petition to divert funds to a dedicated
network connection, even though the connection is only used one week per year. Another group
will periodically run HDTV or AccessGrid videoconferences where eliminating jitter is critical.
They might ask to have a variety of holes opened in the firewall to support their application. Grid
based computing will introduce a variety of servers onto the network that use dynamic ports.
Balancing user needs with technical solutions will require careful analysis. No easy solutions
exist, but the core belief that research and education networks are used to push what is possible
must be kept in sight.

1.4: Trends, Patterns and Predictions
Over the past few years, a variety of forces have pushed networks down several paths. These
forces include the tensions and tradeoffs mentioned above, as well as less controllable elements

Page 6 of 41                                                   filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                            November 2003

such as active attacks (viruses, worms), commoditization of hardware (802.11a/b/g, NAT) and the
realization that non-network administrators (e.g., users) are beginning to exert their influence on
the network.
Highlighted are several trends, patterns and observations discussed during the workshop and
follow up discussions that are worth noting. These are not comprehensive, but are indicative of
the changes that are upcoming if not currently underway.
        Attacks, Malware And Maliciousness
        - More aggressive and frequent attacks forcing
               - Investment to protect net infrastructure as well as hosts
               - Realization that individual host patching can't work
        - User-induced Malware (viruses, spyware) forcing:
               - Lockdown of desktop s/w configuration
               - Host validation before connecting mechanisms
        Outside Forces
        - RIAA: forcing rapid development/deployment of encryption, soon to be used
           routinely by malware
        - Microsoft: forcing increased port blocking
        - Legal requirements for security and privacy are increasing
        Changes in Applications
        - Port blocking forcing:
              - Increased tunneling ("firewall friendly" apps)
              - Increased use of VPNs
        - More VPNs:
              - Higher support costs, and cost shifting
              - Dominant attack vector becomes VPN
              - Pressure to block the same ports that caused use of VPNs
        - P2P nets: forcing
              - Recognition of yet another attack vector
              - Action by RIAA
        Changes in Technology
        - Higher speeds: forcing more expensive middle-boxes
        - Convergence: forcing topological isolation vs. functional isolation
        - Weak end-system security forcing network firewalls
        - Network firewalls forcing:
               - Increase in mean time to repair (MTTR)
               - Cost-shifting from "guilty to innocent"
               - L.C.D. policy conflicts
        - LCD policy conflicts: forcing pressure to have separate networks for different
        - More regulation and financial/legal liability forcing more closed networks
        Specific Events in 2003
        - Rise of more dangerous attacks
        - Rise of more attack vectors (P2P, Spy ware, Windows :)
        - Rise of wireless (802.11) connectivity
        - Death of open Internet (and realization that users may want asymmetry)
        - Death of unmanaged autonomous PC
        - Death of reliable Internet email (mostly due to spam, but some malware is spam

Page 7 of 41                                                  filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                         November 2003

        Trend Impact on Solution Space
        - Encryption will negate stateful packet inspection middleboxes
        - Tunneling will negate port blocking
        Potentially Encouraging Signs
        - Microsoft Windows XP SP2 will turn on integral firewall by default
        - Recognition that IPSEC trust fabric deployment must be simplified
        - Users are now aware of security; anti-virus software is part of routine maintenance
           (like oil changes for cars), security practices may follow the same path.

2: Technologies
S@LS participants spent several hours discussing various approaches and technologies that
support security and performance. Marty Schulman of Juniper Networks summarized the
discussions in a very concise and useful table, presented here with minor edits.
The table is split into two sections describing Network and Host based technologies. The
numbered rows describe techniques, general issues, performance aspects and operational impacts.
Four columns indicate if the techniques are preventative, detective, reactive or analytical in
A few elements were not explicitly discussed during the workshop. For completeness, Schulman
added comments he believed appropriate with the caveat that they might be vendor specific.

Page 8 of 41                                                filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                                                                                       DRAFT VERSION

2.1: Network Based Technologies

                            P   D   R    A
                            R   E   E    N
#    Technique              E   T   A    A   Description                         General Issues                    Performance Aspects              Operational Impacts
1    Host scanning          X   X            Actively measure a computer’s       The amount and integrity of       Scanners need to be              Institutions have varying
                                             responses to determine its          information returned varies.      distributed to scale. At what    policies on how infected
                                             vulnerability (i.e. unpatched OS)   Some hosts are transient.         point does it become a burden    systems are repaired and the
                                             or state of infection. Indicators   How often to scan?                on the network? How big can      standard of proof. Concern
                                             include response to TCP or UDP                                        the database get?                over cutting off connections
                                             ports, TCP ISN, http server                                                                            during critical research
                                             headers.                                                                                               phases, or for key personnel
                                                                                                                                                    (i.e. Deans, Nobel laureates.)
2    Link Registration      X                Collect information upon link-      Good trigger for initial scan –   Fairly low-frequency event       A comprehensive
                                             layer initialization (i.e. DHCP,    and can be used to deny link-     typically, so little             implementation could benefit
                                             ARP, PPP) about host type, OS,      layer access or impose access     performance impact. Will         configuration/asset
                                             or use as scan trigger.             restrictions. 802.1x (unique      WiFi change that?                management.
                                                                                 to Ethernet) is not sufficient.
3    VLANs                  X       X        Separate departments into           Ideal to send user to a special   One Ethernet switch vendor       Departments span multiple
                                             different subnets. Users can be     VLAN where they can only          can isolate a port in 200 ms –   subnets, and some subnets
                                             put into VLANs if scans             fix their problem – but how       user would like this to be       shared – creates policy
                                             determine they are                  do you notify user? Captive       faster.                          conflicts.
                                             compromised.                        portal? They may try email –
                                                                                 looks like network failure.
4    Encrypted VPNs         X                Provide bulk cryptographic          Not much discussion –             (Vendor comment: this is         Key management is not
                                             protection of traffic with IPSec.   preference for host-based         available at Gbps speeds.        mature. This might break
                                                                                 tunnels.                          Jumbo frame support coming       IPSec.
5    Layer 3 VPNs           X                Isolation of traffic through        Not much discussion.              (Vendor comment: available       Not much discussion (Vendor
                                             separation of forwarding tables                                       equipment scales to hundreds     comment: management tools
                                             for different Federations.                                            of VRFs with 1000’s of prefix    lacking.)
                                                                                                                   entries each.)
6    Stateless Network      X   X   X        Also known as “Access Control       Universally considered useful     Routing industry has line-       Wide variations on site
     Firewalls                               Lists” or “Multi-field              (where supported by network       speed performance.               policies (whether preventive,
                                             classifiers” - make packet-         equipment.)                                                        reactive, or neither) to avoid
                                             handling (forward, drop, count)                                                                        breaking apps or creating
                                             decision based on contents of                                                                          second order outages (i.e.
                                             each packet. Source address                                                                            DNS outage.) Some baseline
                                             verification prevents campus                                                                           behavior as input to decision.
                                             from sourcing attacks.

Page 9 of 41                                                                                                                            filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                                                                                       DRAFT VERSION

                            P   D   R    A
                            R   E   E    N
#    Technique              E   T   A    A   Description                          General Issues                   Performance Aspects              Operational Impacts
7    Source Address         X   X            Also known as Unicast Reverse        Not uniformly deployed.          Routing industry has line-       Several modes available to
     Verification                            Path Forwarding check, checks        Reduces volume of sourced        speed performance.               deal with dual homing,
                                             for valid source address.            DDoS traffic from viruses                                         though the protection is
                                             Documented in IETF RFC               that spoof.                                                       slightly weaker.
                                             2827/BCP 38.
8    Stateful Network       X   X   X        In-line function that drops,         Both distributed and             Beware vendor claims of          Some environments need
     Firewalls                               forwards, counts, and/or             centralized approaches are       scalability – load balancing     departments to control, but
                                             modifies packets based on            used – no consensus.             breaks applications or doesn’t   greatly complicates end-end
                                             contents of that packet or           Requires consideration by        scale. Single-device 6 Gbps      troubleshooting, path MTU
                                             previous packets in the flow         applications designers (when     performance demonstrable.        discovery.
                                             according to site security policy.   address/ports embedded in
                                             May also incorporate NAT.            data.)
9    NAT/PAT                X                In-line function to translate        Same as above, though twice-     Gbps NATs rare at this time.     It also greatly complicates
                                             source and/or destination IP         NAT can make things even                                          end-end troubleshooting.
                                             address (and port numbers) to 1.     more complicated. Unclear                                         Requires coordination if
                                             conserve address space, 2.           whether IPv6 local scope                                          RFC1918 address space is
                                             conceal presence of hosts or         addressing will carry forward                                     used.
                                             addresses, 3. limit access to        issues.
                                             hosts. May incorporate firewall-
                                             like functions, or be considered
                                             “poor man’s” firewall. See RFC
10   Port Mirroring             X        X   Replication of packets (possibly     Useful to feed IDS or data       Routing industry has line-   There is uncertainty on the
                                             selective) for remote archive        capture, (e.g. for lawful        speed performance.           implications of viewing
                                             and/or analysis.                     intercept)                                                    potentially private
                                                                                                                                                information, particularly in
                                                                                                                                                medical environments (where
                                                                                                                                                HIPAA applies.)
11   Probes                     X        X   Uses electrical splicing or          Interfaces available for all     Existing adjunct CPUs unable Same as Port Mirroring.
                                             optical splitters to replicate       link types, but still entails    to handle load of desired
                                             packets for external capture and     additional hardware device.      analysis algorithms.
12   Network Intrusion          X        X   Typically out-of-band, real-time     Inbound S/N is low; outbound     While there was a desire to      Not ready out of the box –
     Detection (NIDS)                        or near-real-time analysis of        is useful but late – indicates   make analysis real-time, there   needs skilled employee(s).
                                             traffic. Can be based on             when machines are already        was little performance           Need sharing of signatures,
                                             signatures, anomalies, or            compromised.                     concern either because CPU’s     anomalies, and events for
                                             behavioral.                                                           can be added, or near-real-      (meta-language) for inter- and
                                                                                                                   time is sufficient.              intra-vendor products.

Page 10 of 41                                                                                                                           filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                                                                                         DRAFT VERSION

                             P   D   R    A
                             R   E   E    N
#    Technique               E   T   A    A   Description                        General Issues                     Performance Aspects               Operational Impacts
13   Network Intrusion           X   X    X   Use of IDS to trigger response –   Several interesting                Answer to scalability is          Same as above.
     Prevention (NIPS)                        can be in-line, or controls in-lineexperiments at LBNL –              “throw hardware at it.” No
                                              element. Includes “autonomic       integration of existing            concerns about
                                              techniques.”                       components seen as key.            responsiveness –want to make
                                                                                 Some concerns that IPS could       it real-time, but people accept
                                                                                 be used fooled into blocking       it will slow – not stop –
                                                                                 legit users in future attacks.     infection.
14   Flow Export                 X        X   Capture of information about       Overall agreement of the           Little discussion on state of     There is uncertainty on the
                                              flows – packets sharing common value of the technique – in            current implementations –         implications of archiving or
                                              address, port information part of many cases, top talkers are         though it was stated that         viewing potentially private
                                              same conversation. Inherent        “bad guys” or infected. No         sampled data is not adequate      information, particularly in
                                              data reduction.                    discussion on whether              for some purposes. It may be      medical environments (where
                                                                                 asymmetric routing (not            possible for an attacker to       HIPAA applies.)
                                                                                 uncommon for dual-homed            overwhelm collector
                                                                                 sites) limits its utility. Good    infrastructure.
                                                                                 input to decision whether to
                                                                                 install stateless firewalls.
15   User Registration       X                LAN-based user is required to      Use is growing and no issues       None expressed.                   None expressed.
                                              authenticate before accessing      cited. Obviously, however, it
                                              network resources using captive does not work for servers or
                                              portal or similar technique.       appliances.
                                              Common in the hotel industry,
                                              on WiFi networks.
16   Sink Holes                       X       Routing attack traffic to a        Most useful when done at           Router vendors can do this at     BGP makes this easy to do
                                              discard interface on a router to   aggregation router, upstream       line speed. Can aggregate         without changing router
                                              prevent it from reaching its       of the local loop. It sacrifices   large amounts of traffic and      configurations – but needs
                                              intended destination.              access to victim machine to        must be used with care.           routing integrity to prevent
                                                                                 permit other machines                                                malicious use.
17   Honeypots/ Honeynets1       X        X   Creation one or more carefully     Considered a useful learning       None expressed.                   The group did not express any
                                              monitored systems with no          tool for those with time and                                         concerns about legal issues
                                              useful information or purpose      resources.                                                           surrounding these techniques.
                                              that to be susceptible to attacks.

 Additional information on the use and deployment of honeypots is available from the Project Honeynet <>. From their website, “the
Honeynet Project is a non-profit (501c3) research organization of security professionals dedicated to information security.”

Page 11 of 41                                                                                                                             filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                                                                                        DRAFT VERSION

                                P   D   R   A
                                R   E   E   N
#    Technique                  E   T   A   A   Description                         General Issues                 Performance Aspects              Operational Impacts
18   Routing Integrity          X               Family of techniques to protect     Fairly well understood         Routers provide tools with       The tools are not used
                                                the availability of the router      vulnerability – there has been adequate performance.            everywhere.
                                                control plane and the accuracy      much written on this recently.
                                                of the information. Includes
                                                stateless firewalls, priority
                                                queuing, MD5 check sums or
                                                IPSec, route policy filters, RPSL
                                                and the IRR.

2.2: Host Based Technologies

                                P   D   R   A
                                R   E   E   N
#    Technique                  E   T   A   A   Description                                       General Issues                             Operational Impacts
1    Host-based Encryption      X               IPSec encryption for host-host                    Generally seen as useful, but not a direct Key management is not mature.
                                                communications.                                   solution to bigger problems.               Concern that OS vendor will implement
                                                                                                                                             proprietary scheme that becomes de
                                                                                                                                             facto standard.
2    Host-based Intrusion           X       X   Software running on the end systems that          False positives still occur – one case of Strong concern of false positives will
     Detection (HIDS)                           detects attempted                                 legitimate DNS packet triggering alert. alarm users and overwhelm help desk.
                                                                                                                                             Need to collect and correlate log files
                                                                                                                                             from multiple systems to perform
3    Host-based Intrusion           X   X   X   Software running on the end systems that          Same as HIDS. There is some freeware Same as HIDS. Some success with
     Prevention System                          detects and prevents attempted intrusions.        for this. Disappointment that it’s not     deploying and supporting on a wide
     (HIPS)                                     Synonymous with host-based firewalls.             integrated into OS.                        scale, but difficult to enforce on campus
4    Secure OS                  X   X       X   Endorsing or developing an OS with reduced        NSA did this (SE Linux.)                   Limited discussion.
5    Reducing Existing OS       X               Working with OS vendor(s) to deliver software General disbelief that the R&E                 Sounds like it could have significant
     Vulnerabilities                            with fewer faults.                            community and government have                  operational savings.
                                                                                              influence over OS vendor code quality.
6    Centralized Systems        X   X           Using SMS or other software to centrally      It was implied that current Windows            Issues existing with laptops (not always
     Management                                 manage and patch systems.                     solutions are not workable; no                 accessible) and users not wanting to
                                                                                              discussion of distributed *nix/Linux           cede control.
7    Critical Host Protection   X               Covers a family of actions to protect hosts   DNS root servers are generally safe, but       No discussion.
                                                critical for working of infrastructure – i.e. other servers are likely vulnerable.
                                                DNS, mail.

Page 12 of 41                                                                                                                            filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                                                                                      DRAFT VERSION

                            P   D   R    A
                            R   E   E    N
#    Technique              E   T   A    A   Description                                            General Issues                          Operational Impacts
8    End User Education     X   X   X        All agreed this is critical (can’t let users install   Noted that users may think network-     The time and effort is well spent.
                                             attachments to spoofed emails.) Particularly           based techniques mean they don’t have
                                             effective to train the network/system security         to promptly patch their systems.
                                             folks from other campuses – MIT has an
                                             annual, open, free training event for local

Page 13 of 41                                                                                                                           filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                           DRAFT VERSION

3: Approaches
One of the ongoing goals of the S@LS effort is to gather information on ways in which
technologies can be implemented. The following sections highlight specific details for specific
technologies that address security while providing performance. We hope to catalog additional
information from practitioners as technologies and expertise is developed. If you are interested in
submitting information to expand or correct information shown here, please write to

3.1: Host Scanning
        Network based preventative strategy
        Host scanning is able to scan machines as they attach to a network. Scanning can be
        executed as machines attach to the network, on a periodic schedule, or immediately (after
        a new vulnerability is identified). Scanning supports machines that are not part of the
        network (visitor’s laptop) to attach to the network and be analyzed for known attacks
        supporting wired and wireless connectivity.
        It is also useful as a gating mechanism, providing administrators with an opportunity to
        distribute information, patches and related information. Caveats to this practice are noted
        Once scanning is completed, network connections can be allowed to persist without any
        additional interference from the host scanning system; the scanning system does not
        interfere with network performance once the scan is completed.
        Host scanning is a relatively new process. It is reactive and best used to prevent known
        problems. Depending on the thoroughness of the scan, it is potentially a time consuming
        process. Users will be required to wait for scans to complete each time they connect.
        The scanning process may also come under significant (predictable) load as new
        machines enter the network (beginning of school year, start of large conference).
        It is important to note that requiring machines to patch software may be problematic,
        particularly if those machines are visitors to a campus. Administrators may find that
        users will patch machines without understanding the implications of the patch on existing
        software or compatibility with tools at the machine’s home institution.
        If this type of preventative measure gains popularity, malware should be expected to
        create defensive measure to prevent detection.
        Vulnerabilities that are not caught during the scan will not be prevented; host scanning
        should be used as one of a variety of tools.
        Host scanning is ineffective against machines that attach behind NAT devices.
        Effectiveness against:
         L/M/H         Type of Attack
         Low           External host attacks
         High          Internal host attacks
         Medium        DoS/DDoS

Page 14 of 41                                                 filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                            DRAFT VERSION

         Low            Encrypted threats
         Low            Tunneled threats
         High           Email viruses- Internally sourced
         Low            Email viruses- Externally sourced
         Medium         Spyware
        Anticipated longevity: (effectiveness against emerging threats)
        Host scanning is potentially a useful tool in the long term. While it cannot respond to
        threats in real time, it can slow or prevent the spread of problems once fixes are available.
        Collateral Damage
        Host scanning presents no direct threat to existing applications or technologies.
         L/M/H          Type of Cost
         High           One time setup
         Low            Ongoing maintenance- Hardware
         Low            Ongoing maintenance- Software
         Medium         Ongoing maintenance- Operational
        Impact on:
         L/M/H          Impact
         Low            Performance
         Medium         Users
         Low            System Administration
         Medium         Network Administration

3.2: Host Based Intrusion Detection
        Host Based detection, reaction and analysis strategy.
        Host based intrusion detection systems (HIDS) provide users with control over
        connections to host machines. HIDS can be used to protect systems from a variety of
        attacks and vulnerabilities. This type of system can be used in lieu of centralized systems
        that block classes of traffic that may be desired to specific end hosts.
        By addressing connections to a host at the host system, HIDS are useful for networks that
        desire to maintain an Allow/Deny stance.
        HIDS may be extremely useful in responding to zero day threats. This will depend on the
        HIDS selected.
        Certain classes of attacks can only be addressed upstream from the host. Communication
        channels to upstream devices must be kept clear so that the host can request that specific
        flows be eliminated. Without this communication and prevention mechanism, HIDS will
        simply drop packets, hosts will not be compromised, but network connectivity may still
        be subject to denial of service.
        By their design, HIDS are placed at host systems. If end users are responsible for the
        tool, they must monitor the tool, its log files, and keep the system current with patches

Page 15 of 41                                                   filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                          DRAFT VERSION

        and vulnerability fingerprints. Anecdotally, end users often shirk this responsibility.
        Identifying HIDS that support end user and centralized control may be able to address
        this issue.
        HIDS are prone to false positives and false negatives. Tuning a HIDS to optimize the
        signal to noise ratio is a time consuming task. The optimization is also ongoing as new
        vulnerabilities and classes of desired traffic continue to emerge.
        HIDS may introduce performance degradation (if analysis is run on the machine
        receiving the network connection) or may require additional hardware and system
        administration costs. The level of each will depend on the specific system selected.
        Effectiveness against:
         L/M/H         Type of Attack
         High          External host attacks
         High          Internal host attacks
         Medium        DoS/DDoS
         Medium        Encrypted threats
         Medium        Tunneled threats
         Medium        Email viruses- Internally sourced
         Medium        Email viruses- Externally sourced
         Medium        Spyware
        Anticipated longevity: (effectiveness against emerging threats)
        Depending on the system selected, HIDS may be able to maintain effectiveness for
        extended periods. If HIDS rules are based on host-specific, historical connection
        information, connections should be characterizable. The characterizations should be
        responsive to new vulnerabilities as they develop.
        Collateral Damage
        HIDS may degrade privacy if connection information is shared between hosts.
        Anonymization of the information may not be possible, as specific information is
        required in order to deal with vulnerabilities.
         L/M/H          Type of Cost
         Medium         One time setup
         Low            Ongoing maintenance- Hardware
         Low            Ongoing maintenance- Software
         Medium         Ongoing maintenance- Operational
        Impact on:
         L/M/H          Impact
         Low            Performance
         Medium         Users
         Medium         System Administration
         Low            Network Administration

3.3: Perimeter (Stateful) Firewalls
        Network based prevention, detection and reaction strategy.

Page 16 of 41                                                 filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                            DRAFT VERSION

        Perimeter firewalls create an identifiable delineation between internal and external
        networks. Where the actual perimeter is located may be argued, but the installation of a
        firewall creates a useful, identifiable line.
        By their nature, perimeter firewalls act as a shield between hosts and the network cloud.
        This allows firewalls to prevent entire classes of traffic. This broad power is highly
        effective against externally sourced traffic entering a network and internally sourced
        traffic that crosses the firewall.
        Vendors are confident that firewalls will be able to keep pace with improvements in
        network speed. The highest performance firewalls will be priced accordingly. However,
        with a cascading design, multiple (lower cost) firewalls may be implemented.
        Firewalls are designed to stop classes of traffic. As the number of host systems behind a
        firewall increases, the firewall administrators will face increasing numbers of hosts that
        have anomalous needs. Balancing firewalls rules and the needs of specific hosts will be
        challenging. If used alone, all hosts behind a firewall are left simultaneously vulnerable
        to attacks that penetrate the firewall.
        Firewalls may impose a performance penalty, depending on the system selected.
        Firewalls are not able to address encrypted connections over commonly used ports.
        The ability for a firewall to address dynamic ports should be a selection criterion.
        Firewalls may not be a useful strategy from the viewpoint of mobile devices that require
        promiscuous networking (e.g., mobile sensors in a dispersed sensor network).
        Effectiveness against:
         L/M/H         Type of Attack
         Medium        External host attacks
         Low           Internal host attacks
         Medium        DoS/DDoS
         Low           Encrypted threats
         Low           Tunneled threats
         Low           Email viruses- Internally sourced
         High          Email viruses- Externally sourced
         Low           Spyware
        Anticipated longevity: (effectiveness against emerging threats)
        Firewalls will continue to be utilized in networks in spite of their shortcomings. Their
        ability to act as a checkpoint for large numbers of hosts is valuable. As user communities
        with specific needs develop, firewalls may be deployed in a cascading manner; a small
        number of general prohibitions for common vulnerabilities will be implemented closer to
        the network edge with more specific prohibitions implemented closer to user groups with
        specific needs.

Page 17 of 41                                                  filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                 DRAFT VERSION

        Collateral Damage
        Firewalls are often used to stop traffic from specific attacks. Although patches have
        addressed attacks, they continue to exist2. Firewalls may need to continuously block
        ports slowly eliminating the number of ports available to benign applications.
         L/M/H           Type of Cost
         Medium          One time setup
         Low             Ongoing maintenance- Hardware
         Low             Ongoing maintenance- Software
         Medium          Ongoing maintenance- Operational
        Impact on:
         L/M/H           Impact
         Medium          Performance
         Medium          Users
         Medium          System Administration
         Medium          Network Administration

4: Case Studies/Examples
One goal for this document is to provide practitioners with examples of how the technologies and
approaches can be implemented. These cases are based on discussions during the workshop and
subsequent conversations. Several cases are generalized from specific organizations, highlighting
common problems faced by many institutions.
The cases highlight current practices. They describe implementations, technologies, assumptions
about security/performance, strengths/weaknesses of the solution and lessons learned. The cases
highlight “effective practices” as well as approaches for which “the jury is still out.”

4.1: Case #1: Generic Academic Case
        Background and Introduction
        During the workshop, several participants provided information describing parts of their
        campus’s network security infrastructure. The information aired at the workshop has
        been summarized into one generic example. It does not describe any specific campus,
        but highlights many shared concerns and tactics. The Generic Academic Case is
        indicative of the direction in which many institutions are heading. Limited resources and
        the need to support a large, diverse user base requires that solutions be directed in a
        manner that protects the most common users, but with exception cases added as an
        L.U. (Large University) has allowed individual departments to take on an increasing
        portion of network administration. The rise of semi-autonomous departments with their
        own IT staff has allowed diversity of secure and relaxed LANs to exist. Over the past
        few years, L.U. has experienced a series of security related incidents. In response, L.U.
        administration has “urged” central IT to take action, but has not given them the authority
        needed to modify departmental LANs or to require departmental cooperation.

 See <> for a list of current ports under attack.
Note that fixes for these attacks are generally available.

Page 18 of 41                                                      filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                           DRAFT VERSION

        Central IT responded with a blunt solution- a firewall was implemented at the campus
        edge. Incoming and outgoing traffic flows are analyzed and filtered. Since additional
        funds were not provided, an existing router was used as a firewall. This solution has only
        recently been initiated and has successfully been able to stop known attacks and manually
        respond to new network vulnerabilities.
        Almost all traffic entering and leaving the campus network is subject to the firewall rules.
        Some researchers have been able to convince central IT to create exceptions for specific
        IP address ranges. These exceptions are hand coded and have been sufficient to appease
        the researchers.
        This implementation is informative as it superficially addresses all the concerns of
        administration, central IT and users. A majority of users are now protected behind the
        firewall and to date, security has been maintained in the same reactive manner as
        previously supported. However, this implementation is not without problems.
        First, the firewall policies are not transparent and the system by which routes or flows can
        be “white listed” is not documented. Users who have traffic stopped at the firewall are
        provided with no feedback as to why their application does not work or at what point in
        the network the traffic encountered resistance or how to bypass the filter. Even if the
        filter rules were advertised, the system is modified manually. Each exception case will
        require interaction with several network staff members culminating in a firewall update.
        This type of solution works well for small networks but faces serious scaling issues.
        Secondly, the hardware is generally able to act transparently, but there are times when it
        will become a performance bottleneck. Administration pushed for a solution but did not
        provide additional resources to purchase hardware or investigate alternative solutions.
        Because of this, central IT implemented the most expedient and least expensive solution.
        This solution was tested under normal loads, but is understood to be inadequate for high-
        volume situations or as a long-term solution.
        Lastly, a central firewall is a very coarse solution. Administration should either:
        - Have provided support for a customizable, centralized firewall along with trained
            personnel to manage it;
        - Urged departments to implement local firewalls with rules specific to the department
            with corresponding changes in network responsibility and demarcation; or,
        - Provided resources for an edge-centric host management system.
        A firewall with very basic rules close to the campus edge would be able to apply basic
        and obvious filters using an expensive piece of hardware. However, at the departmental
        levels, network flows should be diluted to a level where relatively inexpensive hardware
        should be available.

4.2: Case #2: Novel Academic Alternative
        Background and Introduction
        Big University is similar in externals to L.U., but has taken a number of different
        approaches. It is preparing for its students to return for the fall quarter and, in mid-
        August, suddenly faces crises caused by the launching of two world-class worms and a
        virus, all within one week. As the network-engineering group organizes to face the
        resulting challenge, they come up with several creative solutions.

Page 19 of 41                                                  filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                               DRAFT VERSION

        First, given that one of the worms depends critically on a compact set of TCP ports used
        by one functional and popular operating system, routers are configured to filter those
        ports, both for incoming and for outgoing traffic. Taking the view that emphasis on
        perimeter defense is unrealistic, if only due to the massive number of PCs that are about
        to physically migrate with their students back onto campus, these filters are organized
        more as watertight compartments within the campus than as a drawbridge at the entry to
        the campus. They are only relied on to slow down the propagation of worms and viruses,
        and healthy allowance is made for the possibility that infected machines might suddenly
        appear within the campus.
        Similarly, router filters are installed for specific signatures of ICMP packets used by one
        of the recent worms. Reports from campuses that have started their semesters a few
        weeks ago suggest that 50% of the student PCs that have arrived back at campuses arrive
        with serious infections.
        Second, CDs are distributed to all incoming students containing patches to the software
        that proved vulnerable to the worms and viruses, as well as up-to-date anti-virus
        software. To help get the timely attention of the students, these CDs are physically
        placed over the Ethernet wall-jack in dormitory rooms.
        Third, after several months of preparation, mandatory registration of campus hosts is
        implemented. For each port on the campus's Ethernet switch structure, one MAC address
        and one IP address will be allowed, and registration will be required when a new host
        appears on the structure. Thus, for example, when a student PC appears on campus, its
        MAC address is noted and, since it is not yet registered, the PC is given a temporary IP
        address and is placed on a special VLAN. From this VLAN, the student is led to a web
        server through which the student provides identification and contact information. Servers
        on the VLAN then probe the new PC to test its vulnerabilities to specific known worms
        and other attacks. If the registration and probe goes well, the PC is given an operational
        globally addressable IP address, is placed on a normal high-performance VLAN, and is
        entered into the registration database. If the probe reveals vulnerabilities, however, the
        PC is placed behind a very restrictive firewall and the PC's owner is told what must be
        done to remove the restrictions imposed. Further, the software patches normally needed
        to accomplish this are also present on the restrictive VLAN. If the PC moves to a
        different Ethernet switch port, this process is repeated.
        A similar approach is taken to hosts dialing in or entering the campus via a VPN. New
        hosts are scanned for infection and redirected to an isolated VLAN if infected, to a
        restricted VLAN if vulnerable, and to a high-performance VLAN if healthy.
        Whether the student's PC is on the high-performance or on the restricted VLAN, its
        traffic is monitored for signs that it might be infected or might be the source of infecting
        traffic. Again, this technique is limited to specific known traffic signatures. If a host
        appears to be infected, its registration entry is changed to require a repeat of the probing
        that followed registration. If a new threat is identified, the tool is able to purge all entries
        and force all hosts to repeat the probe process. This is useful for quickly protecting all
        devices by removing them from the network.
        Though it might go without saying, the IT staff having access to the monitoring tools are
        carefully trained in the sensitivity of such tools and the professional ethics that go with
        such access. Additional steps must be taken to ensure that the process itself does not
        become the agent through which denial of service attacks are executed.

Page 20 of 41                                                    filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                     DRAFT VERSION

         Campus email servers have also been configured to scan for viruses and to filter out any
         incoming or outgoing email containing known viruses.
         Finally, using an extensive human network of campus IT staff and well-trained part-time
         and volunteer student PC consultants, extensive communications are conducted with
         students, faculty, and staff to share an understanding of the dangers of security attacks
         and of available defenses. The new set of security steps is carefully integrated with
         related prudent habits such as file system backups.
         As a consequence of this combination of steps, this campus experienced far fewer
         infections than it had in the previous academic year. By making use of filters,
         registration, scanning of new hosts, and monitoring of traffic, and by less technical steps
         such as communicating with users, attacks common off-campus are very rare within it.
         In some cases, attacks missed by the probes were detected by traffic monitoring and this
         resulted eventually in improved probes (and vice versa).
         Consequently, after a very busy first week of term, students, faculty, and staff were able
         to proceed with confidence into the rest of the academic year. Further, after the third
         week of the fall term, the temporary filters were removed from the routers that connected
         the high-performance VLAN to the rest of the Internet.

4.3: Case #3: LBNL and Bro
         Background and Introduction
         For several years, the Lawrence Berkeley National Laboratory (LBNL) has pioneered the
         use of intrusion detection in preference to conventional firewall techniques. Many in our
         community find this surprising, given the stringent security demands that LBNL faces as
         a DOE national laboratory. During the workshop3, Jim Rothfuss described several
         elements of the LBNL approach. LBNL uses a fundamentally different process to secure
         their network. Rothfuss noted that traditional security systems focus on limiting access to
         pre-identified resources, and consist of four processes:
         - Secure
         - Restrict
         - Control
         - Hide
         The weakness of these traditional systems for a research laboratory is that limitations
         placed on the network can inhibit the underlying scholarly activities. For research
         communities, a system that inhibits scientific breakthroughs can be more costly than the
         many security breach.
         Rothfuss described Bro, an intrusion detection system that allows LBNL to maintain an
         Allow/Deny network disposition. The network is open by default and is designed to
         protect (rather than secure) resources. Bro is a dynamic protection system that analyzes
         network traffic for attacks and policy violations. It utilizes both threat- and vulnerability-
         based methods. LBNL employs Bro in conjunction with a border router.

  This case study is a summarized from Rothfuss’s presentation at the workshop. The original presentation
is available at: in the Presentations section for the 2003 Security at Line Speed

Page 21 of 41                                                         filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                              DRAFT VERSION

        Bro works by monitoring all traffic entering a network. The volume of network data is
        reduced to a manageable size by using the libpcap packet filter library. The data is
        processed into event streams that represent specific types of network activity (e.g.,
        connection events, http_reply). A policy interpreter analyzes event streams and
        determines what action to take. Actions are based on a protected resource’s explicit
        policies as well as from historical and contextual cues based on previous data. The
        actions that the policy engine can initiate include: recording the event to disk, generating
        alerts via syslog or paging, and executing programs as a form of response.
        Bro is a complex system with known deficiencies. Rothfuss acknowledged that Bro
        requires a great deal of technical expertise to maintain. Maintaining an open environment
        requires constant observation and trained personnel. Additionally, Bro focuses on threat
        detection; vulnerability detection is being addressed through a separate system called
        Network Equipment Tracking System (NETS). NETS will integrate with Bro to provide
        a feedback loop allowing threat and vulnerability information to complement one
        another. Bro runs on commodity PCs running Unix. The researchers are working in
        conjunction with vendors to determine methods to minimize custom hardware solution as
        well as create more consistent interfaces for hardware to work in conjunction with Bro.4

4.4: Case #4: Lightly Authenticated Wireless Network
        Background and Introduction
        Internet2 hosts several large conferences each year and wireless service is provided as a
        service to guests. Traditionally, the wireless network was “open”- run without any
        encryption. This maximized the usage of the wireless service while minimizing the load
        on the on-site help desk.
        Recently, wireless technology has become more popular. There is now a sizable class of
        users who are able to modify wireless networking settings without necessarily
        understanding the details of what the various settings mean. An unfortunate result is that
        many users will improperly set up their wireless hosts as adhoc peering points (instead of
        wireless clients). Unknowing users change the SSID to match the conference’s SSID and
        inadvertently set their machines as adhoc peers. This causes everyone within a small
        distance of that user to connect to the network through the user’s machine (instead of
        through the conference’s wireless access point). This causes a variety of problems, most
        noticeably performance.
        In order to prevent this, wireless access will now be gated through a simple database.
        Users connecting to the network will have their MAC address cross-stored in a database.
        If the MAC address is new, the user will be pushed to a login web page. The web page
        will note the MAC address and user supplied userID. Once the information is stored in
        the database, the user will be asked to re-connect to the network. Users connecting to the

  LBL is mostly a Unix shop, which is uncommon in our community at large. This difference is important
to note when discussing the difficulties of compatibility. Rothfuss also adds, “although at LBNL we use
some ‘custom hardware solutions’, that's because we are trying to stay up with state-of-the-art network
speeds (formerly 1gig, and now looking towards 10gig). I would think this is true of any network
components: state-of-the-art network speeds require state-of-the-art network hardware and Bro is no

Page 22 of 41                                                    filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                  DRAFT VERSION

         wireless network with a recognized MAC address will be placed onto the unrestricted
         This process allows the support team to identify the MAC addresses of machines running
         in peering mode. Once the MAC address is identified, an announcement can be made
         (over a loudspeaker) to the userID. This allows the support team to bypass the more
         tedious process of triangulating mobile laptops using wireless sniffing tools.
         Similar systems have been implemented on multiple campuses supporting much more
         robust and complex services. If an enterprise directory supports the login system, users
         can be placed on the VLANS they use in their home buildings [generalize “that if the
         login system can be coupled with other enterprise information, users can be placed on
         VLANS.]. If the enterprise supports Shibboleth5, visiting users can be given privileges
         based on cross-institutional agreements.

4.5: Case #5: Denial of Service
         Background and Introduction
         A Large Midwestern University has implemented a number of knobs on their
         internetwork equipment as well as instituted a numbering of monitoring services to help
         identify and contain DoS attack sources that may arise on their campus hosts. This
         university backbone is made up of more than a half dozen Cisco Catalyst 6509 boxes
         dispersed through the Chicago-land area and interconnected with gigabit Ethernet links.
         While as many as a few thousand hosts per campus support 100 Mbps full-duplex
         Ethernet connections, the total aggregate external Internet/Internet2 capacity is less than
         200 Mbps. In addition to all the other concerns with having a local DoS source, the
         potential to overwhelm the external link is of significant concern.
         At the subnet edges of the entire network, all non-TCP traffic is rate limited to some
         fraction of the overall maximum router interface rate. Traffic classes are mostly based on
         protocol, but some are customized. For example, unicast UDP traffic is rate limited
         separately from multicast UDP traffic. Each non-TCP category is limited to 2% or 10%
         of the total potential rate. So for example on a 100 Mbps router interface all ICMP traffic
         ingress to the router is rate limited to 2 Mbps and all UDP traffic ingress to the router is
         rate limited to 10 Mbps (this is because there have been specific attacks that exploit these
         protocols). These distributed rate limits help minimize the impact of any potential DoS
         agents on any individual subnet, but allow plenty of headroom for normal traffic
         At the external border points, rate limiting is also configured, but the allowance for each
         category is higher at the borders to account for potentially larger aggregate flows. Traffic
         flow monitoring is also configured at the external border, which helps identify out-of-
         profile traffic patterns including packets per second, changes in protocol usage or
         application usage and anomalous source / destination flow monitoring.
         Bogus source and destination IP addresses or specific packet headers are dropped at the
         edges and borders of the network. For example, a TCP packet with a multicast group
         destination address is prohibited, as is a packet to IP addresses not assigned by IANA.

 Shibboleth is an Internet2 project focusing on federated authorization. Additional information is available
at the project’s website <>.

Page 23 of 41                                                       filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                 DRAFT VERSION

        This helps eliminate both the effects of some worm traffic and spoofing by DoS agents,
        but also triggers alerts by the monitoring systems to identify problems quickly.
        Each individual IP address used within the university is also subject to queue
        management based on the average traffic flow being sourced by that IP. If a single
        university IP begins to source more than 1 Mbps of traffic, all traffic exceeding this
        threshold will incur a higher likelihood of drops than conforming traffic. This is based on
        a form of random early detection (RED) queuing at the border router. This helps to
        curtail large, internal DoS sources and prevents large information rate applications from
        starving low usage ones.
        An intrusion detection system at the external border also monitors for known DoS agent
        signatures and remote shells on non-standard ports, which often indicate potential DoS
        agents. Network flows are also monitoring using freely available cflowd tools. A
        sinkhole network is also planned to help discover internal problems and victims of
        reflective attacks.
        The network operational staff participates in various communities of other operators and
        security personnel such as Internet2, the UNISOG mailing list, NANOG, the nsp-security
        mailing list and the INOC-DBA VoIP network. This participation helps ensure a clear
        line of communication is known and available for assistance from third parties if it is ever
        required. It also helps to ensure that the operational network staff is aware of and
        implementing the best and most appropriate best practices in DoS attack mitigation.
        DoS attacks that are launched at the university from sources outside the institution may
        not be solvable with filters, rate limits and other security mechanisms within the
        university network. Often the traffic needs to be stopped or tracked upstream with the
        help of ISPs, peers and Internet2 connectors. The operational network staff needs to be
        able to identify attack profiles, have upstream contact info readily available and the
        ability to contact points upstream through an out of band mechanism.
        Rate limits are an imperfect solution to DoS attacks6. They may end up limiting valid
        traffic if DoS attacks are rare. They can also be a source of complexity that makes
        troubleshooting connectivity problems more difficult. Some vendor systems may also be
        unable to sustain high performance when rate limits are deployed and/or being hit.

4.6: Case #6: Network Auditing at Carnegie Mellon
        Background and Introduction
        In situations where a physical space must be secured, it is common practice to record
        activities in the area, those coming and going and the intent of the visit. This practice of
        generating a record of events is equally valuable for securing virtual spaces. It is now
        feasible to collect an audit trail of significant network activity at nearly any valuable
        Internet or Intranet security boundary, including end hosts. The ideal network audit tool
        would generate a dense but rich transaction history of all services requested, including the
        extent and quality of any services delivered in response. This capability is analogous to
 In a related development, a major university has begun to charge students for network traffic. The more
data that is sent over the network, the more they are charged. Students are now keenly aware of the volume
of traffic that their machines generate and track their usage daily. A result, students are able to quickly
determine if their machines have been compromised and are being used for network based, high-volume
maliciousness. With this knowledge, students repair and protect their machines more quickly and

Page 24 of 41                                                      filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                       DRAFT VERSION

         the call records in the Public Switched Telephone Network (PSTN), but the data is far
         richer since there is a much more complex set of services available in the Internet. This
         audit trail could be analyzed in real-time or with historical perspective for continuous
         improvement in prevention, detection, interception, and mitigation activities. Through
         the use of efficient auditing, accountability for network actions can be established, and
         security problems can be tracked back to their source.
         Through our experience with this approach to network auditing over the last few years,
         we have found that:
         - Through the creation of per-transaction records, network auditing adds significant
            new capabilities to the network management function, enabling a far richer
            understanding of a wide range of network behaviors. Further, it creates a mechanism
            to recognize usage anomalies through real-time and historical analysis of network
         - Network auditing could act as a deterrent to would-be intruders, discouraging
            inappropriate use by creating the capability to strictly bind traffic and transactions to
            connected systems. Of course, effectiveness as a deterrent will depend on broad
            awareness of the capability within the user community.
         - By providing a common audit mechanism and record format, multiple parties can
            share data and create definitive evidence to address repudiation disputes and claims
            of resource misuse.
         At Carnegie Mellon, we have been working with Network Auditing tools since 1993 and
         have consistently found the data to be an invaluable source of information, helping us to
         resolve a broad range of network management issues. These issues have included
         misconfigured network settings, intrusion detection and worm propagation forensics, and
         application performance issues and bandwidth utilization recording.
         Tool of Choice
         Independent work began in 1992 to create a software probe and basic collation engine.
         Shortly thereafter we began using the tool, now named Argus, for our internal
         engineering purposes, providing significant feedback on features and usability. After the
         external launch of Argus7 1.5 in May of 1994, a user community quickly grew that
         included members from the education, private, and public sectors
         Argus is a network-based real time flow-auditing tool designed to track and report the
         status and performance of all transactions seen in a data network traffic stream. Argus
         provides a common data format for reporting the usual flow metrics including source and
         destination addresses and ports, bytes transferred and such, but also provides additional
         information on loss, delay, and jitter on a per transaction basis. Further, this information
         is easily analyzed to provide higher order information on connectivity, service capacity,
         and observed load.
         Argus is a passive, continuous monitor, examining network data and generating an audit
         log of all activity observed in the packet stream. It can be deployed to monitor individual
         end-systems as well as transit network traffic, and can be deployed into highly distributed
         complex network environments. Importantly, Argus also provides good data reduction
         while still preserving valuable information8. Applications currently available in the open-

  Further information about Argus and copies of the open-source version are available from
  Readers familiar with SFlow and related tools will recognize many of these benefits. It is beyond the
scope of this report to discuss the relative merits of the two methods, but it is important to stress that the

Page 25 of 41                                                          filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                     DRAFT VERSION

         source version support a wide range of analysis operations such as selection, sorting,
         aggregation, archiving, anonymization, and reporting. There is XML support for Argus
         data, which makes for fast integration of Argus data into data mining and analysis
         Over the years, we have used network auditing to assist in many different network
         management functions. Presently, Carnegie Mellon uses these methods to assist in
         identifying and tracking network anomalies at three network interconnection points: the
         inter-router core, the Internet egress (commodity and Internet2), and the interconnection
         to the wireless network. Through detailed network audit records at these points, we have
         gained a valuable vantage point to help solve the following problems:
         - Bandwidth abuse
         - Worm and virus detection and propagation
         - Forensic analysis of a security incident
         - Real-time and historical security anomaly analysis
         - Simple IDS alerts that monitor key services and systems
         - Configuration verification of infrastructure security components
         - Provide researchers with customized, anonymous samples of network traffic for a
              broad range of studies9

4.7: Potential Case Topics
It is impossible to provide cases for all potential scenarios. That said, there are several classes of
activity that may be of interest to the audience. Some are listed below; additional cases can be
added if there is a call for specific cases.
- Specific case maximizing performance and security under “common” circumstances (e.g.,
     popular hardware, most frequent hurdles)
- Network architecture to provide local choice of open vs. closed net
- Centrally managed host configuration, including host-based firewalls
- Regular vulnerability scanning
- Real-time active response to infections (inverted IDS auto-blocking)

4: Non-Technical Issues
While the workshop focus was on technical issues, specifically oriented towards enterprise (e.g.
university, lab, company site) support or researchers, a number of other non-technical topics came
forward. These issues have the potential to steer the development of networks, potentially
suggesting specific technological solutions based on non-technical requirements. Addressing
these issues are critical if the research community is to survive the new security regime.
The issues discussed during the workshop include:
- Policy issues for campuses and labs
- Policy issues between campuses and agencies
- Impacts and issues on communities rising from current and future technologies

approaches are in fact complementary. Many of the analysis tools originally built for one record model
have been extended to accept the others data formats.
  The access policy of the data is highly restricted to guard against potential misuse outside of the realm of
network management. If researchers wish to use this data, the Institutional Research Board first reviews
the proposal. If approved, the data is made available and is carefully anonymized according to the IRB

Page 26 of 41                                                         filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                            DRAFT VERSION

Each of these issues is outlined in detail in Appendix 05: Non-Technical Issues and

5: Planning for High Performance Security
Performance requirements for advanced applications vary. The most visible of requirements is
the need for high bandwidth. (There are some meaningful distinctions between real-time and
batch high-bandwidth service choices.) Latency is critical for remote control of instrumentation.
Jitter control is important in real-time video. End-end clarity is required for applications such as
P2P and video that cannot operate if both ends are behind NAT’s. Open ports are essential for
the operation of Grids.
Network architecture and technologies are the primary areas where performance requirements can
be addressed while preserving security. The basic concepts of perimeter, subnet and desktop
have evolved with technology, and rich mixes of strategic perimeter defenses, careful subnetting,
and desktop firewalls can provide a defense in depth infrastructure that is flexible to respond to
specialized research needs. However, there is not a consensus on these issues.
Another strategy is to separate internal and external networking infrastructure, from routers to
SMTP servers, so that local performance can be preserved in the face of external threats. (When
the volume of negative external traffic is much greater than positive traffic, such steps are
necessary. We are reaching that point in email; will other flows follow that pattern?)
A related set of options exists around managed and unmanaged desktop operation. Dollar for
dollar, the best security remains in protecting desktops. The management can take many forms,
from outright scanning and patching to remote operation of multiple desktop firewalls or even as
part of a comprehensive computing support service. Since such management may not be
appropriate for some situations, the development of infrastructure that can support both managed
and unmanaged desktops and devices can significantly improve network security without impact
on performance.
These architectural options are tempered by cost and deployment issues. Costs of the additional
infrastructure can be considerable. Older switching equipment limit VLAN options. Intrusion
detection systems generate significant false positives and needless work. Debugging performance
problems in such a mesh of defenses is difficult.
The development of a consistent middleware infrastructure in the R&E community, catalyzed in
some part by the NSF Middleware Initiative, presents new opportunities for improving both
network security and network performance. Campuses will have the capability to deploy layered
authentication and authorization controls that are responsive to the distinctive needs of the
academic and research communities. On those controls can be built not only customized security
profiles, but access to advanced network capabilities as well.
Applied research should look at asymmetric network connectivity, where end-user workstations
have open access to the Internet but can not be seen from the Internet, except through managed
control. Policy decision points could be embedded into connectivity processes so that users could
have role-based network capabilities. Better understanding of early detection of abnormal flows
and automatic rate adjustment mechanisms would mitigate denial of service attacks.
At the same time, efforts must be made to inform and adapt advanced networked applications to
the realities of campus and lab deployments. Adaptations by these applications could include
limiting the port switching approaches (or providing automatic tools that could interact with the
other middleware controls described above), changing buffering strategies to compensate for
security-induced latencies, and other techniques that can be helpful for preserving performance as
security is increased (such as external service location brokers and rendezvous services).

Page 27 of 41                                                  filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                               DRAFT VERSION

All of these steps serve to complement the effective security practices that campuses and labs
should be undertaking. In the end, user education and official policies are essential to the general
health of the campus network and demonstrate good network citizenship by preventing campus
hosting of external attacks. Security offices and distributed staff can do much to augment the
responsibilities that desktop computer owners must ultimately accept.
It is clear that the collegial Internet is gone, a victim of its success. Whether we can build
collaborative subnetworks, where some measure of transparency and performance can be
maintained among the participants, will be answered in the months ahead.

5.1: Research Agenda
The workshop established an understanding of the current state of network performance and
security, often highlighting fundamental changes in long-held beliefs. As the firmament shifts,
the stability of traditional assumptions must be re-evaluated. Developing new alternatives to
these shifts will require basic research in many areas10.
Participants were able to identify several areas of research that should bring about noticeable
improvements in network performance and security. Research in these areas is highly inter-
related but for clarity, we have identified four basic areas of separation. We believe that funding
for the activities described is crucial to ensure that networks will be able to securely leverage the
full performance potential of research networks.
Each area is described below. Specific research suggestions are detailed in Appendix 06:
Research Agenda.
        Network Infrastructure Directed Solutions
        The network infrastructure is an obvious place to begin working. We believe that there
        are fundamental changes in the way that networks are being used that will require
        additional investigation. Devices and tools will need to be developed to support existing
        line rates as well as upcoming networking technologies. Existing usage patterns point to
        more networked devices, increased device mobility, expanded communication paths and
        multiple purpose hosts.
        Host Directed Solutions
        Protecting the network infrastructure is has limited value unless additional work is done
        to ensure host security and performance. User level tools that simplify the process of
        protecting hosts while simultaneously addressing performance bottlenecks will be
        critically important. Without these tools, support personnel will be required to address
        each problem manually.
        User education is also an important aspect of the solution. Users need to understand the
        fact that security is important. On a more positive note, users should be educated to
        better understand the full potential of the networks they are using. They should be
        encouraged to take advantage of network performance characteristics so that
        development and progress in the field can be pushed from multiple directions.

   In an unfortunate coincidence, the workshop happened to coincide with a high-intensity attack on the
Internet. The worm attack (Microsoft “blaster” worm) took several forms and mutated to cause a great deal
of grief. Information on the specific attack is available, among other places, at
<> and

Page 28 of 41                                                     filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                           DRAFT VERSION

        Management Directed Solutions
        Viewing LANs from an administrative view, there are tools that need to be researched
        and created to assist administrators. Development of centrally controlled performance
        and security tools needs to continue. Additionally, new methods to determine the current
        state of networks need to be developed. The ability to dynamically view and compare the
        current status to historical levels needs to be combined with the ability to securely
        communicate with other similar networks. Additional work is needed to better integrate
        local network information and staffing into IDSs (e.g., the IDS could learn where to
        direct specific warnings, the IDS could be automatically/centrally be updated when new
        equipment is added to the network).
        Field Leadership
        Each of the problem areas described has multiple paths to solutions. These efforts should
        be coordinated by an organization that is able to objectively support competing efforts.
        Singular solutions in this space will not suffice. Many of the security and performance
        bottlenecks that we face are manifestations of monocultures that do not have credible
        While multiple implementations are important, a set of standards via which applications
        can communicate will need to be created. Standardized protocols or a communications
        abstraction layer supporting multiple protocols are potential solutions.

6: Conclusion
The discussions at the Security at Line Speed Workshop outlined the current state of network
security in the advanced networking environments. There is a consensus that network
administrators are barely treading water keeping up with attacks and problems and that
performance is not addressed in a coherent, enterprise manner. While this document notes that
research is needed to solve these problems, a variety of solutions were discussed. The following
elements highlight suggestions and caveats on whom needs to address security and performance
        Specific technologies address specific problems
        Technologies are available today to address a class of known security and performance
        issues. Many of these technologies function as advertised. However, the environment is
        constantly changing and technologies will need to evolve to keep abreast of these
        changes. Technological solutions must be kept up to date; the use of new technologies
        must be expected as should the retirement of older, less useful tools.
        Performance can be addressed
        Vendors are confident that line speed devices such as routers and firewalls will be
        available. 1 Gbps devices are available and 10 Gbps devices will soon be on the market.
        These devices will be expensive, but should be able to address throughput performance
        needs. However, the raw power of devices such as routers and firewalls are only one link
        in the chain that supports security and performance. Identifying solutions to address
        latency and jitter will continue to require additional effort.

  The obvious target is Microsoft of on the desktop. However, there are many areas in which
monocultures have emerged. Recent examples include the recent OpenSSH bugs, reliance on a single DNS
implementation, etc.

Page 29 of 41                                                  filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                             DRAFT VERSION

        The concept of the network perimeter is changing
        Traditionally, the network perimeter was seen as a place to which the security battle
        could be pushed. This concept of the perimeter is changing. First, the perimeter is now
        virtual, not physical. In addition, the perimeter is now permeable. Laptops, by virtue of
        their mobility are simply vectors through the perimeter by which connections can be
        made asynchronously. Open wireless networks act as uncontrollable paths in and out of
        networks. VPNs, instead of isolating connectivity, are now conduits that extend the
        perimeter of a network to machines connected at individual users’ homes. A rational
        security model will must address the reality of the new perimeter.
        Applications must cooperate with existing security and performance devices
        Realistically, a variety of security devices will begin to appear on networks. Users of
        advanced applications must be cognizant of these devices and cooperate with them in
        order to achieve the optimal performance. Applications that rely on non-standard ports,
        utilize dynamic ports and GRID applications will all need to communicate their needs to
        network operators. Some problems can be addressed through technology, but an
        environment fostering communication between network operators, application developers
        and application users must exist.
        Software and hardware must provide security and performance options
        Many applications and devices ship with a variety of settings turned on. Users are often
        unaware of the default settings or their ramifications. Administrators should urge users
        and vendors to ship products in a manner that is by default secure. Users should have the
        opportunity to remove these limitations to maximize security and performance in a case-
        by-case basis. The flexibility to choose security and performance elements should be a
        selection criteria for products.
        Hardware, such as routers, can assist in high performance security by supporting software
        that samples data from the network stream. This information can be used to provide real
        time alerts without the need to process the full data stream. This is indicative of using the
        perimeter as more than a firewall.
        IDSs are not perfect, but they are useful
        Intrusion detection systems have a variety of known problems, but are still a useful tool
        in the security and performance toolkit. Integrating IDSs into network operations will be
        difficult, but their ability to respond in real time to zero day vulnerabilities will continue
        to be useful and should be considered as a selection criteria.
        Expenditure of Effort
        Current devices and technologies are extremely complex and require a great deal of
        effort. A lopsided amount of energy is being expended on border security; more effort
        needs to be placed on subnet protections, host security, incident response, etc. There is
        progress at specific locations, but if this is a trend, we are still in the early stages.
        Rationalizing perimeter policies (as mentioned above) and implementing hybrid systems
        that allow for centralized and end-user control will help balance effort and hopefully
        provide for overall system improvements.

Page 30 of 41                                                   filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                DRAFT VERSION

Appendix 01: Security at Line Speed Workshop
The Security at Line Speed Workshop was held 11-13 August 2003 in Chicago, IL. The
workshop was a working meeting attended by a limited number of invited participants. The goal
of the workshop was to disseminate information on problems, discuss potential solutions and
identify areas requiring additional research.
The workshop was made possible through an NSF grant and with the support of Indiana
University, Internet2, the Massachusetts Institute of Technology and the University of
Washington. Additional thanks go to Guy Almes, Terry Gray, Sharon Moskwiak Ken
Klingenstein, Steve Wallace, and T. Charles Yun; without their individual contributions, neither
the workshop, nor this paper would have been possible.
Information about the workshop is available at <>. The web site
provides links to the most recent copy of this document, as well as related resources and
presentations from the workshop.
The Organizing Committee held an open session at the Internet2 2003 Fall Member Meeting.
Presentations from the session are available online

Appendix 02: S@LS 2003: Attendees

       First Name        Last Name             Institution
       Guy               Almes                 Internet2
       Steve             Corbato               Internet2
       Rich              Cropp                 Penn State University
       Matthew           Davy                  Indiana University
       Ido               Dubrawsky             Cisco Systems, Inc.
       Dale              Finkelson             University of Nebraska
       Terry             Gray                  University of Washington
       Ken               Klingenstein          Internet2
       John              Kristoff12            DePaul University
       Mike              LaHaye                Internet2
       Caren             Litvanyi              Argonne National Lab/MREN/StarLight
       Morrow            Long                  Yale University
       Bob               Mahoney               Massachusetts Institute of Technology
       Joerg             Micheel               NLANR MNA / Endace
       Grant             Miller                NCO/Noesis
       Bob               Morgan                University of Washington
       Sharon            Moskwiak              Internet2
       Clifford          Neuman                USC Information Sciences Institute
       Pejhan            Peymani               Juniper Networks
       Jere              Retzer                Oregon Health and Science University
       David             Richardson            University of Washington
       Jim               Rothfuss              Lawrence Berkeley National Laboratory
       Krishna           Sankar                Cisco Systems Inc.

 Since the workshop, Kristoff has changed institutional affiliation and is now with Northwestern

Page 31 of 41                                                     filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                              DRAFT VERSION

       Martin           Schulman              Juniper Networks
       Kevin            Thompson              NSF
       Steven           Wallace               Indiana University
       Linda            Winkler               Argonne National Lab
       Erik             Wu                    Network Associates
       T. Charles       Yun                   Internet2
       Bill             Yurcik                NCSA/University of Illinois

Appendix 03: Additional Comments from Participants
Creating a document that combines the views of more than one person is always a challenge.
Fortunately, the Security at Line Speed Workshop participants encouraged- if not always
embraced- different opinions. Some of the participants wrote short pieces that extended,
modified, or commented on this report. Their comments are included below.
        From Jim Rothfuss
        I disagree a little with the report's fairly strong implication that "security and performance
        are competing aspects of networking". I realize that this is currently the widely held view
        and I'm not asking that you change the report. However, since this report is an ongoing
        dialog, I'll express my slightly different viewpoint in hopes to spur some future thoughts.
        One of my newest hobbyhorse ideas is that computer security is simply a
        computer/network performance issue, along with speed, latency, reliability, etc.
        To make this point, consider that a network engineer will think of wire characteristics as
        "limitations" to be overcome, not a "threat" to remove. Often limitations are overcome
        by using "tricks" that don't really remove the limitation. An example of a "trick" would
        be accepting a higher error rate in exchange for introducing the overhead of error
        correction. Another example is the use of compression to give an "apparent" increase in
        speed. Both examples recognize that the real underlining goal is to improve the transfer
        of data, not to improve wire.
        I think that focusing on "how do we keep hackers out" is like an engineer focusing on
        "how can I change the characteristics of the wire" as the only method to improve
        performance. While this is certainly a useful pursuit, focusing on this aspect alone may
        cause us to ignore other "tricks" that result in significant performance improvement.
        What if we changed the goal of security to "How can I maximize the performance of my
        computer and network, despite all the garbage (hackers, worms, scans, etc.) that are
        acting as limitations to that performance." Instead of "guarding" against threats and
        attacks, we start to think in terms of limiting the effects of threats and attacks. This twists
        the tone from "security and performance are at odds" to "security is a characteristic of
        An example: performance of a router might be based on both it's speed of passing useful
        packets, AND it's ability to do so in a hostile environment filled with scans, spam, and
        other garbage.
        There might be ways we can negate the effects of threats and attacks on network
        performance, and make huge gains, without actually removing or decreasing the threats
        and attacks.
        Anyway, food for thought and thanks for listening
        - Jim Rothfuss (7 October 2003)

Page 32 of 41                                                   filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                             DRAFT VERSION

Appendix 04: Tradeoffs and Tensions Described
Section 1.3: Tradeoffs and Tensions lists a variety of topics discussed during the workshop.
These conversations are summarized and described in the following elements.
        Security vs. Performance
        In that security and performance might be competing technological goals, they both
        require resources. Resources are finite, so it is important to understand user-needs so that
        the resource requirements to support both of these issues can be addressed.
        Deny/Allow vs. Allow/Deny
        One of the basic elements of security is a network’s default disposition with regard to
        accepting or denying connections to the outside world. Deny/Allow vs. Allow/Deny
        generally describes the dichotomy. Deny/Allow describes the default action that new
        connections will be denied unless explicitly allowed; Allow/Deny describes the inverse
        This is a fundamental decision. Particularly because the Internet has historically
        supported an open network in which (almost) all connections have been allowed by
        default. The number of sites supporting Allow/Deny has slowly dwindled with the
        increasing number of attacks (viruses, worms, DoS, etc.) to networks.
        Those with weak end-system protection want closed nets; those with strong end-system
        protection want open nets.
        End-user control vs. Central management
        The onus of security and performance is often pushed either to the end user or to a central
        technology group. The proliferation of mobile, end-user devices and tools has allowed
        many users to feel that local control is more flexible than central control. In spite of this,
        central management often complains that end-users do not properly update their tools or
        that they deploy tools without understanding the ramifications of doing so. Central
        management desires a centralized system that automatically addresses known problems
        (in terms of security tools) and limits the deployment of uncontrolled middle-boxes.
        Users respond with the complaint that centralized systems are unresponsive.
        Currently, there are models that allow for cooperative end-user and central management.
        These models show promise but will require additional testing before they can be
        considered generalizable solutions.
        It is important to note the distinction between the management of network devices and
        the management of the network. Management of the network generally combines
        elements of centralized control. This control covers campus control (connection to the
        world), departmental control (connection to the campus network) to user level control
        (connection of small work-groups). Departments distributed across physically distant
        locations face a variety of challenges as they may rely on multiple organizations for
        Un-Authenticated networks vs. Authenticated access vs. Host Challenges
        Authenticated network access was a popular topic during the workshop. Many points for
        and against the idea were raised. It is worth noting that the major concern with
        authenticated access is the fact that the veil of anonymity is being lifted. Many argued
        that the veil has been transparent for quite some time. Others argued for solutions that
        were able to maintain some level of anonymity while providing enough information to

Page 33 of 41                                                   filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                            DRAFT VERSION

        satisfy network administrators. While important, the anonymity debate is better handled
        in a different forum. This case will outline ways in which authenticated access can
        support security and performance.
        The idea behind authenticated access is that a machine is not allowed to send traffic
        across the network unless some information about the user or the host machine is known.
        Before authentication, hosts attached to a port are forced to communicate on a VLAN to a
        gatekeeper service. The gatekeeper will signal the port for some information. Depending
        on the response, the port will be given access to a different VLAN. Different VLANs
        will be pre-configured to support different activities on each port. There are several
        implementations for this idea, which can be designed to work cumulatively.
                User Log In
                In this scenario, the gatekeeper requires a user to log into a network, presumably
                using an enterprise aware username/password. This type of system provides very
                fine grain control for specific user activities. Individual users can be given (or
                request specific) types of network processing to support security and
                This type of system supports traditional single-user/single-host configurations as
                well as environments in which individual users have access to multiple physical
                hosts. This type of usage is common on campuses where students log into
                common machines in computer labs. If the system were supported by a robust
                directory service, students in networking courses could be provided with fewer
                restrictions, while others would be placed on more stringent networks. In either
                case, problems could not only be identified by port, but by user as well. This
                end-user knowledge is useful when investigating security incidents.
                Host Interrogation
                In this scenario, a machine connecting to a port would first be barraged with a set
                of tests for known exploits and weaknesses. If a weakness was found, the host
                machine would be placed on a VLAN restricting networking.
                This type of authentication is host centric and does not directly degrade
                individual privacy. The authentication provides a “public service” notifying
                users that their machines are currently susceptible to classes of attacks. This
                interrogation is effective at preventing attacks that have been identified and are
                Host interrogation is particularly useful for networks supporting large numbers of
                laptop computers. Laptops move between various LANs (home, office, etc.)
                with each LAN supporting differing security levels.
        False Positives vs. False Negatives: Controlling Metrics, Volume and Noise
        Tools to protect systems and enhance performance provide users and administrators with
        a plethora of metrics. These metrics are turned into reports and generate alarms. The
        prevalence of false positives and false negatives creates not only a signal to noise ratio,
        but a general problem with volume. Because of this, crucial data is being lost or ignored.
        Determining commonly agreed upon metrics will be needed in order for different tools to
        interact. Further, a process by which the proper information can be filtered or
        summarized will be crucial as additional requirements are placed on security and
        performance tools.

Page 34 of 41                                                  filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                               DRAFT VERSION

        Host vs. Border Security
        How does the network engineer combine host based and border based network security
        techniques most effectively? At this point, there are few who would support the use of
        only one of the options.
        Host-based security is flexible, but places the responsibility on end-users who will have
        varying levels of understanding and rigor. Border-based security provides large coverage
        but may limit flexibility.
        Organizations like the SANS Institute publish a list of “Common Vulnerable Ports”13
        online. Blocking ports can be implemented at the host or border using software or
        hardware (NAT, firewalls). However, this is often considered a fairly blunt tool,
        particularly in the research environment where services and tools are frequently used in
        an experimental fashion.
        Determining who should be responsible for what elements of security is a non-technical,
        but critical element.
        Server vs. Client: Supporting Servers in a Client-Centric Environment
        Historically, computer services were controlled centrally and end users were not provided
        the flexibility to make changes to the environment. Users were not concerned with
        securing or optimizing the machines providing these services. The advent of inexpensive
        hardware has provided end users with the ability to run services locally. Oftentimes, end
        users running server machines will not take the time to properly optimize or secure the
        hardware they are running. Supporting distributed servers blurs the line between central
        technology services and local self-sufficiency, particularly as many of the distributed
        servers function to support centralized services.

Appendix 05: Non-Technical Issues and Recommendations
        Policy issues for campuses and labs:
        Several trends are evident:
        - There is much greater pressure for enterprises to install broad firewalls. Insecurity is
           now seen as a potential source of liability.
        - New security requirements being developed under the Federal e-Authentication work
           may apply to scientific applications and collaborations. Similarly, HIPAA legal
           drivers for medical high-performance applications are getting significantly more real.
        - There is a significant variation among campuses and labs in their ability to deploy
           advanced networking within their security framework.
        - We need to make the management more centralized than the tools or techniques.
           This implies more aggressive assistance to scientists and departments that want help
           in implementation.
        - The unlisted phone number presents an appealing analogue to a desirable state in
           networking. IPSEC might be used for some part of an approach.
        - Providing support for researchers tend to be engineering intensive and perhaps costly
           in deployment. It appears that each researcher needs specialized solutions.
        - Advent of encryption forces implementation to the end-points. How can we do that
           without management at the end-points but still in the enterprise?

  Information about the SANS Institute (SysAdmin, Audit, Network, Security) is available at
<>. Their “Common Vulnerable Ports” list is available at

Page 35 of 41                                                    filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                            DRAFT VERSION

        1. Promote successful campus approaches.
        2. For some NSF solicitations, it might make good sense to require that RFP responses
           attach an endorsement from the campus CIO that asserts that the proposal is
           consistent with campus network security, associated policies and that the network can
           meet the performance requirements of the proposal. A context for deployment
        3. Scanning when a machine authenticates to the network is a reasonable strategy.
        Policy Issues for Inter-institutional Collaborations:
        There are a number of non-technical issues that represent substantial barriers to advanced
        networking collaborations among scientists located at different campuses or national labs.
        One of the hardest non-technical problems is to pull together policies from several
        different loci (each of which may have some jurisdiction on the end-end collaboration)
        and sum/reconcile them into a coherent framework.
        There is a pressing need for protocol developers and enterprise security architects to be in
        regular communication so that the other doesn’t disrupt the work of each group. How
        can we influence the protocol design community?
        The federal e-authentication framework is specifying the Level of Assurance (LOA)
        needed to access federal applications. It will be critical to see where agency research
        applications fit into this LOA scale.
        One of the potentially most awkward scenarios will arise in inter-institutional
        collaborations, where one university permits a scientist to use security variations that the
        other campus security/CIO will not permit. Internet2 could possibly act as a conduit for
        developing some consistency of approaches and permissions between campuses.
        Trust fabrics will play critical roles at several layers:
        - Collaboration among the scientists will require trust
        - Security practitioners between campuses will need a trust fabric to do inter-
            institutional diagnostics and remedies
        - Within a campus, cooperation among central and distributed IT security staff will
            require trust. Moreover, there may be “trusted” and “non-trusted” segments of the
            campus network.
        - Conversations should be scheduled at LSN and MAGIC ensuring that agency’s RFPs
           reflect the changing campus security environments.
        - It would be useful for some campuses and national labs to get together and compare
           their policies, in hopes of developing some common criteria.
        - Two upcoming avenues to have discussions with some parts of the protocol design
           community include GGF9 and SC03. They should be informed about security trends
           in higher education and new work in federations and other trust models.
        Impacts on the Health Sciences due to HIPAA
        The health sciences are emerging as an area that desperately needs and will drive the
        requirements for high performance, highly secure networks. The health sciences are true
        knowledge industries. They produce no tangible end product, yet generate products and
        services intended to promote “health.” Healthcare has historically been called a “trillion
        dollar cottage industry,” and been ignored by many sectors. This is beginning to change.

Page 36 of 41                                                  filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                            DRAFT VERSION

        In 2000, the Institute of Medicine report "To Err is Human" revealed that between 44,000
        and 98,000 die annually in the US as a result of medical errors. Many of these deaths
        could be prevented with widespread adoption of electronic health records and physician
        order entry systems. Computer networked systems will increase in complexity to support
        advances in medical science such as imaging and functional genomics. These two sectors
        are leading the explosive growth in the size and quantity of medical databases. As
        - Digital mammogram studies are typically 300 megabytes per patient.
        - Functional magnetic resonance image (MRI) studies of the brain can easily run 3
        - Genetic studies and drug discovery are generating petabytes of data that will need to
             be accessed and studied.
        Patient care is inherently collaborative and the information shared can be sensitive and
        critically important. Leveraging the Internet infrastructure seems logical, but security
        and performance obstacles will need to be addressed.
        Health Insurance Portability and Accountability Act (HIPAA) mandates that patient
        healthcare information must remain private and secure. Privacy and security concerns
        are leading healthcare providers nationwide to adopt firewalls and data encryption.
        These security devices historically have had negative performance impacts and made it
        difficult to adopt more advanced and interactive applications such as videoconferencing,
        a centerpiece of telemedicine applications.
        A medical school can easily have 600 contractual relationships impacted by HIPAA and
        simultaneously may be engaged in 1000 different clinical trials. Large institutions
        commonly outsource functions such as laboratories, medical transcription, and billing.
        Medical consultation also typically requires providing access to third parties. All of these
        require access to sensitive information that can be technologically mediated.
        The health sciences may also be the next real time, mission and life critical application
        for the Internet. Network applications commonly used today include access and storage
        of digital X-rays, electronic orders for prescriptions and tests, electronic patient records,
        blood bank orders, online databases (e.g., transplant availability, drug interaction, poison)
        and surgery scheduling. The health sciences are also seeing increased use of real time
        applications, such as remote access to patient monitors, as well as remote access and even
        control of diagnostic instruments. These kinds of applications assume secure networks
        and demand low latency, jitter and loss.
        Concern over the rapid inflation of healthcare costs have led to a groundswell for a
        National Health Information Infrastructure. Healthcare is typically a low margin
        operation. Healthcare, perhaps more than any other industry, needs standards-based
        systems that are simple and affordable. A doctor will not tolerate technicians constantly
        adjusting equipment. It has to be simple, reliable, high performance and secure.
        Emerging and even personalized information is the health sciences most important
        business asset. The capture, analysis, storage, transmission, sharing and manipulation of
        sensitive personal health information are business critical for health sciences. The only
        feasible way to execute this type of strategy is to participate in the creation of secure,
        high performance networks.
        Impacts of Future Technologies on Network Security
        Perimeter equipment providers (e.g. routers) believe they will be able to keep up with line
        speed and provide simple security services such as port filtering. Router vendors expect

Page 37 of 41                                                  filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                              DRAFT VERSION

        to have 10 Gbps cards that will not slow down in the face of security processing in one-
        two years.
        Secure video is a driving application, especially in medical computing.
        The advent of SOAP means that security requirements are moving further into the stream
        of traffic (inside http) and will make scanning at firewalls harder. Almost everything
        over port 80 means that attackers will find new techniques that can be carried within http

Appendix 06: Research Agenda
There are four areas where “applied network research” (i.e. network research informed by the
deployed infrastructure) would significantly assist the ability to couple network security to the
requirements of the high-performance community. Some of these areas are already well-known
areas for research and are mentioned here for completeness. Others are lesser known and are
more fully described.

06-1. Network Directed Solutions
Continued investments in new security approaches to the current components of network
engineering are warranted. Some may be undertaken by individual network equipment
manufacturers, but interoperability among these vendors is of considerable concern to
heterogeneous campus networks. Thus research that creates interoperable standards is of
particular value.
Those security related components include: Firewalls, NATs, VPNs, overlay networks, routers,
OS and Application Patch Level Monitors,
In addition, significant opportunities exist in increasing our understanding and tools to address
DoS/DDoS attacks, Source Address Verification, Traffic monitoring and analysis, IDS/IPS, LAN
based firewalls (e.g., Bro), Routing Integrity, and using QOS/Dynamic bandwidth provisioning14.
Several new and important areas of applied research include:
        Authentication Based Network Access
        It is now possible to require all network access to run through a user authentication
        process. Authenticating network usage provides administrators with a tool to support
        security and accountability, as well as enabling the possibility for role-based network
        Those campuses with solutions are currently not standardized and may not be scalable
        beyond their current implementations. Nor are they amenable to the needs of higher
        education, with important amounts of inter-institutional travel. Federated authorization
        systems exist and may play an important part in supporting mobile devices. It is also
        possible to authenticate devices as well as users, providing opportunities for device
        integrity checks and protecting users from rogue services.
        Initiating research into a scalable, interoperable solution will provide a significant layer
        of protection. Bringing systems to operational levels in a variety of environments will
        also test their flexibility and robustness.

  Applications such as VoIP and videoconferencing are ready to take off creating massive numbers of low
to medium bandwidth flows.

Page 38 of 41                                                    filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                  DRAFT VERSION

         Network "Tricorder15"
         Network administrators lack effective tools that correlate network traffic and security.
         As network traffic is often a prime indicator of security issues, such correlations offer
         multiple benefits. (Some tools exist to look for services, but do not reflect traffic. Nor
         are any of the tools integrated with each other.) As stated in this document, these two
         metrics are somewhat orthogonal, however, network administrators have intuitive
         understandings of the way the two are related. Creating a tool that analyzes input from a
         variety of tools to create a summary understanding of a network’s security-performance
         would be extremely useful. Currently, there are a variety of ad hoc and unintegrated
         network traffic tools. However, there are few tools that can systematically measure the
         security of a network as a whole. Creating a single security analysis tool, while ideal, is
         probably not as useful as establishing a framework through which a suite of high-level
         security analysis tools could communicate.
         Additional work to understand the way data from the suite of tools relates to one another
         and correlates to traffic flows is needed. This type of analysis may be scalable so that
         larger networks can use the results from small networks.
         This type of tool is dependent on common standards and shared information as described
         in the Appendix 06-4: Research Agenda: Field Leadership. We note that it is difficult
         politically to share security data.
         A high-level analysis tool that accepts results from a variety of lower-level network and
         security tools would help reduce the signal-to-noise ratio and provide administrators with
         a single “tool of contact” through which they could investigate security and performance

06-2: Host Directed Solutions
As noted above, existent development in host based services, such as IDS/IPS16, could to be
infused with new research. Patch systems that reflect the heterogeneity of campus environments,
as well as the autonomy and mobility of the user community, is another area where research
could be accelerated or repositioned.
Several areas for new investment include:
         Host Interrogation Systems
         Host security is determined through end-user trust or verification. End-user trust has
         been shown to be a weak link; end-users repeatedly have failed to install security patches
         to operating systems and applications. Verification systems can be used to actively
         determine if a machine has been patched, which ports are open, etc.
         Host interrogation systems are still immature and are often custom tools created on a
         campus. The interrogation systems only ask questions that are explicitly defined by

   The science-fiction television show, Star Trek, featured a device called the Tricorder. In the television
series, the device was used as an all-purpose scanner/sensor/analysis tool.
   The entire field of IDS and IPS products has come into the spotlight based on a 2003 Sep Burton Group
report entitled “Intrusion Detection and Response.” The Burton report criticizes IDS systems tendency
towards false negatives and suggests firewall-like IPS systems as an alternative. The debate is ongoing and
one source of media coverage is <>.

Page 39 of 41                                                       filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                              DRAFT VERSION

        Creating a system that automatically creates new questions based on communications
        with other security tools is necessary not only for responsiveness, but to reduce the
        burden on network administrators. This type of tool will probably also provide
        information to identify other problems that a network may be facing, including a variety
        of end-to-end performance characteristics.
        Encryption is one method available to users to assure security. Encryption can be
        implemented at a variety of levels: application, host, or network. Encrypting
        communications between hosts allows users to tunnel traffic across open ports. This
        activity effectively eliminates the ability for traffic monitors to scan for malignant traffic.
        Encryption may also eliminate the ability for certain devices or protocols to function
        properly depending on where the encryption is initiated. Protocols such as IPv6 depend
        on access to information such as packet headers and the original host’s IP address.
        However the end-user interfaces to encryption remain problematic and non-interoperable.
        Usability research, as well as open source implementations of some useful tools (such as
        federated root certificate aggregation and dissemination) would be helpful.

06-3: Research Agenda: Management Directed Solutions
As indicated above, automatic-patch mechanisms for devices (for non-windows machines and
mobile devices) are needed. The portfolio of tools to dynamically observe and detect anomalous
behavior is limited and could be greatly improved.
At the same time, work in honeypots, including safer ways to permit widespread deployment on
campuses, would help. The forensic and investigative tools that work on honeypots are also still
in early stages of understanding.
A number of advanced applications require specialized port configurations that are not consistent
with general campus security approaches. Tools that would permit centralized management of
these singularities, as well as ways to delegate those capabilities as appropriate to local system
admins could significantly help the real-world deployments of Grids and other systems.
        Improve Basic Tools
        Network administrators do not have a standard set of tools that can robustly support each
        of the four stages of the security lifecycle. A variety of post-attack analysis tools exist,
        but they are not easy to use or administer (nor do we expect, will they ever be).
        However, increasing the types of tools will help reduce the amount of time necessary to
        deconstruct an attack scenario. Improving the efficiency of these tools will also go a long
        way into helping reduce the amount of time between awareness and solution. Supporting
        interoperability or the exchange of data to support performance and security will also
        prove beneficial to administrators and users.
        Specific tools might include those that are able to identify aberrant behavior, specifically
        targeted to spot the beginnings of DOS attacks and identify zombies.
        After the August 2003 S@LS workshop, Johns Hopkins sponsored the NSF Cyber Trust
        Point Meeting. Their website has documentation that covers many issues regarding the
        improvement of tools, including the relationship between usability, trust and

Page 40 of 41                                                    filename: 20031108-wr-sals-v1.1.doc
Security at Line Speed Workshop Report                                                    DRAFT VERSION

         trustworthiness17. Lists of popular, existing tools are compiled in various locations and
         may serve as a good starting point for surveys18.
         Trust Fabrics
         Most inter domain security activities require some level of assurance to operate.
         Encryption and signing keys can be exchanged pairwise by key people, but clearly
         scalable trust frameworks are needed that permit the sharing of security data. There are
         many security relationships among partners in the research and educational communities
         that may be supported by trust fabrics that are now emerging within the sector. For
         relationships either outside the sector (with, for example, ISAC’s and commercial
         associations) or requiring different security levels, operational trust relationships must be
         established among security partners.

06-4: Research Agenda: Field Leadership
Access to security data is problematic. Political and financial sensitivities combine with concerns
about revealing too much technical detail and exposing other vulnerabilities. Framing data sets of
security event information with privacy preserving analytic tools would lay the foundation for
role-based sharing of both real time and archival data.
As part of this work, it would be useful to develop a consensus around which hosts require critical
levels of protection and security. Such agreements can be leveraged for campus and agency
         User Needs Analysis- An Anthropo-Socio-Technological Analysis
         There is not a clear understanding, and resulting taxonomy of the ways in which different
         user communities use the network. Experimentation could help determine if there are
         classes of users who would benefit from and potentially prefer to live in a heavily
         guarded and secured network understanding that performance would suffer. Cross-
         platform interoperability, along with user customization capabilities, could then be
         developed to set finer-grained defaults on security profiles.

Appendix 07: Version History
         Version 1.1
         Minor typographical changes and specific identification of NSF award number.
         Version 1.0
         Version 1.0 was released 2003 November 10. Please send corrections and comments to
         <> with “S@LS Paper” in the subject line.

   Additional information about the Johns Hopkins meeting is available at
   One such list is available at <>. This is the website for the creator of
the Nmap tool.

Page 41 of 41                                                        filename: 20031108-wr-sals-v1.1.doc

To top