INTERNET-DRAFT M. Yevstifeyev Intended Status: Experimental December 17, 2010 Expires: June 20, 2011 Hardware Configuration Information Transfer Protocol Version 0.9 (HCITP/0.9) Abstract This document is a specification of Hardware Information Configuration Transfer Protocol version 0.9 (HCITP/0.9). This protocol is used to request and transfer information about hardware and can occasionally be used to request information about OS. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Yevstifeeyv Expires June 20, 2011 [Page 1] INTERNET DRAFT HCITP v0.9 December 17, 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Interaction with Other Protocols . . . . . . . . . . . . . 4 2.2. Functional Description . . . . . . . . . . . . . . . . . . 4 2.3. Model of Work . . . . . . . . . . . . . . . . . . . . . . . 4 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. The Parameters of the Protocols of Lower Levels . . . . . . 6 3.1.1. TCP Parameters . . . . . . . . . . . . . . . . . . . . 6 3.1.2. IPv4 Parameters . . . . . . . . . . . . . . . . . . . 6 3.1.3. IPv6 Parameters . . . . . . . . . . . . . . . . . . . 6 3.2. Protocol Specification . . . . . . . . . . . . . . . . . . 6 3.2.1. Client Commands . . . . . . . . . . . . . . . . . . . 6 3.2.2. Server Response Codes . . . . . . . . . . . . . . . . 7 3.2.3. The Reaction of Server . . . . . . . . . . . . . . . . 8 3.3. Device Numbers to Be Used with HCITP . . . . . . . . . . 10 3.4. Information Formation Rules . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 14 5.2. Devices Numbers Registry . . . . . . . . . . . . . . . . 14 6. Normative References . . . . . . . . . . . . . . . . . . . . 15 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Yevstifeeyv Expires June 20, 2011 [Page 2] INTERNET DRAFT HCITP v0.9 December 17, 2010 1. Introduction The protocol, defined by this document - HCITP, is used to provide possibility to request and transfer the information about hardware configuration and can occasionally be used for requesting information about OS. The main purpose of defined protocol is to provide the auxiliary service (in addition to some sort of 'major' protocol, such as HTTP or FTP), which will allow the server to check its client's hardware so that it would get known if the service it provides is appropriate for it. For instance, some HTTP server (let it be A) is going to transfer to its client (let it be B) some software, which requires special hardware or its configuration. So A sends HCITP request to B to check the configuration of B's hardware. When it receives answer it may continue transferring the information or warn the client that the information is not appropriate for it. Nevertheless client may choose to download it or not. Another way it can be used is controlling large networks, where some kind of hardware may be added but needs to be controlled. This document defined he preliminary version of HCITP - HCITP/0.9. Note that the protocol is Experimental and intended to be in Limited Use while experimenting. The final version - 1.0 - will include many issues not discussed by this document. 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This specification uses the Augmented Backus-Naur Form (ABNF) notation and core rules of [RFC5234]. The construction #element is used as defined in RFC 2616 [RFC2616]. Yevstifeeyv Expires June 20, 2011 [Page 3] INTERNET DRAFT HCITP v0.9 December 17, 2010 2. Overview 2.1. Interaction with Other Protocols The interaction of HCITP and other protocols are shown at the picture below. +---------+ | HCITP | +---------+ | +---------+ | TCP | +---------+ | +---------+ | IP | +---------+ | +-------------------------+ | Physical Layer Protocol | +-------------------------+ Picture 1. The interaction of protocols. 2.2. Functional Description HCITP is used to request and transfer information about hardware configuration of the computer. HCITP uses TCP a as a lower level protocol. TCP-based HCITP uses text commands and response codes to exchange information. HCITP commands and response codes are defined in Section 3.2. 2.3. Model of Work HCITP is a client-server protocol. Each computer can be as server, as client. A computer which requests information is a client. A computer which answers the client is a server. The server listens a TCP port TBD1 for incoming TCP connections. As soon as TCP connection is established, nodes begin to exchange commands and answers. A server closes a transaction if a client sent a corresponding command or the server hasn't received the commands for a definite period of time. While processing request some errors may occur. In this case a server Yevstifeeyv Expires June 20, 2011 [Page 4] INTERNET DRAFT HCITP v0.9 December 17, 2010 SHOULD send an Error Response (ER). After receiving ER a client MAY repeat the request. If the information is requested about the device which is not present in the server's system, it SHOULD send ER with the corresponding error code. In that case a client shouldn't repeat the request. Yevstifeeyv Expires June 20, 2011 [Page 5] INTERNET DRAFT HCITP v0.9 December 17, 2010 3. Specification 3.1. The Parameters of the Protocols of Lower Levels 3.1.1. TCP Parameters HCITP uses TCP ([RFC793]) with the following parameters: a) Client and Server ports - TBD1. b) another fields - depending on the packet. 3.1.2. IPv4 Parameters HCITP uses IPv4 ([RFC791]) with the following parameters: a) Version - 4; b) Flags - None; c) ToS - 00000000; d) TTL - 128; e) another fields - depending on the packet. 3.1.3. IPv6 Parameters HCITP uses IPv6 ([RFC2460]) with the following parameters: a) Version - 6; b) Traffic Class - 2; c) Hop Limit - 128; d) another fields - depending on the packet. 3.2. Protocol Specification 3.2.1. Client Commands This section defines client commands which are used with HCITP. Commands are used by clients to request a definite information or send any information to the server (e. g. opening the connection) The general syntax of HCITP command is: hcitp_command = command_name [SP command_parameter] command_name = token ;see description below command_parameter = token ;see description below part in the command MAY be as REQUIRED as OPTIONAL, depending on the command. Yevstifeeyv Expires June 20, 2011 [Page 6] INTERNET DRAFT HCITP v0.9 December 17, 2010 The following commands MUST be supported by all HCITP nodes. HCITP commands: OPE - is used to open the HCITP connection. The syntax is given below. ope_command = "OPE" SP timeout timeout = 1*3DIGIT ;connection timeout in seconds REQ - is used to request the information about device. The syntax is given below. req_command = "REQ" SP device_code device_code = 1*3DIGIT ;see Section 3.3 ACK - acknowledgment of received information - is used to sure that the client has received the information. Refers to the latest answer. The syntax is given below. SHOULD be sent after each server response with codes 200, 402 and 404 (see Section 3.2.3). ack_command = "ACK" INF - is used to request the information about the transaction. The syntax is given below. inf_command = "INF" RST - is used to reset the connection. The syntax is given below. rst_command = "RST" CLS - is used to close the transaction. The syntax is given below. cls_command = "CLS" The reaction of server is described below (see Section 3.2.4 ) 3.2.2. Server Response Codes This section describes the codes which are used by servers to answer the commands. The general syntax of HCITP Response is: hcitp_response = response_code [SP response_information] response_code = 3DIGIT ;see description below response_information = token ;the information which concerns the ;answer part of Response MAY be as REQUIRED as OPTIONAL, depending on the code. HCITP response codes: 200 - OK. IS used to answer the REQ and INF commands. The syntax is given below. ok_response = "200" SP response_information 201 - Connection opened. Is used to answer the OPE command. The syntax is given below. conn_op_response = "201" [SP response_information] 202 - Connection closed. Is used to answer the CLS command. The Yevstifeeyv Expires June 20, 2011 [Page 7] INTERNET DRAFT HCITP v0.9 December 17, 2010 syntax is given below. conn_cl_response = "202" [SP response_information] 400 - HCITP not used. Used to answer the OPE command. The syntax is given below. hcitp_not_used_response = "400" [SP response_information] 401 - HCITP not allowed to be used. Used to answer the OPE command. The syntax is given below. hcitp_not_allowed_response = "401" [SP response_information] 402 - Information about the requested device is not allowed to be transferred. Used to answer the REQ command. The syntax is given below. device_not_allowed_response = "402" [SP response_information] 403 - TCP-based HCITP not used. Used to answer the OPE command. The syntax is given below. tcp_hcitp_not_used_response = "403" [SP response_information] 404 - Information is requested about absent device. Used to answer the REQ command. The syntax is given below. device_absent_response = "404" [SP response_information] 405 - Wrong command. Used to answer the unknown command (not listed in Section 3.2.2). The syntax is given below. wrong_command_response = "405" [SP response_information] 3.2.3. The Reaction of Server This section defines a reaction of server to the commands (see Section 3.2.2) and other events. If a server receives an 'OPE' command, it can send 201, 400, 401 or 403 codes. Code 201 is sent if server is able to open a connection. In this case it opens a connection with a corresponding timeout value (defined in command option). If HCITP is not used, it sends a code 400 and closes the TCP connection. If HCITP is not allowed to be used, the server sends 401 code and closes TCP connection. If TCP- based HCITP is not supported, the server sends code 403 and closes TCP connection. If a server receives 'REQ' command, it can send 200, 402 or 404 codes. Code 200 is sent with an 'Information' part containing information about the requested device (defined in the command option). (See Section 3.5 for device numbers.) In this case the server keeps the TCP connection alive. Code 402 is sent if the information about requested device is not allowed to be transferred. In this case the server keeps the TCP connection alive. Code 404 is sent if the information is requested about the device, which is not present in the client's system. In this case the server keeps the TCP connection alive. If a server receives the 'ACK' command, it continues to listen for Yevstifeeyv Expires June 20, 2011 [Page 8] INTERNET DRAFT HCITP v0.9 December 17, 2010 other commands. No response is sent. If a server doesn't receive the 'ACK' command after sending the response, it MAY try to repeat the answer. If an ACK command haven't been received during the timeout value, server closes TCP connection without sending any codes. If a server receives the 'INF' command, it sends 200 code followed with an information about the transaction. The 'Information' part of this response syntax is arbitrary. If a server receives the 'RST' command, it closes the TCP connection without sending any response codes. If a server receives the 'CLS' command, it SHOULD send 202 command and close the TCP connection. If a server haven't received any commands during the timeout value time, it closes TCP connection without sending any response codes. Yevstifeeyv Expires June 20, 2011 [Page 9] INTERNET DRAFT HCITP v0.9 December 17, 2010 3.3. Device Numbers to Be Used with HCITP This section defines numbers of devices, which are used to identify them in HCITP commands. HCITP uses device numbers from 0 to 9999. 0 - reserved; 1 - processor; 2 - RAM; 3 - motherboard; 4 - hard drive; 5 - network interface card; 6 - VGA; 7 - sound card; 8 - optical drive; 9 - floppy drive; 10 - monitor; 11 - printer; 12 - scanner; 13 - web-camera; 14 - mouse; 15 - keyboard; 16 - OS; 17-254 - not assigned; 255, 256 - reserved; 257-9998 - not assigned; 9999 - reserved. 3.4. Information Formation Rules This paragraph describes the rules of formation the information about each device, defined in the Section 3.3. processor_information = frequency SP capacity ;information ;about processor frequency = 1*DIGIT ;clock frequency in MHz capacity = 1*3DIGIT ;processor capacity ram_information = size ;information about RAM size = 1*DIGIT ;size in Mb motherboard_information = manufacturer SP model ;information ;about motherboard manufacturer = token ;manufacturer name model = token ;the model of motherboard hdd_information = size ;information about hard drive size = 1*DIGIT Yevstifeeyv Expires June 20, 2011 [Page 10] INTERNET DRAFT HCITP v0.9 December 17, 2010 nic_information = max_speed SP current_speed ;information ;about network interface card max_speed = 1*DIGIT ;maximum speed in Kbit/sec current_speed = 1*DIGIT ;current speed in Kbit/sec vga_information = vga_memory_size SP 3d_accelerator ;information about video graphics adapter vga_memory_size = 1*DIGIT ;size of video memory 3d_accelarator = "1" / "0" ;1 - present, 0 - absent sound_board_information = manufacturer SP model ;information ;about soundboard manufacturer = token ;manufacturer name model = token ;the model of soundboard optical_drive_information = readable_discs "|" writable_discs ;information about optical drive readable_discs = 1#disc_name writable_discs = 1#disc_name disc_name = "CD-R" / "CD-ROM" / "CD-RW" / "DVD-R" / "DVD+R" / "DVD-R DL" / "DVD+R DL" / "DVD-RW" / "DVD+RW" / "DVD-RW DL" / "DVD+RW DL" / "DVD-RAM" / "DVD-D" / "DVD-A" / "DVD-ENAV" / "BD-R" / "BD-RE" / "BD-ROM" / "HD-DVD" / "HD-VMD" / "CH-DVD" / "UDO" / "UMD" / "HVD" / disc_name =/ token floppy_dive_information = is_present ;floppy drive information is_present = "1" | "0" ;1 - present, 0 - present monitor_information = wide SP height ;monitor information wide = 1*DIGIT ;wide-resolution height = 1*DIGIT ;height-resolution printer_information = is_present ;printer information is_present = "1" | "0" ;1 - present, 0 - present scanner_information = is_present ;scanner information is_present = "1" | "0" ;1 - present, 0 - present webcam_information = is_present ;web camera information is_present = "1" | "0" ;1 - present, 0 - present mouse_information = manufacturer SP model ;information ;about mouse manufacturer = token ;manufacturer name model = token ;the model of mouse Yevstifeeyv Expires June 20, 2011 [Page 11] INTERNET DRAFT HCITP v0.9 December 17, 2010 keyboard_information = manufacturer SP model ;information ;about keyboard manufacturer = token ;manufacturer name model = token ;the model of keyboard os_information = name SP version_registry [*("." version_registry)] ;OS Information name = token ;the name of OS version_registry = 1*3DIGIT ;version registry token = Yevstifeeyv Expires June 20, 2011 [Page 12] INTERNET DRAFT HCITP v0.9 December 17, 2010 4. Security Considerations HCITP itself does not provide any security possibilities. It is considered that it may be used to find out vulnerable systems via receiving information about vulnerable OS version etc. Because of this all HCITP implementations SHOULD support ACL (access control lists), which would allow or restrict transferring information about definite device or to definite destination. HCITP does not provide any authentication or encryption services. These issues are intended to be added to the final version of HCITP. Moreover, HCITP nodes SHOULD NOT open more than 256 connections at the same time. This restriction will make DDoS-like attacks through HCITP impossible. Yevstifeeyv Expires June 20, 2011 [Page 13] INTERNET DRAFT HCITP v0.9 December 17, 2010 5. IANA Considerations 5.1. Port Assignment IANA has assigned the TCP port number TBD1 to be used with HCITP. 5.2. Devices Numbers Registry IANA has created the registry called 'HCITP Devices Numbers', which consists of following values: Number, Device Name, Reference. Initial values are given below; new assignments for numbers 17-254 are to be made trough Expert Review, for numbers 257-9999 - following the First Came - First Served policies; the syntax rule fors information about registered device MUST be provided for registration. Number Device Name Reference +---------+---------------------------------+---------------+ |0 |Reserved |RFC xxxx | |1 |Processor |RFC xxxx | |2 |RAM |RFC xxxx | |3 |Motherboard |RFC xxxx | |4 |Hard drive |RFC xxxx | |5 |Network interface card |RFC xxxx | |6 |VGA |RFC xxxx | |7 |Sound card |RFC xxxx | |8 |Optical drive |RFC xxxx | |9 |Floppy drive |RFC xxxx | |10 |Monitor |RFC xxxx | |11 |Printer |RFC xxxx | |12 |Scanner |RFC xxxx | |13 |Web-camera |RFC xxxx | |14 |Mouse |RFC xxxx | |15 |Keyboard |RFC xxxx | |16 |OS |RFC xxxx | |17-254 |Not assigned |RFC xxxx | |255 |Private experimentation |RFC xxxx | |256 |Reserved |RFC xxxx | |257-9998 |Not assigned |RFC xxxx | |9999 |Reserved |RFC xxxx | +---------+---------------------------------+---------------+ [RFC Editor: Replace xxxx with assigned RFC number] Yevstifeeyv Expires June 20, 2011 [Page 14] INTERNET DRAFT HCITP v0.9 December 17, 2010 6. Normative References [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Author's Addresses Mykyta Yevstifeyev 8 Kuzovkov St., flat 25 Kotovsk, Ukraine EMail: evnikita2@gmail.com Yevstifeeyv Expires June 20, 2011 [Page 15]