Next Steps in Signaling H. Schulzrinne Internet-Draft Columbia U. Intended status: Standards Track R. Hancock Expires: January 10, 2008 Siemens/RMR July 9, 2007 GIST: General Internet Signalling Transport draft-ietf-nsis-ntlp-14 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 January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Schulzrinne & Hancock Expires January 10, 2008 [Page 1] Internet-Draft GIST July 2007 Abstract This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation and Terminology . . . . . . . . . . . . 6 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 9 3.2. Modes and Messaging Associations . . . . . . . . . . . . 10 3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 12 3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 14 3.5. GIST Peering Relationships . . . . . . . . . . . . . . . 15 3.6. Effect on Internet Transparency . . . . . . . . . . . . . 15 3.7. Signalling Sessions . . . . . . . . . . . . . . . . . . . 16 3.8. Signalling Applications and NSLPIDs . . . . . . . . . . . 17 3.9. GIST Security Services . . . . . . . . . . . . . . . . . 17 3.10. Example of Operation . . . . . . . . . . . . . . . . . . 18 4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 22 4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 22 4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 24 4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 26 4.4. Routing State and Messaging Association Maintenance . . . 34 5. Message Formats and Transport . . . . . . . . . . . . . . . . 47 5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 47 5.2. Information Elements . . . . . . . . . . . . . . . . . . 49 5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 53 5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 59 5.5. Message Type/Encapsulation Relationships . . . . . . . . 60 5.6. Error Message Processing . . . . . . . . . . . . . . . . 61 5.7. Messaging Association Setup . . . . . . . . . . . . . . . 62 5.8. Specific Message Routing Methods . . . . . . . . . . . . 66 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 72 6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 74 6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 75 Schulzrinne & Hancock Expires January 10, 2008 [Page 2] Internet-Draft GIST July 2007 6.3. Responder Node Processing . . . . . . . . . . . . . . . . 78 6.4. Messaging Association Processing . . . . . . . . . . . . 81 7. Additional Protocol Features . . . . . . . . . . . . . . . . 85 7.1. Route Changes and Local Repair . . . . . . . . . . . . . 85 7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 92 7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 98 7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 101 8.1. Message Confidentiality and Integrity . . . . . . . . . . 101 8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 102 8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 102 8.4. Denial of Service Prevention and Overload Protection . . 104 8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 106 8.6. Security Protocol Selection Policy . . . . . . . . . . . 108 8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 117 11.2. Informative References . . . . . . . . . . . . . . . . . 118 Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 121 A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 121 A.2. General Object Format . . . . . . . . . . . . . . . . . . 122 A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 123 A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 132 Appendix B. API between GIST and Signalling Applications . . . . 141 B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 141 B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 143 B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 144 B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 145 B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 146 B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 146 Appendix C. Deployment Issues with Router Alert Options . . . . 148 Appendix D. Example Routing State Table and Handshake . . . . . 151 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 156 Intellectual Property and Copyright Statements . . . . . . . . . 157 Schulzrinne & Hancock Expires January 10, 2008 [Page 3] Internet-Draft GIST July 2007 1. Introduction Signalling involves the manipulation of state held in network elements. 'Manipulation' could mean setting up, modifying and tearing down state; or it could simply mean the monitoring of state which is managed by other mechanisms. This specification concentrates mainly on path-coupled signalling, controlling resources on network elements which are located on the path taken by a particular data flow, possibly including but not limited to the flow endpoints. Indeed, there are almost always more than two participants in a path-coupled signalling session, although there is no need for every node on the path to participate. Path- coupled signalling thus excludes end-to-end higher-layer signalling. In the context of path-coupled signalling, examples of state management include network resource reservation, firewall configuration, and state used in active networking; examples of state monitoring are the discovery of instantaneous path properties, such as available bandwidth or cumulative queuing delay. Each of these different uses of signalling is referred to as a signalling application. GIST path-coupled signalling does not directly support multicast flows, but the current GIST design could be extended to do so, especially in environments where the multicast replication points can be made GIST-capable. GIST can also be extended to cover other types of signalling pattern, not related to any end-to-end flow in the network, in which case the distinction between GIST and end-to- end higher-layer signalling will be drawn differently or not at all. Every signalling application requires a set of state management rules, as well as protocol support to exchange messages along the data path. Several aspects of this protocol support are common to all or a large number of signalling applications, and hence can be developed as a common protocol. The NSIS framework given in [29] provides a rationale for a function split between the common and application specific protocols, and gives outline requirements for the former, the 'NSIS Transport Layer Protocol' (NTLP). The application specific protocols are referred to as 'NSIS Signalling Layer Protocols' (NSLPs), and are defined in separate documents. The NSIS framework [29], and the accompanying threats document [30], provide important background information to this specification, including information on how GIST is expected to be used in various network types and what role it is expected to perform. This specification provides a concrete solution for the NTLP. It is based on the use of existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST). GIST does not handle signalling application state itself; in that crucial respect, it differs from higher layer signalling Schulzrinne & Hancock Expires January 10, 2008 [Page 4] Internet-Draft GIST July 2007 protocols such as SIP, RTSP, and the control component of FTP. Instead, GIST manages its own internal state and the configuration of the underlying transport and security protocols to ensure the transfer of signalling messages on behalf of signalling applications in both directions along the flow path. The purpose of GIST is thus to provide the common functionality of node discovery, message routing and message transport in a way which is simple for multiple signalling applications to re-use. The structure of this specification is as follows. Section 2 defines terminology, and Section 3 gives an informal overview of the protocol design principles and operation. The normative specification is contained mainly in Section 4 to Section 8. Section 4 describes the message sequences and Section 5 their format and contents. Note that the detailed bit formats are given in Appendix A. The protocol operation is captured in the form of state machines in Section 6. Section 7 describes some more advanced protocol features and security considerations are contained in Section 8. In addition, Appendix B describes an abstract API for the service which GIST provides to signalling applications, and Appendix D provides an example message flow. Parts of the GIST design use packets with IP options to probe the network, which leads to some migration issues in the case of IPv4, and these are discussed in Appendix C. Because of the layered structure of the NSIS protocol suite, protocol extensions to cover a new signalling requirement could be carried out either within GIST, or within the signalling application layer, or both. General guidelines on how to extend different layers of the protocol suite, and in particular when and how it is appropriate to extend GIST, are contained in a separate document. In this document, Section 9 gives the formal IANA considerations for the registries defined by the GIST specification. Schulzrinne & Hancock Expires January 10, 2008 [Page 5] Internet-Draft GIST July 2007 2. Requirements Notation and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. In addition, the security specifications in Section 5.7.3 use the terminology MUST- and SHOULD+ from [5]. The terminology used in this specification is defined in this section. The basic entities relevant at the GIST level are shown in Figure 1. In particular, this diagram distinguishes the different address types as being associated with a flow (end-to-end addresses) or signalling (addresses of adjacent signalling peers). Source GIST (adjacent) peer nodes Destination IP address IP addresses = Signalling IP address = Flow Source/Destination Addresses = Flow Source (depending on signalling direction) Destination Address | | Address V V +--------+ +------+ Data Flow +------+ +--------+ | Flow |-----------|------|-------------|------|-------->| Flow | | Sender | | | | | |Receiver| +--------+ | GIST |============>| GIST | +--------+ | Node |<============| Node | +------+ Signalling +------+ GN1 Flow GN2 >>>>>>>>>>>>>>>>> = Downstream direction <<<<<<<<<<<<<<<<< = Upstream direction Figure 1: Basic Terminology [Data] Flow: A set of packets identified by some fixed combination of header fields. Flows are unidirectional; a bidirectional communication is considered a pair of unidirectional flows. Session: A single application layer exchange of information for which some state information is to be manipulated or monitored. See Section 3.7 for further detailed discussion. Session Identifier (SID): An identifier for a session; the syntax is a 128 bit value which is opaque to GIST. Schulzrinne & Hancock Expires January 10, 2008 [Page 6] Internet-Draft GIST July 2007 [Flow] Sender: The node in the network which is the source of the packets in a flow. A sender could be a host, or a router if for example the flow is actually an aggregate. [Flow] Receiver: The node in the network which is the sink for the packets in a flow. Downstream: In the same direction as the data flow. Upstream: In the opposite direction to the data flow. GIST Node: Any node supporting the GIST protocol, regardless of what signalling applications it supports. [Adjacent] Peer: The next node along the signalling path, in the upstream or downstream direction, with which a GIST node explicitly interacts. Querying Node: The GIST node that initiates the handshake process to discover the adjacent peer. Responding Node: The GIST node that responds to the handshake, becoming the adjacent peer to the Querying node. Datagram Mode (D-mode): A mode of sending GIST messages between nodes without using any transport layer state or security protection. Datagram mode uses UDP encapsulation, with source and destination IP addresses derived either from the flow definition or previously discovered adjacency information. Connection Mode (C-mode): A mode of sending GIST messages directly between nodes using point-to-point messaging associations (see below). Connection mode allows the re-use of existing transport and security protocols where such functionality is required. Messaging Association (MA): A single connection between two explicitly identified GIST adjacent peers, i.e. between a given signalling source and destination address. A messaging association may use a transport protocol; if security protection is required, it may use a network layer security association, or use a transport layer security association internally. A messaging association is bidirectional: signalling messages can be sent over it in either direction, referring to flows of either direction. Schulzrinne & Hancock Expires January 10, 2008 [Page 7] Internet-Draft GIST July 2007 [Message] Routing: Message routing describes the process of determining which is the next GIST peer along the signalling path. For signalling along a flow path, the message routing carried out by GIST is built on top of normal IP routing, that is, forwarding packets within the network layer based on their destination IP address. In this document, the term 'routing' generally refers to GIST message routing unless particularly specified. Message Routing Method (MRM): There can be different algorithms for discovering the route that signalling messages should take. These are referred to as message routing methods, and GIST supports alternatives within a common protocol framework. See Section 3.3. Message Routing Information (MRI): The set of data item values which is used to route a signalling message according to a particular MRM; for example, for routing along a flow path, the MRI includes flow source and destination addresses, protocol and port numbers. See Section 3.3. Router Alert Option (RAO): An option that can be included in IP v4 and v6 headers to assist in the packet interception process; see [3] and [8]. Transfer Attributes: A description of the requirements which a signalling application has for the delivery of a particular message; for example, whether the message should be delivered reliably. See Section 4.1.2. Schulzrinne & Hancock Expires January 10, 2008 [Page 8] Internet-Draft GIST July 2007 3. Design Overview 3.1. Overall Design Approach The generic requirements identified in the NSIS framework [29] for transport of signalling messages are essentially two-fold: Routing: Determine how to reach the adjacent signalling node along each direction of the data path (the GIST peer), and if necessary explicitly establish addressing and identity information about that peer; Transport: Deliver the signalling information to that peer. To meet the routing requirement, one possibility is for the node to use local routing state information to determine the identity of the GIST peer explicitly. GIST defines a three-way handshake which probes the network to set up the necessary routing state between adjacent peers, during which signalling applications can also exchange data. Once the routing decision has been made, the node has to select a mechanism for transport of the message to the peer. GIST divides the transport functionality into two parts, a minimal capability provided by GIST itself, with the use of well-understood transport protocols for the harder cases. Here, with details discussed later, the minimal capability is restricted to messages that are sized well below the lowest maximum transmission unit (MTU) along a path, are infrequent enough not to cause concerns about congestion and flow control, and do not need security protection or guaranteed delivery. In [29] all of these routing and transport requirements are assigned to a single notional protocol, the NSIS Transport Layer Protocol (NTLP). The strategy of splitting the transport problem leads to a layered structure for the NTLP, with a specialised GIST messaging layer running over standard transport and security protocols. The basic concept is shown in Figure 2. Note that not every combination of transport and security protocols implied by the figure is actually possible for use in GIST; the actual combinations allowed by this specification are defined in Section 5.7. The figure also shows GIST offering its services to upper layers at an abstract interface, the GIST API, further discussed in Section 4.1. Schulzrinne & Hancock Expires January 10, 2008 [Page 9] Internet-Draft GIST July 2007 ^^ +-------------+ || | Signalling | NSIS +------------|Application 2| Signalling | Signalling +-------------+ Application |Application 1| | Level +-------------+ | || | | VV | | ========|===================|===== <-- GIST API | | ^^ +------------------------------------------------+ || |+-----------------------+ +--------------+ | || || GIST | | GIST State | | || || Encapsulation |<<<>>>| Maintenance | | || |+-----------------------+ +--------------+ | || | GIST: Messaging Layer | || +------------------------------------------------+ NSIS | | | | Transport .......................................... Level . Transport Layer Security (TLS or DTLS) . (NTLP) .......................................... || | | | | || +----+ +----+ +----+ +----+ || |UDP | |TCP | |SCTP| |DCCP| ... other || +----+ +----+ +----+ +----+ protocols || | | | | || ............................. || . IP Layer Security . || ............................. VV | | | | ===========================|=======|=======|=======|============ | | | | +----------------------------------------------+ | IP | +----------------------------------------------+ Figure 2: Protocol Stack Architecture for Signalling Transport 3.2. Modes and Messaging Associations Internally, GIST has two modes of operation: Connection mode (C-mode): used for larger messages or where fast signalling application state setup in the face of packet loss is desirable, or where channel security is required. Schulzrinne & Hancock Expires January 10, 2008 [Page 10] Internet-Draft GIST July 2007 Datagram mode (D-mode): used for small, infrequent messages with modest delay constraints and no security requirements. A special case of D-mode called Query-mode (Q-mode) is used when no routing state exists. C-mode can in principle use any stream or message-oriented transport protocol; this specification defines TCP as the initial choice. It can in principle employ specific network layer security associations, or an internal transport layer security association; this specification defines TLS as the initial choice. When GIST messages are carried in C-mode, they are treated just like any other traffic by intermediate routers between the GIST peers. Indeed, it would be impossible for intermediate routers to carry out any processing on the messages without terminating the transport and security protocols used. D-mode uses UDP, as a suitable NAT-friendly encapsulation which does not require per-message shared state to be maintained between the peers. Long-term evolution of GIST is assumed to preserve the simplicity of the current D-mode design. Any extension to the security or transport capabilities of D-mode can be viewed as the selection of a different protocol stack under the GIST messaging layer; this is then equivalent to defining another option within the overall C-mode framework. This includes both the case of using existing protocols, and specific development of a message exchange and payload encapsulation to support GIST requirements. Alternatively, if any necessary parameters (e.g. a shared secret for use in integrity or confidentiality protection) can be negotiated out-of-band, then the additional functions can be added directly to D-mode by adding an optional object to the message (see Appendix A.2.1). Note that in such an approach, downgrade attacks as discussed in Section 8.6 would need to be prevented by policy at the destination node. It is possible to mix these two modes along a path. This allows, for example, the use of D-mode at the edges of the network and C-mode in the core of the network. Such combinations may make operation more efficient for mobile endpoints, while allowing shared security associations and transport connections between core routers to be used for messages for multiple flows and signalling applications. The setup for these protocols imposes an initialisation cost for the use of C-mode, but in the long term this cost can be shared over all signalling sessions between peers; once the transport layer state exists, retransmission algorithms can operate much more aggressively than would be possible in a pure D-mode design. It must be understood that the routing and transport functions within by GIST are not independent. If the message transfer has Schulzrinne & Hancock Expires January 10, 2008 [Page 11] Internet-Draft GIST July 2007 requirements that require C-mode, for example if the message is so large that fragmentation is required, this can only be used between explicitly identified nodes. In such cases, GIST carries out the three-way handshake initially in D-mode to identify the peer and then sets up the necessary connections if they do not already exist. It must also be understood that the signalling application does not make the D-mode/C-mode selection directly; rather, this decision is made by GIST on the basis of the message characteristics and the transfer attributes stated by the application. The distinction is not visible at the GIST service interface. In general, the state associated with C-mode messaging to a particular peer (signalling destination address, protocol and port numbers, internal protocol configuration and state information) is referred to as a messaging association (MA). MAs are totally internal to GIST (they are not visible to signalling applications). Although GIST may be using an MA to deliver messages about a particular flow, there is no direct correspondence between them: the GIST message routing algorithms consider each message in turn and select an appropriate MA to transport it. There may be any number of MAs between two GIST peers although the usual case is zero or one, and they are set up and torn down by management actions within GIST itself. 3.3. Message Routing Methods The baseline message routing functionality in GIST is that signalling messages follow a route defined by an existing flow in the network, visiting a subset of the nodes through which it passes. This is the appropriate behaviour for application scenarios where the purpose of the signalling is to manipulate resources for that flow. However, there are scenarios for which other behaviours are applicable. Two examples are: Predictive Routing: Here, the intent is to signal along a path that the data flow may follow in the future. Possible cases are pre- installation of state on the backup path that would be used in the event of a link failure, and predictive installation of state on the path that will be used after a mobile node handover. NAT Address Reservations: This applies to the case where a node behind a NAT wishes to reserve an address at which it can be reached by a sender on the other side. This requires a message to be sent outbound from what will be the flow receiver although no reverse routing state for the flow yet exists. Most of the details of GIST operation are independent of the routing behaviour being used. Therefore, the GIST design encapsulates the Schulzrinne & Hancock Expires January 10, 2008 [Page 12] Internet-Draft GIST July 2007 routing-dependent details as a message routing method (MRM), and allows multiple MRMs to be defined. This specification defines the path-coupled MRM, corresponding to the baseline functionality described above, and a second ("Loose End") MRM for the NAT Address Reservation case. The detailed specifications are given in Section 5.8. The content of an MRM definition is as follows, using the path- coupled MRM as an example: o The format of the information that describes the path that the signalling should take, the Message Routing Information (MRI). For the path-coupled MRM, this is just the Flow Identifier (see Section 5.8.1.1) and some additional control information. Specifically, the MRI always includes a flag to distinguish between the two directions that signalling messages can take, denoted 'upstream' and 'downstream'. o A specification of the IP-level encapsulation of the messages which probe the network to discover the adjacent peers. A downstream encapsulation must be defined; an upstream encapsulation is optional. For the path-coupled MRM, this information is given in Section 5.8.1.2 and Section 5.8.1.3. Current MRMs rely on the interception of probe messages in the data plane, but other mechanisms are also possible within the overall GIST design and would be appropriate for other types of signalling pattern. o A specification of what validation checks GIST should apply to the probe messages, for example to protect against IP address spoofing attacks. The checks may be dependent on the direction (upstream or downstream) of the message. For the path-coupled MRM, the downstream validity check is basically a form of ingress filtering, also discussed in Section 5.8.1.2. o The mechanism(s) available for route change detection, i.e. any change in the neighbour relationships that the MRM discovers. The default case for any MRM is soft-state refresh, but additional supporting techniques may be possible; see Section 7.1.2. In addition, it should be noted that NAT traversal may require translation of fields in the MRI object carried in GIST messages (see Section 7.2.2). The generic MRI format includes a flag that must be given as part of the MRM definition, to indicate if some kind of translation is necessary. Development of a new MRM therefore includes updates to the GIST specification, and may include updates to specifications of NAT behaviour. These updates may be done in separate documents as is the case for NAT traversal for the MRMs of Schulzrinne & Hancock Expires January 10, 2008 [Page 13] Internet-Draft GIST July 2007 the base GIST specification, as described in Section 7.2.3 and [41]. The MRI is passed explicitly between signalling applications and GIST; therefore, signalling application specifications must define which MRMs they require. Signalling applications may use fields in the MRI in their packet classifiers; if they use additional information for packet classification, this would be carried at the NSLP level and so would be invisible to GIST. Any node hosting a particular signalling application needs to use a GIST implementation that supports the corresponding MRMs. The GIST processing rules allow nodes not hosting the signalling application to ignore messages for it at the GIST level, so it does not matter if these nodes support the MRM or not. 3.4. GIST Messages GIST has six message types: Query, Response, Confirm, Data, Error, and MA-Hello. Apart from the invocation of the messaging association protocols used by C-mode, all GIST communication consists of these messages. In addition, all signalling application data is carried as additional payloads in these messages, alongside the GIST information. The Query, Response and Confirm messages implement the handshake that GIST uses to set up routing state and messaging associations. The handshake is initiated from the Querying node towards the Responding node. The first message is the Query, which is encapsulated in a special way depending on the message routing method, in order to probe the network infrastructure so that the correct peer will intercept it and become the Responding node. A Query always triggers a Response in the reverse direction as the second message of the handshake. The content of the Response controls whether a Confirm message is sent: as part of the defence against denial of service attacks, the Responding node can delay state installation until a return routability check has been performed, and require the Querying node to complete the handshake with the Confirm message. In addition, if the handshake is being used to set up a new MA, the Response is required to request a Confirm. All of these three messages can optionally carry signalling application data. The handshake is fully described in Section 4.4.1. The Data message is used purely to encapsulate and deliver signalling application data. Usually it is sent using pre-established routing state. However, if there are no security or transport requirements and no need for persistent reverse routing state, it can also be sent in the same way as the Query. Finally, Error messages are used to indicate error conditions at the GIST level, and the MA-Hello message can be used as a diagnostic and keepalive for the messaging Schulzrinne & Hancock Expires January 10, 2008 [Page 14] Internet-Draft GIST July 2007 association protocols. 3.5. GIST Peering Relationships Peering is the process whereby two GIST nodes create message routing states which point to each other. A peering relationship can only be created by a GIST handshake. Nodes become peers when one issues a Query and gets a Response from another. Issuing the initial Query is a result of an NSLP request on that node, and the Query itself is formatted according to the rules of the message routing method. For current MRMs, the identity of the Responding node is not known explicitly at the time the Query is sent; instead, the message is examined by nodes along the path until one decides to send a Response, thereby becoming the peer. If the node hosts the NSLP, local GIST and signalling application policy determine whether to peer; the details are given in Section 4.3.2. Nodes not hosting the NSLP forward the Query transparently (Section 4.3.4). An existing peering relationship can only be changed by a new GIST handshake; in other words, it can only change when routing state is refreshed. On a refresh, if any of the factors in the original peering process have changed, the peering relationship can also change. As well as network level rerouting, changes could include modifications to NSIS signalling functions deployed at a node, or alterations to signalling application policy. A change could cause an existing node to drop out of the signalling path, or a new node to become part of it. All these possibilities are handled as rerouting events by GIST; further details of the process are described in Section 7.1. 3.6. Effect on Internet Transparency GIST relies on routers inside the network to intercept and process packets which would normally be transmitted end-to-end. This processing may be non-transparent: messages may be forwarded with modifications, or not forwarded at all. This interception applies only to the encapsulation used for the Query messages which probe the network, for example along a flow path; all other GIST messages are handled only by the nodes to which they are directly addressed, i.e. as normal Internet traffic. Because this interception potentially breaks Internet transparency for packets which have nothing to do with GIST, the encapsulation used by GIST in this case (called Query-mode or Q-mode) has several features to avoid accidental collisions with other traffic: Schulzrinne & Hancock Expires January 10, 2008 [Page 15] Internet-Draft GIST July 2007 o Q-mode messages are always sent as UDP traffic, and to a specific well-known port allocated by IANA. o All GIST messages sent as UDP have a magic number as the first 32- bit word of the datagram payload. Even if a node intercepts a packet as potentially a GIST message, unless it passes both these checks it will be ignored at the GIST level and forwarded transparently. Further discussion of the reception process is in Section 4.3.1 and the encapsulation in Section 5.3. 3.7. Signalling Sessions GIST requires signalling applications to associate each of their messages with a signalling session. Informally, given an application layer exchange of information for which some network control state information is to be manipulated or monitored, the corresponding signalling messages should be associated with the same session. Signalling applications provide the session identifier (SID) whenever they wish to send a message, and GIST reports the SID when a message is received; on messages forwarded at the GIST level, the SID is preserved unchanged. Usually, NSLPs will preserve the SID value along the entire signalling path, but this is not enforced by or even visible to GIST, which only sees the scope of the SID as the single hop between adjacent NSLP peers. Most GIST processing and state information is related to the flow (defined by the MRI, see above) and signalling application (given by the NSLP identifier, see below). There are several possible relationships between flows and sessions, for example: o The simplest case is that all signalling messages for the same flow have the same SID. o Messages for more than one flow may use the same SID, for example because one flow is replacing another in a mobility or multihoming scenario. o A single flow may have messages for different SIDs, for example from independently operating signalling applications. Because of this range of options, GIST does not perform any validation on how signalling applications map between flows and sessions, nor does it perform any direct validation on the properties of the SID itself, such as any enforcement of uniqueness. GIST only defines the syntax of the SID as an opaque 128-bit identifier. Schulzrinne & Hancock Expires January 10, 2008 [Page 16] Internet-Draft GIST July 2007 The SID assignment has the following impact on GIST processing: o Messages with the same SID that are to be delivered reliably between the same GIST peers are delivered in order. o All other messages are handled independently. o GIST identifies routing state (upstream and downstream peer) by the triplet (MRI, NSLP, SID). Strictly speaking, the routing state should not depend on the SID. However, if the routing state is keyed only by (MRI, NSLP), there is a trivial denial of service attack (see Section 8.3) where a malicious off-path node asserts that it is the peer for a particular flow. Such an attack would not redirect the traffic but would reroute the signalling. Instead, the routing state is also segregated between different SIDs, which means that the attacking node can only disrupt a signalling session if it can guess the corresponding SID. Normative rules on the selection of SIDs are given in Section 4.1.3. 3.8. Signalling Applications and NSLPIDs The functionality for signalling applications is supported by NSIS signalling layer protocols (NSLPs). Each NSLP is identified by a 16 bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single signalling application, such as resource reservation, may define a family of NSLPs to implement its functionality, for example to carry out signalling operations at different levels in a hierarchy (cf. [22]). However, the interactions between the different NSLPs (for example, to relate aggregation levels or aggregation region boundaries in the resource management case) are handled at the signalling application level; the NSLPID is the only information visible to GIST about the signalling application being used. 3.9. GIST Security Services GIST has two distinct security goals: o to protect GIST state from corruption, and to protect the nodes on which it runs from resource exhaustion attacks; and o to provide secure transport for NSLP messages to the signalling applications. The protocol mechanisms to achieve the first goal are mainly internal to GIST. They include a cookie exchange and return routability check to protect the handshake which sets up routing state, and a random Schulzrinne & Hancock Expires January 10, 2008 [Page 17] Internet-Draft GIST July 2007 SID is also used to prevent off-path session hijacking by SID guessing. Further details are given in Section 4.1.3 and Section 4.4.1, and the overall security aspects are discussed in Section 8. A second level of protection is provided by the use of a channel security protocol in messaging associations (i.e. within C-mode). This mechanism serves two purposes: to protect against on-path attacks on GIST, and to provide a secure channel for NSLP messages. For the mechanism to be effective, it must be able to provide the following functions: o mutual authentication of the GIST peer nodes; o ability to verify the authenticated identity against a database of nodes authorised to take part in GIST signalling; o confidentiality and integrity protection for NSLP data, and provision of the authenticated identities used to the signalling application. The authorised peer database is described in more detail in Section 4.4.2, including the types of entries that it can contain and the authorisation checking algorithm that is used. The only channel security protocol defined by this specification is a basic use of TLS, and Section 5.7.3 defines the TLS-specific aspects of how these functions (for example, authentication and identity comparison) are integrated with the rest of GIST operation. At a high level, there are several alternative protocols with similar functionality, and the handshake (Section 4.4.1) provides a mechanism within GIST to select between them. However, they differ in their identity schemes and authentication methods and dependencies on infrastructure support for the authentication process, and any GIST extension to incorporate them would need to define the details of the corresponding interactions with GIST operation. 3.10. Example of Operation This section presents an example of GIST usage in a relatively simple (in particular, NAT-free) signalling scenario, to illustrate its main features. Schulzrinne & Hancock Expires January 10, 2008 [Page 18] Internet-Draft GIST July 2007 GN1 GN2 +------------+ +------------+ NSLP | | | | Level | >>>>>>>>>1 | | 5>>>>>>>>5 | | ^ V | Intermediate | ^ V | |-^--------2-| Routers |-^--------V-| | ^ V | | ^ V | | ^ V | +-----+ +-----+ | ^ V | >>>>>>>>>>^ >3>>>>>>>>4>>>>>>>>>>>4>>>>>>>>>5 5>>>>>>>>> | | | | | | | | GIST | 6<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<6 | Level +------------+ +-----+ +-----+ +------------+ >>>>>, <<<<< = Signalling messages 1 - 6 = Stages in the example (stages 7 and 8 are not shown) Figure 3: Example of Operation Consider the case of an RSVP-like signalling application which makes receiver-based resource reservations for a single unicast flow. In general, signalling can take place along the entire end-to-end path (between flow source and destination), but the role of GIST is only to transfer signalling messages over a single segment of the path, between neighbouring resource-capable nodes. Basic GIST operation is the same, whether it involves the endpoints or only interior nodes: in either case, GIST is triggered by a request from a local signalling application. The example here describes how GIST transfers messages between two adjacent peers some distance along the path, GN1 and GN2 (see Figure 3). We take up the story at the point where a message is being processed above the GIST layer by the signalling application in GN1. 1. The signalling application in GN1 determines that this message is a simple description of resources that would be appropriate for the flow. It determines that it has no special security or transport requirements for the message, but simply that it should be transferred to the next downstream signalling application peer on the path that the flow will take. 2. The message payload is passed to the GIST layer in GN1, along with a definition of the flow and description of the message transfer attributes (in this case, requesting no reliable transmission or channel security protection). GIST determines that this particular message does not require fragmentation and that it has no knowledge of the next peer for this flow and signalling application; however, it also determines that this application is likely to require secured upstream and downstream Schulzrinne & Hancock Expires January 10, 2008 [Page 19] Internet-Draft GIST July 2007 transport of large messages in the future. This determination is a function of node-internal policy interactions between GIST and the signalling application. 3. GN1 therefore constructs a GIST Query carrying the NSLP payload, and additional payloads at the GIST level which will be used to initiate a messaging association. The Query is encapsulated in a UDP datagram and injected into the network. At the IP level, the destination address is the flow receiver, and an IP Router Alert Option (RAO) is also included. 4. The Query passes through the network towards the flow receiver, and is seen by each router in turn. GIST-unaware routers will not recognise the RAO value and will forward the message unchanged; GIST-aware routers which do not support the NSLP in question will also forward the message basically unchanged, although they may need to process more of the message to decide this. 5. The message is intercepted at GN2. The GIST layer identifies the message as relevant to a local signalling application, and passes the NSLP payload and flow description upwards to it. This signalling application in GN2 indicates to GIST that it will peer with GN1 and so GIST should proceed to set up any routing state. In addition, the signalling application continues to process the message as in GN1 (compare step 1), passing the message back down to GIST so that it is sent further downstream, and this will eventually result in the message reaching the flow receiver. GIST itself operates hop-by-hop, and the signalling application joins these hops together to manage the end-to-end signalling operations. 6. In parallel, the GIST instance in GN2 now knows that it should maintain routing state and a messaging association for future signalling with GN1. This is recognised because the message is a Query, and because the local signalling application has indicated that it will peer with GN1. There are two possible cases for sending back the necessary GIST Response: 6.A - Association Exists: GN1 and GN2 already have an appropriate MA. GN2 simply records the identity of GN1 as its upstream peer for that flow and NSLP, and sends a Response back to GN1 over the MA identifying itself as the peer for this flow. Schulzrinne & Hancock Expires January 10, 2008 [Page 20] Internet-Draft GIST July 2007 6.B - No Association: GN2 sends the Response in D-mode directly to GN1, identifying itself and agreeing to the messaging association setup. The protocol exchanges needed to complete this will proceed in parallel with the following stages. In each case, the result is that GN1 and GN2 are now in a peering relationship for the flow. 7. Eventually, another NSLP message works its way upstream from the receiver to GN2. This message contains a description of the actual resources requested, along with authorisation and other security information. The signalling application in GN2 passes this payload to the GIST level, along with the flow definition and transfer attributes; in this case, it could request reliable transmission and use of a secure channel for integrity protection. (Other combinations of attributes are possible). 8. The GIST layer in GN2 identifies the upstream peer for this flow and NSLP as GN1, and determines that it has an MA with the appropriate properties. The message is queued on the MA for transmission; this may incur some delay if the procedures begun in step 6.B have not yet completed. Further messages can be passed in each direction in the same way. The GIST layer in each node can in parallel carry out maintenance operations such as route change detection (see Section 7.1). It should be understood that several of these details of GIST operations can be varied, either by local policy or according to signalling application requirements. The authoritative details are contained in the remainder of this document. Schulzrinne & Hancock Expires January 10, 2008 [Page 21] Internet-Draft GIST July 2007 4. GIST Processing Overview This section defines the basic structure and operation of GIST. Section 4.1 describes the way in which GIST interacts with local signalling applications in the form of an abstract service interface. Section 4.2 describes the per-flow and per-peer state that GIST maintains for the purpose of transferring messages. Section 4.3 describes how messages are processed in the case where any necessary messaging associations and routing state already exist; this includes the simple scenario of pure D-mode operation, where no messaging associations are necessary. Finally, Section 4.4 describes how routing state and messaging associations are created and managed. 4.1. GIST Service Interface This section describes the interaction between GIST and signalling applications in terms of an abstract service interface, including a definition of the attributes of the message transfer that GIST can offer. The service interface presented here is non-normative and does not constrain actual implementations of any interface between GIST and signalling applications; the interface is provided to aid understanding of how GIST can be used. However, requirements on SID selection and internal GIST behaviour to support message transfer semantics (such as in-order delivery) are stated normatively here. The same service interface is presented at every GIST node; however, applications may invoke it differently at different nodes, depending for example on local policy. In addition, the service interface is defined independently of any specific transport protocol, or even the distinction between D-mode and C-mode. The initial version of this specification defines how to support the service interface using a C-mode based on TCP; if additional protocol support is added, this will support the same interface and so the change will be invisible to applications, except as a possible performance improvement. A more detailed description of this service interface is given in Appendix B. 4.1.1. Message Handling Fundamentally, GIST provides a simple message-by-message transfer service for use by signalling applications: individual messages are sent, and individual messages are received. At the service interface, the NSLP payload, which is opaque to GIST, is accompanied by control information expressing the application's requirements about how the message should be routed (the MRI), and the application also provides the session identifier (SID), see Section 4.1.3. Additional message transfer attributes control the specific transport and security properties that the signalling application desires. Schulzrinne & Hancock Expires January 10, 2008 [Page 22] Internet-Draft GIST July 2007 The distinction between GIST D- and C-mode is not visible at the service interface. In addition, the functionality to handle fragmentation and reassembly, bundling together of small messages for efficiency, and congestion control are not visible at the service interface; GIST will take whatever action is necessary based on the properties of the messages and local node state. A signalling application is free to choose the rate at which it processes inbound messages; an implementation MAY allow the application to block accepting messages from GIST. In these circumstances, GIST MAY discard unreliably delivered messages, but for reliable messages MUST propagate flow-control condition back to the sender. Therefore, applications must be aware that they may in turn be blocked from sending outbound messages themselves. 4.1.2. Message Transfer Attributes Message transfer attributes are used by NSLPs to define minimum required levels of message processing. The attributes available are as follows: Reliability: This attribute may be 'true' or 'false'. When 'true', messages MUST be delivered to the signalling application in the peer exactly once or not at all; for messages with the same SID, the delivery MUST be in order. If there is a chance that the message was not delivered (e.g. in the case of a transport layer error), an error MUST be indicated to the local signalling application identifying the routing information for the message in question. GIST implements reliability by using an appropriate transport protocol within a messaging association, so mechanisms for the detection of message loss depend on the protocol in question; for the current specification, the case of TCP is considered in Section 5.7.2. When 'false', a message may be delivered, once, several times or not at all, with no error indications in any case. Security: This attribute defines the set of security properties that the signalling application requires for the message, including the type of protection required, and what authenticated identities should be used for the signalling source and destination. This information maps onto the corresponding properties of the security associations established between the peers in C-mode. Keying material for the security associations is established by the authentication mechanisms within the messaging association protocols themselves; see Section 8.2. The attribute can be specified explicitly by the signalling application, or reported by GIST to the signalling application. The latter can take place either on receiving a message, or just before sending a message Schulzrinne & Hancock Expires January 10, 2008 [Page 23] Internet-Draft GIST July 2007 but after configuring or selecting the messaging association to be used for it. This attribute can also be used to convey information about any address validation carried out by GIST, such as whether a return routability check has been carried out. Further details are discussed in Appendix B. Local Processing: An NSLP may provide hints to GIST to enable more efficient or appropriate processing. For example, the NSLP may select a priority from a range of locally defined values to influence the sequence in which messages leave a node. Any priority mechanism MUST respect the ordering requirements for reliable messages within a session, and priority values are not carried in the protocol or available at the signalling peer or intermediate nodes. An NSLP may also indicate that upstream path routing state will not be needed for this flow, to inhibit the node requesting its downstream peer to create it; conversely, even if routing state exists, the NSLP may request that it is not used, which will lead to GIST Data messages being sent Q-mode encapsulated instead. A GIST implementation MAY deliver messages with better performance than strictly required by the attributes given. 4.1.3. SID Selection The fact that SIDs index routing state (see Section 4.2.1 below) means that there are requirements for how they are selected. Specifically, signalling applications MUST choose SIDs so that they are cryptographically random, and SHOULD NOT use several SIDs for the same flow, to avoid additional load from routing state maintenance. Guidance on secure randomness generation can be found in [31]. 4.2. GIST State 4.2.1. Message Routing State For each flow, the GIST layer can maintain message routing state to manage the processing of outgoing messages. This state is conceptually organised into a table with the following structure. Each row in the table corresponds to a unique combination of the following three items: Message Routing Information (MRI): This defines the method to be used to route the message, the direction in which to send the message, and any associated addressing information; see Section 3.3. Schulzrinne & Hancock Expires January 10, 2008 [Page 24] Internet-Draft GIST July 2007 Session Identification (SID): The signalling session with which this message should be associated; see Section 3.7. NSLP Identification (NSLPID): This is an IANA-assigned identifier associated with the NSLP which is generating messages for this flow; see Section 3.8. The inclusion of this identifier allows the routing state to be different for different NSLPs. The information associated with a given {MRI,SID,NSLPID} triplet consists of the routing state to reach the peer in the direction given by the MRI. For any flow there will usually be two entries in the table, one each for the upstream and downstream MRI. The routing state includes information about the peer identity (see Section 4.4.3), and a UDP port number for D-mode, or a reference to one or more MAs for C-mode. Entries in the routing state table are created by the GIST handshake, which is described in more detail in Section 4.4. It is also possible for the state information for either direction to be empty. There are several possible cases: o The signalling application has indicated that no messages will actually be sent in that direction. o The node is the endpoint of the signalling path, for example because it is acting as a proxy, or because it has determined that there are no further signalling nodes in that direction. o The node is using other techniques to route the message. For example, it can send it in Q-mode and rely on the peer to intercept it. In particular, if the node is a flow endpoint, GIST will refuse to create routing state for the direction beyond the end of the flow (see Section 4.3.3). Each entry in the routing state table has an associated validity timer indicating for how long it can be considered accurate. When this timer expires, the entry MUST be purged if it has not been refreshed. Installation and maintenance of routing state is described in more detail in Section 4.4. 4.2.2. Peer-Peer Messaging Association State The per-flow message routing state is not the only state stored by GIST. There is also the state required to manage the MAs. Since these are not per-flow, they are stored separately from the routing state, including the following per-MA information: Schulzrinne & Hancock Expires January 10, 2008 [Page 25] Internet-Draft GIST July 2007 o a queue of any messages that require the use of an MA, pending transmission while the MA is being established; o the time since the peer re-stated its desire to keep the MA open (see Section 4.4.5). In addition, per-MA state, such as TCP port numbers or timer information, is held in the messaging association protocols themselves. However, the details of this state are not directly visible to GIST, and they do not affect the rest of the protocol description. 4.3. Basic GIST Message Processing This section describes how signalling application messages are processed in the case where any necessary messaging associations and routing state are already in place. The description is divided into several parts. Firstly, message reception, local processing and message transmission are described for the case where the node hosts the NSLPID identified in the message. Secondly, in Section 4.3.4, the case where the message is handled directly in the IP or GIST layer (because there is no matching signalling application on the node) is given. An overview is given in Figure 4. This section concentrates on the GIST level processing, with full details of IP and transport layer encapsulation in Section 5.3 and Section 5.4. Schulzrinne & Hancock Expires January 10, 2008 [Page 26] Internet-Draft GIST July 2007 +---------------------------------------------------------+ | >> Signalling Application Processing >> | | | +--------^---------------------------------------V--------+ ^ NSLP NSLP V ^ Payloads Payloads V +--------^---------------------------------------V--------+ | >> GIST >> | | ^ ^ ^ Processing V V V | +--x-----------N--Q---------------------Q--N-----------x--+ x N Q Q N x x N Q>>>>>>>>>>>>>>>>>>>>>Q N x x N Q Bypass at Q N x +--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+ | C-mode | | D-mode | | D-mode | | C-mode | |Handling| |Handling| |Handling| |Handling| +--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+ x N Q Q N x x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x x N Q Bypass at Q N x +--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+ |IP Host | | RAO | alert) level | RAO | |IP Host | |Handling| |Handling| |Handling| |Handling| +--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+ x N Q Q N x +--x--N-----------Q--+ +--Q-----------N--x--+ | IP Layer | | IP Layer | | (Receive Side) | | (Transmit Side) | +--x--N-----------Q--+ +--Q-----------N--x--+ x N Q Q N x x N Q Q N x NNNNNNNNNNNNNN = Normal D-mode messages QQQQQQQQQQQQQQ = D-mode messages which are Q-mode encapsulated xxxxxxxxxxxxxx = C-mode messages RAO = Router Alert Option Figure 4: Message Paths through a GIST Node 4.3.1. Message Reception Messages can be received in C-mode or D-mode. Reception in C-mode is simple: incoming packets undergo the security and transport treatment associated with the MA, and the MA provides complete messages to the GIST layer for further processing. Reception in D-mode depends on the message type. Schulzrinne & Hancock Expires January 10, 2008 [Page 27] Internet-Draft GIST July 2007 Normal encapsulation: Normal messages arrive UDP-encapsulated and addressed directly to the receiving signalling node, at an address and port learned previously. Each datagram contains a single message which is passed to the GIST layer for further processing, just as in the C-mode case. Q-mode encapsulation: Where GIST is sending messages to be intercepted by the appropriate peer rather than directly addressed to it (in particular, Query messages), these are UDP encapsulated, and MAY include an IP router alert option (RAO) if required by the MRM. Each signalling node can therefore see every such message, but unless the message exactly matches the Q-mode encapsulation rules (Section 5.3.2) it MUST be forwarded transparently at the IP level. If it does match, GIST MUST check the NSLPID in the common header. The case where the NSLPID does not match a local signalling application at all is considered below in Section 4.3.4; otherwise, the message MUST be passed up to the GIST layer for further processing. Several different RAO values may be used by the NSIS protocol suite. GIST itself does not allocate any RAO values (for either IPv4 or IPv6); an assignment is made for each NSLP using MRMs that use the RAO in the Q-mode encapsulation. The assignment rationale is discussed in a separate document. The RAO value assigned for an NSLPID may be different for IPv4 and IPv6. Note the different significance between the RAO and the NSLPID values: the meaning of a message (which signalling application it refers to, whether it should be processed at a node) is determined only from the NSLPID; the role of the RAO value is simply to allow nodes to pre-filter which IP datagrams are analysed to see if they might be Q-mode GIST messages. For all assignments associated with NSIS, the RAO specific processing is the same and is as defined by this specification, here and in Section 4.3.4 and Section 5.3.2. Immediately after reception, the GIST hop count is checked. Any message with a GIST hop count of zero MUST be rejected with a "Hop Limit Exceeded" error message (Appendix A.4.4.2); note that a correct GIST implementation will never send such a message. Otherwise, the GIST hop count MUST be decremented by one before the next stage. 4.3.2. Local Processing and Validation Once a message has been received, it is processed locally within the GIST layer. Further processing depends on the message type and payloads carried; most of the GIST payloads are associated with internal state maintenance, and details are covered in Section 4.4. This section concentrates on the interaction with the signalling Schulzrinne & Hancock Expires January 10, 2008 [Page 28] Internet-Draft GIST July 2007 application, in particular the decision to peer and how data is delivered to the NSLP. In the case of a Query, there is an interaction with the signalling application to determine which of two courses to follow. The first option (peering) MUST be chosen if the node is the final destination of the Query message, or if the GIST hop count has reached zero. 1. The receiving signalling application wishes to become a signalling peer with the Querying node. GIST MUST continue with the handshake process to set up message routing state, as described in Section 4.4.1. The application MAY provide an NSLP payload for the same NSLPID, which GIST will transfer in the Response. 2. The signalling application does not wish to set up state with the Querying node and become its peer. This includes the case where a node wishes to avoid taking part in the signalling for overload protection reasons. GIST MUST propagate the Query, similar to the case described in Section 4.3.4. No message is sent back to the Querying node. The application MAY provide an updated NSLP payload for the same NSLPID, which will be used in the Query forwarded by GIST. Note that if the node which finally processes the Query returns an Error message, this will be sent directly back to the originating node, bypassing any forwarders. For these diagnostics to be meaningful, any GIST node forwarding a Query MUST NOT modify it except in the NSLP payload and GIST hop count; in particular, it MUST NOT modify any other GIST payloads or their order. An implementation MAY choose to achieve this by retaining the original message, rather than reconstructing it from some parsed internal representation. This interaction with the signalling application, including the generation or update of an NSLP payload, SHOULD take place synchronously as part of the Query processing. In terms of the GIST service interface, this can be implemented by providing appropriate return values for the primitive that is triggered when such a message is received; see Appendix B.2 for further discussion. For all GIST message types other than Queries, if the message includes an NSLP payload, this MUST be delivered locally to the signalling application identified by the NSLPID. The format of the payload is not constrained by GIST, and the content is not interpreted. Delivery is subject to the following validation checks which MUST be applied in the sequence given: 1. if the message was explicitly routed (see Section 7.1.5) or is a Data message delivered without routing state (see Section 5.3.2), Schulzrinne & Hancock Expires January 10, 2008 [Page 29] Internet-Draft GIST July 2007 the payload is delivered but flagged to the receiving NSLP to indicate that routing state was not validated; 2. else, if the message arrived on an association which is not associated with the MRI/NSLPID/SID combination given in the message, the message MUST be rejected with an "Incorrectly Delivered Message" error message (Appendix A.4.4.4); 3. else, if there is no routing state for this MRI/SID/NSLPID the message MUST either be dropped or be rejected with a error message (see Section 4.4.6 for further details); 4. else, the payload is delivered as normal. 4.3.3. Message Transmission Signalling applications can generate their messages for transmission, either asynchronously, or in reply to an input message delivered by GIST, and GIST can also generate messages autonomously. GIST MUST verify that it is not the direct destination of an outgoing message, and MUST reject such messages with an error indication to the signalling application. When the message is generated by a signalling application, it may be carried in a Query if local policy and the message transfer attributes allow it; otherwise this may trigger setup of an MA over which the NSLP payload is sent in a Data message. Signalling applications may specify a value to be used for the GIST hop count; otherwise, GIST selects a value itself. GIST MUST reject messages for which the signalling application has specified a value of zero. Although the GIST hop count is only intended to control message looping at the GIST level, the GIST API (Appendix B) provides the incoming hop count to the NSLPs, which can preserve it on outgoing messages as they are forwarded further along the path. This provides a lightweight loop-control mechanism for NSLPs which do not define anything more sophisticated. Note that the count will be decremented on forwarding through every GIST-aware node. Initial values for the GIST hop count are an implementation matter; one suitable approach is to use the same algorithm as for IP TTL setting [1]. When a message is available for transmission, GIST uses internal policy and the stored routing state to determine how to handle it. The following processing applies equally to locally generated messages and messages forwarded from within the GIST or signalling application levels. However, see Section 5.6 for special rules applying to the transmission of error messages by GIST. Schulzrinne & Hancock Expires January 10, 2008 [Page 30] Internet-Draft GIST July 2007 The main decision is whether the message must be sent in C-mode or D-mode. Reasons for using C-mode are: o message transfer attributes: for example, the signalling application has specified security attributes that require channel-secured delivery, or reliable delivery. o message size: a message whose size (including the GIST header, GIST objects and any NSLP payload, and an allowance for the IP and transport layer encapsulation required by D-mode) exceeds a fragmentation-related threshold MUST be sent over C-mode, using a messaging association that supports fragmentation and reassembly internally. The allowance for IP and transport layer encapsulation is 64 bytes. The message size MUST NOT exceed the Path MTU to the next peer, if this is known. If this is not known, the message size MUST NOT exceed the least of the first-hop MTU, and 576 bytes. The same limit applies to IPv4 and IPv6. o congestion control: D-mode SHOULD NOT be used for signalling where it is possible to set up routing state and use C-mode, unless the network can be engineered to guarantee capacity for D-mode traffic within the rate control limits imposed by GIST (see Section 5.3.3). In principle, as well as determining that some messaging association must be used, GIST MAY select between a set of alternatives, e.g. for load sharing or because different messaging associations provide different transport or security attributes. For the case of reliable delivery, GIST MUST NOT distribute messages for the same session over multiple messaging associations in parallel, but MUST use a single association at any given time. The case of moving over to a new association is covered in Section 4.4.5. If the use of a messaging association (i.e. C-mode) is selected, the message is queued on the association found from the routing state table, and further output processing is carried out according to the details of the protocol stacks used. If no appropriate association exists, the message is queued while one is created (see Section 4.4.1), which will trigger the exchange of additional GIST messages. If no association can be created, this is an error condition, and should be indicated back to the local signalling application. If a messaging association is not appropriate, the message is sent in D-mode. The processing in this case depends on the message type, local policy, and whether routing state exists or not. Schulzrinne & Hancock Expires January 10, 2008 [Page 31] Internet-Draft GIST July 2007 o If the message is not a Query, and local policy does not request the use of Q-mode for this message, and routing state exists, it is sent with the normal D-mode encapsulation directly to the address from the routing state table. o If the message is a Query, or the message is Data and local policy as given by the message transfer attributes request the use of Q-mode, then it is sent in Q-mode as defined in Section 5.3.2; the details depend on the message routing method. o If no routing state exists, GIST can attempt to use Q-mode as in the Query case: either sending a Data message with the Q-mode encapsulation, or using the event as a trigger for routing state setup (see Section 4.4). If this is not possible, e.g. because the encapsulation for the MRM is only defined for one message direction, then this is an error condition which is reported back to the local signalling application. 4.3.4. Nodes not Hosting the NSLP A node may receive messages where it has no signalling application corresponding to the message NSLPID. There are several possible cases depending mainly on the encapsulation: 1. A message contains an RAO value which is relevant to NSIS, but it does not exactly match the Q-mode encapsulation rules of Section 5.3.2. The message MUST be transparently forwarded at the IP layer. See Section 3.6. 2. A Q-mode encapsulated message contains an RAO value which has been assigned to some NSIS signalling application but which is not used on this specific node, but the IP layer is unable to distinguish whether it needs to be passed to GIST for further processing or whether the packet should be forwarded just like a normal IP datagram. 3. A Q-mode encapsulated message contains an RAO value which has been assigned to an NSIS signalling application which is used on this node, but the signalling application does not process the specific NSLPID in the message. (This covers the case where a signalling application uses a set of NSLPIDs.) 4. A directly addressed message (in D-mode or C-mode) is delivered to a node for which there is no corresponding signalling application. With the current specification, this should not happen in normal operation. While future versions might find a use for such a feature, currently this MUST cause an "Unknown NSLPID" error message, Appendix A.4.4.6. Schulzrinne & Hancock Expires January 10, 2008 [Page 32] Internet-Draft GIST July 2007 5. A Q-mode encapsulated message arrives at the end-system which does not handle the signalling application. This is possible in normal operation, and MUST be indicated to the sender with an "Endpoint Found" informational message (Appendix A.4.4.7). The end-system includes the MRI and SID from the original message in the error message without interpreting them. 6. The node is GIST-aware NAT. See Section 7.2. In cases (2) and (3), the role of GIST is to forward the message essentially as though it were a normal IP datagram, and it will not become a peer to the node sending the message. Forwarding with modified NSLP payloads is covered above in Section 4.3.2. However, a GIST implementation MUST ensure that the IP-layer TTL field and GIST hop count are managed correctly to prevent message looping, and this should be done consistently independently of whether the processing takes place on the fast path or in GIST-specific code. The rules are that in cases (2) and (3), the IP-layer TTL MUST be decremented just as if the message was a normal IP forwarded packet; in case (3) the GIST hop count MUST be decremented as in the case of normal input processing, which also applies to cases (4) and (5). A GIST node processing Q-mode encapsulated messages in this way SHOULD make the routing decision based on the full contents of the MRI and not only the IP destination address. It MAY also apply a restricted set of sanity checks and under certain conditions return an error message rather than forward the message. These conditions are: 1. The message is so large that it would be fragmented on downstream links, for example because the downstream MTU is abnormally small (less than 576 bytes). The error "Message Too Large" (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD begin messaging association setup. 2. The GIST hop count has reached zero. The error "Hop Limit Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, which MAY retry with a larger initial hop count. 3. The MRI represents a flow definition which is too general to be forwarded along a unique path (e.g. the destination address prefix is too short). The error "MRI Validation Failure" (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be returned to the sender, which MAY retry with restricted MRIs, possibly starting additional signalling sessions to do so. If the GIST node does not understand the MRM in question it MUST NOT apply this check, instead forwarding the message transparently. Schulzrinne & Hancock Expires January 10, 2008 [Page 33] Internet-Draft GIST July 2007 In the first two cases, only the common header of the GIST message is examined; in the third case, the MRI is also examined. The rest of the message MUST NOT be inspected in any case. Similar to the case of Section 4.3.2, the GIST payloads MUST NOT be modified or re- ordered; an implementation MAY choose to achieve this by retaining the original message, rather than reconstructing it from some parsed internal representation. 4.4. Routing State and Messaging Association Maintenance The main responsibility of GIST is to manage the routing state and messaging associations which are used in the message processing described above. Routing state is installed and refreshed by GIST handshake messages. Messaging associations are set up by the normal procedures of the transport and security protocols that comprise them, using peer IP addresses from the routing state. Once a messaging association has been created, its refresh and expiration can be managed independently from the routing state. There are two different cases for state installation and refresh: 1. Where routing state is being discovered or a new association is to be established; and 2. Where a suitable association already exists, including the case where routing state for the flow is being refreshed. These cases are now considered in turn, followed by the case of background general management procedures. 4.4.1. Routing State and Messaging Association Creation The complete sequence of possible messages for GIST state setup between adjacent peers is shown in Figure 5 and described in detail in the following text. The figure informally summarises the contents of each message, including optional elements in square brackets. An example is given in Appendix D. The initial message in any routing state maintenance operation is a Query, sent from the querying node and intercepted at the responding node. This message has addressing and other identifiers appropriate for the flow and signalling application that state maintenance is being done for, addressing information about the node that generated the Query itself, and it MAY contain an NSLP payload. It also includes a Query Cookie, and optionally capability information about messaging association protocol stacks. The role of the cookies in this and subsequent messages is to protect against certain denial of service attacks and to correlate the various events in the message Schulzrinne & Hancock Expires January 10, 2008 [Page 34] Internet-Draft GIST July 2007 sequence (see Section 8.5 for further details). Provided that the signalling application has indicated that message routing state should be set up (see Section 4.3.2), reception of a Query MUST elicit a Response. This is a normally encapsulated D-mode message with additional GIST payloads. It contains network layer information about the responding node, echoes the Query Cookie, and MAY contain an NSLP payload, possibly a reply to the NSLP payload in the initial message. In case a messaging association was requested, it MUST also contain a Responder Cookie and its own capability information about messaging association protocol stacks. Even if a messaging association is not requested, the Response MAY still include a Responder Cookie if the node's routing state setup policy requires it (see below). Schulzrinne & Hancock Expires January 10, 2008 [Page 35] Internet-Draft GIST July 2007 +----------+ +----------+ | Querying | |Responding| | Node(Q-N)| | Node(R-N)| +----------+ +----------+ Query ----------------------> ............. Router Alert Option . Routing . MRI/SID/NSLPID . state . Q-N Network Layer Info . installed . Query Cookie . at . [Q-N Stack-Proposal . Responding. Q-N Stack-Config-Data] . node . [NSLP Payload] . (case 1) . ............. ...................................... . The responder can use an existing . . messaging association if available . . from here onwards to short-circuit . . messaging association setup . ...................................... Response ............. <---------------------- . Routing . MRI/SID/NSLPID . state . R-N Network Layer Info . installed . Query cookie . at . [Responder Cookie . Querying . [R-N Stack-Proposal . node . R-N Stack-Config-Data]] ............. [NSLP Payload] .................................... . If a messaging association needs . . to be created, it is set up here . . and the Confirm uses it . .................................... Confirm ............. ----------------------> . Routing . MRI/SID/NSLPID . state . Q-N Network Layer Info . installed . [Responder Cookie . at . [R-N Stack-Proposal . Responding. [Q-N Stack-Config-Data]]] . node . [NSLP Payload] . (case 2) . ............. Figure 5: Message Sequence at State Setup Schulzrinne & Hancock Expires January 10, 2008 [Page 36] Internet-Draft GIST July 2007 Setup of a new messaging association begins when peer addressing information is available and a new messaging association is actually needed. Any setup MUST take place immediately after the specific Query/Response exchange, because the addressing information used may have a limited lifetime, either because it depends on limited lifetime NAT bindings or because it refers to agile destination ports for the transport protocols. The Stack-Proposal and Stack- Configuration-Data objects carried in the exchange carry capability information about what messaging association protocols can be used, and the processing of these objects is described in more detail in Section 5.7. With the protocol options currently defined, setup of the messaging association always starts from the Querying node, although more flexible configurations are possible within the overall GIST design. If the messaging association includes a channel security protocol, each GIST node MUST verify the authenticated identity of the peer against its authorised peer database, and if there is no match the messaging association MUST be torn down. The database and authorisation check are described in more detail in Section 4.4.2 below. Note that the verification can depend on what the MA is to be used for (e.g. for which MRI or session), so this step may not be possible immediately after authentication has completed but some time later. Finally, after any necessary messaging association setup has completed, a Confirm MUST be sent if the Response requested it. Once the Confirm has been sent, the Querying node assumes that routing state has been installed at the responder, and can send normal Data messages for the flow in question; recovery from a lost Confirm is discussed in Section 5.3.3. If a messaging association is being used, the Confirm MUST be sent over it before any other messages for the same flow, and it echoes the Responder Cookie and Stack-Proposal from the Response. The former is used to allow the receiver to validate the contents of the message (see Section 8.5), and the latter is to prevent certain bidding-down attacks on messaging association security (see Section 8.6). This first Confirm on a new association MUST also contain a Stack-Configuration-Data object carrying an MA-Hold-Time value, which supersedes the value given in the original Query. The association can be used in the upstream direction for the MRI and NSLPID carried in the Confirm, after the Confirm has been received. The querying node MUST install the responder address, derived from the R-Node Network Layer info, as routing state information after verifying the Query Cookie in the Response. The responding node MAY install the querying address as peer state information at two points in time: Schulzrinne & Hancock Expires January 10, 2008 [Page 37] Internet-Draft GIST July 2007 Case 1: after the receipt of the initial Query, or Case 2: after a Confirm containing the Responder Cookie. The responding node SHOULD derive the peer address from the Q-Node Network Layer Info if this was decoded successfully. Otherwise, it MAY be derived from the IP source address of the message if the common header flags this as being the signalling source address. The precise constraints on when state information is installed are a matter of security policy considerations on prevention of denial-of- service attacks and state poisoning attacks, which are discussed further in Section 8. Because the responding node MAY choose to delay state installation as in case (2), the Confirm must contain sufficient information to allow it to be processed in the same way as the original Query. This places some special requirements on NAT traversal and cookie functionality, which are discussed in Section 7.2 and Section 8 respectively. 4.4.2. GIST Peer Authorisation When two GIST nodes authenticate using a messaging association, both ends have to decide whether to accept the creation of the MA and whether to trust the information sent over it. This can be seen as an authorisation decision: o Authorised peers are trusted to install correct routing state about themselves and not, for example, to claim that they are on- path for a flow when they are not. o Authorised peers are trusted to obey transport and application level flow control rules, and not to attempt to create overload situations. o Authorised peers are trusted not to send erroneous or malicious error messages, for example asserting that routing state has been lost when it has not. This specification models the decision as verification by the authorising node of the peer's identity against a local list of peers, the authorised peer database (APD). The APD is an abstract construct, similar to the security policy database of IPsec [36]. Implementations MAY provide the associated functionality in any way they choose. This section defines only the requirements for APD administration and the consequences of successfully validating a peer's identity against it. The APD consists of a list of entries. Each entry includes an identity, the namespace from which the identity comes (e.g. DNS Schulzrinne & Hancock Expires January 10, 2008 [Page 38] Internet-Draft GIST July 2007 domains), the scope within which the entry is applicable, and whether authorisation is allowed or denied. The following are example scopes: Peer Address Ownership: The scope is the IP address at which the peer for this MRI should be; the APD entry denotes the identity as the owner of address. If the authorising node can determine this address from local information (such as its own routing tables), matching this entry shows that the peer is the correct on-path node and so should be authorised. The determination is simple if the peer is one IP hop downstream, since the IP address can be derived from the router's forwarding tables. If the peer is more than one hop away or is upstream, the determination is harder but may still be possible in some circumstances. The authorising node may be able to determine a (small) set of possible peer addresses, and accept that any of these could be the correct peer. End-System Subnet: The scope is an address range within which the MRI source or destination lie; the APD entry denotes the identity as potentially being on-path between the authorising node and that address range. There may be different source and destination scopes, to account for asymmetric routing. The same identity may appear in multiple entries, and the order of entries in the APD is significant. When a messaging association is authenticated and associated with an MRI, the authorising node scans the APD to find the first entry where the identity matches that presented by the peer, and where the scope information matches the circumstances for which the MA is being set up. The identity matching process itself depends on the messaging association protocol that carries out the authentication, and details for TLS are given in Section 5.7.3. Whenever the full set of possible peers for a specific scope is known, deny entries SHOULD be added for the wildcard identity to reject signalling associations from unknown nodes. The ability of the authorising node to reject inappropriate MAs depends directly on the granularity of the APD and the precision of the scope matching process. If authorisation is allowed, the MA can be used as normal; otherwise it MUST be torn down without further GIST exchanges, and any routing state associated with the MA MUST also be deleted. An error condition MAY be logged locally. When an APD entry is modified or deleted, the node MUST re-validate existing MAs and the routing state table against the revised contents of the APD. This may result in MAs being torn down or routing state entries being deleted. These changes SHOULD be indicated to local signalling applications via the NetworkNotification API call (Appendix B.4). Schulzrinne & Hancock Expires January 10, 2008 [Page 39] Internet-Draft GIST July 2007 This specification does not define how the APD is populated. As a minimum, an implementation MUST provide an administrative interface through which entries can be added, modified, or deleted. More sophisticated mechanisms are possible in some scenarios. For example, the fact that a node is legitimately associated with a specific IP address could be established by direct embedding of the IP address as a particular identity type in a certificate, or by a mapping that address to another identifier type via an additional database lookup (such as relating IP addresses in in-addr.arpa to domain names). An enterprise network operator could generate a list of all the identities of its border nodes as authorised to be on the signalling path to external destinations, and this could be distributed to all hosts inside the network. Regardless of the technique, it MUST be ensured that the source data justify the authorisation decisions listed at the start of this section, and that the security of the chain of operations on which the APD entry depends cannot be compromised. 4.4.3. Messaging Association Multiplexing It is a design goal of GIST that, as far as possible, a single messaging association should be used for multiple flows and sessions between two peers, rather than setting up a new MA for each. This re-use of existing MAs is referred to as messaging association multiplexing. Multiplexing ensures that the MA cost scales only with the number of peers, and avoids the latency of new MA setup where possible. However, multiplexing requires the identification of an existing MA which matches the same routing state and desired properties that would be the result of a normal handshake in D-mode, and this identification must be done as reliably and securely as continuing with this procedure. Note that this requirement is complicated by the fact that NATs may remap the node addresses in D-mode messages, and also interacts with the fact that some nodes may peer over multiple interfaces (and thus with different addresses). MA multiplexing is controlled by the Network-Layer-Information (NLI) object, which is carried in Query, Response and Confirm messages. The NLI object includes (among other elements): Peer-Identity: For a given node, this is an interface independent value with opaque syntax. It MUST be chosen so as to have a high probability of uniqueness across the set of all potential peers, and SHOULD be stable at least until the next node restart. Note that there is no cryptographic protection of this identity; attempting to provide this would essentially duplicate the functionality in the messaging association security protocols. Schulzrinne & Hancock Expires January 10, 2008 [Page 40] Internet-Draft GIST July 2007 For routers, the Router-ID [2], which is one of the router's IP addresses, MAY be used as one possible value for the Peer- Identity. In scenarios with nested NATs, the Router-ID alone may not satisfy the uniqueness requirements, in which case it MAY be extended with additional tokens, either chosen randomly or administratively coordinated. Interface-Address: This is an IP address through which the signalling node can be reached. There may be several choices available for the Interface-Address, and further discussion of this is contained in Section 5.2.2. A messaging association is associated with the NLI object that was provided by the peer in the Query/Response/Confirm at the time the association was first set up. There may be more than one MA for a given NLI object, for example with different security or transport properties. MA multiplexing is achieved by matching these two elements from the NLI provided in a new GIST message with one associated with an existing MA. The message can be either a Query or Response, although the former is more likely: o If there is a perfect match to an existing association, that association SHOULD be re-used, provided it meets the criteria on security and transport properties given at the end of Section 5.7.1. This is indicated by sending the remaining messages in the handshake over that association. This will lead to multiplexing on an association to the wrong node if signalling nodes have colliding Peer-Identities and one is reachable at the same Interface-Address as another. This could be caused by an on- path attacker; on-path attacks are discussed further in Section 8.7. When multiplexing is done, and the original MA authorisation was MRI-dependent, the verification steps of Section 4.4.2 MUST be repeated for the new flow. o In all other cases, the handshake MUST be executed in D-mode as usual. There are in fact four possibilities: 1. Nothing matches: this is clearly a new peer. 2. Only the Peer-Identity matches: this may be either a new interface on an existing peer, or a changed address mapping behind a NAT. These should be rare events, so the expense of a new association setup is acceptable. Another possibility is one node using another node's Peer-Identity, for example as some kind of attack. Because the Peer-Identity is used only for this multiplexing process, the only consequence this has Schulzrinne & Hancock Expires January 10, 2008 [Page 41] Internet-Draft GIST July 2007 is to require a new association setup, and this is considered in Section 8.4. 3. Only the Interface-Address matches: this is probably a new peer behind the same NAT as an existing one. A new association setup is required. 4. Both elements of the NLI object match: this is a degenerate case, where one node recognises an existing peer, but wishes to allow the option to set up a new association in any case, for example to create an association with different properties. 4.4.4. Routing State Maintenance Each item of routing state expires after a lifetime which is negotiated during the Query/Response/Confirm handshake. The Network Layer Info (NLI) object in the Query contains a proposal for the lifetime value, and the NLI in the Response contains the value the Responding node requires. A default timer value of 30 seconds is RECOMMENDED. Nodes which can exploit alternative, more powerful, route change detection methods such as those described in Section 7.1.2 MAY choose to use much longer times. Nodes MAY use shorter times to provide more rapid change detection. If the number of active routing state items corresponds to a rate of Queries that will stress the rate limits applied to D-mode traffic (Section 5.3.3), nodes MUST increase the timer for new items and on the refresh of existing ones. A suitable value is 2 * (number of routing states) / (rate limit in pkts/second) which leaves a factor of two headroom for new routing state creation and Query retransmissions. The Querying node MUST ensure that a Query is received before this timer expires, if it believes that the signalling session is still active; otherwise, the Responding node MAY delete the state. Receipt of the message at the Responding node will refresh peer addressing state for one direction, and receipt of a Response at the querying node will refresh it for the other. There is no mechanism at the GIST level for explicit teardown of routing state. However, GIST MUST NOT refresh routing state if a signalling session is known to be inactive, either because upstream state has expired, or because the signalling application has indicated via the GIST API (Appendix B.5) that the state is no longer required, because this would prevent correct state repair in the case of network rerouting at the IP layer. This specification defines precisely only the time at which routing Schulzrinne & Hancock Expires January 10, 2008 [Page 42] Internet-Draft GIST July 2007 state expires; it does not define when refresh handshakes should be initiated. Implementations MUST select timer settings which take at least the following into account: o The transmission latency between source and destination; o The need for retransmissions of Query messages; o The need to avoid network synchronisation of control traffic (cf. [39]). In most cases, a reasonable policy is to initiate the routing state refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects. 4.4.5. Messaging Association Maintenance Unneeded MAs are torn down by GIST, using the teardown mechanisms of the underlying transport or security protocols if available, for example by simply closing a TCP connection. The teardown can be initiated by either end. Whether an MA is needed is a combination of two factors: o local policy, which could take into account the cost of keeping the messaging association open, the level of past activity on the association, and the likelihood of future activity, e.g. if there is routing state still in place which might generate messages to use it. o whether the peer still wants the MA to remain in place. During MA setup, as part of the Stack-Configuration-Data, each node advertises its own MA-Hold-Time, which is the time for which it will retain an MA which is not carrying signalling traffic. A node MUST NOT tear down an MA if it has received traffic from its peer over that period. A peer which has generated no traffic but still wants the MA retained can use a special null message (MA- Hello) to indicate the fact. A default value for MA-Hold-Time of 30 seconds is RECOMMENDED. Nodes MAY use shorter times to achieve more rapid peer failure detection, but need to take into account the load on the network created by the MA-Hello messages. Nodes MAY use longer times, but need to take into account the cost of retaining idle MAs for extended periods. Nodes MAY take signalling application behaviour (e.g. NSLP refresh times) into account in choosing an appropriate value. Because the Responding node can choose not to create state until a Confirm, an abbreviated Stack-Configuration-Data object containing Schulzrinne & Hancock Expires January 10, 2008 [Page 43] Internet-Draft GIST July 2007 just this information from the initial Query MUST be repeated by the Querying node in the first Confirm sent on a new MA. If the object is missing in the Confirm, an "Object Type Error" message (Appendix A.4.4.9) with subcode 2 ("Missing Object") MUST be returned. Messaging associations can always be set up on demand, and messaging association status is not made directly visible outside the GIST layer. Therefore, even if GIST tears down and later re-establishes a messaging association, signalling applications cannot distinguish this from the case where the MA is kept permanently open. To maintain the transport semantics described in Section 4.1, GIST MUST close transport connections carrying reliable messages gracefully or report an error condition, and MUST NOT open a new association to be used for given session and peer while messages on a previous association could still be outstanding. GIST MAY use an MA-Hello request/reply exchange on an existing association to verify that messages sent on it have reached the peer. GIST MAY use the same technique to test the liveness of the underlying MA protocols themselves at arbitrary times. This specification defines precisely only the time at which messaging associations expires; it does not define when keepalives should be initiated. Implementations MUST select timer settings which take at least the following into account: o The transmission latency between source and destination; o The need for retransmissions within the messaging association protocols; o The need to avoid network synchronisation of control traffic (cf. [39]). In most cases, a reasonable policy is to initiate the MA refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects. 4.4.6. Routing State Failures A GIST node can receive a message from a GIST peer, which can only be correctly processed in the context of some routing state, but where no corresponding routing state exists. Cases where this can arise include: o Where the message is random traffic from an attacker, or backscatter (replies to such traffic). Schulzrinne & Hancock Expires January 10, 2008 [Page 44] Internet-Draft GIST July 2007 o Where routing state has been correctly installed but the peer has since lost it, for example because of aggressive timeout settings at the peer, or because the node has crashed and restarted. o Where the routing state has never been correctly installed in the first place, but the sending node does not know this. This can happen if the Confirm message of the handshake is lost. It is important for GIST to recover from such situations promptly where they represent genuine errors (node restarts, or lost messages which would not otherwise be retransmitted). Note that only Response, Confirm, Error and Data messages ever require routing state to exist, and these are considered in turn: Response: A Response can be received at a node which never sent (or has forgotten) the corresponding Query. If the node wants routing state to exist, it will initiate it itself; a diagnostic error would not allow the sender of the Response to take any corrective action, and the diagnostic could itself be a form of backscatter. Therefore, an error message MUST NOT be generated, but the condition MAY be logged locally. Confirm: For a Responding node which implements delayed state installation, this is normal behaviour, and routing state will be created provided the Confirm is validated. Otherwise, this is a case of a non-existent or forgotten Response, and the node may not have sufficient information in the Confirm to create the correct state. The requirement is to notify the Querying node so that it can recover the routing state. Data: This arises when a node receives Data where routing state is required, but either it does not exist at all, or it has not been finalised (no Confirm message). To avoid Data being black-holed, a notification must be sent to the peer. Error: Some error messages can only be interpreted in the context of routing state. However, the only error messages which require a reply within the protocol are routing state error messages themselves. Therefore, this case should be treated the same as a Response: an error message MUST NOT be generated, but the condition MAY be logged locally. For the case of Confirm or Data messages, if the state is required but does not exist, the node MUST reject the incoming message with a "No Routing State" error message (Appendix A.4.4.5). There are then three cases at the receiver of the error message: Schulzrinne & Hancock Expires January 10, 2008 [Page 45] Internet-Draft GIST July 2007 No routing state: The condition MAY be logged but a reply MUST NOT be sent (see above). Querying node: The node MUST restart the GIST handshake from the beginning, with a new Query. Responding node: The node MUST delete its own routing state and SHOULD report an error condition to the local signalling application. The rules at the Querying or Responding node make GIST open to disruption by randomly injected error messages, similar to blind reset attacks on TCP (cf. [43]), although because routing state matching includes the SID this is mainly limited to on-path attackers. If a GIST node detects a significant rate of such attacks, it MAY adopt a policy of using secured messaging associations to communicate for the affected MRIs, and only accepting "No Routing State" error messages over such associations. Schulzrinne & Hancock Expires January 10, 2008 [Page 46] Internet-Draft GIST July 2007 5. Message Formats and Transport 5.1. GIST Messages All GIST messages begin with a common header, followed by a sequence of type-length-value (TLV) objects. This subsection describes the various GIST messages and their contents at a high level in ABNF [12]; a more detailed description of the header and each object is given in Section 5.2 and bit formats in Appendix A. Note that the NAT traversal mechanism for GIST involves the insertion of an additional NAT-Traversal-Object in Query, Response, and some Data and Error messages; the rules for this are given in Section 7.2. GIST-Message: The primary messages are either part of the three-way handshake, or a simple message carrying NSLP data. Additional types are defined for errors and keeping messaging associations alive. GIST-Message = Query / Response / Confirm / Data / Error / MA-Hello The common header includes a version number, message type and size, and NSLPID. It also carries a hop count to prevent infinite message looping and various control flags, including one (the R flag) to indicate if a reply of some sort is requested. The objects following the common header MUST be carried in a fixed order, depending on message type. Messages with missing, duplicate or invalid objects for the message type MUST be rejected with an "Object Type Error" message with the appropriate subcode (Appendix A.4.4.9). Query: A Query MUST be sent in D-mode using the special Q-mode encapsulation. In addition to the common header, it contains certain mandatory control objects, and MAY contain a signalling application payload. A stack proposal and configuration data MUST be included if the message exchange relates to setup of a messaging association. The R flag MUST always be set (R=1) in a Query, since this message always elicits a Response. Query = Common-Header [ NAT-Traversal-Object ] Message-Routing-Information Session-Identification Network-Layer-Information Query-Cookie [ Stack-Proposal Stack-Configuration-Data ] [ NSLP-Data ] Response: A Response MAY be sent in D-mode, or MAY be sent in C-mode if an existing messaging association is being re-used. It MUST echo the MRI, SID and Query-Cookie of the Query, and carries its own Network-Layer-Information. If the message exchange relates to setup Schulzrinne & Hancock Expires January 10, 2008 [Page 47] Internet-Draft GIST July 2007 of a new messaging association, which MUST involve a D-mode Response, a Responder cookie MUST be included, as well as the Responder's own stack proposal and configuration data. The R flag MUST be set (R=1) if a Responder cookie is present but otherwise is optional; if the R flag is set, a Confirm MUST be sent as a reply. Therefore, in particular, a Confirm will always be required if a new MA is being set up. Note that the direction of this MRI will be inverted compared to that in the Query, that is, an upstream MRI becomes downstream and vice versa (see Section 3.3). Response = Common-Header [ NAT-Traversal-Object ] Message-Routing-Information Session-Identification Network-Layer-Information Query-Cookie [ Responder-Cookie [ Stack-Proposal Stack-Configuration-Data ] ] [ NSLP-Data ] Confirm: A Confirm MUST be sent in C-mode if a messaging association is being used for this routing state, and MUST be sent before other messages for this routing state. If no messaging association is being used, the Confirm MUST be sent in D-mode. The Confirm MUST include the MRI (with inverted direction) and SID, and echo the Responder-Cookie if the Response carried one. In C-mode, the Confirm MUST also echo the Stack-Proposal from the Response (if present) so it can be verified that this has not been tampered with. The first Confirm on a new association MUST also repeat the Stack- Configuration-Data from the original Query in an abbreviated form, just containing the MA-Hold-Time. Confirm = Common-Header Message-Routing-Information Session-Identification Network-Layer-Information [ Responder-Cookie [ Stack-Proposal [ Stack-Configuration-Data ] ] ] [ NSLP-Data ] Data: The Data message is used to transport NSLP data without modifying GIST state. It contains no control objects, but only the MRI and SID associated with the NSLP data being transferred. Network-Layer-Information (NLI) MUST be carried in the D-mode case, but MUST NOT be included otherwise. Schulzrinne & Hancock Expires January 10, 2008 [Page 48] Internet-Draft GIST July 2007 Data = Common-Header [ NAT-Traversal-Object ] Message-Routing-Information Session-Identification [ Network-Layer-Information ] NSLP-Data Error: An Error message reports a problem determined at the GIST level. (Errors generated by signalling applications are reported in NSLP-Data payloads and are not treated specially by GIST.) If the message is being sent in D-mode, the originator of the error message MUST include its own Network-Layer-Information object. All other information related to the error is carried in a GIST-Error-Data object. Error = Common-Header [ NAT-Traversal-Object ] [ Network-Layer-Information ] GIST-Error-Data MA-Hello: This message MUST be sent only in C-mode. It contains the common header, with a NSLPID of zero, and a message identifier, the Hello-ID. It always indicates that a node wishes to keep a messaging association open, and if sent with R=0 and zero Hello-ID this is its only function. A node MAY also invoke a diagnostic request/reply exchange by setting R=1 and providing a non-zero Hello-ID; if this case, the peer MUST send another MA-Hello back along the messaging association echoing the same Hello-ID and with R=0. Use of this diagnostic is entirely at the discretion of the initiating node. MA-Hello = Common-Header Hello-ID 5.2. Information Elements This section describes the content of the various objects that can be present in each GIST message, both the common header, and the individual TLVs. The bit formats are provided in Appendix A. 5.2.1. The Common Header Each message begins with a fixed format common header, which contains the following information: Version: The version number of the GIST protocol. This specification defines GIST version 1. Schulzrinne & Hancock Expires January 10, 2008 [Page 49] Internet-Draft GIST July 2007 GIST hop count: A hop count to prevent a message from looping indefinitely. Length: The number of 32 bit words in the message following the common header. Upper layer identifier (NSLPID): This gives the specific NSLP that this message is used for. Message type: The message type (Query, Response, etc.) Source addressing mode: If set (S=1), this indicates that the IP source address of the message is the same as the IP address of the signalling peer, so replies to this message can be sent safely to this address. S is always set in C-mode. It is cleared (S=0) if the IP source address was derived from the message routing information in the payload and this is different from the signalling source address. Response requested: A flag which if set (R=1) indicates that a GIST message should be sent in reply to this message. The appropriate message type for the reply depends on the type of the initial message. Explicit routing: A flag which if set (E=1) indicates that the message was explicitly routed (see Section 7.1.5). Note that in D-mode, Section 5.3, there is a 32-bit magic number before the header. However, this is regarded as part of the encapsulation rather than part of the message itself. 5.2.2. TLV Objects All data following the common header is encoded as a sequence of type-length-value objects. Currently, each object can occur at most once; the set of required and permitted objects is determined by the message type and encapsulation (D-mode or C-mode). Message-Routing-Information (MRI): Information sufficient to define how the signalling message should be routed through the network. Message-Routing-Information = message-routing-method method-specific-information The format of the method-specific-information depends on the message-routing-method requested by the signalling application. Note that it always includes a flag defining the direction as either 'upstream' or 'downstream' (see Section 3.3). It is Schulzrinne & Hancock Expires January 10, 2008 [Page 50] Internet-Draft GIST July 2007 provided by the NSLP in the message sender and used by GIST to select the message routing. Session-Identification (SID): The GIST session identifier is a 128 bit, cryptographically random identifier chosen by the node which originates the signalling exchange. See Section 3.7. Network-Layer-Information (NLI): This object carries information about the network layer attributes of the node sending the message, including data related to the management of routing state. This includes a peer identity and IP address for the sending node. It also includes IP-TTL information to allow the IP hop count between GIST peers to be measured and reported, and a validity time (RS-validity-time) for the routing state. Network-Layer-Information = peer-identity interface-address RS-validity-time IP-TTL The use of the RS-validity-time field is described in Section 4.4.4. The peer-identity and interface-address are used for matching existing associations, as discussed in Section 4.4.3. The interface-address must be routable, i.e. it MUST be usable as a destination IP address for packets to be sent back to the node generating the signalling message, whether in D-mode or C-mode. If this object is carried in a message with the source addressing mode flag S=1, the interface-address MUST match the source address used in the IP encapsulation, to assist in legacy NAT detection (Section 7.2.1). If this object is carried in a Query or Confirm, the interface-address MUST specifically be set to an address bound to an interface associated with the MRI, to allow its use in route change handling as discussed in Section 7.1. A suitable choice is the interface that is carrying the outbound flow. A node may have several choices for which of its addresses to use as the interface-address. For example, there may be a choice of IP versions, or addresses of limited scope (e.g. link-local), or addresses bound to different interfaces in the case of a router or multi-homed host. However, some of these interface addresses may not be usable by the peer. A node MUST follow a policy of using a global address of the same IP version as in the MRI, unless it can establish that an alternative address would also be usable. The setting and interpretation of the IP-TTL field depends on the message direction (upstream/downstream as determined from the MRI as described above) and encapsulation. Schulzrinne & Hancock Expires January 10, 2008 [Page 51] Internet-Draft GIST July 2007 * If the message is sent downstream, if the TTL that will be set in the IP header for the message can be determined, the IP-TTL