Network Working Group F. Risso Internet-Draft Politecnico di Torino Expires: August 2, 2003 D. Dutt Cisco Systems February 2003 REmote Sample and CApture Protocol (RESCAP) draft-risso-rescap-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 2, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document details a protocol that can be used to capture and sample frames on a remote device. This protocol could be a possible solution for the "Report format and report stream format document" milestone of the PSAMP Working Group. This protocol defines a control connection, which is used to control the remote device, and a data connection, which is used to transport back the sampled data. This protocol includes has a set of optional parameters that allows customizing the behavior of the sampling process. This protocol can be used also for packet capture and it should be possible to implement it on both network devices (router Risso & Dutt Expires August 2, 2003 [Page 1] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 and switches) and workstation hosts. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Existing Solutions . . . . . . . . . . . . . . . . . . . . . 3 1.2 Features Overview . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Remote Sample and Capture Protocol (RESCAP) . . . . . . . . 7 3.1 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 7 3.2 Connection Setup . . . . . . . . . . . . . . . . . . . . . . 8 3.3 General Header Message Format . . . . . . . . . . . . . . . 8 3.4 Control Protocol Messages . . . . . . . . . . . . . . . . . 9 3.5 RESCAP Timers . . . . . . . . . . . . . . . . . . . . . . . 10 3.6 Control and Data Connections . . . . . . . . . . . . . . . . 10 3.7 Congestion Control for UDP Data Connection . . . . . . . . . 11 4. RESCAP Messages . . . . . . . . . . . . . . . . . . . . . . 13 4.1 Authorization Message (Message Type = AUTH) . . . . . . . . 13 4.2 Open RESCAP Session (Message Type = OPEN_SESSION) . . . . . 14 4.2.1 Filtering Section . . . . . . . . . . . . . . . . . . . . . 18 4.2.2 Sampling Information Section . . . . . . . . . . . . . . . . 18 4.2.3 Data Connection Information Section . . . . . . . . . . . . 18 4.3 Close Session (Message Type = CLOSE_SESSION) . . . . . . . . 19 4.4 Close RESCAP Connection (Message Type = CLOSE) . . . . . . . 19 4.5 Start Sampling (Message Type = START_SAMPLING) . . . . . . . 19 4.6 End Sampling (Message Type = END_SAMPLING) . . . . . . . . . 19 4.7 Adjust Sampling Parameters (Message Type = ADJUST_SAMPLING_PARS) . . . . . . . . . . . . . . . . . . . 20 4.8 Get Sampling Statistics (Message Type = GET_SAMPLING_STATS) . . . . . . . . . . . . . . . . . . . . 20 4.9 Error Message (Message Type = ERROR) . . . . . . . . . . . . 22 5. Data Connection: Packet Format . . . . . . . . . . . . . . . 24 6. RESCAP Codes and Values . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . 28 7.1 Authentication of the user colleting samples . . . . . . . . 28 7.2 Authentication of the Collecting and Sampling devices . . . 29 7.3 Protection of origin, integrity and confidentiality of sampled data . . . . . . . . . . . . . . . . . . . . . . . . 29 7.4 Denial of Service Attacks . . . . . . . . . . . . . . . . . 29 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 30 References . . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 A. Choosing the appropriate number of bits for packet counters . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . 33 Risso & Dutt Expires August 2, 2003 [Page 2] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 1. Introduction There are many devices (routers, switches, workstations) on which it would be useful to sample or capture incoming and outgoing traffic to debug problems. These devices typically cannot support graphical analyzers that can do detailed and sophisticated analysis in place. The Remote Sample and CApture Protocol (RESCAP) is an attempt to circumvent this problem by sampling the local traffic and sending it to a remote destination where a tool (e.g. a graphical protocol analyzer) can decode, monitor and analyze the traffic. Since the Packet Capture can be seen as a special case of Packet Sampling, the terms "sample" and "sampling" (instead of "capture") will be used throughout this draft. 1.1 Existing Solutions Standard switches and routers offer, today, the ability to capture the traffic on some of their ports. However, often a protocol analyzer must be connected to a switch port directly in order to debug packets being handled by the device; this of course requires that a port on the switch be dedicated. Furthermore, often people is interested in a subset of data, for example the one that comes out from a sampling process Using remote sample and capture capabilities, the traffic can be switched to laptops not even on the local network. This is very useful for support engineers in debugging devices in the field. Additionally, the remote software may offer greater flexibility than on-device tools, since it can be easily updated and it can take advantage of higher processing capabilities. The network device can become a probe with limited processing capability, while most of the intelligence is available on the remote monitoring station. While some proprietary solutions exist for packet capture, nothing exists for packet sampling. This task is getting increasing important since packet sampling is often the only way to know (and to predict) the status of the network, and this data can be used for activities such as traffic engineering. This proposal aims at defining a standard solution for remote packet sampling (and capture) over remote devices. 1.2 Features Overview The main features of RESCAP are: Risso & Dutt Expires August 2, 2003 [Page 3] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 o Support for sampling from a specific interface of the remote device. o Support for specifying filters remotely to avoid unnecessary packets from being sent to the sampling device. o Support for capturing all the packets on the remote interface. o Support for active and passive modes to permit sampling across firewalls. o Support for heterogeneous devices such as hosts (*nix, Windows), routers and switches. Risso & Dutt Expires August 2, 2003 [Page 4] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 2. Terminology Sampling Process The sampling process extracts a subset (according to some configuration parameters) of the network packets and sends them to one collecting process. Sampling Device (or Probe) The probe is the physical device that runs one or more sampling processes. Collecting Process The collecting process receives sampled packets from one or more sampling processes. The collecting process might store received flow records or further process them, but these actions are out of the scope of this document. Collecting Device The collecting device is a physical device that runs one or more collecting processes. Active Mode The active mode is a running mode in which the sampling process initiates the control connection (i.e. it becomes an "active" device) towards the collecting process. This is useful to overcome the problem of a probe behind firewalls (or network address translators) while the collecting process is on the public Internet. Passive Mode The passive mode is the standard running mode in which the collecting process initiates the control connection towards the sampling process. In this case the sampling process waits for new control connections, i.e. it looks like a "passive" device. Control Connection A transport-layer reliable connection (TCP) between a collecting device and a sampling device, which is used to control the sampling process and to get some control statistics (e.g. the number of sampled and dropped packets so far). Data Connection A transport-layer connection between a collecting process and the corresponding sampling process, which is used to exchange data (sampled frames). This connection can use either TCP or UDP (in this case it does not guarantee any kind of reliability). Risso & Dutt Expires August 2, 2003 [Page 5] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 Sampling Session A logical association between one sampling process (on the sampling device) and one collecting process (on the collecting device), which exchange information by means of a control connection and a data connection. Risso & Dutt Expires August 2, 2003 [Page 6] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 3. Remote Sample and Capture Protocol (RESCAP) This section presents the details of the RESCAP protocol. 3.1 Protocol Overview The Remote Sampling and CApture Protocol (RESCAP) is structured as a client-server protocol on top of TCP/UDP. The protocol consists of two connections, one for control (control connection) and the other for actually transferring the sampled frames (data connection). The former uses TCP and the latter can use either TCP or UDP. In any case, the protocol takes into consideration network congestion issues by defining a feedback mechanism that makes UDP traffic congestion-friendly. On the probe, a daemon accepts (or initiates in case of Active Mode) control connections coming from a collecting process and it creates the appropriate sampling process. The sampling process and the collecting process exchange ther information through the control and data connections. While there can be only one control connection between one collecting and sampling device, there can be more than one data connection since this is intented as a communication channel between collecting and sampling processes. For instance, multiple sampling processes can simultaneously sample traffic on the same interface of a remote device. An example of one possible configuration is shown in Figure 1. The protocol messages use a TLV-like format to communicate objects. The sampled frames are preceded by an header with some statistical information related to the current packet. Security is addressed in several directions. The protocol allows to authenticate both the capture device and the collecting device (or the user) by means of IPsec connections, username / password mechanisms and IP addresses. For instance, the communication channels can make use of both authenticated and encrypted messages. Risso & Dutt Expires August 2, 2003 [Page 7] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 +------------+ Control Connection +------------+ | | <------------------------> | | | Sampling | <-- Request Reply --> | Collecting | | | | | | Process | Data Connection | Process | | | -------------------------> | | +-----+------+ +------------+ | <---------+----------> (Network) Figure 1: RESCAP Architecture 3.2 Connection Setup Remote sampling is started by first establishing the control connection between the sampling device and the collecting device. The connection maybe initiated either by the sampling device (passive mode) or the collecting device (active mode). The port associated with this connection is assumed to be well-known. If it is required to sample traffic from a device behind a firewall, there are two solutions possible: one is to configure the firewall to allow RESCAP to pass through or support a mode where the sampling device will initiate the control connection thereby piercing through the firewall. RESCAP supports both solutions. In order to support the active mode, it is assumed that the collecting process is running and it is ready to accept connections from the sampling device. The actual traffic that is sampled is sent on a separate connection (data connection) established between the two devices. This can be either a TCP or UDP connection. Similar to the control connection, this connection may be setup by either ends, based on their configuration. 3.3 General Header Message Format The message format consists of a general header optionally followed by a command-specific header. The format of the general header is shown in Figure 2. o Version: denotes the version of the message, set to 1 currently. o Response: if it is set, it is a response message. Risso & Dutt Expires August 2, 2003 [Page 8] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 o Type: message type such as OPEN_SESSION, START_SAMPLING, etc. The topmost bit (R) indicates whether this is a request or a response. o Value: it has a message-dependent meaning and it is used to carry short values that can be encoded in 16 bits (such as number of interfaces). o Session ID: an unique identifier for the sampling session; in case the session has still to be started, the value of this field is meaningless and its value must be zero. o Payload Length: length of the rest of this message. 0 7 8 15 31 +-------------+-+-----------+---------------------------+ | Version |R| Msg Type | Value | +-------------+-+-----------+---------------------------+ | Session ID | +-------------------------------------------------------+ | Payload Length | +-------------------------------------------------------+ / Variable Length Payload / +-------------------------------------------------------+ Figure 2: General Header Message Format 3.4 Control Protocol Messages The currently defined protocol messages are: o AUTH: it transports an authorization message. o OPEN_SESSION: it creates a new session between one sampling and one collecting process. o CLOSE_SESSION: it closes an existing session between one sampling and one collecting process. o CLOSE: it closes an existing control connection between one sampling and one collecting device. o START_SAMPLING: it begins sampling packets within an existing session. o END_SAMPLING: it ends sampling packets within an existing session. Risso & Dutt Expires August 2, 2003 [Page 9] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 o ADJUST_SAMPLING_PARS: it adjusts the parameters of the current sampling session. o GET_SAMPLING_STATS: it gets some statistical information about the current sampling session. o ERROR: it reports back the information related to an error occurred to the other end process. All the previous messages (with the exception of ERROR) esist in both the Request and Reply forms, since the sampling and collecting processes must notify the result of the issued command. In case the Request message fails, the Reply message is missing and an ERROR message is returned back instead. For instance, the ERROR message is the only message which is not available in the Request and Reply forms. Sometimes, a message does not have any payload (e.g. if the authentication phase completed succesfully, the reply message is just "OK"). In this case the message will have only the General Header with the appropriate value into the Message Type field, while the Payload Length will be zero. 3.5 RESCAP Timers There are several kinds of timers that are used in RESCAP. most of all are on the server side: o INIT_TIMEOUT: this timer is used to decide the duration to wait for an AUTH message. If an AUTH message is not received within this time, the connection is terminated. o RUN_TIMEOUT: this timer is used after the authentication phase completed succesfully and when a sampling session is not active. It specifies the duration to wait for a message to arrive from the client after successful authentication; if no message arrives within this duration, the connection is terminated. This timer is not used in the active mode because the control connection must last forever (until the collecting device explicitely kills it). o AUTH_FAIL_TIMEOUT: this timer is used to delay the immission of a new couple username/password in case the first one provided is wrong. 3.6 Control and Data Connections The RESCAP protocol makes use of two types of connections: the Risso & Dutt Expires August 2, 2003 [Page 10] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 Control Connection, which is used to trasport commands and responses between two entities, and the Data Connection, which is devoted to transport data. While the former is made up of a TCP connection, the latter can be either TCP or UDP at user's choice. However, the UDP protocol has no congestion avoidance mechanism and it is strongly discouraged. However, there maybe cases in which a UDP connection is appropriate such as when there is a direct connection between the sampling and collecting devices and so is listed. The UDP protocol MUST be coupled with a feedback mechanism that prevents network congestion issues. The feedback uses the mechanism presented in Section 6.7 of the Framework for Passive Packet Measurement [1]. This mechanism is presented in the next Section. 3.7 Congestion Control for UDP Data Connection This Section applies only in case the data connection makes use of UDP messages. The collecting process MUST send an ADJUST_SAMPLING_PARS message every ADJUST_PARS_TIMEOUT seconds over the control connection. This message can contain a section that tells the collecting device which is the maximum allowed speed in sending packets back. The speed is regulated by means of a token bucket mechanism. The token size is equal to the MTU (Maximum Transmission Unit) of the underlying network, and an appropriate number of tokens is generated every second according to the selected bandwidth. Since each RESCAP message requires a response, the ADJUST_SAMPLING_PARS Response permits to calculate the round trip time (RTT) of the connection. Please note that this number is an approximate value because it is calculated on the data transmitted over the control connection (i.e. TCP), while the data connection makes use of UDP. Any adjustment of the present sending rate is decided by the collecting device, which must send an ADJUST_SAMPLING_PARS message to the sampling device. When the collecting device detects one missing packet into the data connection, it reacts by decreasing the maximum speed to 70% of the original speed and it MUST send immediately an ADJUST_SAMPLING_PARS message to the sampling process. This procedure is repeated whenever a missing packet is detected. This decreasing factor has been chosen in order not to penalyze RESCAP data flows the case of a packet reordering problem (since there is no a timeout of receiving packets, a reordered packet is seen as a missing packet). In any case, after Risso & Dutt Expires August 2, 2003 [Page 11] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 two missing packets, the rate drops below 50% of the initial rate, making it compatible with the current implementation of the TCP protocol. Vice versa, the speed is increased to the 101% of the original speed (i.e. ADJUST_SAMPLING_PARS message is sent) if, during a time period of one RTT, no dropped packets are detected. These values have been chosen in order to keep computations simple; in case of a single missing packet, these numbers guarantee to be able to restore the original sending rate in about 35 RTTs. In any case, the maximum speed is limited by the value chosen by the user when the session started, unless the user chooses explicitely to change it in some way. In case the capturing device does not receive any message over the control connection for more than THREE times the ADJUST_PARS_TIMEOUT value, it MUST assume that the network path toward the collecting machine is no longer available and it will close all the current sessions with that host. This congestion control mechanism can be modified in case of some exceptional cases, according to Section 6.7.3 in [1]. This could be needed to get a larger bandwidth, for example in presence of a massice Denial of Service (DoS) attack. The user can explicitely disable the congestion control mechanism by defining the bandwidth that must be used by the data connection in sending data back. However, this is strongly discouraged. Risso & Dutt Expires August 2, 2003 [Page 12] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 4. RESCAP Messages This Section shows all the messages defined into the RESCAP protocol, which are exchanged over the control connection. 4.1 Authorization Message (Message Type = AUTH) The first message exchanged after a connection has been setup is the AUTH message. It is always sent by the collecting device to the sampling device. For instance, in the active mode the sampling device is only responsible for initiating the control connection. After this, it waits for the collecting device to send the AUTH Request. Figure 3 shows the format of the AUTH Request message, which is the payload part of Figure 2. The message contains the following fields: o Authentication Type: it keeps a code that indicates the type of authentication. There are three currently defined authentication mechanisms: * Null authentication * Username and password o First Auth Token Length: it keeps the length of the first authentication token. It is zero in case of the Null authentication. o Second Auth Token Length: it keeps the length of the second authentication token. It is zero in case of the Null authentication. o Variable Length Authentication Token: there are two possible fields (in case their length is not null) that keeps the token for the authentication required. Risso & Dutt Expires August 2, 2003 [Page 13] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 0 15 31 +---------------------------+---------------------------+ | Authentication Type | Unused | +---------------------------+---------------------------+ | First Auth Token Length | Second Auth Token Length | +---------------------------+---------------------------+ / Variable Length Authentication Token 1 / +-------------------------------------------------------+ / Variable Length Authentication Token 2 / +-------------------------------------------------------+ Figure 3: AUTH Request Message Format If the sampling device does not accept the provided authorization, it sends back an ERROR message and it waits for another AUTH Request message. On a successful authorization, an AUTH Reply message is sent back. The SESSION_ID field into the General Header has no meaning in case of an authorization message. 4.2 Open RESCAP Session (Message Type = OPEN_SESSION) The OPEN_SESSION message is used to create a physical association between one sampling and one collecting process. Although no sampling has been started at the moment, this message allows selecting the interface on which the sampling has to be done and the parameters of the session. The OPEN_SESSION is made up of several fields: o Flags: it qualifies the sampling session with additional information that can be used to modify the behaviour of the process. The currently defined flags are: * SAMPFLAG_PROMISCUOUS: it sets the interface in promiscuous mode. This flag could be meaningless on switches and routers, but it is important in case of software worstations. * SAMPFLAG_UDP_DATA: it uses an UDP connection to send the sampled frames. If this is not set, TCP is used. * SAMPFLAG_PROBE_OPEN: the sampling device will attempt to open the data connection toward the collecting device. This is the default setting in case of Active Mode. * SAMPFLAG_INBOUND_ONLY: the sampling device will attempt to sample only inbound frames on the specified interface. This may Risso & Dutt Expires August 2, 2003 [Page 14] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 not be supported on all devices and it is ignored in case the SAMPFLAG_PROMISCUOUS is set. * SAMPFLAG_OUTBOUND_ONLY: the sampling device will attempt to sample only outbound frames on the specified interface. This may not be supported on all devices and it is ignored in case the SAMPFLAG_PROMISCUOUS is set. * SAMPFLAG_DELAYED_SEND: this option is to force the sampling device to store all the selected frames locally and send them back later, when the sampling process has been stopped. Based on the sampling buffer size, only the last set of bytes in the buffer can be sent. o Data Connection Port: it is used to indicate to the sampling device the port on which to establish the data connection toward the collecting device. The value of this field is meaningful only in case the data connection is opened by the capturing device (which is the default behaviour in case of active mode). o Interface Name Length: this field keeps the length of the Interface Name field (which contains a variable-length string). o Snapshot Length: it specifies how many bytes of each packet must be saved. Only the first "snapshot_length" bytes are sent to the collecting device. A value of 0 implies the entire frame. o Sampling Buffer Size (64 bits): this is a request to use a buffer of at least this size in KBytes (i.e. unit of 1024 bytes) in order to buffer packets to avoid drops due to a possible difference in the packet sampling rate and the packet transmission rate. The device returns the value that it is eventually used. o Max Number of Packets to Capture (64 bits): it specifies how many packets are expected by the collecting device. A value of '0' implies that the sampling lasts till a END_SAMPLING message is received. o Max Size of Data to Capture (64 bits): it specifies the maximum size of data that is expected by the collecting device, in KBytes (i.e. unit of 1024 bytes). This is useful in case the target device has a limited space and does not want to exceed a predetermined size. A value of '0' implies that the sampling lasts till a END_SAMPLING message is received. In case both "Max Number of Packets to Capture" and "Max Size of Data to Capture" are non-zero values, the sampling ends when the first threshold is reached. Risso & Dutt Expires August 2, 2003 [Page 15] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 o Interface Name: it keeps a string containing the interface on which the sampling session has to be done. o Filtering Section: it is used to specify an initial filter that is setup before the sampling is started. The support of this is implementation-specific, dependent on the OS of the target device: some devices could not be able to filter packets. The format of this Section is specified in Section 4.2.1. o Sampling Information Section: this keeps some additional information related to the sampling process (e.g. the sampling mode, etc). The format of this Section is specified in Section 4.2.2. o Data Connection Information Section: this keeps some additional information related to the data connection (for example if the data connection does not have to exceed a given rate, or such). The format of this Section is specified in Section 4.2.3. Risso & Dutt Expires August 2, 2003 [Page 16] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 0 15 31 +---------------------------+---------------------------+ | Flags | Data Connection Port | +---------------------------+---------------------------+ | Interface Name Length | Unused | +---------------------------+---------------------------+ | Snapshot Length | +-------------------------------------------------------+ | Sampling Buffer Size (high) | +-------------------------------------------------------+ | Sampling Buffer Size (low) | +-------------------------------------------------------+ | Max Number of Packets to Capture (high) | +-------------------------------------------------------+ | Max Number of Packets to Capture (low) | +-------------------------------------------------------+ | Max Size of Data to Capture (high) | +-------------------------------------------------------+ | Max Size of Data to Capture (low) | +-------------------------------------------------------+ / Interface Name / +-------------------------------------------------------+ / Filtering Section / +-------------------------------------------------------+ / Sampling Information Section / +-------------------------------------------------------+ / Data Connection Information Section / +-------------------------------------------------------+ Figure 4: OPEN_SESSION Request message This message returns some parameters that are of interest for the following messages. The most important one is the SESSION_ID (in the General Header), which is an unique number (within the sampling device) associated to the current session. The SESSION_ID field will be used in all the following control messages to identify the session they belong to. This calls will trigger also the creation of the data connection. This is an advantage in case several sampling sessions will be started (one after the other) within the same SESSION_ID because the data connection is created only once. However, this document does not specify whether the sampling and the collecting processes have to be created in correspondence of this message. The creation of these processes is left to an implementation choice. In RESCAP no negotiation is performed with respect to the parameters. The collecting device specifies its desired values and the sampling Risso & Dutt Expires August 2, 2003 [Page 17] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 device responds with what it can support. If the client does not like the values returned by the server, it can end the sampling session. The Data Connection Port field is used in case the collecting device is going to open the data connection toward the sampling device. In this case, the sampling device will tell the port number on which is going to accept the connection. This port is allocated dynamically in order to make easier the recognition of a new incoming data connection on the target device. A dynamic allocation solves the problem of a device that has two processes waiting for an incoming data connection, which will arrive both on the same destination port. Figure 5 shows the format of the Reply message. 0 15 31 +---------------------------+---------------------------+ | Flags | Data Connection Port | +---------------------------+---------------------------+ | Time Zone | +-------------------------------------------------------+ | Link-Layer Type | +-------------------------------------------------------+ | Sampling Buffer Size (high) | +-------------------------------------------------------+ | Sampling Buffer Size (low) | +-------------------------------------------------------+ Figure 5: OPEN_SESSION Reply message 4.2.1 Filtering Section This format is used to specify the filter used during the sampling process. 4.2.2 Sampling Information Section This format is used to specify the sampling method (and parameters) used in the current sampling process. 4.2.3 Data Connection Information Section This format is used to specify the information related to the data connection (e.g. the maximum speed used to send data to the collecting device). Risso & Dutt Expires August 2, 2003 [Page 18] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 4.3 Close Session (Message Type = CLOSE_SESSION) When the sampling device or the collecting device decide to close a previously opened session, they send a CLOSE_SESSION message. If a sampling session is in progress, it is immediately terminated. Typically, to just stop a sampling without closing the session, an END_SAMPLING message must be used. The CLOSE_SESSION Request and Reply messages do not have a payload and they make use of the General Header only. The Session ID field in the General Header specifies the session this command belongs to. The data connection is torn down in correspondence to this message. The control connection is still up instead. 4.4 Close RESCAP Connection (Message Type = CLOSE) This message is intended to close explicitely every connection between the sampling and collecting devices. This messages wants to avoid that a control connection is closed without informing the other end-party, leaving zombies on the remote device. Following this message, also the control connection has to be torn down. This message does not have payload since it does not transport any information. In case a sampling session is still open, this message will force the sampling ad collecting devices to perform all tasks related to the END_SAMPLING and CLOSE_SESSION messages as well. This message does not use the Session ID field in the General Header. 4.5 Start Sampling (Message Type = START_SAMPLING) START_SAMPLING is the command that actually starts the sampling on an interface. This command can be sent only if the parameters returned back by the OPEN_SESSION Reply message are compatible with the desired ones. The START_SAMPLING Request and Reply (which is used only if the response is succesfully) messages do not have a payload and they make use of the General Header only. The Session ID field in the General Header specifies the session this command belongs to. 4.6 End Sampling (Message Type = END_SAMPLING) This is used to terminate an existing sampling. The END_SAMPLING Request message does not have a payload and it makes use of the General Header only. The Session ID field in the General Risso & Dutt Expires August 2, 2003 [Page 19] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 Header specifies the session this command belongs to. In response to the END_SAMPLING message, the target device returns the message shown in Figure 6, which includes some statistics in the format shown in figure in Figure 7. 0 31 +-------------------------------------------------------+ / Sampling Statistics Section / +-------------------------------------------------------+ Figure 6: END_SAMPLING Reply message 4.7 Adjust Sampling Parameters (Message Type = ADJUST_SAMPLING_PARS) This message is used to change some of the current parameters of the capture (filter, samping information, data connection parameters). 4.8 Get Sampling Statistics (Message Type = GET_SAMPLING_STATS) This message is used to obtain statistics related to an existing capture session. The Request message does not have a payload and it makes use of the General Header only. The Session ID field in the General Header specifies the session this command belongs to. The information provided by the GET_SAMPLING_STATS Reply can be retrieved by other ways (for example through SNMP queries). However, workstations hosts do not usually have SNMP installed; this message enables these devices to get the most relevant statistical information. The format of the response is shown in Figure 7. The fields contained into the Reply message are: o Packets Dropped by Interface: it gives the number of packets dropped by the physical interface due to lack of resources. Although this parameter is meaningless on router and switches, it represents a possible event in case of software capture. This happens indeed when the capturing workstation is overhelmed by packets and the operating system is not able to give service to the high number of interrupts arriving from the network card. o Packets Successfully Received by Interface: it represents the total number of packets that have been succesfully received by the network interface. This number depends on the flags selected for the capture. For instance, if the current section captures only inbound packets (flag SAMPFLAG_INBOUND_ONLY) this number takes Risso & Dutt Expires August 2, 2003 [Page 20] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 into accounts the total number of inbound packets received by the interface. o Packets Submitted to the Filter: it keeps the actual number of packets that have been selected by the sampling mechanism and that have been submitted to the filtering engine. o Packets Matching the filter: it represents the total number of packets that satisfy the filter. o Packets Dropped After Filtering: after applying a filtering function, the sampling process sends the packet to the collecting process. However, for several reasons, this delivery might not be done immediately and the packets must be temporarily stored into the sampling buffer for a delayed delivery. This counter gives the number of packets that have been dropped due to lack of resources (e.g. lack of space into the sampling buffer) before being able to send them to the collecting process. In case of lack of space, the less recent data is overwritten. o Packets Sent to the Collecting Device: it represents the total number of packets that have been sent to the collecting device. This number can be derived from the number of packets that matched the filter minus the ones dropped after filtering and the ones that are actually stored into the sampling buffer (and that are still waiting to be transmitted). It is worth noticing that this number can be higher than the number of packets received by the collecting device, since there can be some packets "in flight" into the network. All the previous numbers refer from the instant of time in which the sampling began to the instant of time in which the statistics have been requested to the sampling process. Risso & Dutt Expires August 2, 2003 [Page 21] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 0 31 +-------------------------------------------------------+ | Packets Dropped by Interface (high) | +-------------------------------------------------------+ | Packets Dropped by Interface (low) | +-------------------------------------------------------+ | Packets Successfully Received by Interface (high) | +-------------------------------------------------------+ | Packets Successfully Received by Interface (low) | +-------------------------------------------------------+ | Packets Submitted to the Filter (high) | +-------------------------------------------------------+ | Packets Submitted to the Filter (low) | +-------------------------------------------------------+ | Packets Matching the Filter (high) | +-------------------------------------------------------+ | Packets Matching the Filter (low) | +-------------------------------------------------------+ | Packets Dropped After Filtering (high) | +-------------------------------------------------------+ | Packets Dropped After Filtering (low) | +-------------------------------------------------------+ | Packets Sent to the Collecting Device (high) | +-------------------------------------------------------+ | Packets Sent to the Collecting Device (low) | +-------------------------------------------------------+ Figure 7: GET_SAMPLING_STATS Reply message 4.9 Error Message (Message Type = ERROR) In case of an error in processing any of the commands listed before, the response is a message called ERROR message. This message does not have the Request and Reply form and it comes only as a Reply. The format of this message is shown in Figure 8. 0 31 +-------------------------------------------------------+ / Error String / +-------------------------------------------------------+ Figure 8: ERROR Message This message puts an Error Code (i.e. the numeric code of the error occurred) into the Value field of the General Header, while the Error String keeps a string description of the error. The length of the error string can be derived from the length of the RESCAP payload, Risso & Dutt Expires August 2, 2003 [Page 22] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 contained into the General Header. The Session ID field in the General Header specifies the session this command belongs to. Risso & Dutt Expires August 2, 2003 [Page 23] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 5. Data Connection: Packet Format The format of the data exchaged over the data connection is very simple. Each packet is preceded by the header shown in Figure 9. The most relevant fields are the following: o Timestamp (sec): a value (derived from the 'tv_sec' field of the structure 'timeval' defined in the BSD sockets) that keeps the timestamp of the packet in seconds. o Timestamp (microsec): a value (derived from the 'tv_usec' field of the structure 'timeval' defined in the BSD sockets) that keeps the timestamp of the packet in microseconds. o Captured Length: it keeps the number of bytes of the packet that have been stored into the Packet Dump field. o Packet Length: it keeps the actual length of the packet, off wire. o Packet Number: each packet within a session are marked by the sampling process with a progressive number; this field is a 64 bit counter that keeps the ordinal number of the packet in the current session. This field must be used by the collecting machine to detect any packet loss (and react appropriately) in case a UDP data channel is used. o Packet Dump: the exadecimal dump of the portion of the packet that has been captured. Risso & Dutt Expires August 2, 2003 [Page 24] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 0 31 +-------------------------------------------------------+ | Timestamp (sec) | +-------------------------------------------------------+ | Timestamp (microsec) | +-------------------------------------------------------+ | Captured Length | +-------------------------------------------------------+ | Packet Length | +-------------------------------------------------------+ | Packet Number (high) | +-------------------------------------------------------+ | Packet Number (low) | +-------------------------------------------------------+ / Packet Dump / +-------------------------------------------------------+ Figure 9: Format of the Packets on the data connection Each packet is preceded by the header above and it is sent over the data connection by means of a distinct message. Risso & Dutt Expires August 2, 2003 [Page 25] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 6. RESCAP Codes and Values This section lists all the codes and the values that have been allocated to the RESCAP Protocol. Protocol Ports The port on which the sampling device waits for connection is . Timers The values for the RESCAP timer are the following: * INIT_TIMEOUT: 30 sec. * RUN_TIMEOUT: 90 sec. * ADJUST_PARS_TIMEOUT: 60 sec, plus or minus 5 sec (randomly calculated). This is used to prevent syncronization issues between ADJUST_SAMPLING_PARS messages. * AUTH_FAIL_TIMEOUT: 5 sec. Protocol Messages The codes used for RESCAP protocol messages are the following: * AUTH: code 1. * OPEN_SESSION: code 2. * CLOSE_SESSION: code 3. * CLOSE: code 4. * START_SAMPLING: code 5. * END_SAMPLING: code 6. * UPDATE_SAMPLING_PARS: code 7. * GET_SAMPLING_STATS: code 8. * ERROR: code 9. Protocol Flags The flags used in some messages of the RESCAP protocols assume the following values: * Risso & Dutt Expires August 2, 2003 [Page 26] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 Authentication Types The types of authentication currently supported are: * AUTH_NULL: code 1. * AUTH_USRPWD: code 2. Error Codes The types of error codes currently supported are: * Risso & Dutt Expires August 2, 2003 [Page 27] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 7. Security Considerations The RESCAP protocol MUST provide means of protection against active attacks (e.g., pretending to be another identity, message insertion, deletion, modification, and replaying) and passive attacks (e.g.,eavesdropping, gaining advantage by analyzing the data or the control traffic sent over the line). The major issues related to security includes: o Authentication of the capturing device on which the remote sampling has to be done. o Authentication of host and/or user attempting the remote sampling. o Protecting the integrity of the traffic on the control and data connection to prevent third-party message manipulation. o Protecting the confidentiality of the traffic on the control and data connection to prevent third-party snooping. To accommodate such issues, RESCAP uses the following security mechanisms: o in-band authentication between the host/user attempting the remote sampling, and the capturing device where the sampling is done (carried out by exchange of RESCAP control messages); o device authentication, security association negotiation, and cryptographic key management is provide by IKE [RFC2409]; o packet protection (integrity, authentication, and confidentiality) is provided by IPsec at the IP level. The security mechanisms above complement each other. The in-band authentication provides uni-directional authentication between the host/user attempting the remote sampling and the capturing device, the IKE exchange provides device authentication, security association negotiation, and cryptographic key management, while IPsec provides a secure channel between the IP communication end points. The security mechanisms supported by RESCAP are described in the following sections. 7.1 Authentication of the user colleting samples User authentication is enabled via a username-password mechanism (passwords are protected by the underlaying security mechanism). Risso & Dutt Expires August 2, 2003 [Page 28] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 Currently defined authentication methods are: o AUTH_NULL: no authentication is required. o AUTH_USRPWD: username/password authentication is required. 7.2 Authentication of the Collecting and Sampling devices A RESCAP implementation MUST meet the cryptographic key management requirements of the IPsec protocol suite. Authentication, security association negotiation, and cryptographic key management MUST be provided by implementing IKE [RFC2409] using the IPsec DOI [RFC2407]. In a RESCAP implementation the authentication between the collecting device and the sampling device MUST support a pre-shared cryptographic key, and MAY support Certificate-based device authentication using digital signatures. 7.3 Protection of origin, integrity and confidentiality of sampled data A RESCAP compliant device MUST provide data integrity and authentication by implementing IPsec [RFC2401] with ESP [RFC2406]. Confidentiality is provided by encrypting the data in every packet. When confidentiality is used it MUST be accompanied by data integrity and authentication to provide comprehensive protection against eavesdropping, message insertion, deletion, modification, and replaying. A RESCAP compliant device MUST provide confidentiality by implementing IPsec [RFC2401] with ESP [RFC2406]. 7.4 Denial of Service Attacks RPCAP has a built-in protection for some DoS attacks. After a succesfully authentication phase has been carried out, the control connection cannot stay more than RUN_TIMEOUT idle. If this happens, the session is closed automatically. Furthermore, in case the authentication phase fails, the sampling device waits for at least AUTH_FAIL_TIMEOUT seconds before accepting another authentication message. Risso & Dutt Expires August 2, 2003 [Page 29] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 8. Acknowledgement The authors wish to thank Fabio Maino for his for his insightful help in the definition of the Security Section. Risso & Dutt Expires August 2, 2003 [Page 30] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 References [1] Duffield, N., Grossglauser, M., Rexford, J., Chiou, D., Marimuthu, P. and G. Sadasivan, "A Framework for Passive Packet Measurement", Internet Draft Work In Progress, November 2002. Authors' Addresses Fulvio Risso Politecnico di Torino Corso Duca degli Abruzzi, 24 Torino 10129 Italy Phone: +39 011 564 7008 EMail: fulvio.risso@polito.it URI: http://www.polito.it/~risso/ Dinesh G. Dutt Cisco Systems 375 East Tasman Drive San Jose, CA 95134 US Phone: +1 408 527 0955 EMail: ddutt@cisco.com Risso & Dutt Expires August 2, 2003 [Page 31] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 Appendix A. Choosing the appropriate number of bits for packet counters The maximum number of packets on a 10Mbps Ethernet is approximately 15 Kpps (14880 packets per second). On high speed networks, this value becomes a fairly large number (for instance, 15Mpps on a 10Gbps link). A 32 bits-wide counter could not be enough, since an overflow can occur in a small time period (less than 3 minutes). Therefore, the size for packet counters has to be 64 bits in order to address future needs. A similar computation shows that also a 32 bits-wise counter for data size could not be enough, since 4GB is equivalent to less than 4 seconds of traffic on a full-speed 10 Gigabit Ethernet. Hence, also variables that gives the value of the data actually being trasferred must use 64 bit counters. Risso & Dutt Expires August 2, 2003 [Page 32] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Risso & Dutt Expires August 2, 2003 [Page 33] Internet-Draft REmote Sample and CApture Protocol (RESCAP) February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Risso & Dutt Expires August 2, 2003 [Page 34]