INTERNET-DRAFT M. Meiss draft-rfc-editor-rfcxxxx.txt Y. Jin Category: Informational S. Wallace Expires: June, 2003 Indiana University December 2002 Layer 2 Query Protocol Status of this Memo "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited." Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Because the most problems of end-to-end performance are found in the last router hop, it is necessary to develop tools to locate and track problems in the local network. This paper describes a protocol which provides layer 2 based query services, introduces the principle of each service, and states how the query works under designed protocol. Table of Contents 1. Introduction 1.1 Motivation 1.2 Key Features 2. Terminology 2.1 Specification of Requirements 2.2 Terminology 3. Mechanism 3.1 Operation 3.2 L2QP Model 3.3 Model Specification 4. L2QP Packet 4.1 L2QP Header Format 4.2 L2QP Requests 4.3 L2QP Responses 4.4 Keyed MD5 Output 5. Query Type Specification References(no reference on latex version document) Author's Address 1. Introduction Meiss Informational [Page 1] INTERNET-DRAFT Layer 2 Query Protocol December 2002 1.1 Motivation The objectives of the L2QP are 1) to promote tracking and troubleshooting performance problems in the local network which could be outside organizations, 2) to build a standard way to discover and visualize Ethernet broadcast domains, 3) to build a standard way to find the actual switching path to a host, 4) to create an appropriate method to cooperate a multi-vendor environment. This paper assumes knowledge of the Transmission Control Protocol (TCP) [1], the User Datagram Protocol (UDP) [2], the TraceRoute [3] and the Internet Control Message Protocol (ICMP) [4]. 1.2 Key Features The key features of the L2QP are: 1. A standard service on the router side The L2QP protocol would be implemented as a standard service on the router side and would use TCP for transport since TCP works better through Network Address Translation (NAT) and the amount of information passed may exceed MTU. 2. Flexibility Users do not need to be given SNMP access to either switches or routers to make use of L2QP. 3. IP6 support It is designed to be IP4 and IP6 compatible, so the IP address mentioned below can be either IP4 or IP6. 4. Network Security The responses to the client are authenticated through the use of the MD5 algorithm. 5. Extensible protocol The primary purpose of the L2QP is to provide layer 2 query services. In this protocol, following services are described: topology information requests, layer-2 traceroute service, layer-2 incremental ping service, media type query, congestion query, and available services query. However, the services are extendable and more features can be added without disturbing existing implementations of the protocol. 2. Terminology 2.1 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully Meiss Informational [Page 2] INTERNET-DRAFT Layer 2 Query Protocol December 2002 weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 2.2 Terminology The document uses the following terms: service - The L2QP provides layer 2 services, such as topology information requests and layer-2 traceroute service, which are described in section 5. query - This means the users compose the L2QP packet to request the L2QP services. Sometimes "query" and "service" means the same thing. silently discard - This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet. 3. Mechanism 3.1 Operation The L2QP protocol follows a client/server model that the client sends the request to the server and the server implements the query and sends back the result to the client. When users request a service from a L2QP server, they send a L2QP packet describing the type of service, the destination they are interested, the port number they would take responses and the IP address version they are preferred in their responses. Once the server receives the requests, the users will get a feed back which indicates the packet has been delivered successfully. Then the server creates a TCP connection with the client to transfer the query results. This process continues until the server send a close message to stop the connection. The L2QP takes advantages of the traceroute routine to send the users' request to the server. The traceroute lists all the intermediate routers a connection must pass through to get to its destination and shows how the target system is connected in layer-3 level. This document will not go into the details about the mechanism of traceroute. Please refer to Traceroute Using an IP Option [3] for that information. However, how to determine when the destination has been reached is emphasized here since it is important for understanding this protocol. Traceroute sends UDP datagrams, which are packed with the L2QP information, to the destination host, but it chooses the destination UDP port number to be an unlikely large value (> 30,000), making it improbable that an application at Meiss Informational [Page 3] INTERNET-DRAFT Layer 2 Query Protocol December 2002 the destination is using that port. When the datagram arrives, the destination host's UDP module generates an ICMP "port unreachable" error, which is different from the received ICMP message-time exceeded before reaching the destination. The use of the traceroute in request sending allows users to get the query result in a mixture of layer-2 and layer-3, but it is not feasible for the responses. The responses of the L2QP are sent through the TCP connection, which will be built after the server finishes the queries and ready to send back results to users. 3.2 L2QP Model The following model (shown in Figure 1) MAY be diagrammed for L2QP structure. L2QP Client (Running on a Router) +--------------------| (a)L2QP Traceroute +---------------------+ |/------\ /--------\|with Query Requests |/------\ /--------\| || L2QP <--> L2QP |<====================>| L2QP |(1)| L2QP || || UI | | RI || ICMP Responses || RH |-->| Engine || |\--^---/ \--------/| |\------/ \--------/| | | | | |(2) | | | | | | | | | | | |/------\ /---v----\| (b)TCP Connection |/---v---\ |(3) | || XML <--| L2QP |<====================>| L2QP | | | ||Parser| | RR || Query Responses || RS |<-----+ | |\------/ \--------/| |\-------/ | +--------------------+ +---------------------+ NOTES: 1. (a) is processed first. Only if it is successful (L2QP RH gets the Query Requests from the client), (b) will be activated to create a TCP connection with the client. 2. Messages flow among models in L2QP Server side: (1) The L2QP RH sends the requests to the L2QP Engine (2) The L2QP RH sends the Client IP and Port number to the Response Sender for creating TCP connection (3) The L2QP Engine sends the Query results in XML format to the L2QP RS Figure 1 The L2QP Model The terms in Figure 1: L2QP UI -- L2QP user interface L2QP RI -- L2QP Request Interpreter L2QP RR -- L2QP Response Receiver L2QP RH -- L2QP Request Handler L2QP RS -- L2QP Response Sender In the model described in Figure 1, the user interface accepts the Meiss Informational [Page 4] INTERNET-DRAFT Layer 2 Query Protocol December 2002 users' inputs which are forwarded to the L2QP RI. Having received the users' requests, the L2QP RI composes the L2QP packet, and initiates a traceroute routine to send out the packet described in section 4.1, L2QP Header Format. Once the Traceroute successfully sends the packets to the destination where users want to make the query, the L2QP RI will get an ICMP message indicating that the process is finished. Then the L2QP RI activates the L2QP RR to listen on the port specified by the user for a TCP connection. On the server side, the L2QP RH deals with the L2QP packets and calls the L2QP Engine. The L2QP Engine provides back-end services to carry out the query. Each invoked service returns the results or error messages in XML format to the L2QP RS. These XML format responses will be encrypted using MD5 and packed into a TCP body in the L2QP RS. To make a TCP connection with the clients, the L2QP RS also need to obtain the client's IP and port number. After the connection is created, the L2QP RS sends XML format responses following keyed MD5 output to the L2QP RR. The connection continues until the L2QP RR gets a close message. (Please refer to section 4.3 for more information). Except receiving the responses from the server, the L2QP RR also checks the XML message with the keyed MD5 output. If they match, the L2QP RR sends the XML responses to the XML parser and at last the parsed XML goes to the user for displaying. 3.3 Model Specification 3.3.1 L2QP UI To make a L2QP query, users should provide following information: (a) The IP address of the destination router which they would like to query (b) The port number which is used to create the TCP connection with the server (c) Service requests with the appropriate parameters if applicable (d) IP addresses(IP4/IP6) representation for the responses In this scenario, the port number used for TCP connection SHOULD not be used by any other applications or L2QP requests. The user interface SHOULD allow users specify multi-services and could display the address for both IP4 and IP6. 3.3.2 L2QP RI The L2QP Request Interpreter takes users' requests (as described in section 3.3.1) from the L2QP UI. First, it validates the request and checks if the query provides the appropriate parameters. It returns the error message if the validation fails. Otherwise, it composes the L2QP packet (Please refer to the section 4.1) which is encapsulated in the UDP data field. Once the L2QP packet is ready, the L2QP UI initiates a traceroute routine which carries the L2QP packet and takes the router's IP address as the destination. When the L2QP RI receives the ICMP messages Meiss Informational [Page 5] INTERNET-DRAFT Layer 2 Query Protocol December 2002 generated by traceroute, it sends to the user interface for displaying. If it obtains an ICMP which indicates that the L2QP packet reaches the destination already, the L2QP RI activates the L2QP RR to listen on the port provided by users for a TCP connection. 3.3.3 L2QP RH When the traceroute routine, which carries the L2QP packet, gets to the destination router, the router checks the first 4 bytes field right behind the UDP header. If the first 4 bytes has the identification "L2QP", the router sends the packet to the L2QP Handler; otherwise, it will be silently discarded. The L2QP Handler processes the L2QP packet, extracts the IP address of the client from the UDP header, and obtains the following information from the L2QP header (Please refer to the section 4.3.1): (a) The version of the L2QP which helps the server properly interpret the request (b) The PORT number is used to make the TCP connection with the server (c) The number of the query requests in this packet (d) The preferred address format (IP4 or IP6) in responses According to the number of the query requests, the L2QP RH processes each query and sends them to the L2QP Engine. 3.3.4 L2QP Engine The L2QP Engine implements the services' query, gets the results in XML format, and signs it using MD5. The XML format is defined in section 4.3, L2QP Responses; the signature are described in section 4.4, Keyed MD5 Output. Before the L2QP Engine performs any query, it first makes sure that the client has the right to use the protocol and the query services are available. An access list and an available service list MUST be maintained by router administrators to restrict the use of the protocol. In three cases that the L2QP Engine SHOULD return the error messages to the users: 1. The user has no permission to use the protocol 2. The service is not available, or 3. The query cannot be completed The error message is also defined in section 4.3. 3.3.5 L2QP RS The L2QP Response Sender is activated when the L2QP RH finishes the L2QP packet handling and sends it the client IP address and Meiss Informational [Page 6] INTERNET-DRAFT Layer 2 Query Protocol December 2002 PORT number. The L2QP RS then makes a TCP connection with the client. After it gets the responses from the L2QP Engine, the L2QP RS wraps them in a TCP packet and transfers the packet to the L2QP RI. This transformation process continues until the last query response has been sent out and the L2QP RS sends a close message to end the connection. The close message is defined in section 4.3. 3.3.6 L2QP RR The L2QP Response Receiver is activated when the L2QP RI receives an ICMP message that indicates the traceroute packet has reached the destination router. It is waiting on the specified port for the TCP connection from the L2QP RS on the server side. The connection will be ended when the L2QP RR receives a close message. Since the responses are authenticated, the L2QP RR needs to first validate the message and then sends it to the XML Parser. If there is no connection from the server or no responses returned within a length of time, the L2QP RR will timeout and return the users with error messages. 3.3.7 XML Parser The XML Parser is responsible for parsing the XML format responses from the L2QP RR and sends the message to the user interface for displaying. 4. L2QP Packet 4.1 L2QP Header Format The L2QP is layered upon UDP/TCP and its header immediately follows the UDP/TCP header. The L2QP header carries several fields, which indicates the packet is a L2QP and provides the information specifying the query requests. Since the L2QP allows multiple queries in one request, the header is divided into two parts: general header and specific header. The general header includes the information which is adopted by all queries; whereas the specific header provides the service type, length and ID which are different for each query. L2QP Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+ | L2QP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Version | #Query | Port# | |-> I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | IP4/IP6 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+ Meiss Informational [Page 7] INTERNET-DRAFT Layer 2 Query Protocol December 2002 | Type | Length(in byte) | Identifier |---> II +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length(in byte) | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ....... Notes: a. one tick mark represents one bit position b. I indicates the general header; II indicates the specific header Figure 2 L2QP Header Format 2.1.1 General Header L2QP (4 bytes) The field contains the 4 bytes information "L2QP" which immediately follows the TCP/UDP header that helps the router to identify that this is a L2QP packet. Version (1 byte) Specifying the version of the L2QP is used. The version control is helpful for the future extension with more services and features. #Query (1 byte) The number of queries is included in this packet. When unpacking a packet, the server only reads the queries with specified number. If more queries in the packet other than specified number, those queries will be ignored. If the number is 0 or the number exceeds the actual queries provided, the packet will be silently discarded. PORT# (2 bytes) If the traceroute successfully delivers the packet to the server, the client will listen on this port for a TCP connection which is created by the server to transfer XML responses. IP4/IP6 (4 bytes) The field aims to provide the IPv6 support. The users can offer the version of IP address(IP4/IP6) they want to get in their responses. Meiss Informational [Page 8] INTERNET-DRAFT Layer 2 Query Protocol December 2002 2.1.2 Specific Header Each query must have a specific header before the message body. Type (1 byte) The type is used to differentiate the query types that provided by the L2QP. Each query type corresponds to a number which simplifies the representation. 1 - Available services query 2 - Topology information requests 3 - Layer-2 traceroute service 4 - Layer-2 incremental ping service 5 - Media type query 6 - Congestion query Length (2 bytes) The field specifies the length for the message body of the query. In a response packet, this length also includes keyed MD5 output. ID (1 byte) The field is used to identify queries since the same query type may occur more than once in a packet. The ID in the response packet helps clients to match the request. 4.2 L2QP Requests The message body for the L2QP request contains the parameters the query type required. It is possible that a query does not have a body. 4.3. L2QP Responses If users make multiple queries in one request, it is not necessary to pack all results in one TCP packet. The responses can be separated depending on the speed of the query. Queries taking less time can be sent earlier. In a response packet, the #Query indicates the number of the results in this packet. The message body for a L2QP response not only includes a XML formed query result, but also follows a keyed MD5 output for the response message. Each specific header MUST contains a message body with either XML formed responses or error messages, and corresponding keyed MD5 output. Three types of message are defined in this section: Query Result, Error Message and the Close Message. 1. Query Result When the L2QP Engine finishes the query, it composes the results Meiss Informational [Page 9] INTERNET-DRAFT Layer 2 Query Protocol December 2002 in XML format. Following DTD file defines the criteria for a query result. 2. Error Message 3. Close Message A close message is a L2QP response packet with the #Query setting to 0. 4.4 Keyed MD5 Output The client and the L2QP server share a secret key, a random large number, which should be unpredictable and unique over the lifetime of Meiss Informational [Page 10] INTERNET-DRAFT Layer 2 Query Protocol December 2002 the transformation. The shared secret key can be obtained by using PKI key distribution or other key distribution technologies. The keyed MD5 output is calculated over a stream of octets consisting of: the L2QP response packet, beginning with the specific header of each query, including the Type, Length, Identifier and the XML formed response message followed by the shared secret key. That is, Keyed MD5 Output = MD5(Type+Length+ID+XML_Message+SecretKey). In client side, when the users received the responses from the server, it first using the same way to encrypt the (Type+Length+ID+XML_Message+SecretKey), and then compare it with the keyed MD5 output from the server. If the two matches, it means that the message is not hacked, corrupt or incomplete. 5. Query Type Specification References [1] Postel, Jon, "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [2] J. Postel, "User Datagram Protocol", RFC 768, 28 August 1980. [3] G. Malkin, "Traceroute Using an IP Option", RFC 1393, January 1993 [4] J. Postel, "INTERNET CONTROL MESSAGE PROTOCOL - DARPA Internet Program Protocol Specification", RFC 792, DARPA, September 1981. [5] P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", RFC 1321, August 1995 [6] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138 April 1997 Authors' Address Mark Meiss Advanced Network Management Lab 501 N. Morton Street, Suite 214 Bloomington, IN 47401 Phone: +1 812-855-1878 Email: mmeiss@indiana.edu Meiss Informational [Page 11] INTERNET-DRAFT Layer 2 Query Protocol December 2002 Ying Jin Advanced Network Management Lab 501 N. Morton Street, Suite 214 Bloomington, IN 47401 Phone: +1 812-857-6073 Email: yinjin@cs.indiana.edu Steven Wallace Advanced Network Management Lab 501 N. Morton Street, Suite 214 Bloomington, IN 47401 Phone: +1 812-855-0960 Email: ssw@indiana.edu Meiss Informational [Page 12]