idnits 2.17.1 draft-rfced-info-ryckman-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 528 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 14 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Expires: June 1997 Internet-Draft 3 Category: Informational S. Ryckman 4 SIMS, Inc. 6 Security Industry Internet Protocol for Alarm Transmission (SIIPAT) 7 9 Status of this Memo 11 This memo provides information for the Internet community. This memo 12 does not specify an Internet standard of any kind. Distribution of 13 this memo is unlimited. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This document suggests a method for delivering alarm information over 34 the Internet. All communication shall use an encryption algorithm 35 for transmission of the data. An immediate response from the host 36 will be used for verification of receipt of the message. 38 This transmission method may be use as a backup transmission method 39 to traditional dial-up or leased line methods, or as a primary 40 transmission method with traditional methods becomming the backup. 42 Due to the required security of the data being transmitted, the 43 encryption algorithm used will only be released on a need to know 44 basis to software developers in the Alarm/Security Industry. 45 A non-disclosure agreement will be required. Terms and conditions 46 of the licensing will depend on the intended purpose for use and 47 may require a non-competition agreement or licensing fees. 49 The Internet Assigned Numbers Authority (IANA) has assigned port 50 1733 for the registered use of SIIPAT transmissions. 52 1. Introduction 54 This transmission protocol was developed to eliminate the need 55 for dial-up communications to send short data bursts of alarm 56 information. Many times, the amount of time it takes to seize 57 the dial-up phone line, dial the number and wait for an answer 58 by the alarm receiving equipment is much greater than the amount 59 of time it takes to transmit the data itself (even at 300 baud). 60 Since many corporations and government agencies as well as alarm 61 companies already have dedicated Internet connections, it seems 62 resonable that it could be used as a quick transmission method. 63 Due to the inherent probability of failures of the network at 64 some point between origination and reception of the alarm signal, 65 it should NOT be used for the sole transmission path for any 66 signal. This transmission method can be treated with the same 67 concerns as a typical radio alarm transmission, quick but not 68 entirely absolute. 70 Throughout the remainder of this document the following terms 71 will be used. 73 Port/Socket - Used interchangably to refer to the logical 74 connection created when the client software polls the host 75 on a particular port number, in this case port 1733. 77 SIIPAT - Security Industry Internet Protocol for Alarm 78 Transmission (Pronounced Si-Pay). 80 Server - The software running at the Alarm Company which is 81 connected to the Internet and monitoring an IP address port. 83 Subscriber - The software/device at the protected location. 85 2. System Philosophy 87 Proposing an alternative method of transportation of alarm signals 88 is not as easy to implement as it sounds. A very simple adoption 89 of such a feat could be accomplished with normal Email. This would 90 not provide immediate notification of receipt however, and would 91 open the system up to tampering from external sources. Clearly a 92 secured encryption routine must be used, to prevent people from 93 creating false signals or using the protocol for sending non-alarm 94 information, as is possible with existing transmission formats. 95 The principle of SIIPAT is to provide security to the alarm transmission 96 process not found currently. This is security both for the originator 97 of the alarm signal (increased transmission speed) and for the 98 alarm company (reduction of false signals due to tampering). 99 Until every home has it's own direct connection to the Internet, 100 SIIPAT can not be used for every alarm system. It's primary purpose 101 is for commercial applications or where the alarm signal may 102 originate from a non-customary device such as a program on a 103 computer used for monitoring network or environmental conditions, 104 home automation/access control computerized systems or from 105 radio network providers for vehicle location/tracking purposes. 107 SIIPAT itself does not include definition for the equipment on either 108 end of the transmission, only the format of the data in between. 109 Implementation of SIIPAT may include a dedicated machine to 110 act as the server or use of an automation software package which 111 supports the SIIPAT interface directly. The way the protocol is 112 designed supports simple "generic" transmissions as well as 113 emulating specific receiver signals so that an automation package 114 can pass the message to an existing receiver interface. 116 3. Why use the Internet to send alarm messages ? 118 Every day, more and more alarm companies are changing from small 119 "mom and pop" companies, to nationwide or global monitoring stations. 120 With the ever increasing competition from other companies, an alarm 121 company must remain unique to remain in business. Switching from 122 a local geopgraphical area of coverage to a larger scale brings 123 with it increased advantages, but also increased problems. Using 124 customary techniques requires either the use of "800" numbers at 125 the alarm company (at great expense to the company) or long distance 126 calls from the subscriber (where they eat the cost of the phone call). 127 As contracts between large corporations and a single alarm company 128 continue, the ability of one central location to monitor a chain 129 of stores around the world becomes more and more expensive. Sending 130 open and close activity reports from a panel around the world could 131 easily add up to the hundreds or thousands of dollars a month in 132 customary phone long distance charages. Because of this expense 133 most sites do not implement test supervision signals unless maybe 134 they are only once a day. With SIIPAT supervision is a two-way 135 street with the alarm company able to "inquiry" the status of a 136 particular system at any moment, even every couple seconds if 137 high-security warrants it. 139 4. The SIIPAT Protocol 141 The SIIPAT protocol is a sequence of commands and replies, and is based 142 loosely on the design of many other Internet protocols currently 143 in use. Please note that the protocol as described does not take 144 into consideration the encryption process which occurs before the 145 data is actually transferred across the Internet, if implemented. 147 SIIPAT has several input commands (the first 6 characters of each are 148 significant) that solicit various server responses. A "burst mode" 149 transmission is also supported whereas the entire authentication 150 and alarm message can be sent on the initial request for the socket. 151 SIIPAT also supports several status commands which can be used by the 152 server to check the status of a subscriber at any time. 154 The messages the subscriber equipment may send vary depending on the 155 equipment in use. Not all subscriber equipment may be capable of 156 or have need to transmit all the various types of messages. All 157 servers should be capable of receiving them all however. 159 Each message transmitted is prefixed by an STX character (Ascii 2) 160 followed by a two character alphabetic 'Message Type' code. The 161 Message Type determines what the remainder of the message contains 162 as well as the length of the entire message. All messages will 163 conform to the following message format: 165 - Start of Transmission identifier (Ascii 2). 166 msg type - Two character Message Type. 167 length - Two digit length of variable data to follow (01-99). 168 data - Raw data message of length characters total. 169 - End of Transmission identifier (Ascii 3). 171 The server sends replies or status inquiries prefixed by an ENQ char- 172 acter (Ascii 5) and terminated by an EOT (Ascii 4). 173 The messages the server should be expected to return are grouped in 174 the following catagories to make it easier for the subscriber equipment 175 to determine the necessary action based solely on the first character. 177 1xxx - Success, Proceed, Verified 178 2xxx - Accepted but Incomplete 179 3xxx - Authentication Error 180 4xxx - Protocol Error 181 5xxx - Duplicate Transmission 182 8xxx - Network Busy/Error 183 9xxx - Status Inquiries 185 Typically, the subscriber initiates the connection with the server. 186 Upon opening the connection, the server issues a "1RDY" message 187 (indicating the willingness of the server to accept SIIPAT commands). 188 At that point, the subscriber sends it's data stream and awaits 189 a response from the server indicating the success or failure of 190 the transmission. The subscribers unit should also be capable 191 of determining no response within a set time frame and resort to 192 customary alarm transmision paths or attempt to contact a differant 193 server at a differant IP address. 195 Status messages can be initiated by the server if the subscriber 196 unit supports it. Each subscriber unit shall at minimum support 197 the type 9999 server response for inquires. The subscriber unit 198 simply needs to respond with a status message with no variable 199 length data supplied. This signifies to the server that this 200 host does not support/want additional status messages to be 201 performed against it. If the subscriber unit supports additional 202 status messages, it will respond with the types of the status 203 messages that it supports in the variable data. This allows for 204 multiple vendors equipments with differant capabilities or for 205 the subscriber to limit the status inquires that can be performed 206 on their unit. 208 4.1 Examples of "simple" SIIPAT Transmissions 210 The following are two examples of how an alarm message may be 211 sent to the server using SIIPAT. Note that the data transferred 212 between subscriber and server may be encrypted before it is sent 213 which is not shown in these examples. 215 Both these examples show the authentication of site 1234 with a 216 password of PASSWORD. Two alarm messages are being sent for the 217 alarm account number of 4321, one is a code 99 and the other is 218 a code 31, both using the SIIPAT 4x2 format. 220 4.1.1 Standard Transmission 222 Subscriber Server 223 -------------------------- ----------------------------------- 224 Open Connection --> 225 <-- 1RDY17ABC ALARM COMPANYv1.00 226 ID041234 --> 227 <-- 1PW?14Enter Password 228 PW08PASSWORD --> 229 <-- 1BGN18Begin Transmission 230 AM11!!4X2432199 --> 231 <-- 1RCV11!!4X2432199 232 AM11!!4X2432131 --> 233 <-- 1RCV11!!4X2432131 234 CC --> 235 <-- 1SNT152 Messages Rcvd 236 Close Connection 238 4.1.2 Burst Transmission 240 When a burst transmission is sent, all the data is sent on one 241 stream. This stream can occur at the time of opening the connection 242 or after the 1RDY message is returned depending on the subscriber 243 unit and it's capabilities. 245 Subscriber Server 246 -------------------------- ----------------------------------- 247 Open Connection --> 248 <-- 1RDY17ABC ALARM COMPANYv1.00 249 ID041234PW08PASSWORDAM11!!4X2432199AM11!!4X2432131 250 <-- 1SNT152 Messages Rcvd 251 Close Connection 253 4.2 Subscriber Messages 255 The following sections briefly describe the possible messages that 256 a subscriber unit can send. All these messages are prefixed by 257 an STX character (Ascii 2) and terminated by an ETX (Ascii 3). 259 4.2.1 "ID" Messages - Logon Information 261 Each transmission must be authenticated against a table the server 262 maintains to ensure that no tampering is being attempted. Therefore 263 each transmission must include an ID type message before actual 264 messages will be acknowledged from the subscriber unit. 266 ID - Message Code. 267 xx - Length of ID to follow (01-99). 268 ..... - Actual ID transmitted. 269 (This ID may or may not coincide with the 270 actual alarm number depending on preferance.) 272 4.2.2 "PW" Messages - Password Authentication 274 In order to determine that a random ID wasn't guessed, a password 275 associated with each ID must also be sent. Whether the server 276 actually verifies this information or not is normally configurable. 278 PW - Message Code. 279 xx - Length of Password to follow (01-99). 280 ...... - Actual Password transmitted. 282 4.2.3 "MA", "MS" and "MV" Messages - Alarm Messages 284 Transmission of actual data is done with Alarm Messages. The three 285 differant types of alarm messages allows the server to sort the 286 messages by priority before sending them to the host computer system. 288 MA - Message Code. (Alarm Messages) 289 or MS (Status Messages) 290 or MV (Verification Messages) 291 xx - Length of Raw Alarm Data (01-99). 292 ........ - Actual Raw Data. 294 The format of the Raw Data for Alarm Type Messages varies depending 295 on the transmitting and receiving equipment. For propeitary 296 implementations this could be any format desired. It is recommended 297 that the following format be used for compatibility so that 298 automation software can parse the Emulated Data from the string 299 and send it to the existing receiver interfaces for that type 300 of receiver. This should ensure that the most current specifications 301 remain in effect for SIIPAT if the manufacturer makes additions 302 to their protocol. 304 ! - Identifies Emulated Data being sent 305 xxxx - Format Identifier 306 of !4X1 - SIIPAT 4x1 Format 307 or !4X2 - SIIPAT 4x2 Format 308 or !4X3 - SIIPAT 4x3 Format 309 or !CID - SIIPAT Contact ID Format 310 or ADMC - Ademco 685 Receiver Emulation 311 or DMP1 - DMP SCS1 Receiver Emulation 312 or FBII - FBII CP220 Receiver Emulation 313 or ITIC - ITI CS4000 Comp Emulation 314 of ITIG - ITI CS4000 Generic Emulation 315 or RMII - Radionics Modem II Emulation 316 or RSIA - Radionics SIA Emulation 317 or SAFE - Senses Intl. Safecom Emulation 318 or SURG - Surgard xLR Receiver Emulation 319 .......... - Emulated Data 320 (length varies depending on the format 321 and is five less than the length of 322 the Length of Raw Data specified for 323 the Alarm Message Type.) 325 4.2.4 "CC" Message - Close Connection 327 Requests a summary from the server and once received closes the 328 connection. All subsequent transmissions from the subscriber on 329 this socket are ignored. 331 4.2.5 "??" Message - Subscriber Status 333 The server must have sent a type 9 Status Inquiry in order for 334 this message to be generated. When the server wishes to inquire 335 on a subscriber, it opens the socket with the subscriber at the 336 subscribers IP address and port and sends out a 9999 response. 337 At that point the subscriber unit sends out a type ?? message 338 indicating it's abilities for further commands. 340 ?? - Message Code. 341 xx - Length of available commands (04-96) 342 yyyy - Number of the Server Inquiry that this 343 subscriber is capable of. This is always 344 a four digit number (9000-9999) that repeats. 345 Ie:9990999199929993 would mean that this 346 subscriber is capable of type 9990-9993 347 status inquiries. 349 4.2.6 "CL" Message - Cancel Last Message 351 When this message is received by the server, the last M type 352 message received is thrown away. This is used by subscriber 353 units that detect the data sent back on the 1RCV message from 354 the server was not the same as it sent. Once a subscriber 355 sends this message, it can then begin to retransmit the message. 357 4.3 Server Responses 359 The following sections explain the various responses that a 360 server can sent to the subscriber. All these transmissions are 361 started with an ENQ character (Ascii 5) and terminated with 362 an EOT character (Ascii 4). 364 1xxx - Success, Proceed, Verified 365 2xxx - Accepted but Incomplete 366 3xxx - Authentication Error 367 4xxx - Protocol Error 368 5xxx - Duplicate Transmission 369 8xxx - Network Busy/Error 370 9xxx - Status Inquiries 372 4.3.1 - Success, Proceed, Verified 374 1RDY - Tells the subscriber that the server is ready to accept 375 data and provides basic information about the server 376 including the servers name and SIIPAT version number. 377 1PW? - Asks the subscriber unit for a password if required by 378 the server. 379 1BGN - Tells the subscriber that it has been authenticated and 380 it should begin transmitting signals. 381 1RCV - Repeats the data received back to the subscriber. 382 1CAN - The last message was cancelled as requested by a CL message. 383 1SNT - Tells the subscriber that the messages were sent to the 384 automation system along with a comment which usually 385 indicates the number of signals received. This message 386 should be recorded by the subscriber unit for display 387 as it may contain other information such as a notice 388 to contact the alarm company regarding an outstanding balance 389 or other informational purposes. 391 4.3.2 - Accepted but Incomplete 393 2INC - The message sent was incomplete in some way but enough 394 information was received to pass it on. This is most 395 likely caused by a message length field being set longer 396 than the actual data received. 398 4.3.3 - Authentication Error 400 3BID - The ID sent is not on file or is blacklisted on this server. 401 3BPW - Bad or missing Password data was detected. 402 3BIP - The ID sent is configured to only be accepted from one IP 403 address, which was not the one this message was from. 405 4.3.4 - Protocol Error 407 4ERR - An invalid Message Code was received or a message was 408 missing relavent parts or incorrect data. 409 4TME - Too Many Errors, closing connection. This will only 410 occur during busy socket usage when the same socket 411 experiences more than three errors in a row. 413 4.3.5 - Duplicate Transmissions 415 5DUP - The message sent is exactly the same as the previous message 416 from this subscriber. This can be caused when a server 417 response is lost in replying to an alarm message and the 418 subscriber tries again. A time limit for expiration of this 419 feature can be set, or it can be disabled globally. 421 4.3.8 - Network/Busy Errors 423 8BSY - The server is too busy to handle the request now. This 424 could be performance related or by lack of sockets available. 425 Every server must be capable of at least 128 concurrent 426 sockets to be approved with SIIPAT. 427 8HST - An error has occured with the host computer, thus making 428 it impossible for this server to pass on the alarm information. 429 8TIM - Timeout waiting for message from subscriber. 431 4.3.9 - Status Inquiries 433 All Status Inquiries with the exception of 9999 return type MS 434 messages. The format of the returned message varies depending 435 on what was requested. NOTE: The subscriber units shall normally 436 be configured to only accept status inquiries from a host which 437 has an IP address that the subscriber unit is programmed to send 438 messages to. This prevents anyone from being able to ask a 439 subscriber unit for it's status since only valid servers for that 440 subscriber can request it. Additionally, as proposed in the 441 optional extensions, programming information can be relayed upon 442 additional authentication of the server by the subscriber. 443 Items marked with an **** require additional authentication. 444 Items marked with an !!!! also require a secondary authentication. 446 9000 - Return subscriber name. 447 9001 - Check Alarm/Restore Status. 448 9002 - Check Open/Close Status. 449 9003 - Sends temporary message to subscriber to be displayed on keypad 450 (displayed until next keypad event occurs). 451 9004 - Changes the permanent keypad message. 452 9970 - Check Zone Status **** 453 9971 - Check Partition Status **** 454 9980 - Arms the system. **** !!!! 455 9981 - Disarms the system. **** !!!! 456 9982 - Bypass zones. **** !!!! 457 9994 - Return Configuration Switches. **** 458 9997 - Return IP address list. **** 459 9998 - Change the IP address list. **** !!!! 460 9999 - Ask the subscriber for it's capabilities. These are returned 461 in an ?? type message. 462 9GMT - Asks subscriber for GMT offset. 463 9PNG - Returns 'PING'. 464 9TM? - Returns the current date/time at subscriber unit. 465 9TMS - Sets the current date/time at subscriber unit. 466 9TST - Returns 'TEST'. 468 4.4 Illegal Commands 470 Should the subscriber issue an illegal command, the server may respond in 471 one of the two following ways: 473 4TME Too Many Errors 474 4ERR Invalid Message Code 476 4.5 Timeouts 478 The SIIPAT server can optionally have an inactivity timeout 479 implemented. At the expiration of the allotted time, the server 480 responds "8TIM Timeout" and closes the connection. 482 5. Author 484 Steven M. Ryckman, Technical Supervisor 485 Security Information & Management Systems, Inc. 486 3112 Teakwood Lane - C.S.M. Division 487 Plano, Texas USA 75075 489 Voice: 972-964-7019 490 Fax: 972-964-0902 491 Email: sryckman@pobox.com 493 6. Additional Information 495 For more information regarding SIIPAT, contact Steve Ryckman by one of 496 the above listed methods (preferably by email). A "home page" has 497 also been established with additional information on SIIPAT at 498 the following URL: http://pobox.com/~sims.support/siipat.html