Network Working Group S. Brim
Internet-Draft A. Simu
Expires: January 30, 2002 Cisco Systems, Inc.
August 2001
Midcom Agents and Topology
draft-brim-midcom-inandout-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 30, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
A midcom agent does not know whether to ask for a ruleset to be
installed in a middlebox or not. Even when it does ask, in some
situations the middlebox does not know how to apply the ruleset.
This document tries to solve these problems without adding an
overwhelming amount of complexity to every agent and middlebox.
Brim & Simu Expires January 30, 2002 [Page 1]
Internet-Draft Midcom Agents and Topology August 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Simplest Scenario . . . . . . . . . . . . . . . . . . . 4
5. Overlapping Address Spaces . . . . . . . . . . . . . . . . . 5
5.1 Should a Request Be Sent? . . . . . . . . . . . . . . . . . 5
5.2 Inside or Outside? . . . . . . . . . . . . . . . . . . . . . 7
5.3 Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Agent on the Outside . . . . . . . . . . . . . . . . . . . . 8
7. More on Rulesets . . . . . . . . . . . . . . . . . . . . . . 8
8. Concatenated Addressing Realms . . . . . . . . . . . . . . . 9
9. Multiple Overlapping Address Spaces . . . . . . . . . . . . 10
10. Middleboxes and Discovery . . . . . . . . . . . . . . . . . 10
10.1 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2 Probing the Target Address . . . . . . . . . . . . . . . . . 11
10.3 Server Location Protocol . . . . . . . . . . . . . . . . . . 11
11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . 15
Brim & Simu Expires January 30, 2002 [Page 2]
Internet-Draft Midcom Agents and Topology August 2001
1. Introduction
The IETF Midcom Working Group is defining a protocol (or extensions
to one) by which an agent with application intelligence can request
middleboxes to install specific sets of rules for packet matching and
treatment [1][2]. The middleboxes of particular interest are NATs
and firewalls. The goal is to make it possible to separate
application intelligence from the actual handling of packets. The
Midcom Working Group has encountered a problem in doing this
separation -- any topology knowledge the middlebox might have, and
any information regarding the security of the networks attached to
its interfaces, is not directly available to the agent. The agent
apparently needs this information to make decisions about when to
make requests of middleboxes. This information could be made
available but a brute force approach would make both functions more
complex than they are now.
What is the minimum amount of information that needs to be given to
an agent? What approach minimizes overall system complexity?
2. Terminology
All terminology is as in the Midcom Framework [1] with the following
additions:
Addressing Realm: A contiguous part of the Internet in which all used
IP addresses are unique.
Inside: In the same addressing realm as the entity being discussed.
Outside: In a different addressing realm from the entity being
discussed.
Ruleset: A set of rules for middlebox packet processing which are
installed and removed as a unit. In particular a ruleset includes
at least one "filtering" or "matching" rule (e.g. any packet
destined for 192.168.100.1 port 42) and at least one "action" rule
(e.g. "let it through", "let it through with source address
translation to 10.0.0.25", or "discard it").
Target Address: A source or destination IP address or address range
in a rule.
Informant Address: The address of the packet originator from which a
target address was learned by the midcom agent. The mechanism by
which the target address is conveyed from the informant to the
agent is not relevant. The mechanism could be, for example,
static configuration, a DNS reply or an application protocol
Brim & Simu Expires January 30, 2002 [Page 3]
Internet-Draft Midcom Agents and Topology August 2001
control packet.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
3. The Problem
In a network with a current NAT or firewall middlebox, the middlebox
sits between an "inside" area and one or more "outside" areas. The
middlebox applies rules to packets passing between the inside and
outside areas (including the possibility of dropping them). The
middlebox is configured to know whether a particular interface is
connected to an inside or outside area. The middlebox also knows the
egress interface for any packet it is supposed to forward -- if it
didn't, the network administrator would have a problem and would
arrange for it to have that information, either through configuration
or through having the middlebox participate in routing in some way.
However, the midcom agent may be physically separate from the
middlebox. There are two problems with using the midcom framework as
it is currently conceived. First a midcom agent will ask a middlebox
to install rules for packets which the agent doesn't know for sure
will ever pass through the middlebox in the first place. Second, it
doesn't know how to tell the middlebox which interfaces on the
outside of the middlebox should carry those packets. Proposed
solutions range from hand-configuration to drastically reducing the
Midcom Working Group's goals.
4. The Simplest Scenario
Consider a very simple scenario to start. Suppose a single agent is
controlling a single middlebox connecting two addressing realms, and
the two address spaces do not overlap.
The agent's client, an end system, wishes to initiate communication.
If the packets are going to pass through the middlebox, a ruleset
needs to be installed in the middlebox allowing them to do so. With
current NATs and firewall middleboxes, application intelligence would
be yet another function co-resident with the middlebox's NAT and/or
firewall ones. Having all these functions, the middlebox would know
what to do with any packet it received on any interface, and would
not have to install any rules before the packets arrived. With
Midcom, and separation of application intelligence from the middlebox
functions, decision has to be made whether to install a ruleset for a
particular packet before the packet arrives at the middlebox.
What if the two endpoints are both on the same side of the middlebox?
Brim & Simu Expires January 30, 2002 [Page 4]
Internet-Draft Midcom Agents and Topology August 2001
In this particular case, since the address spaces do not overlap, no
great harm is done by installing a ruleset, even if the communication
it allegedly supports never passes through it. The only harm would
be useless state information in the middlebox -- a large number of
useless rulesets might block the installation of other, actually
useful, rulesets.
In this simple case, with moderate use, it is probably all right to
use the mechanisms of the midcom protocol as currently conceived of
in the Midcom Framework [1] -- no new capabilities are required.
Heavy use does lead to the risk of exhausting middlebox resources
uselessly, and a new approach is required.
5. Overlapping Address Spaces
Consider a scenario like the one above except let the inside and
outside realms have overlapping addresses. In order for
communication to happen across the middlebox, both the inside and the
outside endpoints need to be given non-overlapping addresses by the
middlebox -- a classic chicken-and-egg problem.
This is a "Twice NAT" scenario [4]. One mechanism for dealing with
this, if necessary, is for an agent (or an endpoint) to request a
globally unique address from its local middlebox, so that when others
try to find that endpoint they will receive a useful address in
response. Another mechanism is for a middlebox or an agent to
monitor responses to DNS or other higher-layer requests, so that when
an address for an endpoint or agent is being looked for, rulesets for
address translation for the address being acquired can be installed
in its local middlebox.
If a NAT middlebox is monitoring DNS itself, it can just install its
own ruleset. If a Midcom agent is doing the monitoring, then after
it receives the response containing the target address it needs to
send a request to the middlebox to have a ruleset installed for it.
It uses the midcom protocol to do so. However, unlike the simple
case in Section 4, there are problems here. The inside and outside
address spaces overlap. The target address, for which a ruleset is
being requested, might be valid in either realm. The middlebox has
no way of knowing which addressing realm the agent is referring to.
Also, unlike the previous case, in this case an unnecessary ruleset
will be a security problem. We need to be sure that packets can only
pass through the middlebox when appropriate.
5.1 Should a Request Be Sent?
Several possible solutions for the problem of avoiding unnecessary
rulesets have been proposed in the Midcom Working Group, including:
Brim & Simu Expires January 30, 2002 [Page 5]
Internet-Draft Midcom Agents and Topology August 2001
o The agent could listen in on the domain's routing protocol and
only make a request of the middlebox when traffic would actually
pass through the middlebox. Because of this the middlebox would
assume that any address which was valid both inside and outside
would refer to an outside address. First, this would add much
more complexity to an agent than was intended by the Midcom
concept. An agent should be able to be a small bit of software,
perhaps resident in the same device as the middlebox function, or
perhaps distributed with an application. Second, the knowledge
that could be gained this way would be limited. The requirement
in the general case is to learn whether a particular destination
address is inside or outside from the point of view of a
middlebox. A distance vector routing protocol would not carry
this information at all, only the next hop to reach that address
from the agent (which could be far from the middlebox). Even with
a link state protocol, area boundaries abstract routing
information.
o The agent could query the middlebox for topology information
available at the middlebox. This would require the middlebox to
be able to dump a list of all network-layer prefixes on one side
of it -- preferably the "inside". The agent would then avoid
asking for rulesets for any destination covered by one of those
prefixes. One problem with this approach is that routing might
change with a network reconfiguration, but we could extend the
protocol so that the middlebox could instruct the agent to refresh
any topology information it might have. However, this approach
would not reduce the complexity of the system at all -- it
requires enough complexity at both ends of the midcom protocol
that midcom as a whole would probably never be accepted by users.
Finally, it adds a security issue because it requires the
middlebox to prefer outside addresses to inside ones at all times.
o The agent could use application-layer intelligence to determine if
an endpoint is inside or outside. For example, a SIP proxy could
parse the identifier of the callee to determine if it is within
its trust boundaries, or keep track of which peers were "inside"
and "outside" the trust boundary itself. This is a treacherous
layer violation and is not robust. It may require constant
monitoring to be sure that network layer configuration is matched
in agent configuration. It may require a globally unique
namespace for all administrative domains, something we don't have
or need to have in the Internet today. We don't know how this
layer violation will constrain our flexibility in the future. The
application trust boundary need not correspond to the middlebox.
Application entities can move around and register at IP addresses
on different sides of the middlebox at unknown times. Finally,
there is the required preference of outside addresses over inside
Brim & Simu Expires January 30, 2002 [Page 6]
Internet-Draft Midcom Agents and Topology August 2001
ones.
In reality the agent only needs to know topology information with
reference to the middlebox for one particular ruleset, for one
particular time.
The simplest approach is to have the agent not care whether its
targets are inside or outside, and to always ask for a ruleset but
allow for the middlebox to reply with two different kinds of
"success" messages: first that the communication can go ahead because
the ruleset is acceptable, and second that the communication can go
ahead because from the point of view of the middlebox such a ruleset
is unnecessary. This is a base for proceeding, but in itself it is
not enough.
5.2 Inside or Outside?
Just because the agent does not have to care if an address (or
address range) is inside or outside, the middlebox still needs to
know. The agent does not need to make that decision, but does hold
information the middlebox needs to do so. It acquired this
information when it acquired the target address. It must pass that
information to the middlebox.
The agent acquired its target addresses somehow. A target address
may be statically configured in the agent, or the agent may acquire
it through some other protocol (including DNS). In all cases, when
it sends a target address to the middlebox as part of a rule, the way
to make sure the middlebox has the proper context for interpreting
that address is for the agent to include, with both source and
destination target addresses, the "informant" address -- the address
of the entity from which it acquired that target address. The
"informant" address is locally unique in the address space shared by
the agent and middlebox, and thus provides an absolutely sure way for
the middlebox to know whether to interpret the target address in
"inside" or "outside" context.
If the target address was learned from an informant in another
addressing realm on the other side of the middlebox, the informant's
remote address will have been translated into a locally unique
address. If the target address was learned from a target or an
informant in the same addressing realm, the informant address could
be the same as the target address, or perhaps be that of its local
DNS server, or agent. If the target address is statically
configured, the agent could list itself as the informant (note this
would make it impossible for an "outside" address to be statically
configured, although a statically configured locally unique
translation of one could be). As a default rule of last resort, to
Brim & Simu Expires January 30, 2002 [Page 7]
Internet-Draft Midcom Agents and Topology August 2001
close off security problems, the middlebox can give precedence to
inside addresses.
Thus, in most cases the informant address is all the middlebox needs
to determine the addressing realm in which the target address is to
be interpreted.
5.3 Wildcards
Sometimes an agent will want to install a matching rule for a source
or destination range of addresses, for example in order to allow
calls to come in to a server. Often any caller is acceptable and
"inside" and "outside" do not matter. However, there will certainly
be cases where an agent wants a server to be able to accept calls
from a range of addresses only as long as they are "inside". We want
to allow this restriction, and even default to it, but not require
it. To handle this case, we add one more attribute to each of the
addresses specified in matching rules: an "outside okay" flag, which
says that an outside address is allowable, and that if an address is
valid both inside and outside the middlebox, the outside should be
chosen.
6. Agent on the Outside
Consider the case where the agent is in a public realm (for example
an ISP) and the two endpoints are in the same private realm. The
same principles hold and no new mechanisms are necessary. The agent
will have acquired the target addresses from an informant. The
target addresses may only be meaningful in the informants' addressing
realms, but the address for the informant will be unique and
meaningful in the addressing realm shared by the agent and the
middlebox. When the agent sends a ruleset request to the middlebox,
specifying the target addresses and informant addresses, the
informant addresses will allow the middlebox to determine that both
the addresses are "outside", and it will respond that no ruleset
installation is necessary.
7. More on Rulesets
Because an agent usually does not know if a target address is inside
or outside when it first passes it to the middlebox, rules cannot
generally be phrased in terms of inside and outside addresses -- only
whether an outside address is acceptable. Because directionality is
important (for example, ports may differ), rules must be phrased in
terms of source and destination.
There was a proposal in the Midcom Working Group that the midcom
protocol should include actual interfaces as attributes for addresses
Brim & Simu Expires January 30, 2002 [Page 8]
Internet-Draft Midcom Agents and Topology August 2001
in matching rules. Besides the fact that it is extremely complex for
the agent to able to keep track of the middlebox's interfaces and
what they are connected to, let alone specify them in a way that is
mutually understandable, it is not necessary. If the agent includes
the addresses of its informants and an "outside okay" flag, it tells
the middlebox all it needs to know how to reach the target addresses
and to determine if installing a ruleset is necessary.
8. Concatenated Addressing Realms
There are several scenarios in which more than two addressing realms
are involved.
Suppose an agent is in one addressing realm and the two endpoints are
reachable through two different middleboxes connected to that realm.
The agent needs to install a ruleset in each middlebox. In this case
the mechanism described above works well. Informant addresses, as
received at the agent, are always unique and meaningful in the
addressing realm of the agent. The agent sends the target addresses
and informant addresses to each middlebox. At each middlebox one
informant address will be "outside", and the associated target
address will be interpreted as such, while the other will appear to
be on the inside (the same side as the agent). The ruleset will be
installed.
The "informant address" technique will not work if the target
addresses provided by informants are not meaningful to the relevant
middleboxes -- for example, if an endpoint is more than one
addressing realm away from the midcom agent and the informant
provides an address which is only meaningful in the endpoint's local
addressing realm. In order for an agent to establish connectivity
between two endpoints, both of them need to be represented by IP
addresses which are unique within the space in which they will be
used. Fortunately it looks like the implementations and strategies
proposed so far do follow this rule. A DNS server representing
endpoints in a NATted addressing realm will respond with global
addresses, and an agent can acquire a global (or at least non-local)
address for its client in advance with the help of the middlebox and
the midcom protocol as described here.
Similarly, the "informant address" technique will not work if the
agent is trying to control a middlebox through an intervening NAT.
The agent and middlebox must share an addressing realm in order for
the midcom protocol to be able to carry addresses as data
meaningfully. Situations where it would be appropriate to run the
midcom protocol through a NAT might not exist at all. Those networks
would be less secure and more difficult to manage. If such
situations did exist, an explicit fix would be to require what agents
Brim & Simu Expires January 30, 2002 [Page 9]
Internet-Draft Midcom Agents and Topology August 2001
seem to be inclined to do anyway, which is to acquire a global
address for any client before it begins communicating. In the worst
case, if nothing else is possible, a subsidiary controller can be
installed in the address realm on the other side of the NAT.
Given that these situations are unlikely, and that there are
workarounds for both of them, elaborating the midcom protocol to
provide general support for unlikely and probably undesirable
situations is not worth the complexity it would require.
9. Multiple Overlapping Address Spaces
There is a situation which is theoretically possible, but which
current NATs don't handle. It may become possible in the future.
Assume there is only one middlebox NAT function, but let it interface
between more than two overlapping address spaces. This could be made
possible using the "informant address" and "outside okay" mechanisms.
10. Middleboxes and Discovery
The problem of finding the right middlebox to make requests of
overlaps somewhat with how those requests are made, so we discuss the
discovery problem briefly.
Middlebox discovery is important in order to find a middlebox at all,
to find a middlebox which is appropriate for the ruleset the agent
wants to install, and to find a middlebox which can handle the
expected load. Draft-lear-middlebox-discovery-requirements-00.txt
[5] lists some requirements. One of those requirements was that no
endpoint or agent should be required to participate in routing, which
the scheme proposed here satisfies.
10.1 Anycast
It might be possible to use anycast and avoid having any explicit
discovery mechanism at all -- the agent would simply launch queries
at an anycast address appropriate for middleboxes of a particular
type.
However, anycast literally finds any target. The only way to
discriminate between middleboxes using anycast would be to use
different addresses. It's very likely that we will want to be able
to discriminate between middleboxes much more flexibly than just by
IP address. For example some middleboxes might be connected to some
outside realms while others were connected to others.
Also, anycast is intended for one-time or at least short duration
interactions, since if routing changes the destination found by an
Brim & Simu Expires January 30, 2002 [Page 10]
Internet-Draft Midcom Agents and Topology August 2001
anycast packet may change. This would be a problem for any
association which has synchronized state. The midcom protocol
already has a long-lasting association --
authentication/authorization and capability negotiation are done for
the middlebox to start with, and it is expected that
authentication/authorization for each request after that will depend
on that initial exchange.
10.2 Probing the Target Address
Tunnel Endpoint Discovery (TED) [6] is for finding IKE
intermediaries. Its approach could possibly be reused. TED sends a
special probe packet toward the target address, which is actually
intended for any appropriate intermediary. If an authorized
intermediary notices the packet it intercepts it and responds. A
similar probe could be used to discover middleboxes.
If there were multiple disjoint connections between the agent's
domain and the outside world, this would ensure that the agent
established an association with the appropriate middlebox for that
particular needed ruleset.
The problem with using special probes like this is the very basic
issue that the agent should not have to know if a target address is
inside or outside the middlebox. If the agent launches a probe
toward an address which is on the same side of the middlebox, it will
get no response. What has it learned then? TED is a different case,
in that discovery of a tunnel endpoint is required for the service to
be provided at all.
10.3 Server Location Protocol
If middlebox discovery used SLP, a request for a middlebox "service"
could be given detailed attributes, including the entire ruleset
needed. A domain could create its own policies for deciding which
middlebox a particular agent should use for a particular ruleset, and
change them arbitrarily. In particular this arbitrariness would
allow complex topologies, middleboxes with differing capabilities --
in series as well as in parallel -- and spontaneous changes in
administrative relationships. Different outside domains could be
reached via different middleboxes at different times of the day and
so on.
SLP uses multicast, which some may think is a problem. However in
simple situations discovery is not necessary, as demonstrated above
for simple scenarios, and in complex situations unicast SLP can be
used.
Brim & Simu Expires January 30, 2002 [Page 11]
Internet-Draft Midcom Agents and Topology August 2001
Thus, SLP might be useful for middlebox discovery. The mechanisms
proposed in this document do not have any architectural conflict with
using SLP.
The mechanisms proposed in this document do lead the agent to ask an
SLS about every ruleset request. There are a number of possible
means to cut back on SLP activity and to reduce the potential scaling
problem. For example, the ability to ask SLP about ranges, the
ability of the SLP responses to include ranges and TTLs, and the
possibility of information being "pushed". If SLP is actually
selected as a base for middlebox discovery, and the rate of SLP
activity is seen as a problem, we could explore ways to make this
approach scale.
11. Summary
The problem is that an agent does not know whether to ask for a
ruleset to be installed or not.
To solve this problem without adding an overwhelming amount of
complexity to every agent and middlebox:
o The agent queries the middlebox about every possible ruleset. The
agent does not have to know if packets for a particular
association would pass through a middlebox or not.
o In a query the agent says what the two endpoint addresses are that
it will need to be able to establish an association between
(wildcards are allowed). Each specific address or address range
has associated with it an "outside okay" attribute and the address
of the "informant" from which the agent learned that address. An
informant address could be the address of the agent itself, for
example in the case of static configuration, the address of some
other helper, or the address of one of the endpoints.
o The middlebox has a new type of reply to such queries, which is
that the query has succeeded through no rules being necessary
(since that association will not pass through the middlebox).
This scheme adds no extra management burden, either locally or
globally, nor does it add any of the concomitant security risk that
extra configuration brings in a dynamic network environment. It does
not threaten Internet scalability or robustness. It does not create
new layer violations. It adds three simple pieces of information to
the coalescing midcom protocol.
Middlebox discovery is still a poorly explored area, but this scheme
appears to work with middlebox discovery mechanisms at least as well
Brim & Simu Expires January 30, 2002 [Page 12]
Internet-Draft Midcom Agents and Topology August 2001
as any other proposal.
There are restrictions on the applicability of this approach, but the
cost of creating a protocol to cover the unusual scenarios which this
approach does not is not worth paying.
There are several loose ends to be explored, but none that call the
basic protocol mechanisms into question.
12. Security Considerations
The topology knowledge which a middlebox uses to make decisions about
whether to install a ruleset or not is no more secure than the source
of that knowledge, which is either configuration or routing
protocols.
The transfer of specific knowledge between the middlebox and the
midcom agent is only as secure as the midcom protocol. There are
requirements for mutual authentication of middlebox and agent.
However, the protocol has not yet been specified or implemented and
cannot be analyzed for security problems.
The middlebox may be misled into opening up trust boundaries if
"inside" versus "outside" is not explicitly indicated, or if an agent
gets confused over the origin from which it learned a particular
address.
References
[1] Srisuresh, P., Kuthan, J., Rosenberg, J. and A. Rayhan,
"Middlebox Communication Architecture and framework", Internet
Draft draft-ietf-midcom-framework-03.txt, July 2001.
[2] Swale, R., Mart, P. and P. Sijben, "Middlebox Control (MIDCOM)
Protocol Architecture and Requirements", Internet Draft draft-
ietf-midcom-requirements-02.txt, July 2001.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Srisuresh, P. and M. Holdredge, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[5] Lear, E., "Requirements for Discovering Middleboxes", Internet
Draft draft-lear-middlebox-discovery-requirements-00.txt, April
2001.
[6] "Tunnel Endpoint Discovery Enhancement", February 2001,
Brim & Simu Expires January 30, 2002 [Page 13]
Internet-Draft Midcom Agents and Topology August 2001
<http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/ted.htm>
.
Authors' Addresses
Scott Brim
Cisco Systems, Inc.
146 Honness Lane
Ithaca, NY 14850
USA
EMail: sbrim@cisco.com
Adina Simu
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: asimu@cisco.com
Brim & Simu Expires January 30, 2002 [Page 14]
Internet-Draft Midcom Agents and Topology August 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Brim & Simu Expires January 30, 2002 [Page 15]