Internet Engineering Task Force Internet Draft H. Schulzrinne Columbia U. H. Tschofenig Siemens X. Fu TU Berlin J. Eisl Siemens R. Hancock Siemens-Roke Manor draft-schulzrinne-nsis-casp-00.txt September 15, 2002 Expires: January 2003 CASP - Cross-Application Signaling Protocol STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The Cross-Application Signaling Protocol (CASP) is a general-purpose protocol for managing state in routers and other on-path network devices. It can be used for QoS signaling, middlebox control, topology discovery, measurement data collection, active network instantiation and any other application where state needs to be established along a data path. CASP consists of a set of building blocks that can be used to construct protocol behavior suited for a H. Schulzrinne et. al. [Page 1] Internet Draft CASP September 15, 2002 particular application. It is transport-neutral, network-friendly and securable. This document describes the usage-independent components of CASP. H. Schulzrinne et. al. [Page 2] Internet Draft CASP September 15, 2002 1 Introduction 1.1 Protocol Overview The Cross-Application Signaling Protocol (CASP) provides a generic signaling service by establishing state along the data path from a sender to one receiver, for unicast data, or multiple receivers, for multicast data. CASP sessions can be initiated by the sender or the receiver. CASP is not restricted to sender or receiver-initiated reservations; it can be used for a variety of signaling purposes. Examples include resource reservation in both in-path and out-of-path modes, configuration of middleboxes [1] such as firewalls and NATs, distribution of code segments in active networks, network diagnostics, and MPLS label distribution. CASP does not place restrictions on the location of signaling initiators and receivers. They can be the same as the data sources or sinks, or can be separate hosts ("proxies"). CASP consists of two layers, the client (C) and messaging (M) layer, as shown in Fig. 1. +-----------------------------+ +-----------------------------+ | | | Discovery protocol | | CASP client (C) layer | | (Scout protocol) | | | | | +-------------------------------------------------------------+ | | | CASP messaging (M) layer | | | +-------------------------------------------------------------+ | | | | | reliable transport layer | | UDP | | (TCP, SCTP, ...) | | | +-----------------------------+ +-----------------------------+ Figure 1: CASP Protocol Layering The motivation for a separate client (application) and messaging layer is given by [2]. For the reasons discussed in Section 5, CASP uses existing transport protocols. H. Schulzrinne et. al. [Page 3] Internet Draft CASP September 15, 2002 CASP establishes sessions. A CASP session consists of all CASP messages that refer to the same state, traverse the same path or parts of it and share the same session identifier, independent of which direction messages travel. The origin and destination of the C and M layers have to be the same for each CASP session. Each CASP message consists of two parts: an application-independent part that handles message routing, discovery and feature negotiation (i.e., the messaging layer), and an application-dependent part that is carried as a payload inside the client layer. We refer to the protocol elements carried in the payload of CASP messages as the client protocol. A sample client protocol for resource reservation is described in [3]. This memo describes the messaging and transport layer common to all CASP client protocols, the common attributes required of client protocols, and a specialized client protocol, namely the scout protocol for next-peer discovery. CASP can establish state for its own use in forwarding messages; the client layer can establish its own state. Expiration of the message- layer state triggers removal of the client-layer state, but the converse may not be true. We assume that client layers within the same messaging layer session share fate and trust. Network nodes that process CASP messages are called CASP nodes. CASP nodes are divided into omnivorous and selective nodes. An omnivorous nodes processes all CASP messages, even if it does not understand the client protocol and thus ignores the client layer object. For example, a CASP node residing at a firewall or NAT may need to see each CASP message, so that it can inspect and modify the traffic selector. A selective CASP node is only interested in messages that carry one of the client protocols it supports. It is not visited by any other CASP message. We call the sequence of omnivorous and selective CASP nodes traversed by a CASP message between the NSIS Initiatior (NI) and the NSIS responder (NR) [4,5] CASP chain. 1.2 Protocol Properties CASP has the following properties: Layered: CASP is a layered protocol with two layers, the client and messaging layer. Each can be changed without affecting the other component. A separate discovery component H. Schulzrinne et. al. [Page 4] Internet Draft CASP September 15, 2002 determines the next CASP peer, which can be either the next router, following the data flow direction, or some other node. One example of the discovery component is the scout protocol, a CASP client protocol, that discovers the next CASP peer. CASP uses the services of a reliable transport protocol that provides sequenced, reliable, flow- and congestion- controlled message transport between two CASP nodes. The messaging layer provides state identification, peer-to-peer message routing and other functionality common across all client layers. The client layer contains the application- specific components. A single CASP messaging layer session can be used by multiple client states, to ensure that all client states are removed at the same time. As an example, active networking or firewall traversal state may be bound to QoS state. C state can only exist as long as the underlying M state exists. Network-friendly: While most signaling messages for classical signaling applications are likely to be small and the overall data volume modest, CASP recognizes that there are potential applications that may need to deliver larger volumes of data or larger packets. For example, instantiating active network nodes may require payloads that are significantly larger than typical network MTUs. Similarly, cryptographic signatures may cause even common signaling messages to exceed MTU size. Thus, CASP would have to deal with fragmentation if it were to implement its own reliability mechanism. Also, we believe that the total volume of signaling information between two nodes can be substantial, even if each signaling flow only contributes a message every few tens of seconds. For example, if we assume resource reservation for a VoIP application with 3-minute calls, four 500 byte signaling messages (for establishment and teardown and the responses), a 45 Mb/s access link could see about 64 kb/s of signaling traffic, which is a modest overhead relative to the useful application data (about 700 simultaneous calls), but still larger than many applications. Also, during overload situations, user applications will be tempted to retry their reservation requests frequently, so that congestion and flow control is desirable. H. Schulzrinne et. al. [Page 5] Internet Draft CASP September 15, 2002 Thus, instead of using its own retransmission mechanism for each session within the messaging layer, CASP establishes a soft-state peer session. Unlike in BGP, these are established on demand and can be torn down after periods of inactivity. Such sessions are likely to result in significantly improved performance for each signaling flow, since retransmission can use better estimates for round- trip times and can reduce the time to loss discovery to multiple packet spacings plus a one-way delay rather than a conservative estimate of the round-trip time. Given that almost all nodes will already have support for a transport protocol, this approach is likely to greatly reduce the complexity of protocol implementations and avoid subtle interoperability problems. Re-using peer sessions also reduces the number of cryptographic computations. Reusing an already established security association at the transport layer and possibly at the client layer avoids expensive security association establishment when a new connection is set up. TLS with session resuming (RFC 2246 [6]) can further reduce the impact of establishing a new transport association. In case of IPsec, SAs are valid for a given time period (if the SA lifetime is bound to a time duration and not to the number of transmitted bytes) and operates at a lower layer uneffected by TCP and SCTP connections. Thus, new CASP sessions will only very rarely suffer from delays caused by setting up a transport connection. (We expect that frequent session setup will only be necessary if a CASP node exchanges messages with several thousand or more peer nodes with equal frequency, so that maintaining transport sessions becomes infeasible.) Transport-neutral: CASP is transport-protocol neutral. Each peer could use a different transport protocol, with TCP and SCTP [7,8] as RECOMMENDED protocols. Using TCP and SCTP also allows it to use channel security for protection of messaging and client layer messages in a peer-to-peer mode and mutual-authentication via TLS. Note that IPsec can be deployed independent of any upper layer transport protocol. The messaging layer only assumes that the transport layer offers reliable, sequenced message or byte stream delivery with flow and congestion control. Use of TCP or SCTP does not necessarily make CASP NAT- friendly [9], since it carries network addresses by necessity. It may, however, simplify traversal of H. Schulzrinne et. al. [Page 6] Internet Draft CASP September 15, 2002 firewalls. Policy-neutral: CASP does not impose a particular AAA or usage policy, but can carry necessary information for AAA protocols such as DIAMETER [10] or public-key credentials in the messaging or client layer. (We make no claim that CASP can support all AAA architectures or support them equally well.) Soft state: CASP provides a generic soft-state mechanism that can be used by all client protocols. Soft state is only used for logical state, not to deal with packet loss. To maintain soft state, requests are simply resent periodically by each node. Refresh periods can vary among CASP nodes. Nodes can also remove state explicitly. Peer-to-Peer refresh was chosen to allow different choices by each administrator, e.g., to enforce uniform values within an autonomous system or to control resource usage. Non-uniform refresh intervals mean, however, that islands of state can persist. Also, dead applications need to be detected at the client layer. Extensible: CASP is extensible. It consists of a sequence of, possibly nested, type-length-value (TLV) objects. Extension objects can be added at any time. Protocol features are negotiated via feature negotiation, not as individual objects. This allows semantic negotiation such as "node X does not support mandatory feature Y" rather than low-level indications that some combination of objects is not supported. Nodes can add and modify objects. Cryptographically protected client-layer objects must not be modified or reordered. These digitally signed or encrypted objects can be recognized easily by their object identification to prevent accidental modification or reordering as described in Section 16. Signaling message security: CASP integrates security protection. The security mechanisms provide means to protect the different signaling messages in different portions of the network, including first-peer, intra and inter domain. They accomodate environments with varying security and performance requirements. Flow splitting: Some networks route packets differently depending on their flow labels or DSCP. Operators may want H. Schulzrinne et. al. [Page 7] Internet Draft CASP September 15, 2002 to treat signaling packets differently than the corresponding data packets. These two objectives may conflict since it may cause signaling packets to diverge from the data path. Because CASP is split into a signaling protocol and a discovery mechanism, CASP only needs to label the scout (discovery) packets in the same manner as the data packets, but can assign labels to signaling packets based on the handling needed for them. Topology hiding: Even in record-routing mode (Section 6), nodes can hide the addresses of nodes already visited by the message. A more detailed description of network topology hiding is given in 16.5. Light-weight: CASP is light-weight in terms of implementation complexity and message forwarding overhead. CASP is designed so that a forwarding implementation can be implemented with minimal effort, consisting of a socket listening for TCP connections, a next-peer lookup table and a state timer. In some cases, the messaging layer can be implemented in user space by non-privileged (non-"root") processes. Depending on the details of the traffic operation needed, the client layer may, however, require access to protected resources. The proposed security mechanisms try to reuse existing protocols to the extent possible. CASP has not been assigned a port yet; we assume that the port number will be above 512. Also, the M layer may require access to kernel data structures to determine the current network address, particularly for mobile hosts. Due to the re-use of transport connections, session setup latency is, on average, low. Once the authentication and key exchange protocol is finished signaling messages at the M layer can be protected efficiently. Mobility transparent: CASP interfaces with route change detection mechanisms; IP mobility is also treated as a route change case. CASP attempts to satisfy the NSIS requirements [4] and framework [5]. However, it also adds additional functionality, such as support for H. Schulzrinne et. al. [Page 8] Internet Draft CASP September 15, 2002 source-specific multicast (SSM) [11] and multiple discovery modes including edge-to-edge and AS routes. 2 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [12] and indicate requirement levels for compliant CASP implementations. 3 Definitions CASP node: Application that supports at least the CASP message layer. CASP chain: The collection of CASP nodes traversed by a CASP message from originator to destination. CASP session: The set of CASP messages that refer to the same state record, along a path of CASP nodes. All messages with the same session identifier belong to the same CASP session, regardless of the direction of travel. Downstream: Downstream refers to the direction of the data flow associated with the CASP session. Originator: The CASP node that sends the CASP message. State record: State (data) that is managed by CASP, located on each CASP node. There is both CASP state and client state. 4 Message Delivery Messages within a CASP session can be generated by the end points or by any intermediate point. An intermediate CASP node can sent a message when triggered by internal state changes, such as a routing change, or a timer expiration. In either case, messages traverse the remainder of the CASP nodes, unless they exhaust their node counter or reach the target IP address. At the messaging layer, CASP is not a request-response protocol, but rather a messaging protocol, i.e., it delivers messages along a path. Client layer applications can, however, send back responses that allow the originator to confirm that the initial message was delivered and to determine whether the operation was successful or encountered an error. This offers end-to-end reliability. The response message uses the existing transport associations in the H. Schulzrinne et. al. [Page 9] Internet Draft CASP September 15, 2002 reverse direction. At the message layer, such responses look the same as requests. CASP messages using a reliable transport protocol are not constrained in length (except by the CASP length field). They make use of the reliable delivery services offered by the transport layer. CASP scout messages are restricted to the path MTU. Soft-state refresh is performed by each node, using the algorithm described in Section 11. Refresh intervals are randomized around a nominal value provided by the originator. 5 Transport Protocol Usage For regular (non-scout) messages, CASP requires reliable, sequenced message delivery with flow and congestion control and can use any transport protocol that supports such a service. (Sequencing is only required for messages within a single CASP session.) Currently, SCTP [8] and TCP provide such services. If we had used a new protocol running directly on top of IP or UDP, we would have had to add much of the same functionality, essentially replicating a full-fledged transport protocol. We believe it is not safe to assume that all signaling messages are small and infrequent. Re- use of connections allows improved round-trip time estimation and amortizes the cost of establishing the connection and security association over many CASP sessions. There generally is only one lower-layer CASP transport connection between any two CASP nodes, regardless of the message and client layer. A CASP node MAY maintain a transport association with another node even if there is no current CASP session. The holding time of these transport connections is an implementation choice. A CASP node discovers the next CASP node for message delivery using any of the methods in Section 9 and then checks if there is an existing transport connection between these two nodes. If so, it sends the CASP message on that transport connection. If not, it establishes a new connection. It is assumed that transport connections are bidirectional, so that response messages can reuse existing transport connections. However, a response message may also establish a new connection if there is no existing one (e.g., after a reboot of the node to be contacted). CASP scout messages can, by their nature, not use an existing H. Schulzrinne et. al. [Page 10] Internet Draft CASP September 15, 2002 transport connection. They are transmitted by the origin towards the network-layer destination, marked with the IP router alert option [13,14]. The originator of a scout message retransmits the message with exponentially increasing time intervals until a response is received, a maximum number of retransmission attempts is reached or an ICMP error message indicates that the destination host or network is unreachable. For each destination and client layer, there can only be one scout message outstanding. Note that a scout message typically does not reach the IP destination address contained in the IP header. 6 Message Forwarding CASP messages can be routed either statefully or statelessly. This generality avoids the strict request-response mechanisms found in other protocols. A message has two routing and state fields that determine forwarding behavior: Destination: The destination flag can have five values: "address" (A), "address+record' (AR), "route" (R), "state forward" (SF) and "state backward" (SB). In "address" mode, each node determines the next CASP node within the chain by looking at the destination address object. In "address+route" mode, it also records the local IP address, transport mechanism and port for future CASP messages, using RecordRoute objects. In "route" mode, the node uses the embedded Route object to find the next location. In "state forward" mode, the node forwards the message in the direction of the initial message that established the CASP session. In "state backward" mode, the message is sent towards the previous CASP node. For the "state forward" and "state backward" modes, nodes fall back to "address" mode if there is no state record. This can occur after route changes. State: The state flag can indicate three operations: "no-op" (NOOP), "add" (ADD), "delete" (DEL). The operations manipulate message layer state. With "no-op", the node does not establish any state. ADD establishes state and DEL deletes the state record. All messages within a CASP session should use the ADD operation. Deleting the state record deletes all client states. The NOOP message is meant for messages that should not establish state. In SF and SB modes, the CASP node only inspects the CASP session identifier and then routes the message according to the stored next- H. Schulzrinne et. al. [Page 11] Internet Draft CASP September 15, 2002 node or previous-node information. Error responses typically contain the "delete" flag and one or more error description objects (see below). They can be routed in "state backward" mode. The origination of CASP messages does not imply that the client protocol has to follow the same direction. For example, in a receiver-oriented QoS protocol, the recipient of the CASP request, sent in "SF/ADD" mode, would return a "SB/ADD" message containing the reservation data. 7 Message Format Unlike most other protocols, CASP does not have requests and responses. Rather, it is based on messages that can make use of state established or paths discovered earlier, traversing such paths in either the original sequence of nodes or the reverse. The CASP message and its components are type-length-value objects, making it possible to use the messages directly with stream-based protocols such as TCP, without having to add an encapsulation layer. The client protocol is encapsulated in one such object, so that no IPv6-style "next protocol" identifier is needed in the common message part. The objects within a CASP message can appear in any order, except that the first object is the message identifier and the final object in each CASP message is the CASP client payload. The order of objects has no semantic signficance. There can be at most one client payload in each message; the client payload is optional. (For example, a CASP node discovery or "traceroute" message may not need a client payload.) CASP nodes can insert and modify certain objects. The design of objects should separate data that is modifiable from end-to-end constant data, to simplify object signing. CASP nodes do not reorder objects; new objects are added at the end of the message. Restricting CASP messages to one client layer message simplifies error reporting and reduces the number of failure scenarios. Destination flag: Governs the determination of the next node. See Section 6. State flag: Governs state establishment and teardown, with the H. Schulzrinne et. al. [Page 12] Internet Draft CASP September 15, 2002 values ADD, DEL and NOOP. See Section 6. Session identifier: The session identifier describes a CASP session, a set of CASP messages that belong together and refer to the same state. It allows subsequent messages that belong together to add, modify or delete existing state information. The special value of zero indicates that this message neither refers to existing state nor establishes state. The session identifier is a random number with 128-bits in length. The length of this value is motivated to prevent collisions since it has to be globally unique for a given path. Thus, messages that have different CASP origin and destination addresses still belong to the same CASP session if they share a session identifier. Security issues related with this session identifier are described in Section 11 and in 16. As motivated in Section 11 it is important to have some sort of identifier which is not based on a network layer address or a combination of it. A globally unique session identifier that is independent of the origin and destination addresses makes it easy for nodes in the middle of the CASP chain to generate messages that only traverse part of the chain. Flow identification: The flow identification (or descriptor) contains fields that assist in the identification of traffic (data packets) which receive treatment by the client-layer protocol. The client layer determines what action is taken for packets matching the flow identification. In case of a QoS reservation client layer the flow identification determines which data packets experience preferential treatment. It therefore maps individual incoming packets to a given QoS class. Depending on the given flow identification values the effect could be a per-flow treatment or a more broad selection of data traffic. Currently, the following fields should be supported: source, destination IP address, port numbers, transport protocol, flow label (for example described in [15]), destination address options (such as the home address), the SPI (which is motivated in [16]), DiffServ code point (DSCP) and VPN tunnel identifiers. A CASP message can contain multiple flow descriptors which might be useful in case of SCTP or for specifying H. Schulzrinne et. al. [Page 13] Internet Draft CASP September 15, 2002 individual flow identifiers which cannot be combined into a single one (e.g. traffic of several non-continuous port regions). A flow identifier should allow ranges of ports to be specified as described in Section 7.13.1 of [17]. The usage of flow identifier stacking was considered but requires further investigations. An application for TSEL stacking would allow reservations for tunnels where the ingress node adds a new flow identifier to a stack knowing that the new traffic selector is useful only for a particular region. The original traffic selector is restored at the egress node. IPv4-to-IPv6 translation is an example of such a flow selector stacking. The flow identifier is included in the common part of a CASP message so that NATs and firewalls can inspect and possibly modify this data. Flow identifiers can change mid-session and mid-chain. Message sequence number: A 32-bit integer that uniquely identifies the message. (Retransmissions are not seen at the message layer.) Each origin issues messages with sequence numbers that increase by one for each message. Message sequence numbers are assigned consecutively by each origin within a CASP session. Sequence numbers are not reset if the transport connection is re-established in mid-session. Sequence numbers are relative to each origin so that intermediate nodes can issue messages without conflicting with the sequence numbers chosen by other nodes in the chain. Origin: The network source address corresponding to the origin of the message; an IPv4 or IPv6 address. Each network source address has its own sequence number space. The network source address does not imply that the data traffic has this origin or destination. Target: The target field indicates the destination IP address to which data packets are later sent. It is used to route the signaling messages along the same path as used by later data packets. Message destination: This field contains either the destination address of the message or a scope flag. The address H. Schulzrinne et. al. [Page 14] Internet Draft CASP September 15, 2002 indicates how far the message should travel; if it reaches the destination named, the CASP chain ends. The address MAY, but does not have to, correspond to the target address. It will be different if the message traverse only part of the path for the CASP session. The message destination address does not have to correspond to the address contained in the flow identifier. For example, for proxied CASP session, they will differ. The scope flag indicates that the CASP chain should terminate at the boundary of the (administrative) scope [18]. For simplicity, only a single scope is supported, rather than, say, nested scopes. This reflects the typical intra/interdomain division or the division between a local network and "the Internet". NodesLeft: To prevent message loops, the NodesLeft counter is decremented by each CASP node and the message is not forwarded if the counter reaches zero. A suitable "node count exceeded" message is returned to the originator if the counter reaches zero. This also allows messages to only traverse parts of a chain of CASP nodes. Other mechanisms are used to restrict the forwarding of CASP messages by scope or address. Lifetime: If this message establishes state, the Lifetime field determines how long the message soft state is to be kept by each node if there is no additional CASP message. The life time is established in an ADD message and can be updated with ADD messages. (NOOP messages do not refer to state and thus there is no lifetime.) Any client state expires with the message state, but client lifetime can be smaller than the message layer session lifetime. State is refreshed node-by-node and may differ at each node. Thus, this value can be adjusted along the CASP chain. Dead branch removal flag: Governs whether to remove the CASP states in the detected dead route. See Section 11. Branch identifier: The branch identifier is a randomly chosen integer that identifies a particular branch. See Section 11 for details. H. Schulzrinne et. al. [Page 15] Internet Draft CASP September 15, 2002 There is no message type, since each client protocol, including the scout protocol, identifies its own message types in the client object. In addition, there are a number of optional objects: Record route: The Record route object is filled with the network addresses of CASP nodes that this message has visited. Route: The Route object enumerates the addresses of nodes that the message should visit, along with a pointer that indicates the next node. [TBD: Addresses could be simply removed by the visited nodes, simplifying network topology hiding, but making error diagnosis harder.] 8 Capability Negotiation The CASP capability discovery model relies on named capabilities. Capabilities are named by 16-bit unsigned integers. The value 0 is reserved and not used for any capability. Client protocols are registered as capability values. Client protocols need to negotiate their own capabilities, possibly using the same mechanism and data structures. The originator can discover capabilities by including a CapDiscovery object in the request. The object has a list of capabilities and counters. Each node that supports a capability increments the counter for that capability. In addition, an overall node count allows to estimate the fraction of nodes supporting a particular feature. If more detail is desired, the CapRecord object records the address of each node and its list of capabilities. A CapRequired object enumerates the capabilities that are required. These capabilities are used in the discovery phase. A scout message will traverse nodes that do not meet these capabilities and be reflected back to its source by the first node that can satisfy all requirements. If there are multiple CapRequired objects, it is sufficient if the node satisfies the conditions in one of them. Unlike other protocols, CASP does not label individual objects as being mandatory-to-understand or optional. Instead, it identifies certain behaviors that may well rely on a set of objects. Each behavior needs certain types of objects and ignores all others. This makes it easy to define behaviors that require one of N objects. H. Schulzrinne et. al. [Page 16] Internet Draft CASP September 15, 2002 9 Next-Node Discovery There are two basic types of CASP nodes, depending on how close they are to the data path. In next-in-path (Section 9.1), each CASP node attempts to discover the next router along the data path that is CASP-aware. In next-AS mode (Section 9.2), there is one (logical) CASP server for each autonomous system and data packets and CASP requests visit the same AS, but not necessarily the same routers. Other paths, such as scopes [19], are possible, but harder to define as a sequence and will not be considered here. (Scopes are, however, important to limit the propagation of CASP messages.) 9.1 Next-in-Path Service The problem of disccovering the next-in-path CASP node can be divided into an intra-domain and inter-domain component. The intra-domain problem can be split into two parts, namely discovering all CASP nodes within a local domain and determining which of these is visited next on the data path. Determining the next node in an adjacent domain (inter-domain) is more difficult. It would greatly simplify the problem if all border routers are CASP-aware. The scout protocol (see below) can locate the next node both within and beyond the local domain. For discovering CASP-aware nodes within a domain, a number of methods can be envisioned: Enhanced routing protocols: It may be possible to extend routing protocols to distribute information about CASP-capable routers to the local routing domain. For example, OSPF [20] could indicate this capability via an Options bit in the common LSA header or a new LSA. A new LSA is needed if capabilities are to be advertised. A CASP node then computes the route based on the CASP request destination address and determines the next CASP-aware node. Routing protocol with probing: Since the identity of CASP-aware nodes is unlikely to change quickly, a CASP node can attempt to contact routers along the path of the request and cache both positive and negative results. Thus, each CASP node will build up a list of the CASP-capabilities of the local domain and can then determine the next CASP node as above. Service discovery: Using standard service discovery mechanisms such as SLP [21], CASP nodes can find out about local CASP nodes and their capabilities. H. Schulzrinne et. al. [Page 17] Internet Draft CASP September 15, 2002 First node: By adding an option to router advertisements [22], local nodes can discover the first CASP node in their path. DHCP: If there is a single CASP node in a local network, DHCP [23] can advertise this node. For inter-domain discovery, it may be possible to add information to BGP advertisements. For next-in-path service, the node wishing to send a CASP message performs the following steps: 1. Determine address N of next CASP node for the destination IP address, using routing table inspection or a scout message. 2. If there already is a transport association with N, send message on that transport association. Done. 3. If not, send a scout message towards the network-layer destination. The first CASP node capable of handling the message responds and includes its IP address in the response. The origin checks whether there is an existing transport association and proceeds as before. The mechanism above works well if the next router in the data path is CASP-capable, as the number of such routers is likely to be modest. If that is not the case, the origin has to send an exploration packet for each new signaling session, since a node cannot generally determine the next CASP node by inspecting the destination address. 9.2 Next AS Service CASP messages can be routed so that they "touch down" once per autonomous system (AS), e.g., for a bandwidth-broker service. In this model, each AS has a logical server, possibly consisting of many physical servers, that provide service for a particular CASP client protocol. One mechanism to find an instance of this server is to create a new, per AS, DNS namespace, such as ASN.as.arpa, where ASN is the AS number. DNS NAPTR [24] queries are then used to determine a suitable server for the AS, using the services "CASP+D2X" and "CASPS+D2X", where X is a letter that corresponds to the the transport protocol This specification defines D2U for UDP, D2T for TCP, and D2S for SCTP. Thus, for example, the NAPTR [24] record 17.as.arpa would identify the CASP service in AS 17. Each NAPTR record in turn points to an SRV record, for coarse-grained redundancy and load balancing. H. Schulzrinne et. al. [Page 18] Internet Draft CASP September 15, 2002 This approach has the advantage that an AS can designate different server clusters for different CASP services. Also, it facilitates discovery. This approach is only necessary if the BGP peers for a domain do not speak CASP. Otherwise, they can route and process CASP messages as needed. 10 Scout Protocol The scout protocol is a specialized client protocol for CASP, having a relationship to the main protocol somewhat similar to control protocols like ICMP, IGMP and RTCP [25]. It is used to discover the next suitable CASP node and the required soft-state refresh interval. Scout messages are only required if the next CASP node is more than one network-layer hop away (Section 9) and if there is no other suitable means of discovering the next CASP node. (Other mechanisms are preferred if available since they incur lower overhead and delay.) Each CASP node that needs to discover the next node "triggers" a scout message that generates a response indicating the next node. Scout messages use the cap_required capability negotiation mechanism to find a suitable node (Section 8). Scout messages also return the session lifetime desired by the next node. Scout messages are UDP packets containing a subset of the CASP message layer, a small client layer and the IP router alert option [13,14]. There are scout requests and responses that follow the usual UDP request-response pattern of reversing source and destination address and ports. Scout requests have an IP destination address set to the target address of the triggering CASP request. Each CASP node that needs to determine the next node issues a scout request. An omnivorous CASP node always returns a scout response message. A selective CASP node checks if it supports the client protocol and other features named in the scout message. If so, it responds with a scout response message addressed to the packet's source address and port. The scout response contains an address record that describes how the CASP node can be reached, i.e., its IP address, the protocols supported and their ports. If not, the scout message is forwarded like a normal UDP/IP packet. The target node always turns around the scout message. TBD: It may be possible to use ICMP instead of UDP, with a new ICMP message type. H. Schulzrinne et. al. [Page 19] Internet Draft CASP September 15, 2002 Scout messages have their own reliability mechanism. They are retransmitted periodically, with exponentially increasing retransmission interval, starting at 500 ms. Scout messages are strictly limited in size to one MTU. They are kept small by only including the common header and a nonce. Requests contain one 64-bit cryptographically random nonce; responses echo that nonce and include an additional random nonce. Responses contain the node's desired lifetime and capability vector, including the security capabilities. Since they do not establish sessions, the sequence number fields in scout messages is zero. Scout messages can estimate the number of non-CASP IP nodes between two nodes by comparing the original IP TTL value to the one received by the next node. The original TTL value, if known, is included in the scout client message. Scout messages transport identity and capability information which are security sensitive, as described in Section 16). Also, an attacker can mislead a node into contacting the wrong next CASP node. We define two nonces that protect against these attacks. The first nonce, InitiatorNonce, is in the scout client layer and is echoed by the target node. That prevents attackers that are not privy to the request from impersonating a CASP node. It does not prevent an attacker that can intercept the scout request from returning a bogus response. The ScoutCheck object in the scout response deals with this latter threat. The ScoutCheck allows the next CASP node to detect if it is receiving a request that was preceded by a scout request. The ScoutCheck object contains the InitiatorNonce and a quantity computed by the next CASP node. The method used for computing this quantity is implementation-defined; one possibility is a hash across a secret known to the next node only and the InitiatorNonce. To reduce the threat of such denial-of-service attacks, CASP nodes SHOULD listen for all scout responses. (TBD: If a CASP node responds to all such answers, this would introduce an amplification attack, but this only occurs for attackers that can intercept messages, not random Internet hosts.) 11 Route Change and Mobility CASP adapts to route changes and node mobility. It supports fast release of state on the old data paths that is no longer needed. There are two cases: Observed: The next CASP node is also the next IP router. In that case, the CASP node can observe changes in the local routing table and detect that the next-hop router for a H. Schulzrinne et. al. [Page 20] Internet Draft CASP September 15, 2002 particular set of destinations has changed. If such a change occurs, the node triggers the discovery process (Section 9) to locate the new CASP node. Refresh: CASP sessions are refreshed periodically end-to-end. Even if there was no change in the routing table, each CASP node has to perform the discovery process for each such message since it has no way of knowing whether the old next next CASP node is still correct. If a CASP node sends a message to a CASP node that differs from the existing next node for a session, that node becomes a branch point. When a node receives a CASP message for an existing session, but with a different IP source address, i.e., a different previous node, it deduces that it is the merge point after a route change. The merge point then performs dead-branch removal iff the dead-branch removal flag is set, removing CASP state on nodes that are no longer on the data path. The merge point, M, creates a DEL message and sends it to the old previous node. The CASP origin is set to M, the CASP destination of the message to the origin of the message that triggered the dead-branch removal. Having the merge point perform dead branch removal avoids that state is removed before new state is installed. We define a branch identifier that is incremented at each node if a node sends a CASP message to a new next node for a given session. Branch identifiers are defined within a session only. TBD: Alternatively, the branch node could insert its address, but this works less well for mobile systems or for systems with addresses that are not globally unique. Mobility is regarded as a special case of route change in CASP processing, i.e., the mobile node (source or destination) is the node which detects the route change. Figure 2 shows an example of a route change. The old path traverses the CASP nodes N1, N2, N3, and N6, while the new path traverses N4 and N5. N1 is the branch point, N6 the merge point. The notation "B=" refers to the branch identifier. N6 detects that it is a branch point and sends back a DEL message on the old branch, but using the new branch identifier (B=2). N2 and N3 simply delete the old state; N1 recognizes that it generated the new branch and thus can terminate the DEL. H. Schulzrinne et. al. [Page 21] Internet Draft CASP September 15, 2002 <-DEL(B=2)- +----+ +----+ --- | N2 | -- | N3 | -- / +----+ +----+ /B=1 old route / +-----+ B=1 +----+ +----+ +-----+ | S | -- > --| N1 | | N6 |-----| D | +-----+ +----+ +----+ +-----+ / B=2 / +----+ +----+ / --- | N4 | -- | N5 | -- +----+ +----+ new route -ADD-> Figure 2: Route Change 12 Multicast Support CASP supports source-specific multicast (SSM) service model [11], which allows one-to-many group communications. This can be achieved by a special scout message for SSM multicast. If a node receives or initiates a CASP message intended for an SSM multicast group, it sends a scout message towards the SSM destination. The source and destination of this scout message should be set (e.g., via raw socket) as the SSM source S and the destination G, respectively. Also, the actual address of this CASP node should be included in the scout message so that a CASP node receiving the scout message can reply to the right address. There are two possibilities to do this: either use origin object in scout message, or introduce an optional scout-sender object. This scout message can detect new and old branch(es), thus CASP transport association along the source-specific multicast tree can be created, updated or removed. If an SSM multicast routing entry (S, G) is created in an SSM-enabled node, only messages with source address S and destination address G can be forwarded according to this entry. H. Schulzrinne et. al. [Page 22] Internet Draft CASP September 15, 2002 In case the multicast routing next hop is CASP-aware, it is possible to speed up the process by inspecting the IP multicast routing next hop table as defined in the IP multicast MIB [26,27]. 1. If all the next hop addresses have an associated CASP state, done. 2. If a next hop has not yet CASP transport association (i.e., pruning a new branch), it sends an "SF/ADD" message to the next hop in this branch to create a new CASP transport association. 3. If a next hop was previously in the next hop table, but currently not any more, it sends an "SF/DEL" message toward this next hop to release the the unnecessary CASP transport association due to dynamic receiver membership. Typically, multicast support replies on the special scout message in addition to similar mechanisms that handle route changes (Section 11). 13 CASP over Tunnels The authors of [28] identified three types of tunnels. These tunnels are differentiated whether they support QoS reservation and to which degree (per-flow allocated resources within the tunnel or non-flow allocated resources). CASP tunnel operation as described in this document is independent of the C layer operation. The implication of tunnels is therefore that they modify routing and they might require modification to the traffic selector since information like ports and transport protocols are hidden. Unlike RSVP only the scout protocol uses a router alert option. A CASP aware ingress node can therefore decide whether to hide the router alert option. In case that the router alert option is hidden then the egress node is the next discovered CASP peer (assuming the egress node is CASP aware). Otherwise other CASP nodes along the tunneled region can be discovered as well. CASP can operate over any types of tunnels (for example IPsec, IP- in-IP, IPv4/IPv6) if both ingress node and egress node of a tunnel support CASP. In case that CASP is not supported at these nodes then the CASP messages are hidden inside the tunnel region. The scout messages then do not discover CASP nodes inside the tunneled region because of the IP encapsulation of the router alert option. Tunnels similar to those used in micro- and macro-mobility schemes where tunneling affects the traffic of a single host only (i.e. H. Schulzrinne et. al. [Page 23] Internet Draft CASP September 15, 2002 where the end-host usually participates in tunnel establishment and termination) are covered by CASP in the following way: A modification to routing (based on the establishment of a tunnel for example because of route optimization in Mobile IP) might require adaptation of the traffic selector along the path (or at parts). The same is true when (possibly nested) IPSec tunnels are used along the path to protect data traffic. Traffic selectors need to reflect the different traffic classification possibilities at various locations along the path. A careful selection of traffic selectors might therefore help not to require adjustments of state established along the path when changes in routing happen. 14 Protocol Heritage CASP attempts to borrow concepts and ideas that have worked well in other application and network-layer signaling protocols. Examples include: o The message format and the use of router alert options in scout messages is similar to RSVP [29]. However, CASP differs from RSVP in having a clearer layering and avoids the complexities of implementing components of a transport protocol [30]. Multicast support is offered for source-specific multicast (SSM) [11], without the complexity of reservation styles [31], receiver diversity and maintaining multiple multicast sink trees in the signaling protocol. o The notion of separating delivery and application was first explored by CSTP [2]. o The feature negotation approach borrows from RTSP [32] and SIP [33]. o The notion of messaging is also explored in BEEP [34]. 15 IANA Considerations A future version of the document will include IANA considerations for object types, client protocols and port numbers for the CASP protocol. 16 CASP Security This section addresses various security issues of the CASP protocol with some background information and possible options. Additionally some threat-specific details are explained which are not yet covered H. Schulzrinne et. al. [Page 24] Internet Draft CASP September 15, 2002 or not described in detail in [35]. Many of the protection mechanisms described are based on what was learned when investigating security mechanisms in RSVP as described in [36]. The content of this section is organized as follows. The first paragraph investigates the scout protocol security. The next two paragraphs focus on securing the transport of signaling messages at various places in the network and the session (or reservation) ownership problem. Next a description of the CMS [37] usage for the client-layer is provided. Finally a miscellaneous issues section addresses security features which are somewhat independent of the previous sections and could also be entitled as framework security topics. Some of these security topics are not directly applicable for securing the CASP protocol itself but try to highlight the interaction with other protocols. The CASP protocol is designed not to rule out interactions with some other protocols or deployment within some non-standard architectures. A summary of this fairly detailed section is given in security considerations section for the impatient reader. 16.1 Scout Messages Problem-Description: The task of bootstrapping a node with configuration information is an important and security relevant task. CASP relies on a number of mechanisms for discovering the next CASP-aware peer. As described in Section 9 additionally to learning the identity of the next peer some capability information is provided. Every of the proposed protocols for distributing information is therefore vulnerable to similar attacks. This section however is mainly focused on the description of threats and the security of scout messages since the mechanisms is different to what is used for learning (or distributing) configuration information in general. A description of the vulnerabilities created by using other protocols like DHCP, Router Advertisements, etc. might be included in a future version of this document. The main purpose of scout messages is to discover the next CASP-aware network element with a certain capability along the path. Since a scout message uses the router alert option mechanism it follows the data path by using the destination address of the IP packet as the endpoint destination address. As such it is not helpful to include a keyed message digest (or a similar cryptographic protection H. Schulzrinne et. al. [Page 25] Internet Draft CASP September 15, 2002 based on symmetric keys) already to the outgoing message since the identity of the receiving node is unknown. Using public key based cryptography (for example a digital signature) to protect the outgoing scout message could be used by an adversary to mount denial of service attacks against CASP-aware nodes. Nothing prevents an adversary from transmitting millions of bogus scout messages to a CASP node and to force heavy cryptographic processing for verification. Note that it would be possible to include a digital signature to the response to provide identity information of the responder in a cryptographic protected manner. Using such a mechanism could however easily be used as a denial of service attack. Scout messages are continuously transmitted from the initiator towards the destination address to react on route changes (if no other configuration mechanism is used). Protecting scout messages which are sent towards the destination address knowing that they will hit a known CASP peer security protection is possible. However such a protection is not particularly useful since the scout reply messages of interest are those that indicate a path change. These scout messages hit a new CASP-aware router which returns among some other information its identity as described in Section 9 and in 4. Threat 1: Downgrading Attack: Security relevant information included in the scout message for example is the identity of the next CASP-aware network device, supported security mechanisms (namely IPSec, TLS and EAP as described in this document) and other capabilities. In case of IPSec various key mangement protocols can be supported and also have to be indicated. Downgrading attacks are therefore easily possible when no protected negotiation takes place. Threat 2: Man-in-the-Middle: An adversary might want to inject a bogus reply message forcing the scout message initiator to start a transport layer connection and the corresponding security association establishment. Figure 3 describes the attack in more detail. Figure 3: Man-in-the-Middle Attack H. Schulzrinne et. al. [Page 26] Internet Draft CASP September 15, 2002 +-----------+ | adversary | transport layer connection +--->+ +<----------------+ (4) transport | +----+------+ | layer | IPx | | connection | |scout reply v (3) | | (IPx) +---+-------+ v | (2) | Access | +------+-----+ | /----------->+ Router +-------- | scout msg +<--+ / scout +-----------+ | initiator +---------/ request IPr +------------+ (1) IPi This attack assumes that the adversary is able to eavesdrop the initial scout message sent by the scout message initiator, for example by a mobile node. A MITM-attack does not require that the first-hop router is CASP aware. There is no particular restriction to the placement of CASP-aware nodes within the network. Furthermore we assume that the scout reply message by the adversary returns to the scout message initiator faster than the real response. This represents some race condition characteristics if the next CASP aware node is very close (in IP-hop terms) to the initiator. As shown in message step (2) in Fig. 3 the adversary returns a scout reply message with its own IP address as the next CASP aware node along the path. Without any additional information the scout message initiator has to trust this information. Then a transport layer connection is established with IPx (i.e. with the adversary) in step (3). The adversary then establishes a transport layer connection with the "real" next CASP aware node (in Fig. 3 with the Access Router). As a variant of this attack an adversary not able to eavesdrop transmitted scout requests could flood a node with bogus scout reply messages. In the scout message sender accidentally accepts one of those bogus messages then a MITM-attack as described in figure 3 is possible. Threat 3: Bogus Reply: An other threat which would disturb the protocol behavior H. Schulzrinne et. al. [Page 27] Internet Draft CASP September 15, 2002 and would serve as a sort of denial of service attack is the following: An adversary might return a bogus scout reply message indicating a different identity which is still legimate CASP node (but not the first CASP node). The scout message initiator would then establish a transport layer connection with the wrong node. One of the possible consequences is that data traffic might not experience proper QoS treatment (in case that a QoS client layer is used) since signaling message establish state not along the data traffic. It would be very difficult for both nodes to discover this type of attack without any precautions. An other variant of this attack is the following. An adversary returns a bogus Scout-reply message to convince a CASP node to establish a new connection with a different CASP node although the previous connection is still valid. Proposed Security Protection: Providing iron-clad security protection for scout messages is difficult. Since they provide information to the initiator of the scout message to which node to start the establishment of a transport layer and security association establishment some threats are possible. - As part of the security association setup process at the M layer authentication and authorization has to be provided. Authentication and authorization prevent identity spoofing and MITM attacks. - To prevent downgrading attacks the information exchanged at the scout protocol is repeated later at the messaging layer to verify the exchanged information. Since signaling messages have to be protected this mechanism allows to detect a downgrading attack. It assumes that the downgraded security mechanisms (because modified by an adversary) provides the necessary security for detecting the modification. An adversary would therefore have to break the chosen security mechanism in realtime in order not to be discovered. This approach is somewhat similar to the protocol exchange provided in [38]. Downgrading to no security protection must not be possible since various attacks could be mounted against the CASP signaling protocol even if separate protection at the client layer via CMS is provided. - To prevent bogus replies and MITM attacks in addition to H. Schulzrinne et. al. [Page 28] Internet Draft CASP September 15, 2002 authentication and authorization two cookie values are used (Cookie(i) and Cookie(r)). - A scout request message contains a Cookie value (Cookie(i)) which is a 64-bit random number to match replies with requests. Including Cookie(i) also in the reply message prevents adversaries from accidentally accepting a bogus scout reply message from an adversary. - A scout response message contains the second Cookie value (Cookie(r)) with the same length which servers functionality similar as used in Mobile IPv6 [39] (for securing the binding update between the mobile node and the corresponding node). A Cookie field with variable length would be required when the Cookie contains encrypted fields (such as Cookie(i)) instead of a keyed message digest algorithm. In any case no per-session state should be stored at the scout message responder when receiving the initial scout message. In order to prevent MITM and bogus replay type of attacks the exchanged information (or some parts of it) might be included in the computation of a keyed hash or encrypted with a locally known key. - Both cookie values are included later in the protected signaling message exchange. When receiving the Cookie value a verification at the responder is possible. If an adversary injects bogus reply messages then a verification step would immediately fail since the new CASP responder would detect the attack when verifying Cookie(r). Since the Cookie(r) value has to be verified only locally its structure is mostly implementation specific. One suggestion for creating this cryptographic cookie would be to use Cookie(r)=Encrypt(local Cookie(i)) in case of encryption or key, Cookie(r)=HMAC-MD5(local ScoutRequestMsg||ScoutReplyMsg) in case of a keyed integrity algorithm. Note that the values used inside the cookie have to be repeated later to support the verification. The time interval for changing the local host key (local ) is policy dependent. key - To prevent the variant of the bogus reply attack whereby an adversary wants the scout message sender to create a H. Schulzrinne et. al. [Page 29] Internet Draft CASP September 15, 2002 new transport layer connection to tear down the old but still valid connection the following counter-measure is necessary. The establishment of a new connection (in replacement to an existing one) must be successful before a tear down of the previous connection takes place. 16.2 Securing the Transport and Messaging Layers The security protection of signaling messages at the messaging layer can be classified into authentication, integrity and replay protection. Providing proper data origin authentication, integrity and replay protection is required as motivated in [4] and in [35]. As a difference to the security provided in RSVP [40] the support for authentication and key establishment protocols should be integrated at the early beginning of the protocol. TCP and SCTP are the main protocols for exchanging signaling message content. It is therefore useful to reuse existing security protocols to protect the integrity of signaling messages. In case of TCP and SCTP a good choice is TLS providing both session key establishment based on unilateral and optionally mutual public key based authentication as described in [6]. Additionally support for Kerberos as described in [41] is available although rarely used. This is primarily because of the dominance of public key based server-to- client authentication in the web environment. As an alternative IPSec [42,43] can be used to secure CASP signaling messages (not including the scout messages) at the network layer. IPSec allows a separation between the key exchange protocol and the actual protection of data packets. IPSec AH and IPSec ESP provide protection of IP packets whereas various key exchange protocols may be used to establish the required IPSec SAs. IKE [44] is the default key management but also KINK [45] and in the near future SON-of-IKE ([17], [46]) can be used. These authentication and key exchange protocols allow some room for adaptation to particular environments with different trust relationships. Establishing security associations for protecting signaling messages at different parts of the network is however difficult. Hence the following subsections describe the security issues at each part of the network. First-Peer Communication: First-peer communication refers to the communication between the originator of the signaling message and the edge router in the attached network. In most mobility scenarios the signaling messages are initiated by (or terminate at) the mobile node. The signaling messages when entering the visiting network (i.e. access network) are intercepted most likely at the edge. H. Schulzrinne et. al. [Page 30] Internet Draft CASP September 15, 2002 The protection of first-peer communication is probably the most difficult for a number of reasons. First there is lack of trust between the initiator and the first network. This requires special care for authentication and more difficulties in session key establishment. Next there is a need to support a larger number of authentication and session key establishment protocols. Different usage scenarios for CASP require support for a particular authentication mechanism and a smooth integration into the existing infrastructure. Furthermore there are both performance limitations that exclude one or the other authentication and session key establishment protocol. In the following text the advantages and disadvantages of using TLS and IPSec for protecting signaling messages are described. When considering possible difficulties listed in the above paragraph then the problem of securing the signaling messages can be separated into two parts. The first part is the actual protection of the messages similar to what is known from the TLS Record Layer or from IPSec ESP/AH. The protocols either add a keyed message digest or encrypt the message and add replay protection (based on sequence numbers) to it to protect the messages from eavesdropping (only in case of confidentiality protection) and from modification. The TLS Handshake Layer provides session key establishment, unilateral and optionally mutual authentication. Although TLS offers client to server authentication as an option we suggest running EAP [47] on top of TLS whereby the EAP exchange is protected by TLS to support client to visited network authentication. Note that the approach taken to secure CASP is different to the approaches suggested to protect the EAP message exchange with TLS (see [48] and [49]). The main motivation for choosing this approach is to make use of an existing protection mechanisms as provided by the TLS Record Layer. Issues regarding session resuming as described in Section 4.2 of [49] are however applicable also in this context. Additionally the usage of [50] for including OCSP [51] protocol information within the TLS protocol for the purpose of certificate validation might also be useful in this context as described in Section 4.3 of [49]. The decision to protect EAP with TLS was therefore not done for protection of EAP message payloads or for H. Schulzrinne et. al. [Page 31] Internet Draft CASP September 15, 2002 providing client identity protection in mobile environments. Nearly all EAP mechanisms do not require confidentiality protection of the EAP message exchange itself. Even though some EAP mechanisms allow the distribution of a session key there is currently no support for a protection mechanism at the transport layer similar to the modular IPSec approach where the key management is separated from the actual data protection mechanisms. Using the fresh session key distributed with AAA (based on some EAP methods) could for example be used to trigger IKE with pre-shared secret authentication mode. Using the EAP distributed keys immediately (without running IKE) for creating IPSec SAs is not possible since information of IKE Phase II (IPSec SA negotiation) is missing. When using TLS we believe that a non-public key based client-to-visited network authentication mechanism is required since not every client is supposed to support client certificates. Using mutual public key based authentication requires a widely deployed PKI. We think that a requirement for a global PKI would put a large burden on the deployment of a protocol. An additional motivation for supporting EAP to support authentication from the client-to-visited network is that a previously established session key can be reused and local authentication to the local AAA server is executed. In future versions of this document message flows and suggestions for EAP authentication methods will be given. Support for IPSec-based protection with IKE or similar to establish an IPSec SA to protect signaling messages between the CASP peers requires interaction between the CASP implementation and the key management daemon. First there needs to be an interface to trigger the dynamic creation and modification of IPSec security associations (such as provided by PF_KEY [52]). Since protection is necessary for the CASP signaling messages only the IPSec security policy database should be able to install traffic selectors with a granularity at protocol type (TCP, SCTP) and specific port numbers. Additionally there is a need to fetch the credentials used at the key management protocol for the purpose of policy based admission control and accounting. Using TLS these tasks are easy since these APIs are available and widely used for example comparing the identity used in a certificate and the URL at a TLS- supporting web browser. We believe that the protection of the transport layer and messaging layer and a separate H. Schulzrinne et. al. [Page 32] Internet Draft CASP September 15, 2002 protection at the client layer for the purpose of "identity representation" [53] as done in RSVP might not be required in most scenarios. This is especially true if both mechanisms terminate at the same endpoint. Intra-Domain Communication: Protecting signaling messages within a single administrative domain is simpler because of the strong trust assumptions, simplified key management and rare network topology changes. Both TLS and IPSec would satisfy the requirements for protecting signaling messages in on a peer-to-peer basis. For key management both pre- shared secret (IKE, main or aggressive mode with pre-shared secret authentication), Kerberos (KINK [45], Kerberos support for TLS [41]) and public key based key management (IKE, SON-of-IKE, TLS) are available. The variety of key exchange protocols gives administrators a large degree of freedom. Inter-Domain Communication: For inter-domain communication again TLS and IPSec can be used. The only difference is the more difficult key management which might demand a public key infrastructure used between the network operators. End-to-End Security: At the messaging layer no end-to-end security (encryption or integrity) of the signaling messages is provided. This is primarily due to the fact that intermediate CASP-aware nodes have to read or modify certain parts of the message. Message objects that need not to be read or modified by nodes along the path direct end-to-end communication is likely to be more efficient and appropriate. If a specific protocol usage requires that some objects have to be protected in an end-to-end fashion then the following two approaches are possible: - The required objects could be exchanged between the desired parties (i.e. end-to-end) without using CASP at all. - If the objects in question have relevance for a particular client-layer (and therefore for some other objects along the path) then CMS protection and encapsulation of objects might be the best choice. 16.3 Session Ownership By allowing a node to refer to a previously established session state an identifier is required. This session identifier is independent of a traffic selector. Apart from different options for generating such H. Schulzrinne et. al. [Page 33] Internet Draft CASP September 15, 2002 an identifier the question arises how a node proves whether it is owner of a session state or not. In the following section first a problem description is given, then different solutions approaches are discussed and finally a solution is proposed for the CASP protocol. Problem Description: The CASP protocol is used to establish distributed state along a path in the network. The number of nodes storing state might be be larger (for example 30) and could also vary from time to time (for example in case of route changes). The session identifier is used to point to a particular stored state at each router. If an adversary is able to obtain the session identifier (for example by eavesdropping) then he might attach himself to any node along the path to modify existing state information. Only the participating entities end-hosts and routers should be able to trigger session state modifications. Routers must be able to react on route changes to execute a local repair mechanism. Hence a protection mechanism should only protect against nodes which are never intended to participate in the signaling message exchange. Some of the described problems are less problematic in non-mobile environments since the first CASP-aware router (for example the edge or access router) could easily associate authentication state with the reservation identifier. Hence ownership verification is possible. If we assume a mobility scenario then the movement of a node makes this verification step much more difficult since each CASP-aware node along the path could possibly forced to do this verification. Figure 4 depicts the session ownership problem for a mobility case: Figure 4: Session Ownership Problem Figure 4 shows that the mobile node establishes state at CASP nodes along the path. As a result the Access Router1 (AR1) (and other nodes along the path - Router1 (R1), Router3, Router4, etc.) store a session state including the session identifier (SIDx). As assumed only the mobile node and the AR1 (prior to the movement of the mobile node) share a security association. Signaling message H. Schulzrinne et. al. [Page 34] Internet Draft CASP September 15, 2002 +--------+ +-----------------+ Router +----> | SIDx | 4 | +---+----+ +--------+ | Router | SIDx +------+ 3 +<-----+ | +---+----+ | | | | SIDx | +---+----+ +---+----+ | Router | | Router | | 1 | | 2 | +---+----+ +---+----+ | ^ | SIDx | SIDx +---+----+ +---+----+ | Access | | Access | | Router | | Router | | 1 | | 2 | +---+----+ +---+----+ | ^ | SIDx | SIDx +---+----+ +---+-----+ | Mobile | |Adversary| | Node | | | +--------+ +---------+ communication between the participating entities is secured based on the peer-to-peer principle. In our example this means that AR1 has a security association with router R1 and secures signaling message. The session identity is included in the signaling messages and forwarded along the path as it serves as a reference to the established state. Without end-host mobility an existing session state is simply modified by transmitting a properly protected signaling message from the mobile node to the AR1 by additionally including the session identifier. Verification can be done at AR1 locally. An adversary who was able to obtain the session identifier of the mobile node includes the same identifier (SIDx) in a new signaling message. The message causes state to be installed at Access Router2 (AR2) and subsequently at Router2. Finally the signaling message hits Router3 where an existing state is noticed. Router3 has to assume a route change took place. The adversary included a the "dead branch removal" flag in the signaling message the path H. Schulzrinne et. al. [Page 35] Internet Draft CASP September 15, 2002 between the mobile node and Route3 is removed. Router3 is unable to decide whether the new signaling message was sent from an adversary or from the mobile node (i.e. the real owner) since there is no additional information that aids in verification. Some approaches to address the problem: Some possible means for verification and proofing ownership of a session are given below. These examples should give the reader background information what issues have been considered during the protocol design phase. Verification can be done by 1. using a cryptographic reservation identifier (for example by using a reverse hash-chain or by transmitting a digitally signed reservation whereby the reservation identifier is the hash of the public key similar to [54]. This scheme would only allow the initiator of the signaling message to trigger a modification. Special handling would be required in cases where route changes happen within the network (such as a local repair). Only the entity possessing the key pair is able to initiate authorized signaling messages. From the described protocol behavior this is not desired. 2. being able to authenticate a signaling message at each router along the path. It is then possible to associate a particular identity with a reservation identifier. The reservation identifier may even serve as a pointer to a security association. Without knowing the correct key belonging to the reservation identifier no updates are allowed. 3. using an authorization token based approach. With this approach the network would return an opaque token (opaque for the mobile node) to the MN with the initial signaling message. The token would then be included in a later signaling protocol message after a handover. 4. relying on Context Transfer which allows reservation state to be forwarded from one access router to an other. Using such a scheme the verification of the reservation identifier can be done at the new access router immediately. Unfortunately Context Transfer is applicable only within a single administrative domain. Reservation merging is however possible at any H. Schulzrinne et. al. [Page 36] Internet Draft CASP September 15, 2002 location along the path. 5. verifying a reservation request by help of a centralized entity within an administrative domain (for example with the help of the PDP). However this approach is again only applicable at a single administrative domain. 6. distributing a session key along the signaling path. A new signaling message then contains a cryptographic object which allows the verification at an arbitrary CASP-aware node along the path where signaling state was established. Approach taken by CASP: Providing confidentiality protection to protect the reservation identifier makes it more very difficult for an adversary to eavesdrop the session identifier and to reuse it for a subsequent attack. The required authentication of signaling message originator Since authentication is required an adversary can furthermore not hide its identity when starting an attack. TLS without integrity-only suites and IPSec ESP without NULL encryption algorithm [55] provides the desired confidentiality protection. To summarize we can state that in order to provide proper security for the reservation ownership problem a solution has to face many challenges including performance, state maintenance and replay protection. The above-described problem of authorization is not restricted to communication at the edge as described above. The problem basically occurs anywhere in the network whenever an old path becomes invalid and a reservation along a new path has to be established. The merge point (or cross-over router from the above mobility scenario) has to make sure that only the legitimate owner of the reservation issued this request. The difference between network internal and edge reservation ownership issues are only trust issues. 16.4 Protection of the Client-Layer In some scenarios the transport-layer hop-by-hop protection (based on TLS or IPSec) might not be sufficient. For those cases we suggest the selective protection of objects at the client-layer by using CMS where such a protection is meaningful. CMS allows objects to be protected with a digital signature and in case that the public key of the recipient is known also encryption. The fact that CMS is known H. Schulzrinne et. al. [Page 37] Internet Draft CASP September 15, 2002 and already used to protect SIP message parts and also applied to selectively protect Diameter AVPs convinced us to include support for such a mechanism. As a difference to Diameter [56] proposed protection where digitally signed AVPs have a P-bit set but are not included in the CMS-protected object the CASP protocol always includes protected objects (both digitally signed and encrypted) inside a CMS object. This avoids conflicts in complex object signing/encrypting scenarios. Additionally to the capability to protect objects CMS also allows a session key to be established based on a key agreement or a key transport technique. An established session key would allow to speed-up the protection of objects between the same peers in a later point in time. Since CMS objects are known to be large (because of certificates, CRLs, digital signatures and the large number of optional support objects) messages containing these CMS objects often exceed the maximum MTU size leading to fragmentation. By using a transport layer protocol like TCP and SCTP such a problem is avoided. It is worth noting that objects of the Client-Layer do not necessarily have to be added by the signaling originating host. Instead for example a PDP might also be able to add a CMS protected authorization token to allow secure delivery of information within a specific administrative region. As mentioned above the identity of the receiving node is required in case of encryption. If this information is not available beforehand then a discovery phase similar to the one proposed for Diameter [56] has to be executed. Since this discovery/negotiation procedure seems to be useful a more detailed description will be included in a future version of the document. 16.5 Miscellaneous Issues The following section discusses security issues which are not immediately applicable for the operation of CASP. However they are worth discussing in the context of a framework. Hence this section is meant to provide background information for a CASP deployment. Authorization:Authorization in a quality of service environment is required as part of the policy-based admission control procedure. What information to include in such a step is however still under discussion. In a corporate network environment information such as group membership and special access rights can be used whereas a very generic mobile environment scenarios only requires the assurance H. Schulzrinne et. al. [Page 38] Internet Draft CASP September 15, 2002 that a particular user is able to pay for the requested resources. Independent of the question which information to distribute in a particular scenario for a given application (e.g. QoS signaling protocol, NAT/Firewall-traversal protocol, etc.) two possible approaches can be used to deliver the required information to various entities. The first approach could be labeled "offline". The handling is similar to what is offered with Kerberos and Attribute- Certificates. A processing entity is thereby able to retrieve the authorization information directly from the credentials received from the user. Authentication and authorization information are therefore cryptographically bundled together. An example how to distribute authorization information within a Kerberos ticket is described in [57]. The second approach is called "online". Using this approach the processing entity would use the identity based on a successful authentication and queries a repository which represents the online characteristic. If the desired information is not cached at the verifying entity then an online request is required. One important requirement for this approach to work is a successful mapping between the identity used for authentication and the entity with which the information at the repository can be obtained. If the information at the repository itself is exchanged based on for example an AAA exchange between the user's home network and the visiting network then a mismatch between the identities might be common. Hence care must be taken to define an appropriate mapping between different identity formats used by various authentication protocols (for example: NAI, DN and Kerberos principal name and realm). Note that the usage of authorization information inside a Kerberos ticket or with attribute certificates is currently rarely used in protocols like KINK, TLS or IKE. Hence some further investigation is required. Trust Establishment: Relying on an authentication and key exchange protocol to mutually authenticate the both endpoints (and to secure subsequent signaling messages) in a wireless environment is often not sufficient. It no additional information is supplied then it often does not provide particular useful H. Schulzrinne et. al. [Page 39] Internet Draft CASP September 15, 2002 information to the signaling message originator that the other endpoint is a router with given IP address (or a FQDN). This is particularly true in a mobile environment where a mobile node attaches to the network for the first time. More important in this case is that either a successful AAA exchange or the service provider's digitally signed certificate gives assurance that a particular business relationship is present and known. In case of public key based authentication a mobile client would be pre-configured with some CA certificates that allow verification of the host-spot provider's certificate. In most cases it is unlikely that the end hosts is able to verify the certificate of the access network provider directly. Non-Repudiation: Non-repudiation of signaling messages is not provided as part of this protocol. However CMS allows Client-Layer objects to be counter-signed where such a procedure is necessary and useful. The main rationality for excluding support at the lower layer in the CASP protocol is based on the question of usefulness and an avoided performance impact. We think that public key cryptography should be used only in cases where security associations have to be established. Much faster cryptographic protection of signaling messages should be based on symmetric techniques to lower computational requirements for nodes participating in the signaling message exchange. Denial of Service: With the design of the protocol we tried to avoid possible denial of service vulnerabilities to some extend. Some denial of service attacks are described in the context of scout messages. Mechanisms to prevent these attacks is explained in the same paragraph. When choosing a transport layer protocol for CASP it should be noted that TCP is more vulnerable to denial of service attacks (for example TCP SYN flooding) than SCTP as described in [8] and in [58]. Using IPSec to protect all upper layer protocols prevents this attack. Especially key exchange protocols tend to be vulnerable against DoS attacks. Hence when using CASP and a specific key exchange protocol it is necessary to consider such a vulernability. Since CASP is to some extend a build block which requires fitting it to a particular architecture this issue needs to be considered. By using TLS the key exchange protocol is built-in. Using IPSec a number of options need to be taken into consideration for each of the protocols H. Schulzrinne et. al. [Page 40] Internet Draft CASP September 15, 2002 like IKE, SON-of-IKE, KINK etc. Network Topology Hiding: This Section discusses network topology hiding issues for CASP when using a record route message forwarding approach. Similar issues have already been discussed at the SIP working group. The following picture should elaborate the idea in more detail. As described in figure 5 router R3 serves as a trust boundary which allows the internal routers R1 and R2 of the administrative domain A to be hidden. For router R4, which belongs to a different administrative domain, only the edge router R3 is visible. When a message with a record route object arrives at router R1 then the router adds its identity. The same procedure happens at R2. A policy at router R3 indicates to hide the internal network entities to the outside world. Hence when the signaling message arrives at R3 the identities of router R1 and R2 at the record route object are replaced by an encrypted version. The key used for encryption is locally known only and the rekeying time interval is also policy dependent. The entire encryption process (including algorithms) is an implementation issue and requires not standardization effort. This approach allows R3 still to be stateless. Finally the result of this encryption and the identity of R3 is forwarded to R4. When R4 routes a signaling message back (by visiting the routers as indicated in the record route in the reverse order) then router R3 decrypts the encrypted routing information and forwards the message back to R2 and R1. It should be noted that the encrypted identity information should be labeled as encrypted to avoid misinterpretations. Using a stateful approach where router R3 simply stores state and indicates only its identity to router R4 the same result is achieved. In this case topology hiding is provided as part of state storing at the individual routers. For diagnostic and query messages a policy might indicate whether the processing is allowed or not. However in such a case some problems with network hiding arise. In general there is a question whether identity hiding in such a case is worth the reduced functionality of the protocol. Most network administrators consider a diagnosis and discovery capability as a very useful tool in their daily work. The H. Schulzrinne et. al. [Page 41] Internet Draft CASP September 15, 2002 same is true for developers. For the above-described issues network topology hiding can be supported as part of a local configuration or policy decision. A network administrator should decide whether to support the above-described mechanism by encrypting the identities. ----------------------------------------+ +---------------- | | | | +----+ +----+ +----+ | | +--+-+ ----+ R1 +--------+ R2 +--------+ R3 +--+---+----| R4 +------ +----+ +----+ +----+ | | +--+-+ | | Administrative Domain A | | Admin.Domain B ----------------------------------------+ +---------------- Figure 5: Network Topology Hiding 17 Security Considerations CASP protocol communication is divided into a discovery part (for example using the scout protocol) and a regular message exchange for which a transport layer connection is established. Scout messages allow the discovery of nodes participating in the CASP protocol (if no other mechanisms is used). These messages experience custom security protection. The subsequently established transport layer connection used to transport M (and C) layer messages is either protected by the TLS Record Layer or by IPSec ESP. These two protocols support protection of the CASP protocol messages. In case of TLS the key exchange protocol is built-in whereas several choices are offered for IPSec (for example KINK, IKE and in the near future SON-of-IKE). Signaling messages travel between different parts of the network where different trust assumptions are valid. To reflect this circumstance we suggest that intra-domain and inter-domain signaling message communication should be either protected by TLS or by IPSec depending on the administrator's choice. For mobile environments protection of the communication between the mobile node and the first-peer in the access network might be based on TLS for access network to client authentication and EAP-based authentication for client to server authentication. This decision is motivated by the H. Schulzrinne et. al. [Page 42] Internet Draft CASP September 15, 2002 different requirements for user-to-network authentication and the non-existence of a global PKI. The above-described security mechanisms operate in a CASP-peer to CASP-peer manner. Some Client-Layer objects however might require additional protection. Digitally signed or encrypted Client-Layer objects can be provided by CMS as successfully used by other protocols like S/MIME, SIP or Diameter. Authorization tokens or information which has to be verified within a domain only can make use of such a selective protection. Security protection for the session ownership problem is difficult and requires more investigation. This document describes the problem and lists a number of possible approaches to tackle the problem. A first version of the protocol may rely on confidentiality protection (as provided by most cipher-suites for TLS and IPSec ESP without NULL encryption) to avoid eavesdroppers to learn the 128-bit random session identifier. Without knowledge of this session identifier the described attack is difficult. Note that CASP-aware network elements along the CASP chain must know the session identifier in order for the protocol to operate correctly. 18 Open Issues and Future Work This Section contains some identified future work items: o The process of discovering CASP-aware nodes is a security sensitive process. Some references and considerations regarding security vulnerabilities of proposed discovery mechanisms for CASP have to be described (in addition to the scout description). o To avoid users the requirement for mutual public key based authentication in TLS for both first-peer as well as last-peer communication some additional text has to be provided. Although EAP is proposed for first-peer communication to supported non-public key based authentication from a user to the network the roles of client/server are reversed in case last-peer communication. o Selective client layer object protection is provided by CMS. The process of discover/negotiation needs some further considerations. Additionally the establishment of symmetric keys for efficiently protecting multiple message exchanges have to be considered. o The usage of EAP is proposed in relationship with client- authentication. Further work is necessary to describe protocol H. Schulzrinne et. al. [Page 43] Internet Draft CASP September 15, 2002 interactions and message flows based on some selected EAP mechanisms. o Interactions with accounting and charging and their implications for the security framework will be described in more detail in a separate document. Together with this document some basic explanations of the trust relationships should be provided. o The security section is more detailed than other parts of the document. It might be therefore suitable to distribute a more detailed description of the security issues in a separate security draft. 19 Acknowledgements We would like to thank (in alphabetical order) Wolfgang Buecker, Jorge Cuellar, Rainer Falk and Dirk Kroeselberg for their comments to this draft. Jorge and Dirk provided us with a large number of comments to improve the security section of this document. Cornel Pampu contributed to the mobility discussions. A Message Format Details For concreteness, we describe a strawman packet format below. All CASP messages are composed of one or more TLV (type-length-value) objects. Within each object, elements are aligned on multiples of their size, to speed processing. All objects have lengths of a multiple of 32 bits. The length field in the object indicates the number of 32-bit words. We describe messages and objects as pseudo-C structs. Elements are enumerated in transmission order. We use the data types uint8, uint16, uint32, uint64, uint128 to identify unsigned integers with 8, 16, 32, 64 or 128 bits, respectively. We define the following data types: typedef struct { uint16 msg_type; uint16 msg_length; } tl; typedef struct { uint16 length; /* actual string length, in bytes */ uint8 chars[length]; /* UTF-8 */ } string; H. Schulzrinne et. al. [Page 44] Internet Draft CASP September 15, 2002 Message types not defined in this document are registered with IANA (Section 15). Text strings are coded in the UTF-8 character set encoding [59]. They are padded to a multiple of 32 bits with zero bytes. typedef struct { tl tl = {message type, total length of packet}, ... objects ... } casp_message; typedef struct { tl tl = {payload}, ... payload bytes .. } casp_payload; typedef struct { tl tl = {msgid}, uint64 random; } msgid; A.1 Network Addresses typedef struct { int8 network; int8 transport; int16 port; uint128 address; } ip6_address; typedef struct { int8 network; int8 transport; int16 port; uint32 address; } ip4_address; typedef struct { H. Schulzrinne et. al. [Page 45] Internet Draft CASP September 15, 2002 uint8 nonce[20] } address_cookie; typedef struct { tl tl = {,}; union { ip4_address; ip6_address; } address[]; } req_route; The address_cookie object contains an encrypted version of an IPv4 or IPv6 address. It can be used for topology hiding. A node that wants to obscure the network addresses in a region encrypts all IPv4 or IPv6 address objects, adding random salt, and then replaces them with the address_cookie. Upon return, the node decrypts the address information and routes the request normally. Thus, the egress node of a protected region is responsible for encrypting and decrypting address objects. A.2 Capability Discovery typedef struct { tl tl; uint16 cap[]; } cap_discovery; typedef struct { tl tl; uint16 cap[]; } cap_required; B Authors' Addresses Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA H. Schulzrinne et. al. [Page 46] Internet Draft CASP September 15, 2002 EMail: schulzrinne@cs.columbia.edu Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich 81739 Germany EMail: Hannes.Tschofenig@mchp.siemens.de Xiaoming Fu Technical University Berlin Sekr. FT 5-2, Einsteinufer 25 Berlin 10587 Germany EMail: fu@ee.tu-berlin.de Jochen Eisl Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Jochen.Eisl@icn.siemens.de Robert Hancock Roke Manor Research Old Salisbury Lane Romsey, Hampshire UK EMail: robert.hancock@roke.co.uk C Bibliography [1] B. Carpenter and S. Brim, "Middleboxes: Taxonomy and issues," RFC 3234, Internet Engineering Task Force, Feb. 2002. [2] B. Braden and B. Lindell, "A two-level architecture for internet signaling," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [3] H. Schulzrinne, H. Tschofenig, X. Fu, and J. Eisl, "A quality- of-service resource allocation client for CASP," Internet Draft, Internet Engineering Task Force, Sept. 2002. Work in progress. [4] M. Brunner, "Requirements for QoS signaling protocols," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [5] B. Hancock et al., "Towards a framework for QoS signaling in the H. Schulzrinne et. al. [Page 47] Internet Draft CASP September 15, 2002 internet," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [6] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, Internet Engineering Task Force, Jan. 1999. [7] L. Ong and J. Yoakum, "An introduction to the stream control transmission protocol (SCTP)," RFC 3286, Internet Engineering Task Force, May 2002. [8] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control transmission protocol," RFC 2960, Internet Engineering Task Force, Oct. 2000. [9] D. Senie, "Network address translator (nat)-friendly application design guidelines," RFC 3235, Internet Engineering Task Force, Jan. 2002. [10] P. Calhoun et al., "Diameter base protocol," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [11] H. Holbrook and B. Cain, "Source-specific multicast for IP," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [12] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [13] D. Katz, "IP router alert option," RFC 2113, Internet Engineering Task Force, Feb. 1997. [14] C. Partridge and A. Jackson, "IPv6 router alert option," RFC 2711, Internet Engineering Task Force, Oct. 1999. [15] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering, "IPv6 flow label specification," Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [16] L. Berger and T. O'Malley, "RSVP extensions for IPSEC data flows," RFC 2207, Internet Engineering Task Force, Sept. 1997. [17] D. Harkins, C. Kaufman, et al., "Propsal for the IKEv2 protocol," Internet Draft, Internet Engineering Task Force, Apr. 2002. Work in progress. [18] J. Manner et al., "Localized RSVP," Internet Draft, Internet Engineering Task Force, May 2002. Work in progress. H. Schulzrinne et. al. [Page 48] Internet Draft CASP September 15, 2002 [19] D. Meyer, "Administratively scoped IP multicast," RFC 2365, Internet Engineering Task Force, July 1998. [20] J. Moy, "OSPF version 2," RFC 2328, Internet Engineering Task Force, Apr. 1998. [21] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service location protocol, version 2," RFC 2608, Internet Engineering Task Force, June 1999. [22] T. Narten, E. Nordmark, and W. Simpson, "Neighbor discovery for IP version 6 (ipv6)," RFC 2461, Internet Engineering Task Force, Dec. 1998. [23] R. Droms, "Dynamic host configuration protocol," RFC 2131, Internet Engineering Task Force, Mar. 1997. [24] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) DNS resource record," RFC 2915, Internet Engineering Task Force, Sept. 2000. [25] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," RFC 1889, Internet Engineering Task Force, Jan. 1996. [26] K. McCloghrie, D. Farinacci, and D. Thaler, "IPv4 multicast routing MIB," RFC 2932, Internet Engineering Task Force, Oct. 2000. [27] J. Nicholas, "Protocol independent multicast MIB," Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [28] A. Terzis, J. Krawczyk, J. Wroclawski, and L. Zhang, "RSVP operation over IP tunnels," RFC 2746, Internet Engineering Task Force, Jan. 2000. [29] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC 2205, Internet Engineering Task Force, Sept. 1997. [30] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, and S. Molendini, "RSVP refresh overhead reduction extensions," RFC 2961, Internet Engineering Task Force, Apr. 2001. [31] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on RSVP regarding multicast," Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. H. Schulzrinne et. al. [Page 49] Internet Draft CASP September 15, 2002 [32] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 1998. [33] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session initiation protocol," RFC 3261, Internet Engineering Task Force, June 2002. [34] M. Rose, "The blocks extensible exchange protocol core," RFC 3080, Internet Engineering Task Force, Mar. 2001. [35] H. Tschofenig, "NSIS threats," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [36] H. Tschofenig, "RSVP security properties," Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [37] R. Housley, "Cryptographic message syntax," RFC 2630, Internet Engineering Task Force, June 1999. [38] J. Arkko et al., "Security mechanism agreement for SIP sessions," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [39] D. Johnson, C. Perkins, and J. Arkko, "Mobility support in IPv6," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [40] F. Baker, B. Lindell, and M. Talwar, "RSVP cryptographic authentication," RFC 2747, Internet Engineering Task Force, Jan. 2000. [41] A. Medvinsky and M. Hur, "Addition of kerberos cipher suites to transport layer security (TLS)," RFC 2712, Internet Engineering Task Force, Oct. 1999. [42] S. Kent and R. Atkinson, "IP authentication header," RFC 2402, Internet Engineering Task Force, Nov. 1998. [43] S. Kent and R. Atkinson, "IP encapsulating security payload (ESP)," RFC 2406, Internet Engineering Task Force, Nov. 1998. [44] D. Harkins and D. Carrel, "The internet key exchange (IKE)," RFC 2409, Internet Engineering Task Force, Nov. 1998. [45] M. Thomas et al., "Kerberized internet negotiation of keys (KINK)," Internet Draft, Internet Engineering Task Force, Nov. 2001. H. Schulzrinne et. al. [Page 50] Internet Draft CASP September 15, 2002 Work in progress. [46] W. Aiello, S. Bellovin, et al., "Just fast keying (JFK)," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [47] L. Blunk and J. Vollbrecht, "PPP extensible authentication protocol (EAP)," RFC 2284, Internet Engineering Task Force, Mar. 1998. [48] P. Funk and S. Blake-Wilson, "EAP tunneled TLS authentication protocol (EAP-TTLS)," Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in progress. [49] H. Andersson, S. Josefsson, G. Zorn, et al., "Protected extensible authentication protocol (PEAP)," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [50] S. Blake-Wilson et al., "Transport layer security (TLS) extensions," Internet Draft, Internet Engineering Task Force, May 2002. Work in progress. [51] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, "X.509 internet public key infrastructure online certificate status protocol - OCSP," RFC 2560, Internet Engineering Task Force, June 1999. [52] D. McDonald, C. Metz, and B. Phan, "PF_KEY key management API, version 2," RFC 2367, Internet Engineering Task Force, July 1998. [53] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, and R. Hess, "Identity representation for RSVP," RFC 3182, Internet Engineering Task Force, Oct. 2001. [54] S. Bradner, A. Mankin, and J. Schiller, "A framework for purpose built keys (PBK)," Internet Draft, Internet Engineering Task Force, July 2002. Work in progress. [55] R. Glenn and S. Kent, "The NULL encryption algorithm and its use with IPsec," RFC 2410, Internet Engineering Task Force, Nov. 1998. [56] P. Calhoun, S. Farrell, and W. Bulley, "Diameter CMS security application," Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in progress. [57] Microsoft, "Microsoft authorization data specification v. 1.0 for Microsoft Windows 2000 Operating Systems," tech. rep., Microsoft, Redmond, Washington, Apr. 2000. H. Schulzrinne et. al. [Page 51] Internet Draft CASP September 15, 2002 [58] L. Coene, "Stream control transmission protocol applicability statement," RFC 3257, Internet Engineering Task Force, Apr. 2002. [59] F. Yergeau, "UTF-8, a transformation format of unicode and ISO 10646," RFC 2044, Internet Engineering Task Force, Oct. 1996. H. Schulzrinne et. al. [Page 52] Table of Contents 1 Introduction ........................................ 3 1.1 Protocol Overview ................................... 3 1.2 Protocol Properties ................................. 4 2 Terminology ......................................... 9 3 Definitions ......................................... 9 4 Message Delivery .................................... 9 5 Transport Protocol Usage ............................ 10 6 Message Forwarding .................................. 11 7 Message Format ...................................... 12 8 Capability Negotiation .............................. 16 9 Next-Node Discovery ................................. 17 9.1 Next-in-Path Service ................................ 17 9.2 Next AS Service ..................................... 18 10 Scout Protocol ...................................... 19 11 Route Change and Mobility ........................... 20 12 Multicast Support ................................... 22 13 CASP over Tunnels ................................... 23 14 Protocol Heritage ................................... 24 15 IANA Considerations ................................. 24 16 CASP Security ....................................... 24 16.1 Scout Messages ...................................... 25 16.2 Securing the Transport and Messaging Layers ......... 30 16.3 Session Ownership ................................... 33 16.4 Protection of the Client-Layer ...................... 37 16.5 Miscellaneous Issues ................................ 38 17 Security Considerations ............................. 42 18 Open Issues and Future Work ......................... 43 19 Acknowledgements .................................... 44 A Message Format Details .............................. 44 A.1 Network Addresses ................................... 45 A.2 Capability Discovery ................................ 46 B Authors' Addresses .................................. 46 C Bibliography ........................................ 47 H. Schulzrinne et. al. [Page 1]