Internet-DRAFT Mykyta Yevstifeyev Expires: 25 April, 2011 October 25, 2010 Intended status: Standards Track Hardware Configuration Transfer Protocol Abstract This document is a specification of Hardware Configuration Transfer Protocol. 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 April 25, 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 April 25, 2011 [Page 1] Internet-Draft HCTP October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. UDP Parameters . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. IPv4 Parameters . . . . . . . . . . . . . . . . . . . . 5 3.2. The Format of Packets . . . . . . . . . . . . . . . . . . . 5 3.2.1. The Header . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1.1. The Format of the Header . . . . . . . . . . . . . . 5 3.2.1.2. Fields Description . . . . . . . . . . . . . . . . . 5 3.2.2. Body Formation Rules . . . . . . . . . . . . . . . . . . 7 3.3. Error Messages Formation . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 6. Normative References . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Yevstifeyev Expires April 25, 2011 [Page 2] Internet-Draft HCTP October 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 HCTP will solve this problem by preceding transfer of information about hadrware configuration of the client. 2. Review 2.1. Interaction with Other Protocols The interaction of HCTP and other protocols are shown at the picture below. +---------+ | HCTP | +---------+ | +---------+ | UDP | +---------+ | +---------+ | IP | +---------+ | +-------------------------+ | Local Network Protocol | +-------------------------+ Picture 1. The interaction of protocols. 2.2. Functional Description HCTP is used to request and transfer information about hardware configuration of the computer. Moreover, it can be used like a ping-tool by sending special types of messages. HCTP use packets to exchange information. Packets consist of header and body. The format of packets is described by this document. Each side of the exchange mustn't open more than 256 connection at the same time. Yevstifeyev Expires April 25, 2011 [Page 3] Internet-Draft HCTP October 2010 2.3. Modes of Work HCTP has 3 modes of work: a) casual. If HCTP 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 HCTP. These modes will be described below more detalized. 2.4. Model of Work HCTP 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. After a server receives the HCTP 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 occure. In this case a server should send an Error Answer (EA). After receiving EA a client may repeat the request. The information about requested hardware or errors is transfered in the body. If the information is rerquested about the device which is not present in the server's system, it should send EA with the corresponding error code. In that case a client shouldn't repeat the request. HCTP trace messages can be used like ICMP Echo messages. Generally they are used to check if HCTP can be used. The text of body in HCTP trace request must be similar to the text in HCTP trace answer. Yevstifeyev Expires April 25, 2011 [Page 4] Internet-Draft HCTP October 2010 3. Specification 3.1. The Parameters of the Protocols of Lower Levels 3.1.1. UDP Parameters (as described in RFC 768 [1]) HCTP 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.2. IPv4 Parameters (as described in RFC 791 [2]) HCTP uses IP with the following parameters: a) Version - 4; b) Flags - DF; c) ToS - 00000000; d) TTL - 128; e) another fields - depending on the packet. 3.2. The Format of Packets 3.2.1. The Header 3.2.1.1. The Format of the Header The HCTP 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.2.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 April 25, 2011 [Page 5] Internet-Draft HCTP October 2010 I (Importance flag) - 1 bit. Shows if this packet should be processed first. 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. Can be set into: 00000 - used for Trace MSGs and TUms; 00001 - processor information; 00010 - RAM information; 00011 - motherboard information; 00100 - HDD information; 00101 - NetWork Card information; 00110 - VGA information; 00111 - soundcard information; 01000 - CD drive information; 01001 - floppy drive information; 01010 - monitor information; 01011 - printer information; 01100 - scanner information; 01101 - web-camera information; 01110 - mouse information; 01111 - keyboard information; 10000 - OS information; 10001-11111 - reserved for future use. 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 must be set into 0 either. Yevstifeyev Expires April 25, 2011 [Page 6] Internet-Draft HCTP October 2010 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.2.2. Body Formation Rules This paragraph describes the rules of formation the body of the packet for each device. Device Body formation rules +------------------+------------------------------------------------+ | Processor |[clock frequency in Mhz] [capacity - integer] | +------------------+------------------------------------------------+ | RAM |[size in Mb] | +------------------+------------------------------------------------+ | Motherboard |[manufactor] [model] | +------------------+------------------------------------------------+ | HDD |[size in Mb] | +------------------+------------------------------------------------+ | NetWork card |[maximum speed in Kbit/sec] | | |[current speed in Kbit/sec] | +------------------+------------------------------------------------+ | VGA |[size of video memory in Mb] | | |[3D-accelerator: 1 - present 0 - not present] | +------------------+------------------------------------------------+ Yevstifeyev Expires April 25, 2011 [Page 7] Internet-Draft HCTP October 2010 +------------------+------------------------------------------------+ | Sound card |[manufactor] [model] | +------------------+------------------------------------------------+ | CD drive |[discs posssible to be read] | | | | | | |[discs possible to be written] | +------------------+------------------------------------------------+ | Floppy drive |[1 - present; 0 - not present] | +------------------+------------------------------------------------+ | Monitor |[resolution (wide)] [resolution (heigh)] | +------------------+------------------------------------------------+ | Printer |[1 - present; 0 - not present] | +------------------+------------------------------------------------+ | Scanner |[1 - present; 0 - not present] | +------------------+------------------------------------------------+ | Web-camera |[1 - present; 0 - not present] | +------------------+------------------------------------------------+ | Mouse |[manufactor] [model] | +------------------+------------------------------------------------+ | Keyboard |[manufactor] [model] | +------------------+------------------------------------------------+ | OS |[name] [1st registry of version] | | |[2nd registry of version] ... | +------------------+------------------------------------------------+ 3.3. Error Messages Formation If an error occures while processing the request or a device is not present, the server should send the Error Answer (EA). It is done by setting AT in 10 and putting the error code into the body of the packet. There are following error codes for HCTP: 100 - HCTP not used; 101 - it is restricted send information about this device; 102 - the requested device not present in the system; 103 - incorrect request; 104 - another error; 105-199 - reserved for future use. Yevstifeyev Expires April 25, 2011 [Page 8] Internet-Draft HCTP October 2010 4. IANA Considerations [TODO: IANA Considerations.] 5. Security Considerations. HCTP, 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 HCTP. We consider that formation of HCTP answers is laborious task. That is why we make the restriction, mentioned in previous paragraph. 6. Normative References [1] Postel, J., "User Datagram Protocol," RFC 768, August 1980. [2] Postel, J., "Internet Protocol," RFC 791, September 1981. Author's Address Mykyta Yevstifeyev Email: evnikita2@gmail.com Yevstifeyev Expires April 25, 2011 [Page 9]