Network Working Group S. Guthery Internet Draft HID Global Intended status: Experimental August 21, 2008 Expires: February 21, 2009 IP and ARP over Wiegand draft-guthery-wiegand-ip-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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 21, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes the transport of IP datagrams over the Security Industry Association standard [3] five-conductor cable called the Wiegand interface used for communication between card readers and control panels in physical access control systems. Guthery Expires February 21, 2009 [Page 1] Internet-Draft IP and ARP over Wiegand August 2008 Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 [1]. Table of Contents 1. Introduction...................................................2 2. Wiegand Physical Layer.........................................2 3. Wiegand Data Link Layer........................................3 4. IP over Wiegand................................................4 5. ICMP Messages..................................................4 6. ARP and RARP Message Format....................................4 7. Card Reader Cache..............................................5 8. Maximum Transmission Unit......................................6 9. IPv6 Considerations............................................6 10. Security Considerations.......................................6 11. IANA Considerations...........................................6 12. Conclusions...................................................6 13. Acknowledgments...............................................6 References........................................................7 13.1. Normative References.....................................7 13.2. Informative References...................................7 Author's Addresses................................................7 Intellectual Property Statement...................................8 Disclaimer of Validity............................................8 1. Introduction This document describes the transport of IP datagrams including ARP and ICMP messages over the five-conductor cable called the Wiegand reader interface that is used for communication between card readers and control panels in physical access control systems. 2. Wiegand Physical Layer The physical and electrical properties of the five conductors on the Wiegand reader interface are described in the Security Industry Association standard AC-01, Access Control Standard Protocol for the 26-BIT Wiegand Reader Interface, dated October 17, 1996 [3]. Guthery Expires February 21, 2009 [Page 2] Internet-Draft IP and ARP over Wiegand August 2008 Two of the five conductors on the Wiegand reader interface, power (from panel to reader) and ground, do not carry communication signals. Two of the remaining three conductors, called DATA0 and DATA1, carry digital data from the reader to the panel using what is known in the trade as the Wiegand Protocol. The remaining conductor, LEDCTL, carries a high-or-low indicator from the panel to the reader. It is used to provide access control feedback to the person, for example turning the color of a light-emitting diode on the reader to green to indicate that access has been granted. Unlike most IP channels including birds and semaphores, the Wiegand channel is asymmetric at the physical layer. Typical implementations of the Wiegand standard block the transmission of any signal from the panel to the reader on DATA0/DATA1 and from the reader to the panel on LEDCTL. The DATA0 conductor carries the 0's of a bit stream and the DATA1 conductor carries the 1's of the bit stream. DATA0 and DATA1 are half-duplex in the sense that there is never a signal on both of these conductors at the same time. The datalink protocol for transmitting bit streams from the reader to the panel on DATA0 and DATA1 is defined by AC-01. LEDCTL is a 2-way switch. In the example usages described in AC-01, when voltage is low a red/green LED on the reader is to be green or a red LED is to be red. When voltage is high a red/green LED on the reader is to be red or a red LED is to be off. Because these light indications are intended to be observable by a human observer, the hold times for both levels are supraliminal and thus of 10ms or more. The use of the LEDCTL line can therefore extended by saying that any signal from the panel to the reader on LEDCTL with a hold time of less than 10ms SHALL interpreted a data link signal in an asynchronous transmission protocol and not as a signal to change the state of the LED. Further details of this protocol are described in the following sections. 3. Wiegand Data Link Layer TTY ("mark-and-space") bit encoding on LEDCTL with one START bit, 8 character bits and one STOP bit and no parity bit (8N1) SHALL be used on LEDCTL. All datalink frames SHALL be the same size. Guthery Expires February 21, 2009 [Page 3] Internet-Draft IP and ARP over Wiegand August 2008 SLIP packet framing within the Wiegand data link frame SHALL be used on DATA0/DATA1 and LEDCTL. 4. IP over Wiegand IP datagrams over Wiegand SHALL be wholly contained within one datalink frame. IP over Wiegand does not support IP datagram fragmentation across multiple datalink frames. The Version field SHALL be set to 4. The Internet Header Length field SHALL be set to 5. No IP datagram options are supported by IP over Wiegand. The Type of Service field SHALL be set to 0. The Flags and Fragment Offset fields SHALL be set to 0. The Protocol field SHALL be set to 61 ("any host internal protocol") in the case that the data field contains a proprietary or vendor- specific protocol packet; i.e. the packet of a protocol other than one with an IANA Assigned Internet Protocol Number. 5. ICMP Messages The card reader SHOULD support ECHO REQUEST. The card reader MAY support TIMESTAMP and TIMSTAMP REPLY. The card reader and the control panel MAY support ICMP security failure messages (type=40) with the proviso that the message need not be restricted to the failure of a Photuris session key management protocol execution but rather to the execution of any security protocol known implicitly to both the card reader and the control panel. 6. ARP and RARP Message Format A Wiegand network consists of a control panel together with all the card readers that are physically connected to it. Each physical connection is through an interface that has a 16-bit address on the control panel. A Wiegand network is structurally similar to the Logical IP Subnetwork (LIS) of ATM networks [9] since each of the card readers can communicate directly with the control panel but not with each other. Guthery Expires February 21, 2009 [Page 4] Internet-Draft IP and ARP over Wiegand August 2008 The Wiegand ARP/RARP protocol uses the same packet format as ARP for Ethernet. ARP packets shall be transmitted with the assigned Wiegand hardware type code, XX. ARP packets SHALL be accepted by a card reader only if received with this hardware type. ar$hrd (16 bits) SHALL contain the Wiegand specified hardware type value, XX (decimal). ar$pro (16 bits) SHALL contain the IP protocol code 2048 (decimal). ar$hln (8 bits) SHALL contain 2. ar$pln (8 bits) SHALL contain 4. ar$op (16 bits) SHALL contain 1 for requests, 2 for responses. ar$sha (16 bits) in requests SHALL contain the requester's interface address. In replies it SHALL contain the target node's interface address. ar$spa (32 bits) in requests SHALL contain the requester's IP address if known, otherwise zero. In replies it shall contain the target node's IP address. ar$tpa (32 bits) in requests SHALL contain the target's IP address if known, otherwise zero. In replies it SHALL contain the requester's IP address. ar$atn (8 bits) is the octet length of following ar$uid. ar$uid (n octets) in requests SHALL contain the requester's unique identifier. In replies it shall contain the target node's unique identifier. Support for ARP and RARP by both card readers and control panels is OPTIONAL. 7. Card Reader Cache The default entry in the route cache of card reader contains SHOULD be the control panel. A card reader MAY maintain a route cache that consists of solely of this entry. Guthery Expires February 21, 2009 [Page 5] Internet-Draft IP and ARP over Wiegand August 2008 8. Maximum Transmission Unit The effective upper bound on the size of a Wiegand IP datagram is not determined by the properties of the link layer protocol but rather by the computational capabilities of card readers. Card readers considered in this document include those that use interrupts-off, software UART ("bit banging") techniques for low-level input and output. Since a card reader's primary responsibility is to respond to the presentation of a card, time intervals during which this is not possible SHOULD be minimized. Therefore the MTU for IP over Wiegand is set to the maximum datagram that all hosts must be prepared to accept, namely 576 octets. 9. IPv6 Considerations It is desirable to be able to give each card reader and each control panel its own static IP address in the IT infrastructure within which the card readers and control panels are installed. Therefore it is expected that IPv6 will be more attractive than IPv4 for physical access control systems. IPv6 requires that the MTU be at least 1280 octets. This requirement exceeds the design capabilities of today's Wiegand wire infrastructure. Therefore, this document does not foresee the use of IPv6 in the context it has considered. 10. Security Considerations Security issues are not discussed in this document. 11. IANA Considerations 12. Conclusions This document describes a realization of the Internet Protocol on the physical, electrical and logical characteristics of the Wiegand reader interface as described the Security Industry Association standard AC-01, Access Control Standard Protocol for the 26-BIT Wiegand Reader Interface, dated October 17, 1996. The realization is backward compatible with and maintains conformance to that standard. 13. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Guthery Expires February 21, 2009 [Page 6] Internet-Draft IP and ARP over Wiegand August 2008 References 13.1. Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP9, RFC 2026, October 1996 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Security Industry Association, AC-01, Access Control Standard Protocol for the 26-BIT Wiegand Reader Interface, October 17, 1996 [4] Braden, R. "Requirements for Internet Hosts - Communication Layers", RFC 1122, October 1989 [5] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981 [6] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, Stanford, June 1984 [7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994 [8] Postel, J., "Internet Control Message Protocol", RFC-792, STD 5, USC/Information Sciences Institute, September 1981 [9] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM," RFC 2225, April 1998 [10] Karn, P., "ICMP Security Failures Messages," RCF 2521, March 1999 13.2. Informative References Author's Addresses Scott Guthery HID Global 1320 Centre Street #201A Newton Center, MA 02459-2497 Guthery Expires February 21, 2009 [Page 7] Internet-Draft IP and ARP over Wiegand August 2008 Phone: +1 617 365 3059 Email: sguthery@hidcorp.com Intellectual Property Statement 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. 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, THE IETF TRUST 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. Copyright Statement Copyright (C) The IETF Trust (2008). 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. Guthery Expires February 21, 2009 [Page 8] Internet-Draft IP and ARP over Wiegand August 2008 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Guthery Expires February 21, 2009 [Page 9]