One document matched: draft-shore-tist-prot-00.txt
Internet Draft Melinda Shore
draft-shore-tist-prot-00.txt Cisco Systems
May 2002
Expires November 2002
The TIST (Topology-Insensitive Service Traversal) Protocol
<draft-shore-tist-prot-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 docu-
ments 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.
Abstract
TIST is an application of the RSVP protocol to the problem of com-
municating application requests, such as pinhole openings and NAT
table entries, to NATs and firewalls. By using RSVP we avoid the
problem of having to locate these devices in the network and estab-
lish trusted relationships with each one we would like to influ-
ence.
1. Introduction
Network transparency was one of the original design goals of the IP
protocol suite. Over time, as the economic and social drivers
Shore [Page 1]
Internet Draft TIST May 2002
behind network have changed, services are appearing within the net-
work that undermine transparency. Examples of these services
include security services (such as security gateways and fire-
walls), address translation services, data compression, and QoS.
Applications are increasingly needing to influence the behavior of
these services in order improve their function on the network and
sometimes, in dire cases, to be able to function at all.
Several different approaches to solving this problem have been pro-
posed in different contexts. The IETF Middlebox Communication
(midcom) working group [Srisuresh] is developing a protocol to run
between an application endpoint or proxy and a "middlebox," such as
a firewall or NAT, in the network. Cisco's Tunnel Endpoint Discov-
ery Protocol (TED) [Fluhrer] is based on an IKE extension using the
Vendor ID to find IPSec peers and negotiate proxies.
Aspects of the problem include:
+ Location
+ Provisioning
+ Dynamic state installation and maintenance
+ Routing
Policy-related aspects of the problem include authorization and
admission control. Policy can be statically provisioned or it can
be determined through consultation with a policy server (also known
as a "policy decision point"). While the protocol between a mid-
dlebox and a policy server is outside the scope of this document,
we need to ensure that sufficient information is carried in the
TIST protocol for a middlebox to be able to consult with a policy
server.
2. TIST
TIST (Topology-Insensitive Service Traversal) is based on a frame-
work first outlined in [Shore]. Like TED, TIST relies on the net-
work to deal with network-layer issues, including routing and dis-
covery. Where midcom assumes that a layer-violating explicit con-
nection will be established between each application endpoint need-
ing to influence a middlebox and each middlebox, TIST simply sends
a request from a source host to a destination host with an "atten-
tion" flag set (whether protocol number, port number, or IP
option). Applications no longer need knowledge of network
Shore [Page 2]
Internet Draft TIST May 2002
topology, and solutions to the location and routing problems are
inherent in this approach. We refer to it as "topology-insensi-
tive" because it expected to be robust across complex, varied net-
work topologies and in the face of changing network topologies.
Shore [Page 3]
Internet Draft TIST May 2002
As evaluation of requirements for a network-transparent protocol
progressed it became clear that RSVP [RFC2205] was a very close
match and that it constains the necessary protocol machinery to
install and maintain middlebox state. RSVP relies on network-layer
routing to find RSVP-capable routers. It has the considerable
advantage of being widely available on routers and reasonably
widely available on host operating systems. RSVP has the following
attractive attributes [RFC2205]:
+ It recovers from routing changes
+ RSVP operates on unidirectional data flows
+ RSVP operates independently of network routing protocols
+ RSVP allows the transport of data elements that are opaque to
the protocol
+ RSVP provides transparent operation through routers that don't
support it
+ RSVP supports both IPv4 and IPv6
+ RSVP messages can be processed both by endpoints (host fil-
ters, for example) and by intermediate devices
This document assumes familiarity with the RSVP protocol and with
its message processing rules [RFC2209].
3. Terminology
Downstream
Away from the sender (see below) towards the receiver
Middlebox
A network intermediate devices that implements one or more of
the middlebox services, such as NAT or firewall. See
[Srisuresh].
Receiver
The entity towards which a Path message is ultimately
directed, and which generates a Resv message.
Resource
The state being manipulated in TIST requests, such as a NAT
table mapping or a firewall pinhole.
Shore [Page 4]
Internet Draft TIST May 2002
Sender
The entity generating the original TIST Path message.
Upstream
Towards the sender and away from the receiver.
4. Protocol
4.1. Requesting Resources
TIST is based on the RSVP protocol, in particular its flow model
and the use of the two main messages, Path and Resv.
Each data flow arrives from a previous hop node through a corre-
sponding incoming interface and after processing departs through
one or more outgoing interfaces. For the purposes of firewall con-
figuration, this represents a significant advantage in that it
allows a firewall or NAT to use the IP-layer routing information it
already has in order to correctly identify the interface to which
the TIST request should be applied. Unlike midcom, information on
interfaces and routing table contents need not be exported to
clients or agents.
A host requiring firewall or NAT services (say, a pinhole opened or
a NAT table mapping installed) sends a Path message downstream
towards the host with which it intends to communicate. Path mes-
sages include a service request and parameters and the unicast
address of the previous node. It also includes a Sender Template
[RFC2205]. For the purposes of this application, we will use only
a Fixed Filter reservation style, and we will NOT include a Sender
Tspec.
When the downstream host receives the Path message, it returns a
reservation request (Resv) upstream towards the original sender.
This message MUST exactly follow the reverse of the path it took
downstream. It is upon receipt of the Resv message that the mid-
dlebox confirms and finally installs new state.
4.2. State Maintenance
As with RSVP, TIST uses a soft state approach to managing state in
firewalls and NATs. State is created and refreshed through the use
of idempotent Path and Resv messages, which 1) provides automatic
cleanup of stale state, and 2) provides robustness across topology
and routing changes. See [RFC2205] for state maintenance details.
Shore [Page 5]
Internet Draft TIST May 2002
4.3. Path Teardown
In support of more efficient resource management TIST senders
SHOULD explicitly tear down the resources they have requested,
using the RSVP PathTear message. TIST receivers SHOULD NOT use the
ResvTear message to delete installed resources (and cannot, when
request authentication is being used).
If a middlebox wishes to delete an installed resource it SHOULD
send a ResvErr back to the TIST sender, which may then send a
PathTear message to remove the resource. [There's an issue here,
and that's whether or not a middlebox wishes to conceal its exis-
tence.]
5. Traversing TIST-unaware Middleboxes
When RSVP messages traverse non-RSVP-capable routers, traffic may
be perturbed but the RSVP protocol will itself function properly.
Traffic that has been admitted for privileged service may be per-
turbed as it traverses a non-RSVP-capable router but it will likely
receive best-effort service. When TIST messages traverse non-TIST-
capable middleboxes the potential impact is quite different.
If a TIST message is passed along without being processed by a non-
TIST-capable firewall, it may appear to the originator of the Path
message that the TIST request was successful while, in fact, a
firewall along the path did not process the request at all and
therefore did not open an appropriate pinhole. Consequently care
must be taken to craft the protocol to maximize the likelihood that
TIST requests will be blocked by non-TIST-capable firewalls.
Potential approaches might include setting IP options bits, such as
the Router Alert option [RFC2113], and/or carrying the messages in
raw IP packets rather than over a standard transport protocol such
as TCP or UDP. See "Transport Considerations."
6. TIST Messages
TIST uses existing RSVP messages. It introduces some new classes
and modifies the use of some existing classes. Because TIST is
based on RSVP, it shares the RSVP common header format:
Shore [Page 6]
Internet Draft TIST May 2002
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Flags| Msg Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| Send TTL | (Reserved) | RSVP Length |
+-------------+-------------+-------------+-------------+
where:
Vers: 4 bits
Protocol version number. Currently 1
Flags: 4 bits
Not used
Msg Type: 8 bits
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConf
RSVP Checksum: 16 bits
See [RFC2205]
Send_TTL: 8 bits
The original IP TTL with which the message was sent.
RSVP Length: 16 bits
Total RSVP message length, including headers.
Every RSVP object consists of one or more 32-bit words with a one-
word header, with the following format:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
Length: 16 bits
Shore [Page 7]
Internet Draft TIST May 2002
Total object length in bytes. Must be a multiple of 4 and at least
4.
Class-num
Identifies the object class. See [RFC2205] for details. The RSVP
messages which MUST be supported by a TIST implementation include:
NULL
SESSION
RSVP_HOP
TIME_VALUES
SENDER_TEMPLATE
ERROR_SPEC
POLICY_ DATA
INTEGRITY
6.1. TIST Path Messages
While TIST Path messages are sent by a sender in order to initiate
request processing. Each sender periodically sends a Path message
downstream towards a receiver. The Path message contains NAT
and/or firewall requests, along with associated data such as policy
objects or integrity objects.
A Path message travels from a sender to a receiver. The IP source
address in the packet header MUST be the address of the sender, and
the destination address MUST be the address of the receiver. This
allows TIST to leverage existing routing state for the location of
and communication with middleboxes along the data path. Note, how-
ever, that by including addresses in TIST objects we allow the pos-
sibility of 3rd-party requests, where appropriate. Therefore TIST-
capable middleboxes MUST act on the addresses in the TIST objects
and not on the addresses in the IP headers of the TIST requests.
The TIST Path message format is:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP HOP>
Shore [Page 8]
Internet Draft TIST May 2002
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <SENDER_TEMPLATE> ]
[ <FW> ... ]
[ <NAT> ... ]
All RSVP objects in the Path message MUST obey the behavior defined
in [RFC2205]. When a NAT table mapping is being requested, after
the mapping is installed the node MUST write the address/port tuple
of the new mapping into the Previous Hop IP Address field in the
NAT object.
6.2. TIST Resv Messages
TIST Resv messages are returned by the receiver to the sender in
response to a Path message. These are the messages that actually
confirm and install soft state, and they are returned along the
reverse paths of data flows for the session. As with RSVP, the
destination address of a Resv message is the unicast address of the
previous-hop node. The source address is that of the node sending
the message (not the TIST receiver).
The Resv format is:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ]
[ <FW> ... ]
[ <NAT> ... ]
[ <POLICY_DATA> ... ]
All objects MUST obey the same behavior as they do in RSVP. The
NAT object carries the address(es) which are being NATted-to by
NATs in the data path. In addition, each TIST-capable NAT that
chooses to honor the NAT request MAY add the address and port to
which it will be mapping the requested address and port, as a NAT
object. The NAT objects are ordered, so that the first NAT added
will be first, the second will follow, and so on. Each NATting
node adding a NAT object MUST replace the contents of Previous Hop
IP Address field with the current contents of IP Address field;
this allows the selection of the correct IP address and port number
for installation in a firewall pinhole rule.
Shore [Page 9]
Internet Draft TIST May 2002
Note that a NAT may, according to site-local policy, choose not to
add a NAT object. The primary reason for choosing not to do so
would be to obscure the presence of a particular NAT, but given
that this would likely cause protocol failures and that there are
other options, such as STUN [Rosenberg], for finding NATted-to
addresses, this is not recommended.
Because the IP transport address/port pair may be modified by NATs
along the path and because there may be more than one NAT, fire-
walls MUST install pinhole informormation based on the most
recently-assigned address - that is to say, the last NAT object.
[The ability of receivers to send back the address they see (i.e.
that of the outermost NAT) is an open question and needs further
consideration.]
6.3. TIST PathTear Messages
As with RSVP, the recipient of a PathTear message MUST delete
matching path state, whether it is a firewall pinhole, a NAT table
entry, or both. State is matched on the SESSION, SENDER_TEMPLATE,
and PHOP objects, and MAY match on a FW or NAT object as appropri-
ate. Unlike RSVP, however, non-matching PathTear messages SHOULD
be forwarded. The TIST PathTear message format is:
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<SENDER_TEMPLATE>
[ <FW> ] [ <NAT> ]
6.4. TIST ResvTear Messages
Receipt of a ResvTear message deletes matching reservation state.
State is matched on the SESSION and RSVP_HOP objects. ResvTear
messages are initiated by receivers (for example, upon call termi-
nation in a VoIP application).
If a middlebox wishes to delete an installed resource it SHOULD
send a ResvErr back to the TIST sender, which may then send a
PathTear message to remove the resource.
A ResvTear message must be routed like the corresponding Resv mes-
sage, and its IP destination address MUST be the unicast adress of
a previous hop.
Shore [Page 10]
Internet Draft TIST May 2002
The TIST ResvTear message format is:
<ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP>
6.5. TIST PathErr Messages
PathErr messages are error messages in response to errors in pro-
cessing Path messages. They are returned to the sender and they
are routed hop-by-hop using path state. At each hop, the IP desti-
nation address is the unicast address of the previous hop. PathErr
messages are not processed by intermediate nodes, but only by the
sender application.
The format for PathErr messages is:
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...]
The ERROR_SPEC object specifies the error being reported and
includes the IP address of the node that encountered the error.
The POLICY_ DATA object(s) may carry information about policy
errors.
6.6. TIST ResvErr Messages
ResvErr messages report Resv processing errors or disruption in
reservation (pinhole/NAT table mapping) state. ResvErr messages
are returned towards the receiver that initiated the Resv message
and are routed hop-by-hop using the reservation state. At each hop
the IP destination address is the unicast address of the next-hop
node.
The format for a ResvErr message is:
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <POLICY_DATA> ...]
The ERROR_SPEC object specifies the error being reported and
includes the IP address of the node that encountered the error.
The POLICY_DATA object(s) may carry information about policy
errors.
Shore [Page 11]
Internet Draft TIST May 2002
7. TIST Classes
TIST adds these new classes:
NAT
Carries NAT-specific requests.
FW
Carries firewall-specific requests.
7.1. Object Definitions
7.1.1. FW Class
FW Class = <to be assigned by IANA>.
7.1.1.1. IPv4 FIREWALL object: Class = <xxx>, C-Type = 1
[This bit needs major tweaking]
+-------------+-------------+-------------+-------------+
| Source IPv4 Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Source IPv4 Netmask (4 bytes) |
+-------------+-------------+-------------+-------------+
| Dest IPv4 Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Dest IPv4 Netmask (4 bytes) |
+-------------+-------------+-------------+-------------+
| Source Port | Dest Port |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | Options |
+-------------+-------------+-------------+-------------+
| ICMP type | ICMP code | Unused |
+-------------+-------------+---------------------------+
The FW object describes a filter rule to be installed. It is
derived from the Diameter IPFilterRule AVP [Diameter].
The Netmask fields are provided to allow arbitrary-length network
wildcarding, such as CIDR addresses or locally-visible subnets, to
be filtered upon.
Shore [Page 12]
Internet Draft TIST May 2002
If the port is set to zero, it is treated as a wildcard matching
any port number.
The Protocol ID is any IP protocol number.
Options
FRAG . . . . . . . . . . . . . . . x
SSRR . . . . . . . . . . . . . . x .
LSRR . . . . . . . . . . . . . x . .
RR . . . . . . . . . . . . x . . .
TCPESTABLISHED . . . . . . . . . . . x . . . .
TCPSETUP . . . . . . . . . . x . . . . .
ICMP . . . . . . . . . x . . . . . .
When the FRAG bit is set, match if the packet is a fragment but not
the first fragment of a datagram.
When the SSRR bit is set, match if the strict source route IP
option is set. The LSRR bit is used to indicate the loose source
route IP option, and RR is used to indicate the record route IP
option.
TCPESTABLISHED is used to match TCP packets that have the RST or
ACK bits set. It is meaningless for non-TCP packets and the mid-
dlebox SHOULD return a XXX error if it receives a request in which
this bit is set but the protocol is not TCP.
TCPSETUP is used to match TCP packets. It is meaningless for non-
TCP packets and the middlebox SHOULD return a XXX error if it
receives a request in which this bit is set but the protocol is not
TCP.
The ICMP type and ICMP code fields are ignored unless the ICMP bit
is set in the options field.
Flags
ALLOW . . . . . . . x
These flags affect how the rules should be processed by the middle-
box. If the ALLOW bit is set, the request is that matching traffic
should be allowed by the firewall. If it is not set, the request
is that matching traffic should be denied.
Shore [Page 13]
Internet Draft TIST May 2002
7.1.1.2. IPv4 FIREWALL Offset object: Class = <xxx>, C-Type = 2
+-------------+-------------+-------------+-------------+
| Offset | Length |
+-------------+-------------+-------------+-------------+
| Value |
+---------------------------+-------------+-------------+
| Flags | Unused |
+-------------+-------------+-------------+-------------+
This object allows senders to request filtering on arbitrary values
at arbitrary offsets from the start of the IP packet. For example,
this could be used to carry an IPSec SPI, which would allow filter-
ing requests on encapsulated packets.
Offset is a 16-bit value representing the number of octets from the
start of the IP packet at which to begin the comparison. Length a
16-bit value representing number of length in octets of the value
to be compared against, and Value is the Value itself.
Flags
ALLOW . . . . . . . x
These flags affect how the rules should be processed by the middle-
box. If the ALLOW bit is set, the request is that matching traffic
should be allowed by the firewall. If it is not set, the request
is that matching traffic should be denied.
7.1.2. NAT Class
NAT Class = <to be assigned by IANA>
7.1.2.1. IPv4 NAT object: Class = <xxx>, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Port | Protocol | Unused |
+-------------+-------------+-------------+-------------+
| Previous Hop IPv4 Address (4 bytes) |
+-------------+-------------+-------------+-------------+
Shore [Page 14]
Internet Draft TIST May 2002
The NAT object describes an address/port/protocol tuple for which a
NAT table mapping is requested. The Previous Hop IPv4 address con-
tains the most recent address assignment, so that, for example, if
there has been no NAT in the path to this point it contains the
address of the sending host, and if there has been a NAT in the
path it contains the address/port tuple to which the sending host's
address has most recently been mapped.
8. Error Codes and Values
TIST uses existing RSVP error codes. Usage details follow.
8.1. Error Code = 01: Admission control failure
Error code 01 would be sent in the case where there were insuffi-
cient resources on the middlebox, for example if the NAT table were
full. The ss, u, and r bits are to be treated as specified in [RFC
2205].
8.2. Error Code = 05: Conflicting reservation style
This error code is not used.
8.3. Error Code = 06: Unknown reservation style
This error code is not used.
8.4. Error Code = 12: Service preempted
This error code is not used.
8.5. Error Code = 21: Traffic Control Error
This error code is not used. Malformed or unreasonable requests
would return error code 23.
8.6. Error Code = 22: Traffic Control System error
This error code is not used.
9. Transport Issues
The primary issue related to TIST transport is that we need to max-
imize the likelihood that TIST requests will be dropped by any non-
TIST-capable firewall/NAT that they traverse. Note that this con-
trasts immediately with RSVP, where it is desirable that RSVP
Shore [Page 15]
Internet Draft TIST May 2002
requests be forwarded by non-RSVP-aware devices.
There are several options for doing this, the most promising of
which are 1) setting an IP option, and 2) using a "surprising"
transport-layer protocol (i.e. not TCP or UDP). The RSVP protocol
requires that RSVP messages be sent with the Router Alert IP option
[RFC2113] and RSVP messages be sent in "raw" IP packets (and only
optionally be UDP-encapsulated). The risk is that a firewall may
be configured to pass RSVP traffic and that a TIST packet may,
therefore, be forwarded without having been processed. Because of
this it may be desirable to assign a separate IP protocol number.
10. IANA Considerations
The following classes need RSVP class numbers assigned:
NAT
FW
[We may wish to have a new protocol number assigned.]
11. Security Considerations
Security is critically important to TIST because TIST is used to
communicate with security devices such as firewalls. The threats
must be well-understood and appropriate countermeasures taken. In
particular, we need to protect against inappropriate manipulation
of state both at the sender and receiver as well as at the interme-
diate nodes.
The use of the RSVP INTEGRITY object [RFC2747], in particular, will
provide hop-by-hop message authentication and anti-replay protec-
tion, and it SHOULD be applied to all TIST messages. Unfortu-
nately, while the specification provides a keying example based on
Kerberos, keying is unspecified and will need to be addressed in
future versions of this document.
Authorization (admissions) decisions must be made on the basis of
the authenticated identify of the requesting user or application
(the sender). TIST implementations MUST include the authentication
policy element (AUTH_DATA) [RFC3182]. In order to protect against
application-layer data hijacking attacks, all NAT responses from a
NAT back to the sender SHOULD include AUTH_DATA elements. Note
that this implies that the NAT device either participates in a PKI
or in a Kerberos deployment.
Shore [Page 16]
Internet Draft TIST May 2002
12. Proxy considerations
In some cases it may be desirable to have proxies generate Path
messages, or receive Path messages and/or generate Resv messages,
on behalf of topologically-appropriate hosts. Whether or not this
is possible will depend on the addressing and security models. A
primary consideration will be location and addressing - a proxy
providing an AUTH_DATA object in a Resv message may lead to that
message being inappropriately discarded if the sender expects the
Resv message to come from the host to which the Path message was
originally addressed.
13. Multicast considerations
Multicast will be addressed in a future iteration of this document.
14. References
[Diameter] Calhoun, P. et al. "Diameter Base Protocol," work in
progress. April 2002.
[Fluhrer] Fluhrer, S. "Tunnel Endpoint Discovery," work in
progress. November 2001.
[RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP
-- Version 1 Functional Specification." RFC 2205.
[RFC2209] Braden, R. and Zhang, L. "Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules." RFC 2209.
[RFC2113] Katz, D. "IP Router Alert Option," RFC 2113.
[RFC2747] Baker, F., Lindell, B., and Talwar, M. "RSVP Crypto-
graphic Authentication." RFC 2747.
[Rosenberg] Rosenberg, J. et al. "STUN - Simple Traversal of UDP
Through NATs," work in progress. April 2002.
[Shore] Shore, M. "Towards a Network-Friendlier Midcom," work in
progress. October 2001.
[Srisuresh] Srisuresh, S. et al. "Middlebox Communication Archi-
tecture and framework," work in progress. October 2001.
Shore [Page 17]
Internet Draft TIST May 2002
15. Acknowledgements
I would like to thank Adina Simu and Mahadev Somasunderam for their
analysis and discussion.
16. Copyright
The following copyright notice is copied from RFC 2026 [RFC2026]
Section 10.4, and describes the applicable copyright for this docu-
ment.
Copyright (C) The Internet Society October 1, 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, pub-
lished and distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and this para-
graph are included on all such copies and derivative works. How-
ever, 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 proce-
dures 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 assignees.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI-
NEERING 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 WAR-
RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
17. Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996], Sec-
tion 10.4, and describes the position of the IETF concerning intel-
lectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
Shore [Page 18]
Internet Draft TIST May 2002
pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such pro-
prietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Execu-
tive Director.
Author's Address
Melinda Shore
Cisco Systems
809 Hayts Road
Ithaca, NY 14850
USA
mshore@cisco.com
Shore [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-22 06:59:29 |