Internet DRAFT - draft-shore-stun-signaling
draft-shore-stun-signaling
Network Working Group M. Shore
Internet-Draft K. Biswas
Expires: June 8, 2006 D. McGrew
Cisco Systems
December 5, 2005
A STUN-Based Signaling (SBS) Framework
draft-shore-stun-signaling-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 June 8, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
STUN has proven to be a popular mechanism for providing basic NAT
traversal capabilities for UDP traffic. As it has matured it has
become an attractive target for extensions that move away from STUN's
discovery function towards explicit communication with middleboxes --
in other words, as an on-path signaling protocol. This document
describes a more generalized framework for using STUN for solving on-
path signaling problems.
Shore, et al. Expires June 8, 2006 [Page 1]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 5
2. SBS Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Message Processing Overview . . . . . . . . . . . . . . . 6
2.2. NAT Traversal Support . . . . . . . . . . . . . . . . . . 7
2.3. SBS Message Format . . . . . . . . . . . . . . . . . . . . 7
2.3.1. SBS Message Types . . . . . . . . . . . . . . . . . . 7
2.3.2. The SBS Control Block . . . . . . . . . . . . . . . . 7
2.3.3. NAT_ADDRESS . . . . . . . . . . . . . . . . . . . . . 8
2.3.4. TIMEOUT . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.5. IPV4_HOP . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.6. IPv6_HOP . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.7. IPv4_ERROR_CODE . . . . . . . . . . . . . . . . . . . 10
2.3.8. IPv6_ERROR_CODE . . . . . . . . . . . . . . . . . . . 12
2.3.9. AGID . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.10. CHALLENGE . . . . . . . . . . . . . . . . . . . . . . 13
2.3.11. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 13
3. Sending SBS messages . . . . . . . . . . . . . . . . . . . . . 14
4. Messaging and State Maintenance . . . . . . . . . . . . . . . 15
4.1. BUILD-ROUTE . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. HOP-BY-HOP . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. BIDIRECTIONAL . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Path Teardown Messages . . . . . . . . . . . . . . . . . . 16
4.5. Network Address Translation . . . . . . . . . . . . . . . 16
5. Application interface . . . . . . . . . . . . . . . . . . . . 18
6. NAT interactions . . . . . . . . . . . . . . . . . . . . . . . 19
7. Using SBS as a NAT traversal protocol . . . . . . . . . . . . 20
8. Discovery of non-SBS NATs, and recovery . . . . . . . . . . . 21
9. Endhost processing . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Intermediate Node Processing . . . . . . . . . . . . . . . . . 25
11. Using SBS to support bidirectional reservations . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27
12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.2. Security Model . . . . . . . . . . . . . . . . . . . . . . 27
12.3. Cryptography . . . . . . . . . . . . . . . . . . . . . . . 28
12.3.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.4. Datatypes . . . . . . . . . . . . . . . . . . . . . . . . 28
12.5. The Authentication Exchange (AX) . . . . . . . . . . . . . 30
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
13.1. SBS Application Identifiers . . . . . . . . . . . . . . . 32
13.2. SBS Attribute Identifiers . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Shore, et al. Expires June 8, 2006 [Page 2]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Shore, et al. Expires June 8, 2006 [Page 3]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
1. Introduction
RSVP [rfc2205] is based on a "path-coupled" signaling model, in which
signaling messages between two endpoints follow a path that is tied
to the data path between the same endpoints, and in which the
signaling messages are intercepted and interpreted by RSVP-capable
routers along the path. While RSVP was originally designed to
support QoS signaling for Integrated Services [rfc1633], this model
has proven to generalize to other problems extremely well. Some of
these problems include topology discovery, QoS signaling,
communicating with firewalls and NATs, discovery of IPSec tunnel
endpoints, test applications, and so on.
This document describes the use of the STUN [rosenberg] protocol for
on-path signaling. Unlike RSVP, STUN-Based Signaling (SBS) is not
tied directly to IntServ and the protocol machinery itself is
sufficiently generalized to be able to support a variety of
applications. What this means in practice is that there will be
different signaling applications, all of which share a base STUN
transport layer. This is similar to the concepts used in secsh,
where authentication and connection protocols run on top of a secsh
transport protocol (see [ylonen] for details).
The protocol machinery was originally based somewhat on RSVP without
refresh overhead reduction extensions [rfc2961], but in the process
of generalization has lost many of the features that define RSVP,
such as necessary receiver-oriented reservations and processing
requirements at each node.
SBS differs from RSVP in several important ways. One of the most
significant of these is that the protocol described in this document
does not itself trigger reservations in network nodes. The STUN
application will do that, and, indeed, some STUN applications may not
carry reservation requests at all (discovery protocols, for example).
Because of this SBS does not support reservation styles (those would
be also be attributes of an application). Another significant
difference is that that reservations may be installed by an SBS
application in either a forward (from the sender toward the receiver)
or backward (from the receiver toward the sender) direction -- this
is application-specific.
Other possibly significant differences include that NAT traversal
support is integrated into the message transport, and that SBS allows
an application to install reservations for paths that are
bidirectional and asymmetric.
Shore, et al. Expires June 8, 2006 [Page 4]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
1.1. Transport Layer
This document describes the transport layer. The SBS transport layer
is as simple as we could make it, supporting two basic functions:
routing and NAT traversal. The sources of complexity in signaling
protocols tend to be the signaling applications themselves. Those
applications have varying performance and reliability requirements,
and consequently we feel that application-specific functions belong
in the application layer.
The SBS transport layer is also relatively stateless. By "stateless"
we mean that the transport layer does not itself create or manipulate
state in participating nodes. By "relatively" we take exception to
the previous assertion, in that the transport layer provides
facilities for route identification and route pinning. This is an
optimization, albeit a significant one, which allows SBS to be used
without a separate route discovery process. Another source of state
is in the case of NATs, where an SBS request may trigger the creation
of a NAT table mapping. However, this latter case does not create
SBS maintenance state.
An application may wish to support summary refreshes or other
performance enhancements; that type of function is application-
specific and requires no support from the transport layer.
Shore, et al. Expires June 8, 2006 [Page 5]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
2. SBS Messages
2.1. Message Processing Overview
Unlike RSVP, SBS has only one fundamental message type plus one error
message type, and directionality is significant to the SBS
application only. Three new attributes, HOP-BY-HOP, BUILD-ROUTE, and
BIDIRECTIONAL, have been added in support of greater flexibility in
the SBS application. For example, some applications which already
know network topology or which run a separate routing protocol may
choose to route hop-by-hop in a forward direction. Conversely, a
topology discovery protocol may choose to route end-to-end in the
return direction. Both of these would be departures from the Path/
Resv message handling specified in RSVP.
The BUILD-ROUTE flag has been added to allow route discovery to be
overloaded on top of basic messaging, much like the RSVP Path
message. If the BUILD-ROUTE flag is present, SBS nodes store routing
information carried in incoming HOP objects. They also overwrite
routing information into the HOP attribute in outgoing SBS messages.
The BIDIRECTIONAL flag may be used to indicate that the application
for which this SBS message carries a payload must be executed in each
direction. It may be used in combination with the HOP-BY-HOP flag in
some circumstances, but typically it will be used with the HOP-BY-HOP
flag set to 0.
Even with these departures, the basic operation of the protocol may
made be similar to RSVP with the appropriate use of the new
attributes. For example, a message may be injected into a network by
the sender towards a receiver, routed end-to-end with the receiver's
address in the destination address in the IP header. If the BUILD-
ROUTE bit is set in the SBS flags, entities along the path the
message traverses will intercept it, store path state, act on (or
not) the application payload data, and forward the message towards
its destination. In SBS, "path state" refers specifically to the
unicast IP address of the previous hop node along with the previous
node's optional logical interface information.
When the message arrives at the receiver (or its proxy), the receiver
may generate another SBS message in response, this time back towards
the original sender. As with the message in the forward direction,
this message may be routed either end-to-end or hop-by-hop, depending
on the requirements of the application. In order to emulate an RSVP
Resv message, the HOP-BY-HOP is set to 1 and the BUILD-ROUTE bit is
set to 0.
BUILD-ROUTE and HOP-BY-HOP MUST not be set in the same SBS message,
Shore, et al. Expires June 8, 2006 [Page 6]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
and BUILD-ROUTE and TEARDOWN MUST not be set in the same SBS message.
2.2. NAT Traversal Support
NAT traversal poses a particular challenge to a layered protocol like
SBS. If we assume the use of discrete, opaque applications, one of
which is NAT, interactions between other applications that make use
of addresses (for example, firewall rules or QoS filter specs) and
the NAT application are complicated. Either every application will
need to be able to peek into NAT payloads and identify which address
mapping is the one they need, or NATs supporting SBS will need to be
able to parse and write into every application payload type. Neither
approach is particularly robust, reintroducing a type of stateful
inspection and constraining how applications can be secured.
Because of the desire to be able to have a variety of STUN signaling
applications successfully interact with NATs and because of the
constraints described above, in SBS NAT is supported in the transport
layer rather than in a separate application. Addresses needing
translation are tagged and put in STUN attributes and passed to the
appropriate application at each SBS node. Application identification
is based on tag contents.
2.3. SBS Message Format
SBS messages consist of an SBS control block followed by optional
attribute fields followed by an optional application payload.
2.3.1. SBS Message Types
STUN-Based Signaling uses the following STUN message types:
0x0003: Signaling Message
0x0103: Reserved
0x0113: Signaling Error Response
2.3.2. The SBS Control Block
All SBS messages (and by implication, all SBS-based signaling
applications) MUST start with an SBS Control Block as the first
attribute following the STUN header. The Control Block is formatted
as follows:
Shore, et al. Expires June 8, 2006 [Page 7]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
0 1 2 3
+-------------+-------------+-------------+-------------+
| Version | (Reserved) | Flags |
+-------------+-------------+-------------+-------------+
| Flow ID |
+-------------+-------------+-------------+-------------+
Figure 1
where the fields are as follows:
Version: 8 bits. The protocol version number; in this case 0x01.
Flags: 16 bits. Flag bits include
0x01 HOP-BY-HOP
0x02 BUILD-ROUTE
0X04 TEARDOWN
0x08 AX_CHALLENGE
0x10 AX_RESPONSE
0x20 BIDIRECTIONAL
Flow ID: 32 bits. This is a value which, combined with the source
IP address of the message, provides unique identification of a
message, which may be used for later reference for actions such as
quick teardowns, status queries, etc. The mechanism used for
generating the value is implementation-specific.
Rather than including a separate Flow-ID, we rely on the Transaction
ID in the STUN message header.
2.3.3. NAT_ADDRESS
+-------------+-------------+-------------+-------------+
| Application ID | Flags | Proto |
+-------------+-------------+-------------+-------------+
| Address ID Tag |
+-------------+-------------+-------------+-------------+
| Original IPv4 Address |
+-------------+-------------+-------------+-------------+
| Mapped IPv4 Address |
+-------------+-------------+-------------+-------------+
| Original Port | Mapped Port |
+-------------+-------------+-------------+-------------+
Shore, et al. Expires June 8, 2006 [Page 8]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Figure 2
where the fields are as follows:
Application ID: 16 bits. This is the same as the value that's used
for identifying application payloads.
Flags: 8 bits. Flag bits include
0x01 = TRANSLATE
0x02 = NO_REWRITE
TRANSLATE indicates that a NAT device handling the packet should
create a NAT table entry for the original address. If the
TRANSLATE bit is not set, the NAT does nothing.
NO_REWRITE indicates that when the reply message is being returned
towards the sender, any NATs along the path MUST NOT overwrite the
Mapped Address.
Proto: IP protocol for this translation (TCP, UDP, SCTP, etc.).
Address ID: 32 bits. An value that's unique within the set of
Address IDs used with a particular Application ID; used to
uniquely identify a particular address (i.e. provide a tag).
Original IPv4 Address: The original address for which a translation
is being requested.
Mapped IPv4 Address: The address created by the NAT -- i.e. the
"external" address.
Original Port: The original port for which a translation is being
requested
Mapped Port: The port number created by the NAT for this mapping.
2.3.4. TIMEOUT
+-------------+-------------+-------------+-------------+
| Timeout Value |
+-------------+-------------+-------------+-------------+
The TIMEOUT attribute carries the number of milliseconds for which
state associated with a particular flow should be retained, with the
expectation that the state will be deleted when the timeout expires.
"State" in this case refers to routing state and to NAT state; STUN
Shore, et al. Expires June 8, 2006 [Page 9]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
application state will be managed by its application.
2.3.5. IPV4_HOP
+-------------+-------------+-------------+-------------+
| IPv4 Hop Address |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
The IPv4_HOP attribute carries the IPv4 address of the interface
through which the last SBS entity forwarded the message. The logical
interface handle may be used to distinguish between multiple
interfaces on the same entity, or it may be set to all 0s.
2.3.6. IPv6_HOP
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
The IPv6_HOP attribute carries the IPv6 address of the interface
through which the last SBS entity forwarded the message. The logical
interface handle may be used to distinguish between multiple
interfaces on the same entity, or it may be set to all 0s.
2.3.7. IPv4_ERROR_CODE
+-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 octets) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
The IPv4_ERROR_CODE attribute carries the address of a node at which
an SBS error occurred, along with an error code and error value.
When no Error Value is defined, the Error Value field MUST be set to
0 by its sender and ignored by its receiver.
Shore, et al. Expires June 8, 2006 [Page 10]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
If the high-order bit of the Error Code is not set, the attribute
carries an error message. If it is set, the attribute carries an
informational message. Therefore Error Codes with values between 0
and 127 contain error messages and Error Codes with values between
128 and 255 contain informational messages.
IPv4 Error Node Address: 4 octets. The IPv4 address of the interface
on the node that generated the error.
Flags: 8 bits. None currently defined.
Error Code: 8 bits. The type of error or informational message, with
values as follows:
Error Code = 0: No error
Error Code = 1: Bad parameters
Error Value = 1: HOP-BY-HOP and BUILD-ROUTE both present
Error Value = 2: BUILD-ROUTE present but no HOP attribute
Error Code = 3: HOP-BY-HOP present but no local stored
routing state
Error Code = 4: Message length not a multiple of 4
Error Code = 2: Unrecognized attribute
Error Value = attribute number
Error Code = 3: Unrecognized application
Error Value = Application ID
Error Code = 4: Non-SBS NAT detected in path
Shore, et al. Expires June 8, 2006 [Page 11]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Error Code = 128: No message
Error Code = 129: Sending node has detected a route change
2.3.8. IPv6_ERROR_CODE
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Error Node Address (16 octets) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
The IPv6_ERROR_CODE attribute carries the address of a node at which
an SBS error occurred, along with an error code and error value.
"IPv6 Error Node Address:" 16 octets. The IPv6 address of the
interface on the node that generated the error.
Flags: 8 bits. None currently defined.
The Error Code and Error value fields are the same as those used in
the IPv4_ERROR_CODE.
2.3.9. AGID
+-------------+-------------+-------------+-------------+
| id |
+-------------+-------------+-------------+-------------+
The AGID is the authentication group ID, used in the authentication
dialogue to identify the group key.
Shore, et al. Expires June 8, 2006 [Page 12]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
2.3.10. CHALLENGE
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Nonce +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
The CHALLENGE attribute is used to carry a 16-octet random nonce to
be used as an authentication challenge.
2.3.11. RESPONSE
+-------------+-------------+-------------+-------------+
| |
// HMAC //
| |
+-------------+-------------+-------------+-------------+
The RESPONSE attribute carries the response to the authentication
challenge. It is a variable length attribute with the length
dependent on the transform being used.
Shore, et al. Expires June 8, 2006 [Page 13]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
3. Sending SBS messages
STUN-based signaling messages are sent as STUN messages with the
message type 0x0003.
When an endhost or its proxy wishes to initiate an SBS session, it
creates a SBS message. If the message is being sent end-to-end the
destination address in the IP header is the address of the device
interface that is expected to terminate the path along which
signaling is expected to be sent. It may be a application peer host
or terminal, or it may be a proxy. If the message is being sent hop-
by-hop the destination address in the IP header is the address of the
device interface that is the next hop along the path. That address
will have been discovered either through a separate routing process
or through RSVP-style soft-state messaging.
If the message is end-to-end and needs route discovery and pinning,
the BUILD-ROUTE bit in the SBS Control Block flags header MUST be set
to 1 and the HOP-BY-HOP bit MUST be set to 0. If the message is
being routed hop-by-hop, the HOP-BY-HOP bit MUST be set to 1 and the
BUILT-ROUTE bit MUST be set to 0. (Note that there may be
applications in which both the HOP-BY-HOP and the BUILD-ROUTE bit
will be set to 0.)
If the SBS application wishes to support bidirectional reservations,
the BIDIRECTIONAL flag must be set to 1, the BUILD-ROUTE flag should
be set to 1, and the HOP-BY-HOP flag should be set to 0, at least in
the initial message. If the application makes use of periodic
refreshes it may optionally choose to route some number of them hop-
by-hop along the discovered path before sending out another message
to refresh the route state; that is an application design issue.
Shore, et al. Expires June 8, 2006 [Page 14]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
4. Messaging and State Maintenance
Message handling and state maintenance are determined by the presence
(or absence) of two flags in the SBS Control Block: the HOP-BY-HOP
bit and the BUILD-ROUTE bit. They also involve, and are involved by,
NAT processing.
4.1. BUILD-ROUTE
The BUILD-ROUTE bit in the flags field of the SBS Control Block
allows STUN signaling to function as a discovery and routing
protocol, much like the Path message described in RFC 2205.
If the BUILD-ROUTE flag is present, upon receipt an SBS node MUST
check for the presence of an IPv4_HOP or IPv6_HOP attribute in the
SBS payload. If one is not present, the message MUST be discarded
and an error returned to the sender. If both are present, the
message MUST be discarded and an error returned to the sender.
Otherwise, if there is no installed soft state associated with the
Flow ID, the node stores the HOP information, Flow ID, and other
state information it chooses to retain, and forwards the message
towards the address in the destination field of its IP header. If
there is installed soft state associated with the Flow ID, the node
compares the contents of the HOP field with the installed state. If
they are identical nothing needs to be done; if they are different
the HOP information in the node is overwritten with the information
in the current message. This allows the protocol to be responsive to
route changes, endpoint mobility, and so on.
An SBS node MAY send notification of a routing change back to the
sender.
4.2. HOP-BY-HOP
If the HOP-BY-HOP bit is set in the flags field of the SBS Control
Block, an SBS node MUST forward the message to the address stored in
associated local soft state. That is to say, the node MUST write the
address in the local HOP information associated with the Flow ID into
the destination field in the IP header on the outbound message. This
is like message processing in the Resv message in RFC 2205.
The HOP information may have been acquired using a routing process
based on HOP-BY-HOP processing, but it may have been acquired using
an external routing mechanism. If there is no HOP information stored
locally, the node MUST drop the message and return an error to the
sender.
Shore, et al. Expires June 8, 2006 [Page 15]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
4.3. BIDIRECTIONAL
If the BIDIRECTIONAL flag is set, the receiver must send the
answering message to the sender (that is to say, the destination
address in the IP header must be set to the address of the sender)
with the BUILD_ROUTE flag set and the HOP_BY_HOP flag set to 0. As
with the message sent from the sender to the receiver, the HOP
attribute contains information used to install routing state. If the
nodes are already authenticated to one another (they were already
traversed in the forward direction) it is unnecessary for the
authentication dialogue to be performed again. If the nodes are not
already authenticated to one another then the route is asymmetric and
the authentication dialogue must be performed.
Note that the sender and receiver should retain knowledge that the
session is bidirectional, as it may affect subsequent messaging and
error processing.
Because a complete authentication dialogue may take place in each
direction, with each node being authenticated to its adjacent node
(i.e. the dialogue takes care of authenticating both A to B and B to
A), this proposal neither changes the authentication dialogue nor
should it undermine the security of the protocol.
4.4. Path Teardown Messages
Receipt of an SBS message with the TEARDOWN bit set indicates that
matching path state must be deleted. Note that this is independent
of directionality, and the teardown message may be sent in either
direction. The applications which have reservations that were
installed by a message containing a matching Flow ID must be
notified, and they are responsible for managing (in this case,
deleting) their own flow-related state. TEARDOWN and HOP-BY-HOP MUST
not be set in the same message.
Unlike RFC 2205, if there is no matching path state the teardown
message must be forwarded. There may be path state in support of an
SBS application that is not running on every node, and the teardown
message must not be lost.
4.5. Network Address Translation
If there is one or more NAT_ADDRESS attribute present, an SBS-capable
NAT must process each one that does not have the NO_TRANSLATE bit set
in the flags field. Processing takes place as follows:
Shore, et al. Expires June 8, 2006 [Page 16]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
o The originator (sender) of the message creates a NAT_ADDRESS
attribute for each address/port/protocol tuple requiring NAT
mappings. It also creates a random 32-bit tag, which is used to
identify the address in application payloads and to tag the
mapping in the NAT_ADDRESS attribute in the SBS Control Block. It
also zeros the Mapped Address field.
o When an SBS-capable NAT receives a request, for each NAT_ADDRESS
attribute in which the NO_TRANSLATE bit is not set and the Mapped
Address is all nulls, it creates a NAT table mapping for the
Original Address and Original Port and inserts the "external"
address and port into the Mapped Address and Mapped Port fields.
o When an SBS-capable NAT receives a request, for each NAT_ADDRESS
attribute in which the NO_TRANSLATE bit is not set and the Mapped
Address is not nulls, it creates a NAT table mapping for the
Mapped Address and Mapped port and overwrites those values with
the new external addresses and ports.
o When an SBS-capable node receives a request, for reach NAT_ADDRESS
attribute in which the Application ID matches an SBS application
payload ID and the application is supported by the node, the
attribute is passed to the application with the application
payload, allowing the application module on the node to correlate
and use the address based on the tag.
Note that this approach to NAT requires that participants be
sensitive to directional issues in cases where ordering matters, such
as the need to find the outermost NAT address. API support is
required in order to turn the NO_TRANSLATE bit on and off as needed
by a particular application.
Also note that in cases where the only function required is NAT table
mapping requests, there may be no application payloads, or it may be
desirable to create a rudimentary NAT SBS application that does
nothing other than allow the receiver, or other nodes, to turn the
NO_TRANSLATE bit on.
Shore, et al. Expires June 8, 2006 [Page 17]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
5. Application interface
Application payloads are encapsulated within SBS attributes and MUST
follow any NAT attributes.
The Application Payload attribute includes the Application ID field,
which is used to vector the requests off to the correct application
on the router upon receipt. It is also used to identify NAT_ADDRESS
attributes to be passed to the application. In a nutshell, if the
Application ID in a NAT_ADDRESS attribute matches the Application ID
in an Application attribute, the NAT_ADDRESS attribute must be passed
to the application along with the application payload.
Note that there is no identifier in the attribute other than the
Application ID. If there is a need for an application-specific
identifer for reservations or other applications requiring retained
state, those must be added to the application payload.
Shore, et al. Expires June 8, 2006 [Page 18]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
6. NAT interactions
STUN-based signaling uses IP addresses for routing, both end-to-end
and hop-by-hop. Given the applications which SBS will be
transporting, it is highly likely that those applications will be
using payload-embedded addresses and there will be some interactions.
The use of a NAT application together with other applications can
mitigate this, but there will be problems transiting non-SBS-capable
NATs.
When an SBS entity receives a message travelling in the forward
direction, it writes the address in the IPv4_HOP or IPv6_HOP, as
appropriate, from the packet into local per-session state and
replaces the HOP data in the message with the address of the outgoing
interface. When the entity is a NAT, it will write the translated-to
address. Note that while it is usually the case that payload
integrity protection breaks in the presence of NATs if embedded
addresses are being rewritten, this is not substantially different
from the rewriting of the HOP field which occurs within SBS anyway.
However, if an SBS message crosses a non-SBS-capable NAT, several
problems may occur. The first is that if the message is being
dropped in a raw IP packet, the NAT may simply drop the packet
because it doesn't know how to treat it. Another is that the address
in the HOP field will be incorrect. SBS and the applications it
carries cannot be expected to function properly across non-
participating NATs. Discovery of a non-SBS-capable NAT is described
in Section 8.
Shore, et al. Expires June 8, 2006 [Page 19]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
7. Using SBS as a NAT traversal protocol
Using STUN-Based Signaling as a stand-alone NAT traversal protocol is
straightforward -- simply use it without application attributes, but
set the NO_REWRITE flag in the NAT_ADDRESS attribute to 1. This
provides two functions: 1) installation of new NAT table mappings,
and 2) allowing the sender to learn what the "external" mappings are.
The Control Block flags in the forward direction must be
HOP-BY-HOP = 0
BUILD-ROUTE = 1
TEARDOWN = 0
The Control Block flags in the reverse direction (i.e. in the
response message) must be
HOP-BY-HOP = 1
BUILD-ROUTE = 0
TEARDOWN = 0
The NAT table mappings are kept fresh through the retransmission of
the request every refresh period. The refresh messages are identical
to the original request message.
When the NAT table mappings are no longer required, the sender must
send a teardown message containing the Flow ID of the installed
mappings and with the Control Block flags set to
HOP-BY-HOP = 0
BUILD-ROUTE = 0
TEARDOWN = 1
An acknowledgement response message is not required. If there has
been no refresh message received prior to the expiration of the
timeout period, the NAT table mappings must be deleted when the
timeout period ends.
Shore, et al. Expires June 8, 2006 [Page 20]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
8. Discovery of non-SBS NATs, and recovery
This section describes a method of discovering non-SBS NATs in the
path, and a recovery mechanism if one is discovered.
When there are non-SBS-capable NATs in the path, they will only be
able to process or modify the IP/UDP header of the SBS message and
will not be able to understand or modify the SBS message itself
(including the NAT_ADDRESS attribute).
If there are non-SBS NATs in the path the sender needs to be made
aware of this, and it should be able to fall back to processing
without SBS, using any other mechanisms that may be available. Also,
the SBS-capable NATs in the path which have allocated the NAT
mappings based on NAT_ADDRESS attribute processing, need to be able
to release these mappings.
The following algorithm can be applied for non-SBS NAT detection by
SBS nodes:
if (NAT NAT_ADDRESS_ATTR mapped_addr == 0) {
This SBS NAT is first SBS NAT in path
if (SBS packet's source IP address != NAT_ADDRESS_ATTR's
original_address) {
This SBS NAT is not the first in the path, and
some non-SBS NAT has touched this packet;
send SBS error message back to the sender
with SBS error-code = 4 (non-SBS-nat in path)
} else {
This SBS NAT is the first in the path, and no non-
SBS NAT has touched this packet;
proceed with SBS processing.
}
} else {
This SBS NAT is not the first SBS NAT in path.
if (SBS packet's source IP address != NAT_ADDRESS_ATTR's
mapped_address) {
Some non-SBS NAT has touched this packet, send
SBS error message back to the sender with SBS
error-code = 4 (non-SBS-nat in path)
} else {
No non-SBS NAT has touched this packet; proceed
with regular SBS processing.
}
}
The SBS error message will be relayed back to the sender.
Shore, et al. Expires June 8, 2006 [Page 21]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Intermediate SBS nodes should not be processing the SBS error
message, but let this SBS packet be routed back to the sender.
Once the sender sees an SBS error-message with Error-Code = 4 (non-
SBS-nat in path), it should resend the same SBS message as earlier
with the NAT_ADDRESS attribute's Original IPv4 Address/Port/Protocol
as earlier and the Mapped IPv4 Address/Port as NULL, but should set
the TEARDOWN flag in the Control Block.
The intermediate SBS NATs in the path, upon seeing an SBS message
with the TEARDOWN bit set, should delete its local NAT mapping
corresponding to the Flow ID and send the message on towards the
receiver, traversing other SBS-capable NATs along the path which will
also process the TEARDOWN message.
Shore, et al. Expires June 8, 2006 [Page 22]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
9. Endhost processing
9.1. Sending
When a host or its proxy wishes to send an SBS request, it puts
together the application attribute and encapsulates it in a STUN
packet.
If the application needs to request NAT service because of its use of
addresses for reservations, etc., it must create a random 32-bit tag
for use as an address token in the application payload, and it must
create a NAT_ADDRESS attribute in which it inserts the address and
port for which it is requesting NAT service, as well as the 32-bit
tag.
For example, in a hypothetical QoS application that needed NAT
services for the address 209.4.89.110, TCP port 6603 in the flow
description, it would generate the random tag 0x24924924, use that in
the application payload instead of an address, and create a
NAT_ADDRESS attribute with the following values:
Application ID = QoS
Flags = TRANSLATE
Proto = TCP
Address ID = 0x24924924
Original IPv4 Address = 209.4.89.110
Original Port = 6603
The endpoint also needs to set the flags that determine how path
establishment and routing are to be handled on intermediate nodes.
In some cases the application requires no stored state in SBS nodes
or it simply requires a single SBS pass. Examples of this kind of
application include topology discovery, tunnel endpoint discovery, or
diagnostic triggers. In this case, in the SBS Control Block both the
HOP-BY-HOP flag and the BUILD-ROUTE flag are set to 0.
If an application is establishing per-node state and wants SBS to
establish and pin SBS routing for it, as might be the case with a QoS
application or a firewall pinholing application, the sending endpoint
must set the BUILD-ROUTE flag to 1 and the HOP-BY-HOP flag to 0.
The endhost then packages together the attributes and transmits it as
a STUN packet.
Shore, et al. Expires June 8, 2006 [Page 23]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
9.2. Receiving
An SBS node "knows" that it's an endpoint or proxy when the following
conditions are satisfied:
if (IP destination address == my address) {
if (HOP_BY_HOP)
if (next hop data available)
forward it on;
else
it's mine;
}
When an endpoint receives a packet and identifies it as terminating
there, it demultiplexes the payload and passes the payload and
associated NAT_ADDRESS data to the appropriate application.
If an application in the payload is not supported by the endpoint,
the endpoint must return a message to the sender with an ERROR_CODE
attribute with the error value set to 3 (Unrecognized application).
Shore, et al. Expires June 8, 2006 [Page 24]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
10. Intermediate Node Processing
The processing of SBS packets at intermediate nodes is substantially
the same as processing at endpoints. Upon the arrival of a request,
the node demultiplexes the packet contents and vectors the
application payloads off to their respective applications.
One major difference from endpoint processing is the handling of NAT
requests by NAT intermediate nodes. When an SBS-capable NAT receives
an SBS request, it checks for the presence of NAT_ADDRESS attributes.
For each NAT attribute, it executes the process described in
Section 4.5.
For state maintenance and forwarding, the node must follow the
processes described in section Section 4.1, Section 4.2, and
Section 4.4.
Shore, et al. Expires June 8, 2006 [Page 25]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
11. Using SBS to support bidirectional reservations
When an application that uses SBS to transport reservation requests
(for example, QoS reservations or firewall pinholes) and it wishes to
make the request for a bidirectional data stream, the reservations
should be made when the message is received in the "forward"
direction. Note that this is a significant departure from the model
used in RSVP. The reason for this should be apparent -- if the route
between the sender and receiver is asymmetric, it is possible that a
device traversed by a Path message may not be traversed by a Resv
message, and vice-versa.
It may be desirable to have different characteristics for the
reservation in one direction than for the other. In this case the
SBS application designer should make provision for identifying
reservation specifications to be used in each direction.
It should also not be assumed, as is done in RSVP, that error
messages will traverse all affected nodes unless care is taken by the
sender, or the "owner" of the reservation, to ensure that error
messages are propagated correctly. So, for example, if a reservation
fails at a particular node, it may not be sufficient to return the
error message towards the sender.
An application that manages reservations may wish to refresh
application state more frequently than it wishes to refresh route
state. In that case it should send the message with the
BIDIRECTIONAL and HOP_BY_HOP flags set, and the BUILD_ROUTE flag set
to 0.
Shore, et al. Expires June 8, 2006 [Page 26]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
12. Security Considerations
12.1. Overview
This section describes a method for providing cryptographic
authentication to the STUN-Based Signaling protocol. The method
incorporates a peer discovery mechanism. Importantly, there is no
provision for confidentiality. This fact simplifies the protocol,
and removes the need for export control on products implementing it.
SBS applications which require confidentiality may provide it
themselves.
This mechanism provides both entity and message authentication along
a single hop. In other words, the device on each end of the hop is
assured that the identity of the other device, and the content of the
message from that device, are correct. These security services are
provided only on a hop-by-hop basis. That is, there are no
cryptogrpahic services provided across multiple hops, and each hop
can independently use or not use authentication. In the following,
we restrict our discussion to a single hop along an SBS path.
In order to support authentication, we introduce an optional two-
message exchange into SBS called the Authentication Exchange, or AX.
This exchange is needed in order to carry the challenge-response
information.
12.2. Security Model
Authenticated SBS provides both authorization and entity
authentication using a group model. Authorizations correspond to
particular applications. An Authorization Group (AG) is a set of
network interfaces that share the following information:
o a list of SBS Application IDs; these correspond to applications
which the group is authorized to use,
o a group authentication key,
o a Message Authentication Code (MAC) algorithm type
Note that AGs are associated with interfaces and not devices since in
many situations there are different trust levels associated with
different interfaces.
For each device implementing Authenticated SBS, each interface is
associated with a list of Application IDs, each of which is
associated with:
Shore, et al. Expires June 8, 2006 [Page 27]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
o a list of AGIDs that authorize the corresponding application, or
o the symbol ALLOW, which indicates that the application has been
explictly allowed on the associated interface, or
o the symbol DROP, which indicates that the application has been
explicitly disallowed on the associated interface.
In this model, finer grained authorizations are impossible. For
example, it is impossible to authorize VoIP traversal of a Firewall
while still disallowing telnet across the firewall. The model can be
expanded to accomodate finer grained authorizations, but this issue
is not considered further in this draft. Sensitive applications,
such as firewall pinholing, must provide their own authentication and
authorization.
12.3. Cryptography
Authenticated SBS uses a single cryptographic function: a
pseudorandom function that accepts arbitrary-length inputs and
produces fixed-length outputs. This function is used as a message
authentication code (MAC). [Note: in the future, it might be used as
a key derivation function (KDF).]
The default function is HMAC SHA1. When used as a MAC, its length is
truncated to 96 bits.
12.3.1. Keys
Authenticated SBS uses group keys, in order to reduce the amount of
protocol state and to mitigate the peer-discovery problem.
Implementations MUST provide a way to set and delete keys manually.
However, they SHOULD also provide an automated group key management
system such as GDOI [rfc3547], so that efficient revocation is
possible.
12.4. Datatypes
An SBS message MSG has the following format:
MSG :== HDR OPT* APP SEC*
where HDR, OPT, APP, and SEC are as follows:
HDR is the SBS Control Block
Shore, et al. Expires June 8, 2006 [Page 28]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
OPT is an SBS-optional Attribute
APP is the Application Object
SEC is an AGID, A_CHALLENGE, A_RESPONSE, B_CHALLENGE, or
B_RESPONSE. These datatypes are defined below.
The security attribute are always last in order to avoid data-
formatting issues with the inputs to the message authentication
codes, and to minimize the amount of data movement needed during the
Authentication Exchange.
Authorization Group Identifier (AGID): The AGID attribute
identifies a particular group key. The Value field carries an
identifier; there is no defined format. The length of this field
is variable, and MUST be a multiple of four octets. If it is
generated at random, the it SHOULD be at least 16 octets.
A_CHALLENGE: The A_CHALLENGE contains a 16-octet random nonce.
This attribute is put into a message whenever outbound
authentication is desired. When this attribute is recieved, then
the next message sent MUST contain either an A_RESPONSE attribute
or an error message indicating that no authentication is possible.
The value MUST be generated either by using a strong random or
pseudorandom source, or by the method described in Section X.Y.
B_CHALLENGE: The B_CHALLENGE contains a 16-octet random nonce.
This attribute is put into a message whenever inbound
authentication is desired. When this attributeis recieved, then
the following message MUST contain either a B_RESPONSE attribute
or an error message indicating that no authentication is possible.
The value MUST be generated either by using a strong random or
pseudorandom source.
A_RESPONSE: The A_RESPONSE attribute is sent in response to a
message containing an A_CHALLENGE attribute. It contains a
message authentication code (MAC) value computed over the complete
SBS message containing the A_CHALLENGE, including the SBS Control
Block.
B_RESPONSE: The B_RESPONSE is sent in response to a message
containing a B_CHALLENGE attribute. It contains a message
authentication code (MAC) value computed over the complete SBS
message containing the IN_CHALLENGE, including the SBS Control
Block.
Shore, et al. Expires June 8, 2006 [Page 29]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
12.5. The Authentication Exchange (AX)
Two new SBS Control Block flags are defined:
0x0008 AX_CHALLENGE, which is set for all messages carrying an
A_CHALLENGE attribute.
0x0016 AX_RESPONSE, which is set for all messages carrying an
A_RESPONSE attribute.
In the following, we consider only the SEC attributes.
1. A -> B : AGID*, B_CHALLENGE
2. B -> A : AGID, A_CHALLENGE, B_RESPONSE
3. A -> B : AGID, A_RESPONSE
Message 1: Device A includes in the message each AGID that is
associated with the Application ID in the SBS message to be sent to
B. Device B checks its local policy to determine which AGIDs are
associated with the Application ID in the message, and determines
which AGIDs are associated with that value. Device B then checks to
see if the AGID set in the message intersects with the locally
derived AGID set. If they intersect, then one of the AGID values is
chosen to be 'active'; this choice is arbitrary. Otherwise, the AX
cannot be successfully completed, and an error message is returned.
A also constructs a B_CHALLENGE attribute and sends it to device B.
Message 2: Device B constructs Message 2 by replacing the AGID list
of Message 1 with the active AGID and an A_CHALLENGE attribute, as
well as a B_RESPONSE attribute, and sends it to device A. The rest of
the SBS message is unchanged from Message 1, except that the
AX_CHALLENGE flag is now set. Device A processes Message 1 by
Verifying that the AGID in the message is associated with the
Application ID in the SBS message. If it is not, then the AX
cannot be successfully completed, and an error message is
returned.
Computing its own value of B_RESPONSE, using as input the key
associated with the AGID in the message, and a reconstruction of
Message 3 created using the locally cached value of the
A_CHALLENGE attribute. If the locally constructed B_RESPONSE
matches that in Message 2, then the message is rejected, and an
error message is returned.
Shore, et al. Expires June 8, 2006 [Page 30]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Looking up the key associated with the AGID. If it cannot find an
associated key, then the AX cannot be successfully completed, and
an error message is returned.
If those steps succeed, then the A_RESPONSE attribute is computed,
using Message 2 and the key associated with the active AGID as its
input.
Message 3: Device A constructs Message 3 by replacing the A_CHALLENGE
attribute with the A_RESPONSE attribute computed in the preceeding
step and a randomly generated B_CHALLENGE attribute. The rest of the
SBS message is identical to that of Message 1, except that the
AX_RESPONSE flag is set. Device B processes Message 3 by
Verifying that the AGID in the message is associated with the
Application ID in the SBS message. If it is not, then the AX
cannot be successfully completed, and an error message is
returned.
Computing its own value of A_RESPONSE, using as input the key
associated with the active AGID, and a reconstruction of Message 2
created using the locally cached value of the A_CHALLENGE
attribute. If the locally constructed A_RESPONSE matches that in
Message 3, then the message is rejected, and an error message is
returned.
Shore, et al. Expires June 8, 2006 [Page 31]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
13. IANA Considerations
This document describes a protocol requiring the registration of
SBS Application IDs (SBS Application Identifiers)
SBS Attribute IDs (SBS Attribute Identifiers)
Initial values are given below. Future assignments are to be made
through expert review.
13.1. SBS Application Identifiers
NAME VALUE DEFINITION
Control Point Discovery 1 See ...
Firewall Traversal 2 See ...
13.2. SBS Attribute Identifiers
NAME VALUE DEFINITION
NAT_ADDRESS
APPLICATION_PAYLOAD
TIMEOUT
IPV4_HOP
IPV6_HOP
IPV4_ERROR_CODE
IPV6_ERROR_CODE
AGID
CHALLENGE
RESPONSE
14. References
[rfc1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[rfc2205] Braden, R., Zhang, L., Berson, S., and S. Herzog,
"Resource Reservation Protocol -- Version 1 Functional
Specification", RFC 2205, September 1997.
[rfc2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Shore, et al. Expires June 8, 2006 [Page 32]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Extensions", RFC 2961, April 2001.
[rfc3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[rosenberg]
Rosenberg, J., "Simple Traversal of UDP Through Network
Address Translators (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-02.txt (work in progress),
July 2005.
[ylonen] Ylonen, T., "SSH Protocol Architecture",
draft-ietf-secsh-architecture-15.txt (work in progress),
October 2003.
Shore, et al. Expires June 8, 2006 [Page 33]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Appendix A. Acknowledgements
The authors would like to express their gratitude to Senthil
Sivakumar, Jan Vilhuber, and Bill Foster for their careful review and
gentle feedback.
Shore, et al. Expires June 8, 2006 [Page 34]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Authors' Addresses
Melinda Shore
Cisco Systems
809 Hayts Road
Ithaca, New York 14850
USA
Email: mshore@cisco.com
Kaushik Biswas
Cisco Systems
510 McCarthy Blvd
Milpitas, California 95035
USA
Email: kbiswas@cisco.com
David A. McGrew
Cisco Systems
510 McCarthy Blvd
Milpitas, California 95035
USA
Email: mcgrew@cisco.com
Shore, et al. Expires June 8, 2006 [Page 35]
Internet-Draft A STUN-Based Signaling (SBS) Framework December 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shore, et al. Expires June 8, 2006 [Page 36]
