idnits 2.17.1 draft-petrescu-ipwave-diaser-checksum-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There is 1 instance of too long lines in the document, the longest one being 101 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 20, 2019) is 1795 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group A. Petrescu 3 Internet-Draft M. Sarr 4 Intended status: Standards Track CEA, LIST 5 Expires: November 21, 2019 May 20, 2019 7 The checksum in DIASER/UDP/IP is a XOR without STX 8 draft-petrescu-ipwave-diaser-checksum-01 10 Abstract 12 This document defines the manner in which to calculate the checksum 13 for the protocol DIASER. DIASER is a protocol for communication with 14 traffic lights controllers used in France. DIASER is specified at 15 AFNOR. The specification misses an instruction on how to compute the 16 'BCC' checksum ('Byte Character Control'). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 21, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. DIASER Protocol and IETF Protocols . . . . . . . . . . . . . 2 54 3. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 60 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 4 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Terminology 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 2. DIASER Protocol and IETF Protocols 71 The DIASER protocol does this and that with a Traffic Lights 72 controller - it is an Application Layer protocol. DIASER can be 73 transported over UDP and over IP. The DIASER specification is 74 available at a cost from AFNOR, on the World Wide Web. The DIASER 75 specification does not describe the mechanism to compute the checksum 76 'BCC' (Byte Control Character). There exist several verbal (oral) 77 versions of this mechanism: to cover or not to cover the STX (Start 78 of Text), or the ETX (End of Text). Studying some implementations of 79 a particular controller (Aximum) and packet dumps from independent 80 sources, lead to a possibility to reverse engineer the specification 81 of the checksum calculation of DIASER. 83 The DIASER protocol is an application layer protocol. Initially it 84 was designed to run on serial lines like RS-232. Later on it was put 85 on UDP (User Datagram Protocol). The UDP protocol is an IETF 86 protocol. Running DIASER over UDP over IP is a great fact; contrary 87 to RS-232, it allows to query a Traffic Lights Controller from a 88 remote 'Poste de Commande et Control', and further from any other 89 point in the Internet; second, it allows to query the controller over 90 the future generation of Internet Protocol namely IPv6; thirdly, it 91 allows to query the controller from nearby like an autonomous 92 shuttle, with lower latency communications, thus supporting higher 93 autonomous shuttle speeds; fourthly, it is easy to secure - rely on 94 numerous security tools for software (IPsec, VPN) widely available 95 and enjoy trust developped by Certificate Authorities and Let's 96 Encrypt. 98 IETF has its own way to specify a checksum. UDP, ICMP and other IETF 99 protocols use a unique kind of checksum, which is specified in a 100 particular RFC. It is clear that the RFC checksum is different from 101 the DIASER checksum, at least because it involves also a notion of 102 complement (not just XOR). 104 3. Checksum 106 The DIASER checksum is independent of the checksum field in the UDP 107 header preceding the DIASER payload. In a DIASER/UDP packet there 108 are two checksums: the DIASER checksum and the UDP checksum. 110 The DIASER checksum is an exclusive or operation (XOR) performed 111 sequentially on the DIASER command; the bytes are read from left to 112 right; the STX character is not read; the ETX character is read. 114 In French, the description of the checksum can be found in a proposal 115 of updating the DIASER standard dated September 2018. It is written 116 like this: 'Le caractA¨re de contrA'le BCC [checksum] est le 117 rA(C)sultat du "ou exclusif" de tous les caractA¨res du message 118 aprA¨s le STX non inclus, et peut prendre n'importe quelle 119 valeur ASCII.' 121 A python implementation of the DIASER checksum is the following. 122 Note the use of '^' operator for XOR and the 'for' iteration on each 123 byte. Note that only ETX is covered by the checksum, not the STX. 125 #!/usr/bin/env python 126 # Mariama for CEA 128 packet="\x43\x6B\x30\x33\x47\x30\x30\x47\x30\x31\x47\x30\x32\x47\x30\x33\x47\x30\x34\x47\x30\x35\x47\x30\x36\x47\x30\x37\x47\x30\x38\x2A\x2A\x2A\x2A\x2A\x2A\x2A\x2A\x2A\x03" 129 # packet is 'Ck03G00G01G02G03G04G05G06G07G08*********|ETX' 130 checksum = 0 131 for el in packet: 132 checksum ^= ord(el) 133 print hex(checksum) 134 # code snippet found on 'stack overflow' on April 25th, 2019; and 135 # adapted for DIASER. 137 Figure 1: Code snippet for DIASER Checksum 139 4. Security Considerations 141 Wrongly calculating a checksum may lead to security risks. 143 5. IANA Considerations 145 no request. 147 6. Contributors 149 Listed. 151 7. Acknowledgements 153 StA(C)phane GOEURIOT suggested an initial approximative oral 154 description of the checksum calculation. Christophe DAMAS detailed 155 the description of the checksum calculation with more precision, as 156 an improvement to the DIASER standard. Marco PEROTTI faced necessity 157 of proper checksum calculation. 159 8. Normative References 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, 163 DOI 10.17487/RFC2119, March 1997, 164 . 166 Appendix A. ChangeLog 168 The changes are listed in reverse chronological order, most recent 169 changes appearing at the top of the list. 171 -01: added the description of checksum calculation as reported in 172 French. 174 Authors' Addresses 176 Alexandre Petrescu 177 CEA, LIST 178 CEA Saclay 179 Gif-sur-Yvette , Ile-de-France 91190 180 France 182 Phone: +33169089223 183 Email: Alexandre.Petrescu@cea.fr 184 Mariama Sarr 185 CEA, LIST 186 CEA Saclay 187 Gif-sur-Yvette , Ile-de-France 91190 188 France 190 Phone: +phone 191 Email: Mariama.Sarr@cea.fr