Request for Comments: 1636 ISI
Category: Informational D. Clark
MIT Laboratory for Computer Science
S. Crocker
Trusted Information Systems, Inc.
C. Huitema
INRIA, IAB Chair
June 1994
Report of IAB Workshop on
Security in the Internet Architecture
February 8-10, 1994
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document is a report on an Internet architecture workshop,
initiated by the IAB and held at USC Information Sciences Institute
on February 8-10, 1994. This workshop generally focused on security
issues in the Internet architecture.
This document should be regarded as a set of working notes containing
ideas about security that were developed by Internet experts in a
broad spectrum of areas, including routing, mobility, realtime
service, and provider requirements, as well as security. It contains
some significant diversity of opinions on some important issues.
This memo is offered as one input in the process of developing viable
security mechanisms and procedures for the Internet.
Table of Contents
1. INTRODUCTION .................................................. 2
2. OVERVIEW ...................................................... 4
2.1 Strategic and Political Issues ........................... 4
2.2 Security Issues .......................................... 4
2.3 DNS Names for Certificates ............................... 7
3. FIREWALL ARCHITECTURE ......................................... 9
3.1 Introduction ............................................. 9
3.2 Application-Layer Firewalls .............................. 11
3.3 IP-Layer Firewalls ....................................... 12
4. SECURE QOS FORWARDING ......................................... 21
4.1 The Requirement for Setup ................................ 21
4.2 Securing the Setup Process. .............................. 22
4.3 Validating an LLID ....................................... 24
4.4 Dynamics of Setup ........................................ 28
4.5 Receiver-Initiated Setup ................................. 30
4.6 Other Issues ............................................. 30
5. AN AUTHENTICATION SERVICE ..................................... 35
5.1 Names and Credentials .................................... 36
5.2 Identity-Based Authorization ............................. 37
5.3 Choosing Credentials ..................................... 38
6. OTHER ISSUES .................................................. 39
6.1 Privacy and Authentication of Multicast Groups ........... 39
6.2 Secure Plug-and-Play a Must .............................. 41
6.3 A Short-Term Confidentiality Mechanism ................... 42
7. CONCLUSIONS ................................................... 44
7.1 Suggested Short-Term Actions ............................. 44
7.2 Suggested Medium-Term Actions ............................ 46
7.3 Suggested Long-Term Actions .............................. 46
APPENDIX A -- Workshop Organization .............................. 48
Security Considerations .......................................... 52
Authors' Addresses ............................................... 52
1. INTRODUCTION
The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet
architecture. This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working
groups of the Internet Engineering Task Force (IETF), under the
leadership of the Internet Engineering Steering Group (IESG) and area
directorates.
An IAB-initiated workshop on the role of security in the Internet
Architecture was held on February 8-10, 1994 at the Information
Sciences Institute of the University of Southern California, in
Marina del Rey, California. This RFCreports the results of the
workshop.
In addition to the IAB members, attendees at this meeting included
the IESG Area Directors for the relevant areas (Internet, Transport,
Security, and IPng) and a group of 15 other experts in the following
areas: IPng, routing, mobility, realtime service, and security (see
Appendix for a list of attendees). The IAB explicitly tried to
balance the number of attendees from each area of expertise.
Logistics limited the attendance to about 30, which unfortunately
meant that many highly qualified experts were omitted from the
invitation list.
In summary, the objectives of this workshop were (1) to explore the
interconnections between security and the rest of the Internet
architecture, and (2) to develop recommendations for the Internet
community on future directions with respect to security. These
objectives arose from a conviction in the IAB that the two most
important problem areas for the Internet architecture are scaling and
security. While the scaling problems have led to a flood of
activities on IPng, there has been less effort devoted to security.
Although some came to the workshop eager to discuss short-term
security issues in the Internet, the workshop program was designed to
focus more on long-term issues and broad principles. Thus, the
meeting began with the following ground rule: valid topics of
discussion should involve both security and at least one from the
list: (a) routing (unicast and multicast), (b) mobility, and (c)
realtime service. As a basis for initial discussion, the invitees
met via email to generate a set of scenarios (see Appendix)
satisfying this ground rule.
The 30 attendees were divided into three "breakout" groups, with each
group including experts in all the areas. The meeting was then
structured as plenary meetings alternating with parallel breakout
group sessions (see the agenda in Appendix). On the third day, the
groups produced text summarizing the results of their discussions.
This memo is composed of that text, somewhat rearranged and edited
into a single document.
The meeting process determined the character of this document. It
should be regarded as a set of working notes produced by mostly-
autonomous groups, containing some diversity of opinions as well as
duplication of ideas. It is not the output of the "security
community", but instead represents ideas about security developed by
a broad spectrum of Internet experts. It is offered as a step in a
process of developing viable security mechanisms and procedures for
the Internet.
2. OVERVIEW
2.1 Strategic and Political Issues
Despite the workshop emphasis on architectural issues, there was
considerable discussion of the real-politik of security.
For a number of years, the IETF, with IAB backing, has worked on
developing PEM, which provides email security with a great deal of
functionality. A question was repeatedly raised at the workshop:
why has user acceptance of PEM been slow? A number of answers to
this question were suggested.
(a) High-quality implementations have been slow in coming.
(b) The use of a patented technology, the RSA algorithm, violates
social conventions of the Internet.
(c) Export restrictions dampen vendor enthusiasm.
(d) PEM currently depends upon a certificate hierarchy for its
names, and certificates form a new and complex name space.
There is no organizational infrastructure in place for creat-
ing and managing this name space.
(e) There is no directory infrastructure available for looking up
certificates.
The decision to use X.500 has been a complete failure, due to
the slow deployment of X.500 in the Internet. Because of UDP
packet size restrictions, it is not currently feasible to
store certificates in the DNS, even if the DNS were expanded
to hold records for individual email users.
It seems probable that more than one, and possibly all, of these
reasons are at work to discourage PEM adoption.
The baleful comment about eating: "Everything I enjoy is either
immoral, illegal, or fattening" seems to apply to the cryptography
technology that is required for Internet security.
2.2 Security Issues
Almost everyone agrees that the Internet needs more and better
security. However, that may mean different things to different
people. Four top-level requirements for Internet security were
identified: end-to-end security, end-system security, secure QOS,
and secure network infrastructure.
A. End-to-End Security
One requirement is to support confidentiality, authentication
and integrity for end-to-end communications. These security
services are best provided on an end-to-end basis, in order
to minimize the number of network components that users must
trust. Here the "end" may be the end system itself, or a
proxy (e.g., a firewall) acting on behalf of an end system.
For point-to-point applications, the workshop felt that
existing security techniques are well suited to support
confidentiality, authentication and integrity services
efficiently. These existing techniques include symmetric
encryption applied on an end-to-end basis, message digest
functions, and key management algorithms. Current work in
these areas in the IETF include the PEM and Common
Authentication Technologies working groups.
The group favored a strategic direction for coping with
export restrictions: separate authentication from privacy
(i.e., confidentiality). This will allow work to proceed on
authentication for the Internet, despite government
restrictions on export of privacy technology. Conversely, it
will allow easy deployment of privacy without authentication,
where this is appropriate.
The workshop explored the implications of multicasting for
end-to-end security. Some of the unicast security techniques
can be applied directly to multicast applications, while
others must be modified. Section 6.2 contains the results of
these discussions; in summary, the conclusions were:
a) Existing technology is adequate to support
confidentiality, authentication, and integrity at the
level of an entire multicast group. Supporting
authentication and integrity at the level of an
individual multicast source is performance-limited and
will require technology advances.
b) End-to-end controls should be based on end system or
user identifiers, not low level identifiers or locator
information. This requirement should spawn engineering
work which consists of applying known key distribution
and cryptographic techniques.
B. End-System Security
Every host has its own security defenses, but the strength of
these defenses depends upon the care that is taken in
administering them. Careful host security administration
means plugging security holes in the kernel and applications
as well as enforcing discipline on users to set good (hard to
crack) passwords.
Good security administration is labor-intensive, and
therefore organizations often find it difficult to maintain
the security of a large number of internal machines. To
protect their machines from outside subversion, organizations
often erect an outer security wall or "perimeter". Machines
inside the perimeter communicate with the rest of the
Internet only through a small set of carefully managed
machines called "firewalls". Firewalls may operate at the
application layer, in which case they are application relays,
or at the IP layer, in which case they are firewall routers.
The workshop spent considerable time on the architecture of
firewall routers. The results are contained in Section 3.
C. Secure QOS
The Internet is being extended to provide quality-of-service
capabilities; this is the topic called "realtime service" in
the workshop. These extensions raise a new set of security
issues for the architecture, to assure that users are not
allowed to attach to resources they are not authorized to
use, both to prevent theft of resources and to prevent denial
of service due to unauthorized traffic. The resources to be
protected include link shares, service classes or queues,
multicast trees, and so on. These resources are used as
virtual channels within the network, where each virtual
channel is intended to be used by a particular subset or
"class" of packets.
Secure QOS, i.e., protection against improper virtual channel
usage, is a form of access control mechanism. In general it
will be based on some form of state establishment (setup)
that defines authorized "classes". This setup may be done
via management configuration (typically in advance and for
aggregates of users), or it may be done dynamically via
control information in packets or special messages (typically
at the time of use by the source or receiver(s) of the
flow/data). In addition to state establishment, some form of
authentication will be needed to assure that successive
packets belong to the established class. The general case to
be solved is the multicast group, since in general the
multicast problem includes the two-party case as a subset.
The workshop developed an approach to the secure QOS problem,
which appears in Section 4 below.
D. Secure Network Infrastructure
Network operation depends upon the management and control
protocols used to configure and operate the network
infrastructure, including routers and DNS servers. An attack
on the network infrastructure may cause denial-of-service
from the user viewpoint, but from the network operators'
viewpoint, security from attack requires authentication and
integrity for network control and management messages.
Securing the routing protocols seems to be a straightforward
engineering task. The workshop concluded the following.
a) All routing information exchanges should be
authenticated between neighboring routers.
b) The sources of all route information should be
authenticated.
c) Although authenticating the authority of an injector of
route information is feasible, authentication of
operations on that routing information (e.g.,
aggregation) requires further consideration.
Securing router management protocols (e.g., SNMP, Telnet,
TFTP) is urgent, because of the currently active threats.
Fortunately, the design task should be a straightforward
application of existing authentication mechanisms.
Securing DNS is an important issue, but it did not receive
much attention at the workshop.
2.3 DNS Names for Certificates
As noted in Section 2.1, work on PEM has assumed the use of X.509
distinguished names as the basis for issuing certificates, with
public-key encryption. The most controversial discussion at the
workshop concerned the possibility of using DNS (i.e., domain)
names instead of X.509 distinguished names as (at least) an
interim basis for Internet security.
The argument in favor of DNS names is that they are simple and
well understood in the Internet world. It is easy for a computer
operating in the Internet to be identified this way, and users who
receive email on such machines already have DNS mailbox names. In
contrast, introducing X.509 distinguished names for security will
add a new layer of names. Most importantly, there is an existing
administrative model for assigning DNS names. There is no
administrative infrastructure for assigning X.509 distinguished
names, and generating them may be too complex for early
acceptance. The advocates of DNS names for certificates hope that
using DNS names would encourage the widespread use of security in
the Internet. It is expected that DNS names can be replaced later
by a more capable naming mechanism such as X.509-based
certificates.
The basic argument against DNS names as a basis for security is
that they are too "weak". Their use may lead to confusion in many
instances, and this confusion can only grow as more organizations
and individuals attach to the Internet. Some commercial email
systems employ numeric mailbox names, and in many organizations
there are uncertainties such as whether "bumber@foo.edu" belongs
to Bill Umber or Tom Bumber. While it is feasible to make DNS
names more descriptive, there is a concern that the existing
infrastructure, with millions of short, non-descriptive names,
will be an impediment to adoption of more descriptive names.
It was noted that the question of what name space to use for
certificates is independent of the problem of building an
infrastructure for retrieving those names. Because of UDP packet
size restrictions, it would not be feasible to store certificates
in the DNS without significant changes, even if the DNS were
expanded to hold records for individual email users.
The group was unable to reach a consensus on the issue of using
DNS names for security; further discussion in the Internet
community is needed.
3. FIREWALL ARCHITECTURE
3.1 Introduction
A firewall may be used to isolate a specific connected segment of
Internet topology. When such a segment has multiple links to the
rest of the Internet, coordinated firewall machines are required
on all the links.
Firewalls may be implemented at different layers in the protocol
stack. They are most commonly implemented at the application
layer by forwarding (application) gateways, or at the IP
(Internet) layer by filtering routers. Section 3.2 discusses
application gateways. Section 3.3 concerns Internet-layer
firewalls, which filter IP datagrams entering or leaving a
security perimeter.
The general architectural model for a firewall should separate
policy, i.e., determining whether or not the requester of a
service should be granted access to that service, from control,
i.e., limiting access to resources to those who have been granted
access.
3.1.1 The Use for Firewalls
Firewalls are a very emotional topic in the Internet community.
Some community members feel the firewall concept is very
powerful because firewalls aggregate security functions in a
single place, simplifying management, installation and
configuration. Others feel that firewalls are damaging for the
same reason: they provide "a hard, crunchy outside with a soft
chewy center", i.e., firewalls foster a false sense of
security, leading to lax security within the firewall
perimeter. They observe that much of the "computer crime" in
corporate environments is perpetrated by insiders, immune to
the perimeter defense strategy. Firewall advocates counter
that firewalls are important as an additional safeguard; they
should not be regarded as a substitute for careful security
management within the perimeter. Firewall detractors are also
concerned about the difficulty of using firewalls, requiring
multiple logins and other out-of-band mechanisms, and their
interference with the usability and vitality of the Internet.
However, firewalls are a fact of life in the Internet today.
They have been constructed for pragmatic reasons by
organizations interested in a higher level of security than may
be possible without them. This section will try to outline
some of the advantages and disadvantages of firewalls, and some
instances where they are useful.
Consider a large organization of thousands of hosts. If every
host is allowed to communicate directly with the outside world,
attackers will attempt to penetrate the organization by finding
the weakest host in the organization, breaching its defenses,
and then using the resources of that host to extend the
penetration further within the organization. In some sense,
firewalls are not so much a solution to a security problem as
they are a reaction to a more basic software
engineering/administration problem: configuring a large number
of host systems for good security. If this more basic problem
could be solved, firewalls would generally be unnecessary.
It is interesting to consider the effect that implementing a
firewall has upon various individuals in the organization.
Consider first the effect upon an organization's most secure
host. This host basically receives little or no extra
protection, because its own perimeter defenses are as strong or
stronger than the firewall. In addition, the firewall will
probably reduce the connectivity available to this host, as
well as the reliability of the communications path to the
outside world, resulting in inconvenience to the user(s) of
this host. From this (most secure) user's point of view, the
firewall is a loss.
On the other hand, a host with poor security can "hide" behind
the firewall. In exchange for a more limited ability to
communicate with the outside world, this host can benefit from
the higher level of security provided by the firewall, which is
assumed to be based upon the best security available in the
entire organization. If this host only wants to communicate
with other hosts inside the organization, the outside
communications limitations imposed by the firewall may not even
be noticed. From this host's viewpoint, better security has
been gained at little or no cost.
Finally, consider the point of view of the organization as a
whole. A firewall allows the extension of the best security in
the organization across the whole organization. This is a
benefit (except in the case where all host perimeter defenses
in the organization are equal). Centralized access control
also becomes possible, which may be either a benefit or a cost,
depending upon the organization. The "secure" hosts within the
organization may perceive a loss, while the "unsecure" hosts
receive a benefit. The cost/benefit ratio to the organization
as a whole thus depends upon the relative numbers of "secure"
and "unsecure" hosts in the organization.
Consider some cases where firewalls do not make sense. An
individual can be thought of as an organization of one host.
The security of all the host(s) is thus (trivially) identical,
and by definition the best available to the organization. In
this case the choice of firewall is simple. Does this
individual wish to communicate with the outside or not? If
not, then the "perfect" firewall is implemented (by complete
disconnection). If yes, then the host perimeter will be the
same as the firewall perimeter, so a firewall becomes
unnecessary.
Another interesting case is an organization that consists of
individuals with few shared interests. This might be the case
of a service provider that sells public access to the network.
An unrelated community of subscribers should probably be
considered as individuals, rather than an organization.
Firewalls for the whole organization may make little sense in
this case.
To summarize, the benefit of a firewall depends upon the nature
of the organization it protects. A firewall can be used to
extend the best available protection within the organization
across the entire organization, and thus be of benefit to large
organizations with large numbers of poorly administered hosts.
A firewall may produce little or no perceived benefit, however,
to the individuals within an organization who have strong host
perimeters already.
3.2 Application-Layer Firewalls
An application-layer firewall can be represented by the following
diagram.
C <---> F <---> S
Here the requesting client C opens its transport connection to the
firewall F rather than directly to the desired server S. One
mechanism for redirecting C's request to F's IP address rather
than S's could be based on the DNS. When C attempts to resolve
S's name, its DNS lookup would return a "service redirection"
record (analogous to an MX record) for S. The service redirection
record would return the IP address of F.
C enters some authentication conversation to identify itself to F,
and specifies its intention to request a specific service from S.
F then decides if C is authorized to invoke this service. If C is
authorized, F initiates a transport layer connection to S and
begins the operation, passing requests and responses between C and
S.
A major advantage of this scenario over an IP-layer firewall is
that raw IP datagrams are never passed through the firewall.
Because the firewall operates at the application layer, it has the
opportunity to handle and verify all data passing through it, and
it may be more secure against illicit rendezvous attacks (see
below).
Application layer firewalls also have important disadvantages.
For full benefit, an application level firewall must be coded
specifically for each application. This severely limits the
deployment of new applications. The firewall also represents a
new point of failure; if it ceases to be reachable, the
application fails. Application layer firewalls also may affect
performance more than IP-layer firewalls, depending on specific
mechanisms in use.
3.3 IP-Layer Firewalls
Our model of an IP-layer firewall is a multi-ported IP router that
applies a set of rules to each incoming IP datagram, to decide
whether it will be forwarded. It is said to "filter" IP
datagrams, based on information available in the packet headers.
A firewall router generally has a set of filtering rules, each of
which specifies a "packet profile" and an "action". The packet
profile specifies values for particular header fields, e.g.,
source and destination IP address, protocol number, and other
suitable source and destination identifying information (for
instance, port numbers). The set of possible information that may
be used to match packets is called an "association". The exact
nature of an association is an open issue.
The high-speed datagram forwarding path in the firewall processes
every arriving packet against all the packet profiles of all
active rules, and when a profile matches, it applies the
corresponding action. Typical actions may include forwarding,
dropping, sending a failure response, or logging for exception
tracking. There may be a default rule for use when no other rule
matches, which would probably specify a drop action.
In addition to the packet profile, some firewalls may also use
some cryptographic information to authenticate the packet, as
described below in section 3.3.2.
3.3.1 Policy Control Level
This section presents a model for the control of a firewall
router, with some examples of specific mechanisms that might be
used.
1. A client C attempts to access a service S. (Client here
can mean either a person or a process - that also is an
issue to be resolved.)
2. The initiation of access to that service may result in an
attempt to cross one or more boundaries of protection via
firewall router(s).
3. The policy control level sets filters in the firewall
router(s), to permit or deny that attempt.
The policy control level consists of two distinct functions,
authentication and authorization. Authentication is the
function of verifying the claimed identity of a user. The
authentication function should be distributed across the
Internet, so that a user in one organization can be
authenticated to another organization. Once a user is
authenticated, it is then the job of the authorization service
local to the resource being requested to determine if that user
is authorized to access that resource. If authorization is
granted, the filter in the firewall can be updated to permit
that access.
As an aid to understanding the issues, we introduce a
particular detailed mechanism. We emphasize that this
mechanism is intended only as an illustrative example; actual
engineering of the mechanism will no doubt lead to many
changes. Our mechanism is illustrated by the following sketch.
Here a user wishes to connect from a computer C behind firewall
F1, to a server S behind firewall F2. A1 is a particular
authentication server and Z1 is a particular authorization
server.
C <-------> F1 <-------> F2 <-------> S
\ /
\_____ /
\ \ /
A1 Z1
C attempts to initiate its conversation by sending an initial
packet to S. C uses a normal DNS lookup to resolve S's name,
and uses normal IP routing mechanisms. C's packet reaches
firewall router F1, which rejects the packet because it does
not match any acceptable packet profile. F1 returns an
"Authentication Required" error indication to C, including a
list of authentication/authorization servers that F1 trusts.
This indication might be a new type of ICMP Destination
Unreachable packet, or some other mechanism for communicating
with C.
When C receives the error indication, authenticates itself with
A1, one of the authentication servers listed in the error
indication, after validating A1's identity. C then requests
authorization from server Z1 (using a ticket provided by A1),
informs Z1 of the application it wishes to perform, and
provides a profile for the packets it wishes to pass through
F1. Z1 then performs an authorization function to decide
whether to allow C to penetrate F1. If C is to be allowed, Z1
then informs the firewall F1 to allow packets matching the
packet profile to pass through the firewall F1.
After C's packets penetrate F1, they may again be rejected by a
second firewall F2. C could perform the same procedures with
authentication server A2 and authorization server Z2, which F2
trusts. This is illustrated by the following schematic diagram
of the sequence of events.
----------+--------+--------+------------+------------+----
| C | A1 | Z1 | F1 | F2 | S
----------+--------+--------+------------+------------+----
| Sends pkt| | | | |
| to S ----------------------->Intercept;| |
| | | | requires | |
| | | |authenticat'n |
| <------------------------------- | |
|Auth'cate | | | | |
| C to A1 ----> | | | |
| |Provide | | | |
| <------- ticket| | | |
| Request | | | | |
|authoriz'n| | | | |
| -------------------> Is C| | |
| | |allowed?| | |
| | | OK ---------> | |
|Resend | | | Set filter | |
| first pkt| | | | |
| to S -------------------------->(OK)------>Intercept;|
| | | | | requires |
| | | | |authenticat'n
| <------------------------------------------- |
| (Repeat | | | | |
|procedure | | | | |
with A2,Z2)| | | | |
| ... | | | | |
|Resend | | | | |
| first pkt| | | | |
| ------------------------------>(OK)--------(OK)------>
| | | | | |
-----------+--------+--------+------------+------------+----
Again, we emphasize that this is only intended as a partial
sketch of one possible mechanism. It omits some significant
issues, including the possibility of asymmetric routes (see
3.3.3 below), and the possibility that the profiles may be
different in the two directions between C and S.
We could imagine generalizing this to an arbitrary sequence of
firewalls. However, security requires that each of the
firewalls be able to verify that data packets actually come
from C. This packet authentication problem, which is discussed
in the next section, could be extremely difficult if the data
must traverse more than one or possibly two firewalls in
sequence.
A firewall router may require re-authentication because:
* it has been added to the path by a routing change, or
* it has timed out the profile entry, or
* it has been newly re-activated, perhaps after a crash that
lost its list of acceptable profiles.
If C contacts authentication and authorization servers that S
trusts, C may utilize tickets given it by these servers when
initiating its use of S, and avoid re-authenticating itself to
S.
Although the authentication server A1 and the authorization
server Z1 are conceptually separate, they may run on the same
computer or router or even be separate aspects of a single
program. The protocol that C speaks to an An, the protocol
that C speaks to a Zn, and the protocol that Zn speaks to Fn
are not specified in these notes. The authentication mechanism
used with An and the packet profile required by a firewall Fn
are considered matters of policy.
3.3.2 Source Authentication
We next consider how to protect against spoofing the IP source
address, i.e., injecting packets that are alleged from come
from C but do not. There are three classes of mechanisms to
prevent such spoofing of IP-level firewalls. The mechanisms
outlined here are also discussed in Section 4.3 below.
o Packet Profile Only
The lowest level of security consists of allowing the IP-
layer firewall to filter packets purely on the basis of
the packet profile. This is essentially the approach used
by filtering routers today, with the addition of (1)
authentication and authorization servers to control the
filtering profiles, and (2) the automatic "Authentication
Required" notification mechanism. This approach provides
almost no security; it does not prevent other computers
from spoofing packets that appear to be transmitted by C,
or from taking over C's transport level connection to S.
o Sealed Packets
In the second level of security, each packet is "sealed"
with a secure hash algorithm. An authentication server Ai
chooses a secret and shares it with the source host S and
also with the authorization server Zi, which shares the
secret with the firewall Fi. Every packet that C
transmits contains a hash value that depends upon both the
contents of the packet and the secret value. The firewall
Fi can compute the same hash function and verify that the
packet was originated by a computer that knew the shared
secret.
This approach does raise issues of how much C trusts Zi
and Fi. Since they know C's secret, Zi or Fi could spoof
C. If C does not trust all Z's and F's in its path, a
stronger mechanism (see below) is needed.
A more difficult problem arises in authenticating C's
packets when more than one firewall lies in the path.
Carrying a separate seal for each firewall that is
penetrated would be costly in terms of packet size. On
the other hand, in order to use a single seal, all the
firewalls would have to cooperate, and this might require
a much more complex mechanism than the one sketched in the
previous section. Morever, it may require mutual trust
among all of the authentication servers Ai and
authorization servers Zi; any of these servers could
undermine all the others. Another possibility to be
investigated is to use hop-by-hop rather than end-to-end
authentication of C's packets. That is, each firewall
would substitute into the packet the hash needed by the
next firewall.
Multi-firewall source authentication is a difficult
problem that needs more investigation.
o Packet Signatures
In the third level of security, each packet is "signed"
using a public/private key algorithm. C shares its public
key with Zn, which shares it with Fn. In this scenario, C
can safely use one pair of keys for all authorization
servers and firewalls. No authorization server or
firewall can spoof C because they cannot sign packets
correctly.
Although packet signing gives a much higher level of
security, it requires public key algorithms that are
patented and currently very expensive to compute; their
time must be added to that for the hash algorithm. Also,
signing the hash generally makes it larger.
3.3.3 Other Firewall Issues
o Performance
An Internet-layer firewall has the advantage of generality
and flexibility. However, filtering introduces a
potential performance problem. Performance may depend
upon the number and position of the packet fields used for
filtering, and upon the number of rules against which a
packet has to be matched.
Denial of service attacks require that the per-packet rule
matching and the drop path be able to keep up with the
interface speed.
o Multicasting
To allow multicast traffic to penetrate a firewall, the
rule that is needed should be supplied by the receiver
rather than the sender. However, this will not work with
the challenge mechanism outlined in Section 3.3.1, since
"Authentication Required" notifications would be sent to
the sender, not to the receiver(s).
Multicast conversations may use any of the three levels of
security described in the previous section, but all
firewalls will have to share the same secret with the
originator of the data stream. That secret would have to
be provided to the receivers through other channels and
then passed to the firewalls at the receivers' initiative
(in much the same way that resources are reserved at
receiver's initiative in RSVP).
o Asymmetric Routing
Given a client computer C utilizing a service from another
computer C through a firewall F: if the packets returning
from S to C take a different route than packets from C to
S, they may encounter another firewall F' which has not
been authorized to pass packets from S to C (unlike F,
which has been). F' will challenge S rather than C, but S
may not have credentials to authenticate itself with a
server trusted by F'.
Fortunately, this asymmetric routing situation is not a
problem for the common case of single homed administrative
domains, where any asymmetric routes converge at the
firewall.
o Illicit Rendezvous
None of these mechanisms prevent two users on opposite
sides of a firewall from rendezvousing with a custom
application written over a protocol that may have been
authorized to run through a firewall.
For example, if an organization has a policy that certain
information is sensitive and must not be allowed outside
its premises, a firewall will not be enough to enforce
this policy if users are able to attach sensitive
information to mail and send it outside to arbitrary
parties. Similarly, a firewall will not prevent all
problems with incoming data. If users import programs and
execute them, the programs may have Trojan horses which
disclose sensitive information or modify or delete
important data. Executable code comes in many, many
forms, including PostScript files, scripts for various
interpreters, and even return addresses for sendmail. A
firewall can detect some of these and scan for some forms
of potentially hazardous code, but it cannot stop users
from transforming things that look like "data" into
programs.
We consider these problems to be somewhat outside the
scope of the firewall router mechanism. It is a matter of
the policies implemented by the organization owning the
firewalls to address these issues.
o Transparency for Security Packets
For the mechanisms described above to operate, the
"Authentication Required" notification and the
authentication/authorization protocol that is used between
the client computer and the authentication and
authorization servers trusted by a firewall, must be
passed by all firewalls automatically. This might be on
the basis of the packet profiles involved in security.
Alternatively, firewall routers might serve as
application-layer firewalls for these types of
communications. They could then validate the data they
pass to avoid spoofing or illicit rendezvous.
3.3.4 Firewall-Friendly Applications
Firewall routers have problems with certain communication
patterns where requests are initiated by the server, including
callbacks and multiple connections (e.g., FTP). It was
suggested that it would be useful to have guidelines to
application designers to help them to build 'firewall-friendly
applications'. The following guidelines were suggested:
1) no inbound calls (the xterm problem),
2) fixed port numbers (no portmapper or tcpmux),
3) integral redirection is good (application gateways),
4) no redirection in the protocol,
5) 32 bit sequence numbers that are crypto-strong random #'s,
and
6) fixed length and number of header fields.
Type fields are good, but they may not be needed if there are
fixed port numbers.
3.3.5 Conclusions
Compared to an application-layer firewall, an IP-layer firewall
scheme could provide a number of benefits:
- No extra authentication is required for end hosts.
- A single authentication protocol can be used for all
intended applications.
- An IP-layer firewall causes less performance degradation.
- An IP-layer firewall may be able to crash and recover
state without disturbing open TCP connections.
- Routes can shift without disturbing open TCP connections.
- There is no single point of failure.
- It is independent of application.
However, there are substantial difficult design issues to be
solved, particularly in the areas of multiple firewalls,
assymmetric routes, multicasting, and performance.
4. SECURE QOS FORWARDING
When the Internet supports special qualities-of-service (QOS) for
particular packet flows, there will be a new set of security
problems. There will be a need to authenticate and authorize users
asking for those QOS values that are expensive in network resources,
and it will be necessary to prevent theft of these resources and
denial-of-service attacks by others. This section contains a
conceptual model for these problems, which we may call secure QOS
forwarding. The issues here differ from end-to-end security and
firewalls, because QOS forwarding security may need to be enforced at
every router along a path.
It was noted that this is not a new problem; it was stated and solved
in a theoretical way in a thesis by Radia Perlman.
4.1 The Requirement for Setup
Setup is an essential part of any QOS mechanism. However, it may
be argued that there are also good engineering reasons for setup
in any Internet-layer security mechanism, even without QOS
support. In the abstract, one could imagine a pure datagram model
in which each IP packet separately carried the necessary
authorizations for all the stages in the forwarding path.
Realistically, this is not practical, since the security
information may be both unacceptably large and computationally
demanding for inclusion in every packet. This seems to imply the
need for some form of state setup for security.
Thus, we presume a two stage process that moves somewhat away from
the pure datagram model. In the first stage, the setup stage,
some state is established in the routers (and other network
elements) that describes how a subsequent stream of packets is to
be treated. In the second stage, the classification stage, the
arriving packets are matched with the correct state information
and processed. The terminology in use today calls these different
state descriptions "classes", and the process of sorting
"classification".
Setup can take many forms. It could be dynamic, invoked across
the network by an application as described above. The setup
process could also be the manual configuration of a router by
means of a protocol such as SNMP or remote login. For example, a
network link, such as a link across the Atlantic, might be shared
by a number of users who purchase it jointly. They might
implement this sharing by configuring a router with
specifications, or filters, which describe the sorts of packets
that are permitted to use each share. Whether the setup is
dynamic or manual, short-lived or semi-permanent, it has the same
effect: it creates packet classes in the router and defines how
packets are to be classified as they arrive.
Much of the current research on extensions to IP for QOS, such as
realtime service, has assumed an explicit setup phase and a
classification stage. The setup stage is accomplished using
protocols such as RSVP or ST-II, which also specify how the
subsequent classification is to be done. Security at the setup
stage would thus simply be an extension to such a protocol. It
should be noted that there are alternative proposals for realtime
QOS, based on an implicit setup process.
4.2 Securing the Setup Process.
To secure the setup process, we require that a setup request be
accompanied by user credentials that provide a trustworthy
assurance that the requester is known and is authorized to make
the request in question. We refer to the credentials used in the
setup phase as the high-level identification (HLID).
A simple version of this authorization would be a password on the
management interface to a router (the limitations of such a
password scheme are well known and not the issue here). In the
case of setup requests made by individual applications, some
user-specific authorization must be assumed.
While there could be any number of ways to organize the HLIDs, the
objective of scaling suggests that a global framework for user
naming and authentication would be useful. The choice of naming
framework is discussed further in Section 5. Note that this
discussion, which concerns controlling access to network resources
and security devices, is distinct from end-to-end authentication
and access control; however, the same authentication
infrastructure could be used for both.
In general, while significant engineering effort will be required
to define a setup architecture for the Internet, there is no need
to develop new security techniques. However, for the security
aspects of the classification process, there are significant
problems related to performance and cost. We thus focus on that
aspect of the overall framework in more detail.
Above, we defined the high-level ID (HLID) as that set of
information presented as part of a setup request. There may also
be a "low-level ID" (LLID), sometimes called a "cookie", carried
in each packet to drive classification. In current proposals for
IP extensions for QOS, packets are classified based on existing
packet fields, e.g., source and destination addresses, ports, and
protocol type.
It is important to note that the LLID is distinct from the address
of the user, at least conceptually. By stressing this distinction
we make the point that the privileges of the user are not
determined by the address in use. If the user's address changes,
the privileges do not.
The LLID in a packet acts as a form of tag that is used by some or
all routers along a path to make decisions about the sort of QOS
that shall be granted to this packet. An LLID might refer to a
data stream between a single source-destination address pair, or
it might be more general and encompass a range of data streams.
There is no requirement that the LLID embody a syntax that permits
a router to discern the QOS parameters that it represents, but
there also is no prohibition against imposing such a structure.
We propose that an IP datagram contain one LLID, which can be used
at various stages of the network to map the packet to a class. We
reject the alternative that the packet should have a variable
number of LLIDs, each one for a different point in the net.
Again, this is not just a security comment, but it has security
implications.
The attributes of the LLID should be picked to match as broad a
range of requirements as possible.
* Its duration (discussed below) must match both the needs of
the security protocol, balancing robustness and efficiency,
and the needs of the application, which will have to deal
with renewal of the setup when the LLID expires. A useful
end-node facility would be a service to renew setup requests
automatically.
* The degree of trust must be high enough to meet the most
stringent requirement we can reasonably meet.
* The granularity of the LLID structure must permit packet
classification into classes fine-grained enough for any
resource selection in the network. We should therefore
expect that each separate stream of packets from an
application will have a distinct LLID. There will be little
opportunity for aggregating multiple streams under one LLID
or one authenticator.
4.3 Validating an LLID
At a minimum, it is necessary to validate the use of an LLID in
context, i.e., to ensure that it is being asserted in an
authorized fashion. Unauthorized use of an LLID could result in