Internet DRAFT - draft-buxmann-atcp
draft-buxmann-atcp
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]
