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]