Next steps in signaling H. Schulzrinne
Internet-Draft Columbia U.
Expires: December 22, 2003 June 23, 2003
GIMPS: General Internet Messaging Protocol for Signaling
draft-schulzrinne-nsis-ntlp-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 December 22, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Generic Internet Messaging Protocol for Signaling (GIMPS)
provides a generic transport messaging service to set up, modify and
tear down signaling state in signaling nodes.
Schulzrinne Expires December 22, 2003 [Page 1]
Internet-Draft GIMPS June 2003
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Operations . . . . . . . . . . . . . . . . . . . . 7
5. Transport Usage . . . . . . . . . . . . . . . . . . . . . . . 10
6. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 13
7.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 13
7.4 Denial of Service Prevention . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17
Schulzrinne Expires December 22, 2003 [Page 2]
Internet-Draft GIMPS June 2003
1. Requirements notation
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 [1].
Schulzrinne Expires December 22, 2003 [Page 3]
Internet-Draft GIMPS June 2003
2. Introduction
Alternate name: GIST: Generic Internet Signaling Transport
Application-neutral: GIMPS is designed to support the largest range
of signaling applications. While a number of such applications
have been identified, it appears likely that new applications will
emerge. (This was the case after the development of RSVP, for
example.)
Mobility support: End systems can change their network attachment
point and network address during a session.
Efficient: Signaling often occurs before an application such as an IP
telephone conversation can commence, so that any signaling delay
becomes noticeable to the application. Signaling delays are
incurred by the delay in finding signaling nodes along the path
(peer discovery), in retransmitting lost signaling messages and in
setting up security associations between nodes, among other
factors.
IP version neutral: GIMPS supports both IPv4 and IPv6.
Transport neutral: GIMPS can operate over any message or
stream-oriented transport layer, including UDP, DCCP, TCP and
SCTP. [TBD: support raw IP?] Messages sent over protocols that do
not offer a native fragmentation service, such as UDP, are
strictly limited in size and rate to avoid network congestion and
loss-amplification problems. [TBD: The 'transport' terminology
tends to confuse readers. Maybe we should rename the NTLP as a
messaging layer; this document uses the term messaging instead.]
Proxy support: The end systems in a session may not be capable of
handling either the signaling transport or the application and may
instead rely on proxies to initiate and terminate signaling
sessions.
Signaling involves the setting up, modifying and tearing down of
state in network elements. GIMPS maintains state along the data path
of a data session [ref]. Examples of such state include network
resource allotments (for "resource reservation"), a firewall
configuration and active network state. Each of these applications
is considered a signaling service that uses the transport service
defined in this document. Different applications may make use of
different services provided by GTSP.
Signaling establishes state sessions, which have a defined beginning
and end. While the beginning of a session is always established by
Schulzrinne Expires December 22, 2003 [Page 4]
Internet-Draft GIMPS June 2003
explicit protocol action, a session may end by a signaling teardown
message or a time-out ("soft state").
Not every router along the datapath needs to be involved in the
signaling session. Indeed, it appears likely that only a subset of
nodes will be aware of any given signaling application.
A related set of applications visits nodes along the data path, to
discover path properties, for example, but does not leave any state
behind. This can be considered a signaling application that
establishes and tears down state in the same message and thus is
within the scope of this effort.
GIMPS is not an end-to-end transport mechanism for a higher-layer
signaling. An example of the latter would be SCTP, used to transport
ISUP (SS7 signaling) messages between two nodes. In GIMPS, there are
almost always more than two participants in a signaling session, as
there is not much point in using a signaling protocol just to
communicate between two end points.
GIMPS is not meant to manage application-layer state, but rather to
manage state related to data transport. Thus, GIMPS messages need to
follow the path of the data. In that crucial respect, it differs from
application signaling protocols such as the control component of ftp,
SIP [4] and RTSP.
A more detailed discussion can be found in the Next Steps in
Signaling Framework [6].
Schulzrinne Expires December 22, 2003 [Page 5]
Internet-Draft GIMPS June 2003
3. Objectives
The signaling transport mechanism has to accomplish two fundamental
objectives:
1. Discover the set of nodes along the path from the data sender to
the receiver (peer discovery);
2. Deliver signaling information along this chain of nodes.
In many cases, signaling information needs to be delivered reliably
between the signaling initiator and responder. Some applications may
implement their own reliability mechanism, but experience with RSVP
has shown [3] that relying on soft-state refreshes itself may yield
unsatisfactory performance if signaling messages are lost even
occasionally.
Schulzrinne Expires December 22, 2003 [Page 6]
Internet-Draft GIMPS June 2003
4. Overview of Operations
GIMPS does not attempt to replicate a full-featured transport
protocol such as TCP or SCTP. It does not support congestion
control, message fragmentation, flow control, acknowledgment windows
and selective acknowledgements (SACK). Thus, its "raw" efficiency in
more demanding network conditions is likely to be low. Instead, GIMPS
leverages the continuing advances in transport protocols such as TCP
and SCTP for messages where these features are useful. For small
messages and discovery, it uses UDP [or raw IP.]
Each node maintains a forwarding state table that includes
session identifier: Cryptographically random and globally unique
session identifier;
destination address: The destination address of the message,
contained in the GIMPS message. (This is not necessarily the IP
address in the message.)
Generally, each session will have at least two entries, one for the
initiator-to-responder direction, the other for the
responder-to-initiator message flow. If the end points are mobile,
additional entries may be added. The forwarding state table entries
are discarded after the Rediscovery Period (RDP).
For efficiency, GIMPS offers two modes a operation, a "datagram" mode
for small, infrequent messages with modest delay constraint and a
"connection" mode for larger data objects or where fast setup in the
face of packet loss is desirable. The datagram mode can use any
lower-layer unreliable datagram transport mechanism, with UDP as the
initial choice. The connection mode can use any stream or
message-oriented transport protocol, including TCP and SCTP.
On receiving a GIMPS message, a node performs the operations
described below. (It does not matter whether the message arrived
over a reliable or unreliable lower-layer transport mechanism.)
Below, we call the GIMPS node that tries to determine the next-hop
peer the querying node.
1. The GIMPS node compares the GIMPS destination network address
(not the lower-layer network address) to its own address. If it
matches one of its addresses, the message has arrived and is
passed to the signaling application for further processing.
2. The GIMPS node inspects the session identifier in the incoming
message and determines if it matches an existing session. It
Schulzrinne Expires December 22, 2003 [Page 7]
Internet-Draft GIMPS June 2003
also compares the responder address to the responder contained in
the state record. If both match and the rediscovery period (RDP)
has not expired, the node forwards the message to the next node
on the existing transport and security association (e.g., TCP
connection, TLS session, or IPsec session).
If there is no known next-hop, the node checks the message size
and compares it against the maximum datagram size (MDS, below), a
global constant. (Since the message may be forwarded across
multiple hops, knowledge of the link MTU size is not sufficient.)
If the message size falls below MDS, the message is forwarded
towards the network address contained in the GIMPS message, i.e.,
the current responder and marked with an IP router-alert option
that causes it to be intercepted by the next GIMPS-capable node.
The GIMPS message uses the source address of this node, to
facilitate the discovery of network problems and to allow the
next node to return a confirmation message (see below).
If the message size exceeds MDS, the node constructs a discovery
message that has the same message type, session identifier and
client-layer identifier as the GIMPS message triggering it. It
then transmits it in the same manner described in the last
paragraph.
Messages that arrive during the discovery phase can be queued or
also sent forth as discovery messages. Messages that exceed MDS
in size MUST be queued. To avoid network congestion, a node MUST
NOT have more than one message outstanding at any given time. If
no response is received within the retransmission interval (RTI,
default 1 s), the message is retransmitted. (No instance
identifier is used since round-trip time estimation is unlikely
to be successful.)
The node records the transport association or network address of
the previous hop. This information is used for messages that are
sent by the responder to the initiator.
3. When the next node receives a GIMPS message with the
'response-requested' flag, it sends a response to the IP address
of that message, confirming receipt. The response uses the
source address of the next-hop node and is addressed to the
querying node. The response includes a cookie that is used to
prevent denial-of-service (state-exhaustion) attacks by nodes
spoofing the source address in the GIMPS message. The node only
establishes the GIMPS session if it contains a valid cookie.
4. When a node receives a message, regardless of the transport
protocol, the node records the transport association that the
Schulzrinne Expires December 22, 2003 [Page 8]
Internet-Draft GIMPS June 2003
message arrived on in the state table. This information is then
used to route messages in the opposite direction. For example,
if a discovery message arrived with a source address of A and a
destination address of B, the node records that any message with
destination address B can reach B via that association.
5. When a node receives a response to a pending discovery message,
it determines if there is an existing transport and/or security
association with that node. If not, it establishes such a
connection or association. (The response indicates the types of
security and transport mechanisms that are available, e.g.,
TLS-over-SCTP, UDP, etc.)
In either case, the GIMPS node sends any queued messages on that
new or existing association. If the message indicates the error
condition that no state was established, the node extracts the
cookie from the message and tries again, this time addressing the
message to the correct next-hop destination.
Schulzrinne Expires December 22, 2003 [Page 9]
Internet-Draft GIMPS June 2003
5. Transport Usage
As noted above, GIMPS can operate in a datagram mode, for peer
discovery and short-message delivery, and in connection mode, for
messages that exceed the size threshold MDS (typically, 500 bytes).
Nodes MUST support both modes, but applications can be structured so
that they only use one or the other mode. Connection mode requires
the datagram mode for data-path peer discovery; in the future, there
may be other peer-discovery mechanism that do not require sending
data. However, these are beyond the scope of this document.
It is possible to combine these two modes along a chain of nodes,
without coordinationor manual configuration. This allows, for
example, the use of datagram modes at the edges of the network and
connection-oriented operation in the core of the network. Such
combinations may make operation more efficient for mobile endpoints,
while allowing multiplexing of signaling messages across shared
security and transport associations between core routers.
Schulzrinne Expires December 22, 2003 [Page 10]
Internet-Draft GIMPS June 2003
6. Message Format
The following items are contained in each GIMPS message:
Initiator address: The current network (IPv4 or IPv6) address of the
initiator of the signaling session. The initiator may change
during a session, e.g., if the initiator moves to a different
network.
Responder address: The current network (IPv4 or IPv6) address of the
destination (responder) of the signaling session. The responder
may change during a session, e.g., if the initiator moves to a
different network.
Session identifier: The GIMPS session identifier is a long,
cryptographically random identifier chosen by the initiator. The
length is TBD, but 128 bits should be more than sufficient to make
the probability of collisions orders of magnitude lower than other
failure reasons.
Hop counter: A hop counter prevents a message from looping
indefinitely. (Since messages may get translated between different
lower-layer transport protocols, the IP hop count cannot be relied
upon.)
Service identifier: The service identifier [TBD: application
identifier?] describes the signaling application, such as resource
reservation or firewall control.
Message identifier: A four-octet message counter, used to associate
messages with their confirmations.
Cookies: Each message contains two X-octet cookies, generated for
each hop. The cookie in the next request with the same session
identifier and needs to be designed so that a node can determine
the validity of a cookie without keeping state.
Flags: A number of flags define protocol operations, such as
"confirmation requested" (hop-by-hop confirmation message).
Message type: The operation code defines three operations:
establish: Establish or refresh a session.
refresh: Refresh only if the session exists [TBD: is this useful?]
Schulzrinne Expires December 22, 2003 [Page 11]
Internet-Draft GIMPS June 2003
failure: A message-layer failure occurred, such as a mis-formatted
message or an authentication or integrity check failure.
teardown: Tear down.
confirmation: Confirms the receipt of an earlier message, with the
message number included.
The following items are optional:
Lifetime: The lifetime of a session in the absence of refreshes,
measured in seconds. Defaults to 30 seconds. Cannot be changed by
any intermediate node.
Confirm: Confirms receipt of a message. [May not be needed if
'confirmation' automatically means that the message number is
confirmed.]
The message content is encoded in an RSVP-style format, i.e.,
consisting of type-length-value (TLV) objects. If transported on a
bytestream-oriented protocol, the whole message is preceded by a
four-octet length field.
Schulzrinne Expires December 22, 2003 [Page 12]
Internet-Draft GIMPS June 2003
7. Security Considerations
7.1 Confidentiality
GIMPS can use lower-layer transport functionality, such as TLS or
IPsec, to ensure message confidentiality. In many cases,
confidentiality of messages is not likely to be a prime concern at
the messaging layer, in particular since messages are often sent to
parties which are unknown ahead of time. Signaling applications will
likely have their own mechanism for securing content as necessary.
7.2 Integrity
GIMPS can use lower-layer hop-by-hop transport functionality, such as
TLS or IPsec, to ensure message integrity. Message-layer
cryptographic integrity protection requires a shared secret or that
the receiver knows the public key of the sender. Some components of
the message, such as the hop count, will need to be modified by GIMPS
nodes, so that only hop-by-hop integrity is likely to be useful for
the messaging layer part. The use of CMS [5] encapsulation is
RECOMMENDED.
7.3 Authentication
GIMPS nodes can assure themselves of the identity of the next hop via
the the lower-layer transport functionality. However, with
discovery, there is no effective way to know what is the legitimate
next hop as opposed to an impostor.
7.4 Denial of Service Prevention
GIMPS is designed so that each connection-less discovery message only
generates at most one response, so that a GIMPS node cannot become
the source of a denial of service attack.
However, GIMPS can still be subjected to denial-of-service attacks
where an attacker using forged source addresses forces a note to
establish state without return routability, causing a problem similar
to TCP SYN flood attacks. There are two types of state attacks and
one computational resource attack. In the first state attack, an
attacker floods a node with messages that the node has to store until
it can determine the next hop. If the destination address is chosen
so that there is no next hop, the node would accumulate messages for
several seconds until the discovery retransmission attempt times out.
The second type of state-based attack causes GIMPS state to be
established by bogus messages. A related computational/
network-resource attack uses unverified messages to cause a node to
make AAA queries or attempt to cryptographically verify a digital
Schulzrinne Expires December 22, 2003 [Page 13]
Internet-Draft GIMPS June 2003
signature. (RSVP is vulnerable to this type of attack.)
There are at least three defenses against these attacks:
1. The receiving node does not establish a session or discover its
next hop on receiving the unreliable (discovery) message, but
rather waits for a setup message on a reliable channel. If the
reliable channel exists, the additional delay is one one-way
delay and is no more than the minimal theoretically possible
delay of a three-way handshake, i.e., 1.5 node-to-node round-trip
times. The delay gets significantly larger if a new connection
needs to be established first.
2. The response to the initial discovery message contains a cookie.
The previous hop repeats the discovery with the cookie included.
State is only established for messages that contain a valid
cookie. The setup delay is also 1.5 round-trip times. (This
mechanism is similar to that in SCTP [2].)
3. If there is a chance that the next-hop nodes shares a secret with
the previous hop, the sender could include a hash of the session
ID and the sender's secret. The receiver can then verify that the
message was likely sent by the purported source. This does not
scale well, but may work if most nodes tend to communicate with a
small peer clique of nodes. (In that case, however, they might as
well establish more-or-less permanent transport sessions with
each other.)
These techniques are complementary; we chose a combination of the
first and second method.
Schulzrinne Expires December 22, 2003 [Page 14]
Internet-Draft GIMPS June 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[3] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
2961, April 2001.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[6] Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-02 (work in progress), March 2003.
Author's Address
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7042
EMail: hgs+nsis@cs.columbia.edu
URI: http://www.cs.columbia.edu
Schulzrinne Expires December 22, 2003 [Page 15]
Internet-Draft GIMPS June 2003
Appendix A. Acknowledgements
This document is based on the discussions within the IETF NSIS
working group. The comments by ... helped improve the document.
Schulzrinne Expires December 22, 2003 [Page 16]
Internet-Draft GIMPS June 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; 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
proprietary rights by implementors 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 Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assignees.
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
Schulzrinne Expires December 22, 2003 [Page 17]
Internet-Draft GIMPS June 2003
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.
Schulzrinne Expires December 22, 2003 [Page 18]