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