Network Working Group                                         B. Buxmann 
Internet-Draft                                                R. Hintner 
Expires: <date>                                              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 <date>                        [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 <date>                        [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 <date>                        [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 <date>                        [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 <date>                        [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 <date>                        [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 <date>                       [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 <date>                        [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [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 <date>                       [Page 23]