Internet-DRAFT Mykyta Yevstifeyev Expires: June 3, 2011 November 30, 2010 Intended Status: Experimental Hardware Configuration Information Transfer Protocol Abstract This document is a specification of Hardware Information Configuration Transfer Protocol. This protocol is used to request and transfer information about hardware. 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/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 June 3, 2011. Copyright 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 to this document. Yevstifeyev Expires June 3, 2011 [Page 1] Internet-Draft HCITP November 30, 2010 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Interaction with Other Protocols . . . . . . . . . . . . . . 3 2.2 Functional Description . . . . . . . . . . . . . . . . . . . 3 2.3 Modes of Work. . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Model of Work. . . . . . . . . . . . . . . . . . . . . . . . 4 3 Specification. . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 The Parameters of the Protocols of Lower Levels. . . . . . . 5 3.1.1 TCP Parameters. . . . . . . . . . . . . . . . . . . . . 5 3.1.2 UDP Parameters. . . . . . . . . . . . . . . . . . . . . 5 3.1.3 IPv4 Parameters . . . . . . . . . . . . . . . . . . . . 5 3.1.4 IPv6 Parameters . . . . . . . . . . . . . . . . . . . . 5 3.2 TCP-based HCITP. . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1 Connection States . . . . . . . . . . . . . . . . . . . 5 3.2.2 Client Commands . . . . . . . . . . . . . . . . . . . . 6 3.2.3 Server Response Codes . . . . . . . . . . . . . . . . . 6 3.2.4 The Reaction of Server. . . . . . . . . . . . . . . . . 7 3.3 UDP-based HCITP. . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1 The Format of Packets . . . . . . . . . . . . . . . . . 8 3.3.1.1 The Format of the Header. . . . . . . . . . . . . . 8 3.3.1.2 Fields description. . . . . . . . . . . . . . . . . 8 3.3.2 Error Messages Formation for UDP-based HCITP. . . . . .10 3.4 Information Formation Rules. . . . . . . . . . . . . . . . 10 3.5 Device Numbers to Be Used with HCITP . . . . . . . . . . . 11 4 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12 5 Security Considerations. . . . . . . . . . . . . . . . . . . . 12 6 Normative References . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Yevstifeyev Expires June 3, 2011 [Page 2] Internet-Draft HCITP November 30, 2010 1. Introduction Many protocols of the Internet are used to transfer large amount of information which can be displayed at the receiver's computer only if required hardware is present or its configuration allow to do this. Now if the receiver is not able to display the information, this information is being sent. This causes the overload of the network. Using HCITP will solve this problem by preceding transfer of information about hardware configuration of the client. 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 [RFC2119]. 2. Overview 2.1. Interaction with Other Protocols The interaction of HCITP and other protocols are shown at the picture below. +---------+ | HCITP | +---------+ / \ +---------+ +---------+ | UDP | | TCP | +---------+ +---------+ \ / +---------+ | IP | +---------+ | +-------------------------+ | Local Network 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 supports TCP as well as UDP as a lower level protocol. Every HCITP node MUST support TCP-based HCITP, but its use is OPTIONAL. TCP-based HCITP is RECOMMENDED for common use. Yevstifeyev Expires June 3, 2011 [Page 3] Internet-Draft HCITP November 30, 2010 TCP-based HCITP uses text commands and response codes to exchange information. HCITP commands and response codes are defined in Section 3.2. UDP-based HCITP use packets to exchange information. Packets consist of header and body. The format of packets is described in this document (see Section 3.3). Each node mustn't open more than 256 connection at the same time. 2.3. Modes of Work TCP-based HCITP has no modes of work. UDP-based HCITP has 3 modes of work: a) casual. If HCITP works in this mode, it just transfers the information about hardware configuration. b) "If has". This mode allows to get known the fact of presence of a device. c) trace. This mode is similar to ICMP Echo messages and is used to check the availability of using HCITP. These modes will be described below more detailed. 2.4. 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. Models of work of TCP-based and UDP-based HCITP are different. If a server uses TCP-based HCITP (see Section 3.2), it listens a TCP port XXXX 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 difinite period of time. If a server uses UDP-based HCITP (see Section 3.3), it listens the UDP port XXXX. After a server receives the HCITP request, it forms an answer and sends it to a client. Then a client SHOULD send Thank You Message (TUM) in order a server close a transaction. While processing request some errors may occur. In this case a server 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. Yevstifeyev Expires June 3, 2011 [Page 4] Internet-Draft HCITP November 30, 2010 HCITP trace messages (UDP-based HCITP) can be used like ICMP Echo messages. Generally they are used to check if HCITP can be used. The text of body in HCITP trace request MUST be similar to the text in HCITP trace answer. [TO BE DELETED Note: XXXX - a port is being approved by IANA.] 3. Specification 3.1. The Parameters of the Protocols of Lower Levels 3.1.1. TCP Parameters (as described in [RFC793]) HCITP uses TCP with the following parameters: a) Protocol - is being approved by IANA; b) Client and Server ports - is being approved by IANA. 3.1.2. UDP Parameters (as described in [RFC768]) HCITP uses UDP with the following parameters: a) Protocol - is being approved by IANA; b) Client and Server ports - is being approved by IANA. 3.1.3. IPv4 Parameters (as described in [RFC791]) HCITP uses IPv4 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.4. IPv6 Parameters (as described in [RFC2460]) HCITP uses IPv6 with the following parameters: a) Version - 6; b) QoS - 2; c) Hop Limit - 128; d) another fields - depending on the packet. 3.2. TCP-based HCITP This section specifies the TCP-based HCITP and its use. 3.2.1. Connection States Connection states are used to identify the status of HCITP connection. Connection states: NONE - no TCP and HCITP connection; CLOSED - TCP connection established, no HCITP connection; Yevstifeyev Expires June 3, 2011 [Page 5] Internet-Draft HCITP November 30, 2010 OPEN - TCP and HCITP connections established; CLOSING - TCP connection established, HCITP connection is being closed. 3.2.2. 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 scheme of HCITP command is: +---------+-+---------- | Command | | Options +---------+-+---------- \ space 'Options' part in th command MAY be as obligatory as OPTIONAL, depending on the command. The following commands MUST be supported by all HCITP nodes. HCITP commands: OPE - is used to open the HCITP connection. Has an option 'Connection Timeout' (in sec.) (up to 3 characters; integer - from 1 to 128). Can be used only in CLOSED state. REQ - is used to request the information about device. SHOULD be followed with the number of device (up to 3 characters; integer - from 0 to 255) (see Section 3.5 ). Can be used only in OPEN state. ACK - acknowledgment of received information - is used to shoe that the client has received the information. Refers to the latest answer. Has no options. SHOULD be sent after each server response with codes 200, 402 and 404. INF - is used to request the information about the transaction. Has no options. RST - is used to reset the connection. Has no actions. CLS - is used to close the transaction. Has no options. The reaction of server is described below (see Section 3.2.4 ) 3.2.3. Server Response Codes This section describes the codes which are used by servers to answer the commands. The general scheme of HCITP Response is: +---------+-+------------- | Code | | Information +---------+-+------------- \ space Yevstifeyev Expires June 3, 2011 [Page 6] Internet-Draft HCITP November 30, 2010 The 'Information' part of Response MAY be as obligatory as OPTIONAL, depending on the code. HCITP response codes: 200 - OK. IS used to answer the REQ and INF commands. The 'Information' part MUST be present in this response. 201 - Connection opened. Is used to answer the OPE command. 'Information' part is OPTIONAL. 202 - Connection closed. Is used to answer the CLS command. 'Information' part is OPTIONAL. 400 - HCITP not used. Used to answer the OPE command. 'Information' part is OPTIONAL. 401 - HCITP not allowed to be used. Used to answer the OPE command. 'Information' part is OPTIONAL. 402 - Information about the requested device is not allowed to be transferred. Used to answer the REQ command. 'Information' part is OPTIONAL. 403 - TCP-based HCITP not used. Used to answer the OPE command. 'Information' part is OPTIONAL. 404 - Information is requested about absent device. Used to answer the REQ command. 'Information' part is OPTIONAL. 405 - Wrong command. Used to answer the unknown command (not listed in Section 3.2.2). 'Information' part is OPTIONAL. 3.2.4. 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 other commands. No response is sent. Yevstifeyev Expires June 3, 2011 [Page 7] Internet-Draft HCITP November 30, 2010 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. 3.3. UDP-based HCITP This section specifies a UDP-based HCITP and its use. 3.3.1. The Format of Packets 3.3.1.1. The Format of the Header The HCITP header has the following format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ToP|AT |vers.|I| Transaction number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subject |B| IH |Msg. num.|Tr.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3.1.2. Fields Description ToP (Type of Packet) - 2 bits. Can be set into: 00 - request; 01 - answer; 10 - TUM; 11 - Trace Message. AT (Answer Type) - 2 bits. Can be set into: 00 - this packet is not answer; 01 - answer, no error; 10 - answer, error; 11 - reserved for future use. Version - 3 bits. This specification described version 1. Yevstifeyev Expires June 3, 2011 [Page 8] Internet-Draft HCITP November 30, 2010 Transaction number - 16 bits. Shows the number of transaction. Is unique for a client. Subject - 5 bits. Shows the device, information about which is requested. Device numbers to be used with HCITP are defined in the Section 3.5. When the server receives the request with certain "Subject" field, it forms the answer with the same "Subject" field, but with the information about the device defined in "Subject" field. B (Body present flag) - 1 bit. Shows, if the body is present in the packet. IH ("If has" mode option) - 3 bits. Shows, if "If has" mode is enabled. "If has" mode is used when only fact of presence of the requested device is needed to be known. Consists of 3 bits: 0 1 2 +---+---+---+ | | | | | E | T | A | | | | | +---+---+---+ Bit 0 (enabled flag):0 - "If has" not enabled, 1 - "If has" enabled. If this bit is set into 0, then bits 1 and 2 Yevstifeyev Expires June 3, 2011 [Page 9] Internet-Draft HCITP November 30, 2010 MUST be set into 0 either. Bit 1 (type flag): 0 - "If has" request", 1 - "If has" answer. Used only if bit 0 is set into 1. If this bit is set into 0, bit 2 MUST be set into 0 either. Bit 2 (answer): 0 - requested device is not present, 1 - requested device is present. Used only if bit 0 and 1 are set into 1. Msg. num. (Message in transaction number) - 5 bits. Shows the number of the message in transaction. Each side while forming answer increases this number in 1. Tr. (Trace state option) - 2 bits. Shows if Trace mode is used. Consists of 2 bits: 0 1 +---+---+ | | | | E | T | | | | +---+---+ Bit 0 (enabled flag):0 - Trace not enabled, 1 - Trace enabled. If this bit is set into 0, then bits 1 MUST be set into 0 either. Bit 1 (type flag): 0 - Trace request, 1 - Trace answer. Used only if bit 0 is set into 1. 3.3.2. Error Messages Formation for UDP-based HCITP This section defines the rules for formation the error responses in UDP-based HCITP. If an error occurs while processing the request or a device is not present, the server SHOULD send the Error Response (ER). It is done by setting AT in 10 and putting the error code into the body of the packet. Yevstifeyev Expires June 3, 2011 [Page 10] Internet-Draft HCITP November 30, 2010 Error codes are similar to that in TCP-based HCITP. See Section 3.2.3 for details. 3.4. Information Formation Rules This paragraph describes the rules of formation the information about each device, defined in the Section 3.5. Device Body formation rules +------------------+------------------------------------------------+ | Processor |[clock frequency in MHz] [capacity - integer] | +------------------+------------------------------------------------+ | RAM |[size in Mb] | +------------------+------------------------------------------------+ | Motherboard |[manufacturer] [model] | +------------------+------------------------------------------------+ | Hard drive |[size in Mb] | +------------------+------------------------------------------------+ | Network interface|[maximum speed in Kbit/sec] | | card |[current speed in Kbit/sec] | +------------------+------------------------------------------------+ | VGA |[size of video memory in Mb] | | |[3D-accelerator: 1 - present 0 - not present] | +------------------+------------------------------------------------+ | Sound card |[manufacturer] [model] | | | | +------------------+------------------------------------------------+ | CD drive |[discs possible to be read] | | | | - separator | | |[discs possible to be written] | +------------------+------------------------------------------------+ | Floppy drive |[1 - present; 0 - not present] | +------------------+------------------------------------------------+ | Monitor |[resolution (wide)] [resolution (height)] | +------------------+------------------------------------------------+ | Printer |[1 - present; 0 - not present] | +------------------+------------------------------------------------+ | Scanner |[1 - present; 0 - not present] | +------------------+------------------------------------------------+ | Web-camera |[1 - present; 0 - not present] | +------------------+------------------------------------------------+ | Mouse |[manufacturer] [model] | +------------------+------------------------------------------------+ | Keyboard |[manufacturer] [model] | +------------------+------------------------------------------------+ | OS |[name] [1st registry of version] | | |[2nd registry of version] ... | +------------------+------------------------------------------------+ Yevstifeyev Expires June 3, 2011 [Page 11] Internet-Draft HCITP November 30, 2010 3.5. Device Numbers to Be Used with HCITP This section defines devices, which can be used to transfer information about and their number to be used in HCITP packets and commands. The first values is decimal (used in TCP-based HCITP) and the second is binary (used in UDP-based HCITP). 0, 00000 - used for Trace MSGs and TUMs (UDP-based HCITP); 1, 00001 - processor information; 2, 00010 - RAM information; 3, 00011 - motherboard information; 4, 00100 - Hard drive information; 5, 00101 - Network interface card information; 6, 00110 - VGA information; 7, 00111 - Sound Card information; 8, 01000 - CD drive information; 9, 01001 - floppy drive information; 10, 01010 - monitor information; 11, 01011 - printer information; 12, 01100 - scanner information; 13, 01101 - web-camera information; 14, 01110 - mouse information; 15, 01111 - keyboard information; 16, 10000 - OS information; 17-31, 10001-11111 - not used. 4. IANA Considerations IANA should assign TCP and UDP ports number and Protocol Number to be used by HCITP. The corresponding application has been made and at the moment it is being processing. 5. Security Considerations HCITP, as mentioned before, supports only 256 connection at the same time on one of the side of exchange. It won't make possible DDoS attacks using HCITP. We consider that formation of HCITP answers is laborious task. That is why we make the restriction, mentioned in previous paragraph. It is considered that some information can be used for hacker goals. That is why each HCITP client MUST support ACL (access control lists) which can allow or restrict transferring some kinds of information. Yevstifeyev Expires June 3, 2011 [Page 12] Internet-Draft HCITP November 30, 2010 6. Normative References [RFC768] J. Postel, "User Datagram Protocol," STD 6, RFC 768, August 1980. [RFC791] J. Postel, "Internet Protocol," STD 5, RFC 791, September 1981. [RFC793] J. Postel, "Transmission Control Protocol," STD 7, RFC 793, September 1981. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, December 1998. Author's Address Mykyta Yevstifeyev 8 Kuzovkov St., flat 25 Kotovsk, Ukraine Email: evnikita2@gmail.com Yevstifeyev Expires June 3, 2011 [Page 13]