Network Working Group B. Buxmann Internet-Draft R. Hintner Expires: DAFUER GmbH August 2006 Automatic Telephone Configuration Protocol draft-buxmann-atcp-00.txt Status of this memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 Abstract This document is about the Automatic Telephone Configuration Protocol (ATCP). ATCP provides a framework for passing configuration information to SIP-telephones in a Voice over IP-network and to register users in the network. ATCP needs DHCP for configuring the telephones with TCP/IP-networkparameters (e.g. IP-address). Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Problem definition and issues . . . . . . . . . . . . . 3 1.2 Requirements. . . . . . . . . . . . . . . . . . . . . . 3 Buxmann [Page 1] Automatic Telephone Configuration Protocol August, 2006 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Design goals. . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . 5 2.1 Configuration parameters repository . . . . . . . . . . 8 2.2 Searching a registrar . . . . . . . . . . . . . . . . . 9 2.3 Registering the user. . . . . . . . . . . . . . . . . . 9 2.4 Getting the configuration . . . . . . . . . . . . . . . 9 2.5 Checking the connection to the registrar. . . . . . . . 10 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . 10 3.1 Client-registrar interaction - searching a registrar and getting configuration . . . . . . . . . . . . . . . . . 10 3.2 Client-registrar interaction - checking the registrar's availability. . . . . . . . . . . . . . . . . . . . . . 12 3.3 Client parameters . . . . . . . . . . . . . . . . . . . 13 3.4 When clients should use ATCP. . . . . . . . . . . . . . 13 4. Specifications of the ATCP client-server protocol . . . . . 13 4.1 Constructing and sending messages . . . . . . . . . . . 13 4.2 Registrar behaviour . . . . . . . . . . . . . . . . . . 14 4.3 Client behaviour. . . . . . . . . . . . . . . . . . . . 15 4.4 Use of broadcast and unicast. . . . . . . . . . . . . . 17 5. Normative References. . . . . . . . . . . . . . . . . . . . 17 6. Informative References. . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . 19 8. Author's Address. . . . . . . . . . . . . . . . . . . . . . 19 9. Copyright Notice. . . . . . . . . . . . . . . . . . . . . . 20 10. Disclaimer of Validity. . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 A. Possible content of the ATCP-fields . . . . . . . . . . . . 21 List of Figures 1. Format of a ATCP-message . . . . . . . . . . . . . . . . . . 5 2. Format of the 'configs'-field. . . . . . . . . . . . . . . . 7 3. Timeline diagram of messages exchanged between client and registrar when searching a registrar and getting configuration. . . . . . . . . . . . . . . . . . . . . . . . 11 List of Tables 1. Description of fields in a ATCP-message . . . . . . . . . . 6 2. Description of fields in a 'configs'-field. . . . . . . . . 8 3. Description of possible ATCP-messages . . . . . . . . . . . 10 4. Fields and options used by registrars . . . . . . . . . . . 15 5. Fields and options used by clients. . . . . . . . . . . . . 17 6. Possible codes for 'op'-field . . . . . . . . . . . . . . . 21 7. Possible codes for 'mtype'-field. . . . . . . . . . . . . . 21 8. Possible codes for 'key'-field. . . . . . . . . . . . . . . 21 Buxmann Expires [Page 2] Automatic Telephone Configuration Protocol August, 2006 9. Possible codes for 'requinf'-field. . . . . . . . . . . . . 22 10. Possible codes for 'configs'-field. . . . . . . . . . . . . 23 1. Introduction This Protocol is used to configure Session Initiation Protocol (SIP)[n1]-Terminals automatically. You need a file at the registrar[n2] which includes every possible configuration-parameter, that a terminal could need. Furthermore you need a file with registration-information of the users who are allowed to get this informations. The user just needs to type in his username and his password at the terminal. The terminal sends this information to the Registrar, this registrar answers and sends back the configuration. In addtion, the protocol is used to find registrars in the subnet, the terminal belongs to. To do this, the terminal sends out a broadcast-message in which it tells the registrar, that it searches for registrars to login. Registrars in this subnet send a respond to the terminal and the terminal sends back username and password which the user typed in. The registrar compares the received registration- information with the information saved in its configfile. If the informations match, the Registrar sends back the configuration. If they don't match, the Registrar answers the terminal, too. Due to the packet the terminal receives in this case, it knows that the registration was not successful and tells the user to retype username and password. 1.1. Problem definition and issues This protocol is defined to supply SIP-clients with the configuration they need to start a communication. With this protocol a user can take a SIP-telephone and start telephoning without a long configuration. The user just needs to type in his username and his password. 1.2. Requirements Throughout this document, the words that are used to define the significance of particular requirements are capitalized. 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 [n7]. The words used in this document are: Buxmann Expires [Page 3] Automatic Telephone Configuration Protocol August, 2006 - "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. - "MUST NOT" This phrase means that the item is an absolute prohibition of this 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 should be understood and the case carefully weighed before choosing a different course. - "SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. - "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 1.3. Terminology This document uses the following terms: - Client A client is an Internet host using ATCP to obtain configuration parameters. - Registrar A registrar is used in a SIP-network to register the user in the network. It needs the user's username and his password. Buxmann Expires [Page 4] Automatic Telephone Configuration Protocol August, 2006 1.4. Design goals - Clients should require no manual configuration, the user just needs to type in his username and his password - Administrators should be able to configure all clients in one subnet by one file which is saved at one registrar. - Clients must be prepared to receive multiple responses to a SEARCH-message. - Clients must check if the registrar is available periodically. If the connection to the registrar broke, the client should restart the whole protocol-process to find a new registrar. 2. Protocol Summary Before ATCP can be started, the client needs an IP-address. It is recommended, that the client is configured via Dynamic Host Configuration Protocol (DHCP)[n3] before starting ATCP. Of course, all the configuration of can be made manually, too, without using DHCP. If ATCP works correctly, four packets will be sent, two from the client to the registrar and two the other way. Figure 1 shows the format of these messages, table 1 explains each field. The number in parentheses indicate the size of each field in octets. The names for the fields given in the figure will be used throughout this document to refer to the fields in the messages. Format of the packets: The ATCP-packets MUST look like this example: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op(1) | mtype(1) | length(2) | +---------------+---------------+-------------------------------+ | key(1) | username(3) | +---------------+-----------------------------------------------+ | | | username(16) | | | | | +---------------------------------------------------------------+ | | Buxmann Expires [Page 5] Automatic Telephone Configuration Protocol August, 2006 | | | password(20) | | | | | +---------------------------------------------------------------+ | requinf(4) | +---------------------------------------------------------------+ | | | configs(variable) | +---------------------------------------------------------------+ Figure 1: Format of a ATCP-message Each field of the packet is described in the following table: FIELD OCTETS DESCRIPTION ----- ------ ----------- op 1 Operation Code: 1=REQUEST, 2=REPLY mtype 1 Messagetype: 1=SEARCH, 2=FOUND, 3=CFGREQU 4=CFGACK, 5=CFGNACK. Length 2 Overall length of the packet. Key 1 Code for the used key. A table of possible codes can be found in chapter A. Username 19 Field for the username, typed in by the user. Password 20 Field for the password, typed in by the user. Requinf 4 Field for the requested configuration information. If a bit is set to "1", the configuration is requested. For a table of which bit belongs to which configuration, look at chapter A. Configs variable Field for the configurations. This field is explained in chapter A. Table 1: Description of fields in a ATCP-message 'mtype' is used to define the type of the message. There are five possible messagetypes. In the first step the client sends the SEARCH-message to all hosts in its own subnet. This message is sent as broadcast. If a registrar receives a SEARCH-message, it sends a FOUND-message back to the client, from which it received the SEARCH- message. Because of this message the client knows the IP-address of Buxmann Expires [Page 6] Automatic Telephone Configuration Protocol August, 2006 the registrar. The client always takes the registrar which answered first. In the next step, the client sends the CFGREQU-message to the registrar. In this message it tells the registrar its username, password and which configuration it wants to have ('requinf'). The registrar checks if username and password are identical to the information saved in its userfile. If that's the case, the registrar analyses the 'requinf'-field and sends back the requested configuration in a CFGACK-message. If received username and password can not be found in the userfile, the registrar answers the CFGREQU-message with a CFGNACK-message, in which the client is told, that the registration was not successful. 'key' contains the code for the used encryption. A table of possible encryptions is shown in chapter A. This field is only used in the CFGREQU-message. The only fields that can be crypted are 'username' and 'password'. It is possible, that no encryption is used. In this case the 'key'-field is '0'. 'username' and 'password' contain the username and the password of the user. If an encryption is used, the information of these fields MAY be put together to one string with a maximum size of 39 bytes ('password' and 'username'). This conclomerated information SHOULD be separated by a ':'. 'requinf' consists of 32 bit. Every bit stands for one configuration that can be requested. At the moment only 24 bit are in use, the remaining bits are reserved for future use. If a bit is set, the corresponding configuration is requested, if the bit is not set, the configuration is not requested. 'configs' is used by the registrar to send the configuration. For every configuration a field is generated which has the following format: 'configs'-Field: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | code(1) | length(1) | configs(variable) | +---------------+---------------+-------------------------------+ Figure 2: Format of the 'configs'-field Buxmann Expires [Page 7] Automatic Telephone Configuration Protocol August, 2006 These fields have the following meaning: FIELD OCTETS DESCRIPTION ----- ------ ----------- code 1 The code of the following configuration. A table of possible codes is shown in chapter A. Length 1 Length of the following configuration. Configs variable The configuration, the Registrar wants to send to the client. Table 2: Description of fields in a 'configs'-field The 'code'-field contains the code for the configuration. Every configuration has a code, a table with every possible code is shown in chapter A. The 'length'-field contains the length of the following configuration. The size of 'code' and 'length' are not included in this information, it's just the length of the 'configs'-field. The 'configs'-field contains the configuration. The registrar reads the requested configuration out of its configfile and adds it to this field. The 'configs'-field has a maximum size of 255 byte. 2.1. Configuration parameters repository It is necessary that the userinformation and the configurations are saved at the registrar. It is recommended that these two types of information are saved in two different files. The userfile: It is necessary that every password is assigned to one username unmistakably. You MAY separate the password from its username by inserting a symbol e.g. ':'. This string SHOULD NOT be saved in clear text. It SHOULD be crypted with a hash-algorithm, such as MD5. From this it follows, that if username and password were transmitted uncrypted, they have to be crypted in MD5, before comparing the received userdata with the saved userdata. The configfile: The configfile MUST contain a key-value entry for each Buxmann Expires [Page 8] Automatic Telephone Configuration Protocol August, 2006 configuration. These two strings MAY be separated by a "=". There MAY be empty values. Each key-value entry SHOULD be terminated by a line break. 2.2 Searching a registrar The first service provided by ATCP is finding a registrar in the local subnet. To do this, the client sends a broadcast into the subnet and available registrars send a response to the clients. From this response the clients can get the IP-address of the registrars. If more than one registrars answer the request, the client takes the one which answers first. It is assumed that the following communication to the registrar, which answered first in this step, will be the fasted, too. Because of this, always the first registrar that answers, is taken by the client for its next steps. If no registrar answers the request, the client waits and sends the request again. If, after several tries to get a response, no registrar answers, the client displays an errormessage to the user. 2.3. Registering the user The second service provided by ATCP is registering the user. The client sends its informations, which are needed to register (username and password) to the registrar. These informations are sent together with the information which configuration is requested. The registrar compares the received information with the information saved at its harddisk. If they match, it sends back the requested information. If there is a difference, it sends back a message, from which the client knows that something went wrong. The client then asks the user to retype his username and password and sends the new information again. 2.4. Getting the configuration The third service is the main reason for the existence of this protocol. With the same packet, which is used to register the user, the client sends a request, which configuration it wants to know. If the registration was successful, the registrar sends back the requested configurations to the client. If no message from the Buxmann Expires [Page 9] Automatic Telephone Configuration Protocol August, 2006 registrar is received by the client, the client restarts the whole protocol. 2.5. Checking the connection to the registrar The client checks in periodical intervals that the registrar is still available. If it is not available, the search for a registrar is restarted. 3. The Client-Server Protocol The 'op'-field of each message from client to registrar contains REQUEST. REPLY is used for each message sent from the registrar to the client. Throughout this document, the messages of the protocol will be referred to by the messagetype of the packet, e.g. a message with '1' in the 'mtype'-field will be referred to as a SEARCH-message. 3.1. Client-registrar interaction - searching a registrar and getting configuration The following summary of the protocol exchanges between client and server refers to the messages described in table 3. The timeline diagram in figure 3 shows the timing relationships in a typical client-server interaction. Message Use ------- --- SEARCH Client broadcast to locate available registrars. FOUND Registrar's response to SEARCH, the client knows with this message the registrar's IP-address. CFGREQU Message from client to registrar. It contains the username and password of the user and the information which configuration is requested. CFGACK Response of the registrar to CFGREQU, if the transmitted userdata was identical to the registrar's. Contains the requested configuration. CFGNACK Response of the registrar to CFGREQU, if the transmitted userdata did not match to the registrar's. Buxmann Expires [Page 10] Automatic Telephone Configuration Protocol August, 2006 Table 3: Description of possible ATCP-messages Server Client Server v v v | | | | Begins initialization | | | | | _______________/|\__________________ | |/ SEARCH | SEARCH \| | | | | | | | | __________________/| |\_______________ |/ FOUND | | FOUND \| | | | | | |\__________________ | | | CFGREQU \| | | | | | | | | __________________/| | |/ CFGACK | | | | | Initialization complete | | | | v v v Figure 3: Timeline-diagram of messages exchanged between client and registrar when searching a registrar and getting configuration Step 1: The client broadcasts a SEARCH-message on its local physical subnet. This message always has a size of three bytes, which include 'op', 'mtype' and 'length'. Step 2: The registrar receives the SEARCH-message and sends a FOUND-message as response. This message has a fix size of three bytes like the SEARCH-message. It includes 'op', 'mtype' and 'length',too. Step 3: The client receives one or more FOUND-messages from one or more registrars. It is recommended that the client takes the first response for the following communication, Buxmann Expires [Page 11] Automatic Telephone Configuration Protocol August, 2006 because this registrar will probably be the fasted for the following communication. From the IP-header, the client gets the IP-address of this registrar. To this address, it sends the CFGREQU-message. This message MUST include username and password, which the user typed in. Also, it SHOULD contain the request for the configuration. It is possible to send a CFGREQU message without filling the 'requinf'-field. Then the registrar just registers the user but doesn't send any configuration. If the client receives no FOUND-message, it times out and retransmits the SEARCH-message. Step 4: The registrar receives the CFGREQU-message from the client. First, the registrar analyses the 'username'- and the 'password'-field. If this information is crypted, (the regisrar knows this because of the 'key'-field) the registrar MUST first decrypt it. If the saved userinformation at the harddisk of the registrar is crypted, what is recommended, the registrar MUST crypt the received information with the same algorithm. Then, the registrar compares the received userinformation with the saved information. If they don't match, the registrar sends back a CFGNACK-message. In this case, the 'requinf'-field is not interpreted. If saved and received userdata match, the registrar analyses the 'requinf'- field. It reads every requested information out of the userfile and appends a 'configs'-field for each configuration to the packet. After that, this packet is sent as CFGACK-message to the client. Step 5: The client receives the CFGACK-message with configuration parameters. At this point, the client is configured. If the client receives a CFGNACK-message, it restarts the configuration with the demand to the user to retype the username and the password. These informations will be sent in a new CFGREQU-message. If no message is received, the client times out and restarts the whole process with the sending of a SEARCH-message. The client SHOULD inform the user about this step. 3.2. Client-registrar interaction - checking the registrar's availability Buxmann Expires [Page 12] Automatic Telephone Configuration Protocol August, 2006 If the configuration was completed successfully, the client SHOULD check periodically if the registrar is still available. There are two possibilities to do this: 1. Sending a SEARCH-message to the registrar (not as broadcast). If the registrar responds a FOUND-message, it is still available. The client SHOULD NOT continue with the communication as shown in chapter 3.1. 2. Sending an ICMP-Echo-Request-packet (ping)[n4] to the IP-address of the registrar. If the registrar responds, it is still available. 3.3 Client parameters Not every client needs initialization of all configuration parameters. To reduce the number of parameters transmitted from the registrar to the client, the 'requinf'-field is used. This field has a size of 32 bit. Each of these bits represents one configuration parameter. The client fills in this field when it sends the CFGREQU- message. If a bit is set to '1', the appropriate configuration parameter is requested, if it is set to '0', the configuration parameter is not requested. If the client requests a configuration parameter, which the registrar can't send, the registrar doesn't append a Config-packet for this parameter to the message. The client will then use the parameter which was used before. 3.4. When clients should use ATCP The client SHOULD use ATCP to find a registrar and get the configuration after every reboot and if the client was disconnected from the network. During this time, registrars can get disconnected, too or the administrator could have changed the configurationfile. 4. Specifications of the ATCP client-server protocol In this section we assume, that minimum one registrar is in the subnet of the clients. It must have a configfile and a userfile. 4.1. Constructing and sending messages Clients and registrars both construct messages by filling in fields in the fixed format section of the message. Registrars can append informations in the variable configs-section. Buxmann Expires [Page 13] Automatic Telephone Configuration Protocol August, 2006 The protocol uses User Datagram Protocol (UDP)[n5] as transport protocol. The messages from the registrar to the client and from the client to the registrar are both sent to port 22222. The clients are responsible for all message retransmissions. The only messages that can be retransmitted are the SEARCH-message and the CFGREQU-message. If a client doesn't get a response to a CFGREQU-message it times out and resends the SEARCH-message. The delay between retransmissions SHOULD be chosen to allow sufficient time for replies from the server to be delivered based on the characteristics of the internetwork between the client and the server. The time chosen for the first transmission SHOULD be doubled if still no response from the registrar is received. There MUST be a limit of tries the client has to get a respond. If this limit is reached, the user SHOULD be informed, that the registrar doesn't answer. 4.2 Registrar behaviour A registrar can receive the following messages from the client: - SEARCH - CFGREQU 1. SEARCH-message If the registrar receives a SEARCH- message from a client, it first checks if the packet really has the length which is stored in the packet. If this is not the case, the registrar doesn't send a reply to the client. If everything is allright, it looks for the IP- address in the IP-header. This address will be used as destination for the following FOUND-message. This FOUND-message is constructed by the registrar in the next step. The registrar fills in the first three bytes of the packet, the rest MUST be left empty. 'op' MUST contain 'REPLY', 'mtype' MUST contain 'FOUND' and 'length' MUST contain the length of this packet (in this case three byte). This message is sent to the address, the registrar read out of the SEARCH-packet. 2. CFGREQU-message After receiving a CFGREQU-message, the registrar checks the correct length of the message again, as done after receiving the SEARCH- Buxmann Expires [Page 14] Automatic Telephone Configuration Protocol August, 2006 message. In the next step, username and password are checked. The registrar compares the received userinformation with the data saved in its userfile. If they don't match, the CFGNACK-message is constructed and the registrar sends it back. This message MUST contain 'REPLY' in the 'op'-field and 'CFGNACK' in the 'mtype'- field. The 'length'-field MUST contain the length of the packet (three byte in this case). The other fields MUST be empty. If received and saved userinformation match, the 'requinf'-field is analysed. The registrar checks which bits are set to '1' and attaches the corresponding configuration to the CFGACK-message. This message MUST consist of 'REPLY' in the 'op'-field. The 'mtype'-field MUST contain 'CFGACK', the 'length'-field MUST contain the length of the whole packet, 'key', 'username', 'password' and 'requinf' MUST be empty. Each configuration MUST bei constructed as shown in figure 2. These configurations MUST be attached to the message in the 'configs'-field. This message MUST be sent to the address, the CFGREQU-message was received from. Table 4 shows which message, the registrar can send, MUST contain which information. Field FOUND CFGACK CFGNACK ----- ----- ------ ------- 'op' REPLY REPLY REPLY 'mtype' FOUND CFGACK CFGNACK 'length' (Length of the packet in octets) 'key' MUST NOT MUST NOT MUST NOT 'username' MUST NOT MUST NOT MUST NOT 'password' MUST NOT MUST NOT MUST NOT 'requinf' MUST NOT MUST NOT MUST NOT 'configs' MUST NOT Requested MUST NOT Configuration Table 4: Fields and options used by registrars 4.3 Client behaviour A client can receive the following message from the registrar: - FOUND - CFGACK Buxmann Expires [Page 15] Automatic Telephone Configuration Protocol August, 2006 - CFGNACK 1. FOUND-message After the client broadcasted the SEARCH-message, it waits for a FOUND-message from the registrar. If it receives this message, it first checks if the value in the 'length'-field corresponds to the length of the message. If this is the case, it constructs the CFGREQU-message. This message MUST contain 'REQUEST' in the 'op'- field and 'CFGREQU' in the 'mtype'-field. The 'length'-field MUST contain the length of the packet. 'key' MUST contain the code for the used encryption or 0x00 if no encryption is used. 'username' MUST be filled with the username, either crypted with the method described by the code in the 'key'-field or uncrypted if the 'key'- field contains 0x00. 'password' SHOULD contain the password. It is possible, that username and password are put together to one string, and this string is crypted with the method described by the code in the 'key'-field and filled in the 'username'-field. If the 'username'-field is not long enough, the 'password'-field CAN be used, too. In this cast, the 'password'-field CAN be empty. Of course, the password can be crypted alone. Then the crypted password MUST be filled in the 'password'-field. In the next step, the 'requinf'-field is filled. For every configuration the client wants to receive, the corresponding bit MUST be set to '1'. The 'configs'-field MUST be left empty. This message MUST be sent to the registrar, the FOUND-message came from. 2. CFGACK The client receives this message if the configuration was successful. Again, after checking the 'op'-field and the 'mtype'- field, the length of the packet is checked . If it is not the same as declared in the 'length'-field, the packet gets discarded and a new SEARCH-packet is sent. If everything is ok with the packet, the client analyses the 'configs'-field. After identifying the configuration by the code, the client checks if the length of the following information is the length declared in the 'length'-field of this configuration. If not, the client CAN resend a CFGREQU- message to the registrar and request this configuration again. The second possibility is to restart the whole configuration by sending a new SEARCH-packet. The client CAN first check all configurations received and request the wrong configurations after that. If the length in the 'length'-field is the same as the length of the Buxmann Expires [Page 16] Automatic Telephone Configuration Protocol August, 2006 configuration, the client can use the received configuration and write it to the file where it is needed. 3. CFGNACK The client receives this message if the configuration was not successful. It CAN check the length, as done with the other packets. The next step, if the packet has a wrong length is the same as when the packet is correct. The client tells the user to retype his userinformation and either resends the CFGREQU-message or it sends a new SEARCH-message. Table 5 shows which message, the client can send, MUST contain which information. Field SEARCH CFGREQU ----- ------ ------- 'op' REQUEST REQUEST 'mtype' SEARCH CFGREQU 'length' (Length of the packet in octets) 'key' MUST NOT Code of the used encryption 'username' MUST NOT Username 'password' MUST NOT Password 'requinf' MUST NOT Requested Information 'configs' MUST NOT MUST NOT Table 5: Fields and options used by clients 4.4 Use of broadcast and unicast The only message that is broadcasted during the whole protocol is the SEARCH-message. It is not necessary that the other messages are broadcasted. They SHOULD NOT be sent as broadcast to reduce traffic and to avoid problems with broadcast storm-protections. If the client checks the availability of the registrar with SEARCH- messages, these messages SHOULD NOT be sent as broadcast because the client knows the registrar it wants to send the message and it can avoid traffic by sending this message as unicast in this case. 5. Normative References Buxmann Expires [Page 17] Automatic Telephone Configuration Protocol August, 2006 [n1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3543, June 2002. [n2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3543, June 2002. [n3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [n4] Postel, J., "Internet Control Message Protocol", RFC 792, September 1981. [n5] Postel, J., "User Datagram Protocol", RFC 768, August 1980. [n6] Postel, J., "Transmission Control Protocol", RFC 793, September 1981. [n7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 6. Informative References [i1] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [i2] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [i3] Rivest, R., "The RC4 Encryption Algorithm", 1987. [i4] Rivest, R., "The RC5 Encryption Algorithm", In Proceedings of the Second International Workshop on Fast Software Encryption, pages 86-96, Leuven Belgium, December 1994. [i5] [i6] Rivest, R., Robshaw, M.J.B., Sodney, R.and Y.L. Yin, Y, "The RC6 Block Cipher", RSA Laboratories, August 1998. [i7] Mediacrypt AG, Switzerland, "International Data Encryption Algorithm, 1991. [i8] Schneier, B., "Description of a New Variable-Length Key, 64 Bit Block Cipher (Blowfish)", Fast Software Encryption, Cambridge Security Workshop Proceedings, Springer-Verlag, 1994, pp. 191 204, December 1993. [i9] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall, C. and N. Ferguson, "Twofish: A 128-Bit Block Cipher", June 1998. [i10] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)" FIPS 197, November 2001. Buxmann Expires [Page 18] Automatic Telephone Configuration Protocol August, 2006 [i11] Jonsson, J., Kaliski, B., "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [i12] Elgamal, T., "A Public Key Cryptosystem and a Signature Scheme based on Discrete Logarithms", 1985. [i13] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [i14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [i15] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995. [i16] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [i17] Microsoft Corporation, "Telephony Application Programming Interface", 1993. [i18] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. 7. Security Considerations ATCP is built directly on UDP and IP which are as yet insecure. It is possible to set up unauthorized registrars which can send false data to the clients. These registrars can receive the user's password and username, too. If this information is uncrypted, it can be used to register clients which don't have the right to be in this network. 8. Author's Address Bernd Buxmann DAFUER GmbH Zur Eisernen Hand 27 64367 Muehltal Phone: 00496151/95140 FAX: 00496151/144260 EMail: bu@dafuer.com Ralf Hintner DAFUER GmbH Zur Eisernen Hand 27 64367 Muehltal Phone: 00496151/951417 FAX: 00496151/144260 Buxmann Expires [Page 19] Automatic Telephone Configuration Protocol August, 2006 EMail: rh@dafuer.com Comments are solicited and should be addressed to the the authors. 9. Copyright Notice Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 10. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org." Buxmann Expires [Page 20] Automatic Telephone Configuration Protocol August, 2006 11. IANA Considerations There are no IANA considerations in this document. A. Possible content of the ATCP-fields 'op' Name Code ---- ---- REQUEST 0x01 From client to registrar. REPLY 0x02 From registrar to client. Table 6: Possible codes for 'op'-field 'mtype' Message Code ------- ---- SEARCH 0x01 Client searches registrars (broadcast). FOUND 0x02 Registrar's response when it received SEARCH-packet. CFGREQU 0x03 Client requests configuration and registration. CFGACK 0x04 Registrar registered client. CFGNACK 0x05 Registrar didn't register client. Table 7: Possible codes for 'mtype'-field 'key' Key Code --- ---- Uncrypted 0x00 DES[i1] 0x01 Triple-DES[i2] 0x02 RC4[i3] 0x03 RC5[i4] 0x04 RC5a[i5] 0x05 RC6[i6] 0x06 IDEA[i7] 0x07 Blowfish[i8] 0x08 Twofish[i9] 0x09 AES[i10] 0x0a RSA[i11] 0x0b Buxmann Expires [Page 21] Automatic Telephone Configuration Protocol August, 2006 Elgamal[i12] 0x0c Diffie-Hellman[i13] 0x0d MD5[i14] 0x0e SHA-1[i15] 0x0f Table 8: Possible codes for 'key'-field 'requinf' Configuration Bit ------------- --- Netmask 0 Gateway 1 Voicecodec 2 DNS-Server[i16] 3 Timezone 4 Timeserver 5 Proxyserver 6 Proxyport 7 TAPI-Port[i17] 8 Workingmode 9 Workingmode of the phone (e.g. Headset, USB-Phone). Communication-port 10 Voiceport 11 Automatic portdetection 12 Can be on or off. Syslog-server[i18] 13 Syslog-port 14 Syslog-mask 15 TCP-port[n6] 16 Waitingloop-number 17 Own number 18 Automatic exchange line seizure 19 Bitfield with 1 or 0 for several functions. Internal prefix 20 External prefix 21 Enblock dial 22 Automatic update 23 Future use 24-32 Table 9: Possible codes for 'requinf'-field 'configs' Configuration Code ------------------ ---- Buxmann Expires [Page 22] Automatic Telephone Configuration Protocol August, 2006 Netmask 0x01 Gateway 0x02 Voicecodec 0x03 DNS-Server 0x04 Timezone 0x05 Timeserver 0x06 Proxyserver 0x07 Proxyport 0x08 TAPI-Port 0x09 Workingmode 0x0A Workingmode of the phone (e.g. Headset, USB-Phone). Communication-port 0x0B Voiceport 0x0C Automatic portdetection 0x0D Can be on or off. Syslog-server 0x0E Syslog-port 0x0F Syslog-mask 0x10 TCP-port 0x11 Waitingloop-number 0x12 Own number 0x13 Automatic exchange line seizure 0x14 Bitfield with 1 or 0 for several functions. Internal prefix 0x15 External prefix 0x16 Enblock dial 0x17 Automatic update 0x18 Future use 0x19-0x20 Table 10: Possible codes for 'configs'-field Buxmann Expires [Page 23]