Internet-Draft Expires: June 1997 Internet-Draft Category: Informational S. Ryckman SIMS, Inc. Security Industry Internet Protocol for Alarm Transmission (SIIPAT) Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This document is an Internet-Draft. 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". To learn the current status of any Internet-Draft, please check the "1id-abstract.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document suggests a method for delivering alarm information over the Internet. All communication shall use an encryption algorithm for transmission of the data. An immediate response from the host will be used for verification of receipt of the message. This transmission method may be use as a backup transmission method to traditional dial-up or leased line methods, or as a primary transmission method with traditional methods becomming the backup. Due to the required security of the data being transmitted, the encryption algorithm used will only be released on a need to know basis to software developers in the Alarm/Security Industry. A non-disclosure agreement will be required. Terms and conditions of the licensing will depend on the intended purpose for use and may require a non-competition agreement or licensing fees. The Internet Assigned Numbers Authority (IANA) has assigned port 1733 for the registered use of SIIPAT transmissions. 1. Introduction This transmission protocol was developed to eliminate the need for dial-up communications to send short data bursts of alarm information. Many times, the amount of time it takes to seize the dial-up phone line, dial the number and wait for an answer by the alarm receiving equipment is much greater than the amount of time it takes to transmit the data itself (even at 300 baud). Since many corporations and government agencies as well as alarm companies already have dedicated Internet connections, it seems resonable that it could be used as a quick transmission method. Due to the inherent probability of failures of the network at some point between origination and reception of the alarm signal, it should NOT be used for the sole transmission path for any signal. This transmission method can be treated with the same concerns as a typical radio alarm transmission, quick but not entirely absolute. Throughout the remainder of this document the following terms will be used. Port/Socket - Used interchangably to refer to the logical connection created when the client software polls the host on a particular port number, in this case port 1733. SIIPAT - Security Industry Internet Protocol for Alarm Transmission (Pronounced Si-Pay). Server - The software running at the Alarm Company which is connected to the Internet and monitoring an IP address port. Subscriber - The software/device at the protected location. 2. System Philosophy Proposing an alternative method of transportation of alarm signals is not as easy to implement as it sounds. A very simple adoption of such a feat could be accomplished with normal Email. This would not provide immediate notification of receipt however, and would open the system up to tampering from external sources. Clearly a secured encryption routine must be used, to prevent people from creating false signals or using the protocol for sending non-alarm information, as is possible with existing transmission formats. The principle of SIIPAT is to provide security to the alarm transmission process not found currently. This is security both for the originator of the alarm signal (increased transmission speed) and for the alarm company (reduction of false signals due to tampering). Until every home has it's own direct connection to the Internet, SIIPAT can not be used for every alarm system. It's primary purpose is for commercial applications or where the alarm signal may originate from a non-customary device such as a program on a computer used for monitoring network or environmental conditions, home automation/access control computerized systems or from radio network providers for vehicle location/tracking purposes. SIIPAT itself does not include definition for the equipment on either end of the transmission, only the format of the data in between. Implementation of SIIPAT may include a dedicated machine to act as the server or use of an automation software package which supports the SIIPAT interface directly. The way the protocol is designed supports simple "generic" transmissions as well as emulating specific receiver signals so that an automation package can pass the message to an existing receiver interface. 3. Why use the Internet to send alarm messages ? Every day, more and more alarm companies are changing from small "mom and pop" companies, to nationwide or global monitoring stations. With the ever increasing competition from other companies, an alarm company must remain unique to remain in business. Switching from a local geopgraphical area of coverage to a larger scale brings with it increased advantages, but also increased problems. Using customary techniques requires either the use of "800" numbers at the alarm company (at great expense to the company) or long distance calls from the subscriber (where they eat the cost of the phone call). As contracts between large corporations and a single alarm company continue, the ability of one central location to monitor a chain of stores around the world becomes more and more expensive. Sending open and close activity reports from a panel around the world could easily add up to the hundreds or thousands of dollars a month in customary phone long distance charages. Because of this expense most sites do not implement test supervision signals unless maybe they are only once a day. With SIIPAT supervision is a two-way street with the alarm company able to "inquiry" the status of a particular system at any moment, even every couple seconds if high-security warrants it. 4. The SIIPAT Protocol The SIIPAT protocol is a sequence of commands and replies, and is based loosely on the design of many other Internet protocols currently in use. Please note that the protocol as described does not take into consideration the encryption process which occurs before the data is actually transferred across the Internet, if implemented. SIIPAT has several input commands (the first 6 characters of each are significant) that solicit various server responses. A "burst mode" transmission is also supported whereas the entire authentication and alarm message can be sent on the initial request for the socket. SIIPAT also supports several status commands which can be used by the server to check the status of a subscriber at any time. The messages the subscriber equipment may send vary depending on the equipment in use. Not all subscriber equipment may be capable of or have need to transmit all the various types of messages. All servers should be capable of receiving them all however. Each message transmitted is prefixed by an STX character (Ascii 2) followed by a two character alphabetic 'Message Type' code. The Message Type determines what the remainder of the message contains as well as the length of the entire message. All messages will conform to the following message format: - Start of Transmission identifier (Ascii 2). msg type - Two character Message Type. length - Two digit length of variable data to follow (01-99). data - Raw data message of length characters total. - End of Transmission identifier (Ascii 3). The server sends replies or status inquiries prefixed by an ENQ char- acter (Ascii 5) and terminated by an EOT (Ascii 4). The messages the server should be expected to return are grouped in the following catagories to make it easier for the subscriber equipment to determine the necessary action based solely on the first character. 1xxx - Success, Proceed, Verified 2xxx - Accepted but Incomplete 3xxx - Authentication Error 4xxx - Protocol Error 5xxx - Duplicate Transmission 8xxx - Network Busy/Error 9xxx - Status Inquiries Typically, the subscriber initiates the connection with the server. Upon opening the connection, the server issues a "1RDY" message (indicating the willingness of the server to accept SIIPAT commands). At that point, the subscriber sends it's data stream and awaits a response from the server indicating the success or failure of the transmission. The subscribers unit should also be capable of determining no response within a set time frame and resort to customary alarm transmision paths or attempt to contact a differant server at a differant IP address. Status messages can be initiated by the server if the subscriber unit supports it. Each subscriber unit shall at minimum support the type 9999 server response for inquires. The subscriber unit simply needs to respond with a status message with no variable length data supplied. This signifies to the server that this host does not support/want additional status messages to be performed against it. If the subscriber unit supports additional status messages, it will respond with the types of the status messages that it supports in the variable data. This allows for multiple vendors equipments with differant capabilities or for the subscriber to limit the status inquires that can be performed on their unit. 4.1 Examples of "simple" SIIPAT Transmissions The following are two examples of how an alarm message may be sent to the server using SIIPAT. Note that the data transferred between subscriber and server may be encrypted before it is sent which is not shown in these examples. Both these examples show the authentication of site 1234 with a password of PASSWORD. Two alarm messages are being sent for the alarm account number of 4321, one is a code 99 and the other is a code 31, both using the SIIPAT 4x2 format. 4.1.1 Standard Transmission Subscriber Server -------------------------- ----------------------------------- Open Connection --> <-- 1RDY17ABC ALARM COMPANYv1.00 ID041234 --> <-- 1PW?14Enter Password PW08PASSWORD --> <-- 1BGN18Begin Transmission AM11!!4X2432199 --> <-- 1RCV11!!4X2432199 AM11!!4X2432131 --> <-- 1RCV11!!4X2432131 CC --> <-- 1SNT152 Messages Rcvd Close Connection 4.1.2 Burst Transmission When a burst transmission is sent, all the data is sent on one stream. This stream can occur at the time of opening the connection or after the 1RDY message is returned depending on the subscriber unit and it's capabilities. Subscriber Server -------------------------- ----------------------------------- Open Connection --> <-- 1RDY17ABC ALARM COMPANYv1.00 ID041234PW08PASSWORDAM11!!4X2432199AM11!!4X2432131 <-- 1SNT152 Messages Rcvd Close Connection 4.2 Subscriber Messages The following sections briefly describe the possible messages that a subscriber unit can send. All these messages are prefixed by an STX character (Ascii 2) and terminated by an ETX (Ascii 3). 4.2.1 "ID" Messages - Logon Information Each transmission must be authenticated against a table the server maintains to ensure that no tampering is being attempted. Therefore each transmission must include an ID type message before actual messages will be acknowledged from the subscriber unit. ID - Message Code. xx - Length of ID to follow (01-99). ..... - Actual ID transmitted. (This ID may or may not coincide with the actual alarm number depending on preferance.) 4.2.2 "PW" Messages - Password Authentication In order to determine that a random ID wasn't guessed, a password associated with each ID must also be sent. Whether the server actually verifies this information or not is normally configurable. PW - Message Code. xx - Length of Password to follow (01-99). ...... - Actual Password transmitted. 4.2.3 "MA", "MS" and "MV" Messages - Alarm Messages Transmission of actual data is done with Alarm Messages. The three differant types of alarm messages allows the server to sort the messages by priority before sending them to the host computer system. MA - Message Code. (Alarm Messages) or MS (Status Messages) or MV (Verification Messages) xx - Length of Raw Alarm Data (01-99). ........ - Actual Raw Data. The format of the Raw Data for Alarm Type Messages varies depending on the transmitting and receiving equipment. For propeitary implementations this could be any format desired. It is recommended that the following format be used for compatibility so that automation software can parse the Emulated Data from the string and send it to the existing receiver interfaces for that type of receiver. This should ensure that the most current specifications remain in effect for SIIPAT if the manufacturer makes additions to their protocol. ! - Identifies Emulated Data being sent xxxx - Format Identifier of !4X1 - SIIPAT 4x1 Format or !4X2 - SIIPAT 4x2 Format or !4X3 - SIIPAT 4x3 Format or !CID - SIIPAT Contact ID Format or ADMC - Ademco 685 Receiver Emulation or DMP1 - DMP SCS1 Receiver Emulation or FBII - FBII CP220 Receiver Emulation or ITIC - ITI CS4000 Comp Emulation of ITIG - ITI CS4000 Generic Emulation or RMII - Radionics Modem II Emulation or RSIA - Radionics SIA Emulation or SAFE - Senses Intl. Safecom Emulation or SURG - Surgard xLR Receiver Emulation .......... - Emulated Data (length varies depending on the format and is five less than the length of the Length of Raw Data specified for the Alarm Message Type.) 4.2.4 "CC" Message - Close Connection Requests a summary from the server and once received closes the connection. All subsequent transmissions from the subscriber on this socket are ignored. 4.2.5 "??" Message - Subscriber Status The server must have sent a type 9 Status Inquiry in order for this message to be generated. When the server wishes to inquire on a subscriber, it opens the socket with the subscriber at the subscribers IP address and port and sends out a 9999 response. At that point the subscriber unit sends out a type ?? message indicating it's abilities for further commands. ?? - Message Code. xx - Length of available commands (04-96) yyyy - Number of the Server Inquiry that this subscriber is capable of. This is always a four digit number (9000-9999) that repeats. Ie:9990999199929993 would mean that this subscriber is capable of type 9990-9993 status inquiries. 4.2.6 "CL" Message - Cancel Last Message When this message is received by the server, the last M type message received is thrown away. This is used by subscriber units that detect the data sent back on the 1RCV message from the server was not the same as it sent. Once a subscriber sends this message, it can then begin to retransmit the message. 4.3 Server Responses The following sections explain the various responses that a server can sent to the subscriber. All these transmissions are started with an ENQ character (Ascii 5) and terminated with an EOT character (Ascii 4). 1xxx - Success, Proceed, Verified 2xxx - Accepted but Incomplete 3xxx - Authentication Error 4xxx - Protocol Error 5xxx - Duplicate Transmission 8xxx - Network Busy/Error 9xxx - Status Inquiries 4.3.1 - Success, Proceed, Verified 1RDY - Tells the subscriber that the server is ready to accept data and provides basic information about the server including the servers name and SIIPAT version number. 1PW? - Asks the subscriber unit for a password if required by the server. 1BGN - Tells the subscriber that it has been authenticated and it should begin transmitting signals. 1RCV - Repeats the data received back to the subscriber. 1CAN - The last message was cancelled as requested by a CL message. 1SNT - Tells the subscriber that the messages were sent to the automation system along with a comment which usually indicates the number of signals received. This message should be recorded by the subscriber unit for display as it may contain other information such as a notice to contact the alarm company regarding an outstanding balance or other informational purposes. 4.3.2 - Accepted but Incomplete 2INC - The message sent was incomplete in some way but enough information was received to pass it on. This is most likely caused by a message length field being set longer than the actual data received. 4.3.3 - Authentication Error 3BID - The ID sent is not on file or is blacklisted on this server. 3BPW - Bad or missing Password data was detected. 3BIP - The ID sent is configured to only be accepted from one IP address, which was not the one this message was from. 4.3.4 - Protocol Error 4ERR - An invalid Message Code was received or a message was missing relavent parts or incorrect data. 4TME - Too Many Errors, closing connection. This will only occur during busy socket usage when the same socket experiences more than three errors in a row. 4.3.5 - Duplicate Transmissions 5DUP - The message sent is exactly the same as the previous message from this subscriber. This can be caused when a server response is lost in replying to an alarm message and the subscriber tries again. A time limit for expiration of this feature can be set, or it can be disabled globally. 4.3.8 - Network/Busy Errors 8BSY - The server is too busy to handle the request now. This could be performance related or by lack of sockets available. Every server must be capable of at least 128 concurrent sockets to be approved with SIIPAT. 8HST - An error has occured with the host computer, thus making it impossible for this server to pass on the alarm information. 8TIM - Timeout waiting for message from subscriber. 4.3.9 - Status Inquiries All Status Inquiries with the exception of 9999 return type MS messages. The format of the returned message varies depending on what was requested. NOTE: The subscriber units shall normally be configured to only accept status inquiries from a host which has an IP address that the subscriber unit is programmed to send messages to. This prevents anyone from being able to ask a subscriber unit for it's status since only valid servers for that subscriber can request it. Additionally, as proposed in the optional extensions, programming information can be relayed upon additional authentication of the server by the subscriber. Items marked with an **** require additional authentication. Items marked with an !!!! also require a secondary authentication. 9000 - Return subscriber name. 9001 - Check Alarm/Restore Status. 9002 - Check Open/Close Status. 9003 - Sends temporary message to subscriber to be displayed on keypad (displayed until next keypad event occurs). 9004 - Changes the permanent keypad message. 9970 - Check Zone Status **** 9971 - Check Partition Status **** 9980 - Arms the system. **** !!!! 9981 - Disarms the system. **** !!!! 9982 - Bypass zones. **** !!!! 9994 - Return Configuration Switches. **** 9997 - Return IP address list. **** 9998 - Change the IP address list. **** !!!! 9999 - Ask the subscriber for it's capabilities. These are returned in an ?? type message. 9GMT - Asks subscriber for GMT offset. 9PNG - Returns 'PING'. 9TM? - Returns the current date/time at subscriber unit. 9TMS - Sets the current date/time at subscriber unit. 9TST - Returns 'TEST'. 4.4 Illegal Commands Should the subscriber issue an illegal command, the server may respond in one of the two following ways: 4TME Too Many Errors 4ERR Invalid Message Code 4.5 Timeouts The SIIPAT server can optionally have an inactivity timeout implemented. At the expiration of the allotted time, the server responds "8TIM Timeout" and closes the connection. 5. Author Steven M. Ryckman, Technical Supervisor Security Information & Management Systems, Inc. 3112 Teakwood Lane - C.S.M. Division Plano, Texas USA 75075 Voice: 972-964-7019 Fax: 972-964-0902 Email: sryckman@pobox.com 6. Additional Information For more information regarding SIIPAT, contact Steve Ryckman by one of the above listed methods (preferably by email). A "home page" has also been established with additional information on SIIPAT at the following URL: http://pobox.com/~sims.support/siipat.html