idnits 2.17.1 draft-smyslov-ipsecme-ikev2-compression-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2018) is 2239 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2-IANA' == Outdated reference: A later version (-02) exists of draft-mglt-6lo-diet-esp-requirements-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Standards Track March 2, 2018 5 Expires: September 3, 2018 7 Using compression in the Internet Key Exchange Protocol Version 2 8 (IKEv2) 9 draft-smyslov-ipsecme-ikev2-compression-05 11 Abstract 13 This document describes a method for reducing the size of the IKEv2 14 messages by using lossless compression. Making IKEv2 messages 15 smaller is desirable for low power consumption battery powered 16 devices. It also helps to avoid IP fragmentation of IKEv2 messages. 17 This document describes how compression is negotiated maintaining 18 backward compatibility and how it is used in IKEv2. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 3, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 56 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Using Compression in the IKE_SA_INIT Exchange . . . . . . 4 58 3.2. Using Compression in Subsequent Exchanges . . . . . . . . 6 59 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Compressed Payload . . . . . . . . . . . . . . . . . . . 7 61 4.2. INVALID_COMPRESSION_ALGORITHM Notification . . . . . . . 8 62 5. Interaction with other IKEv2 Extensions . . . . . . . . . . . 8 63 5.1. Interaction with IKEv2 Fragmentation . . . . . . . . . . 9 64 5.2. Interaction with IKEv2 Resumption . . . . . . . . . . . . 9 65 5.3. Interaction with IKEv2 Redirect . . . . . . . . . . . . . 9 66 5.4. Interaction with IKEv2 Puzzles . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 The Internet Key Exchange protocol version 2 (IKEv2) defined in 77 [RFC7296] is used in the IP Security (IPsec) architecture for the 78 purposes of Security Association (SA) parameters negotiation and 79 authenticated key exchange. The protocol uses UDP as a transport for 80 its messages. The size of the IKEv2 messages varies from hundreds 81 bytes to several kBytes. 83 Sending large UDP messages may cause IP fragmentation to take place, 84 that may interact badly with some Network Address Translators (NAT). 85 One of the possible solutions to the problem is IKEv2 fragmentation 86 described in [RFC7383]. However, the IKEv2 fragmentation cannot be 87 used for unencrypted messages and thus cannot be used in the initial 88 IKEv2 exchange (IKE_SA_INIT). Usually the messages of the 89 IKE_SA_INIT exchange are relatively small and this restriction 90 doesn't cause problems. However with adoption more and more new 91 algorithms and new IKEv2 extensions there is a tendency for these 92 messages to grow up in size. 94 The lossless compression can be used to reduce the size of the IKEv2 95 messages. Each IKEv2 message contains different types of data 96 structured in payloads. Depending on the type of payload the 97 compressibility of the data it contains varies greatly. Some types 98 of payloads, like the Nonce payload, contain data that are almost 99 uncompressible. On the other hand, such payloads like the Security 100 Association payload or Notification payload usually have a lot of 101 redundancy in their encoding and hence are highly compressible. 102 Since many emerging IKEv2 extensions add new type of notification or 103 new parameter to the Security Association payload contained in the 104 IKE_SA_INIT messages, the ability to compress these messages would 105 help keep their size bounded. 107 Compression can also be applied to the messages followed the 108 IKE_SA_INIT exchange. In this case the reduced size of the messages 109 would make the necessity to use the IKEv2 fragmentation less likely 110 or would decrease the number of fragments the messages are divided 111 into, increasing the protocol reliability and productivity. 113 The other field where using compression may be useful is the Internet 114 of Things (IoT) devices utilizing a lower power consumption 115 technology. For many such devices the power consumption for 116 transmitting extra bits over network is much higher than the power 117 consumption for spending extra CPU cycles to compress data before 118 transmission. The appendix A of [IPSEC-IOT-REQS] gives some estimate 119 data. Since many such devices are battery powered without ability to 120 recharge or to replace the battery which serves for the lifecycle of 121 the device (a few years), the task of reducing the power consumption 122 for such devices is very important. 124 This document specifies how lossless compression is used in IKEv2. 125 In order to enable compression in the IKE_SA_INIT exchange a new 126 payload is introduced that contains other payloads in compressed 127 form. The processing of the Encrypted payload is modified to 128 accommodate compression in subsequent exchanges. The document also 129 specifies how the use of compression is negotiated between the peers 130 maintaining backward compatibility. 132 2. Terminology and Notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 3. Protocol Description 142 Compression is accommodated differently in the initial IKEv2 exchange 143 and in subsequent exchanges. The difference comes out from the fact, 144 that the messages of all the IKEv2 exchanges except for the initial 145 exchange contain the Encrypted payload. In this case the compression 146 is added as an additional step while constructing the Encrypted 147 payload. The initial IKEv2 exchange requires introduction a new 148 payload, which would contain other payloads in compressed form. 150 3.1. Using Compression in the IKE_SA_INIT Exchange 152 The use of compression is not negotiated in a usual for IKEv2 manner 153 - by exchanging appropriate Notification or Vendor ID payloads. 154 Instead a different negotiation mechanism is used. 156 If an Initiator wants to use compression for the IKE SA being 157 created, it constructs the IKE_SA_INIT request message in a following 158 way. A new payload which is called Compressed payload and described 159 in the Section 4.1 is included into the request message. This 160 payload contains other payloads in compressed form as well as an 161 indication of what compression algorithm is used. When selecting 162 compression algorithm the Initiator must guess what algorithms are 163 supported by the peer and choose an appropriate one. If the guess is 164 wrong the Responder informs about this fact and the mutually 165 appropriate algorithm is then negotiated by the cost of an extra 166 round trip and a message recompression. The Critical bit in the 167 Compressed payload header MUST be set to 1. 169 Initiator 170 --------- 171 HDR, C!{SA, KE, [N+,] [V+]}, Ni, [N+,] [V+] --> 173 Not all payloads that are usually present in the IKE_SA_INIT messages 174 are subject for compression. Some payloads contain random or pseudo- 175 random data that is almost uncompressible. Other payloads must be 176 processed as early as possible, before the responder spends resources 177 decompressing them. In particular, the Nonce payload the Puzzle 178 Solution payload and the COOKIE notification payload MUST NOT be 179 included into the Compressed payload. Obviously, if the compression 180 algorithm ID is from private range (241-255), then the corresponding 181 Vendor ID payload MUST NOT be included into the Compressed payload 182 either. See Section 5 for more details about interaction compression 183 with other IKEv2 extensions. 185 If the Responder doesn't support IKEv2 compression, then it is 186 expected to return the UNSUPPORTED_CRITICAL_PAYLOAD notification in 187 response to such request message, as prescribed in the Section 2.5 of 188 [RFC7296]. Depending on the implementation it may also return the 189 INVALID_SYNTAX notification or doesn't respond at all. 191 Legacy Responder 192 ---------------- 193 <-- HDR, N(UNSUPPORTED_CRITICAL_PAYLOAD) 195 or 197 <-- HDR, N(INVALID_SYNTAX) 199 or 201 (No response) 203 If the Initiator receives the UNSUPPORTED_CRITICAL_PAYLOAD 204 notification with the Compressed payload type in its notification 205 data or if it receives the INVALID_SYNTAX notification or if it 206 receives no response after several retransmissions then the Initiator 207 MUST restart the IKE_SA_INIT exchange with no compression. 209 If the Responder supports IKEv2 compression, but doesn't support the 210 particular compression algorithm the Initiator has chosen, then the 211 Responder sends back a new error notification: 212 INVALID_COMPRESSION_ALGORITHM. This notification is described in the 213 Section 4.2. Its notification data contains the list of IDs of 214 compression algorithms supported by the Responder. 216 Responder 217 --------- 218 <-- HDR, N(INVALID_COMPRESSION_ALGORITHM) 220 If the Initiator receives the INVALID_COMPRESSION_ALGORITHM 221 notification, then it looks through the list of algorithms included 222 into the notification data and selects an appropriate one. After 223 that it MUST restart the IKE_SA_INIT exchange using the newly 224 selected algorithm for compression. If no mutually appropriate 225 algorithm found, then the Initiator MUST restart the IKE_SA_INIT 226 exchange with no compression. 228 Once the Responder receives the IKE_SA_INIT request with appropriate 229 compression algorithm in the Compressed payload, the included 230 payloads are decompressed and along with the outer payloads form the 231 uncompressed request message, which is then processed as usual. If 232 the Responder agrees to use compression in the SA being created then 233 the Responder MUST include the Compressed payload in the response 234 message. The compression algorithm indicated in the Compressed 235 payload MUST be the algorithm from the request. 237 Responder 238 --------- 239 <-- HDR, C!{SA, KE, [N+,] [V+]}, Nr, [N+,] [V+] 241 If for some reason the Responder doesn't want to use compression in 242 the SA being created (e.g. using compression is disabled by 243 administrator) then it MUST send back an uncompressed IKE_SA_INIT 244 response message. In this case the endpoints MUST NOT use 245 compression in subsequent exchanges. 247 3.2. Using Compression in Subsequent Exchanges 249 Once the endpoints have used compression in the IKE_SA_INIT exchange, 250 they may continue to use it in subsequent exchanges. However 251 compression is used differently in these exchanges. Messages of 252 every IKEv2 exchange except for the initial exchange are protected by 253 the Encrypted payload. With compression the rules for forming and 254 processing of the Encrypted payload are modified as follows. 256 The content of the Encrypted payload is compressed before it is 257 encrypted and authenticated. According to the IKEv2 specification 258 the Next Payload field in an Encrypted payload indicates the payload 259 type of the first payload inside the Encrypted payload. If case of 260 using compression, the Next Payload field in the Encrypted payload 261 MUST be set to XXX (TBA by IANA) - the value for the payload type of 262 a Compressed payload. However, the Compressed payload itself MUST 263 NOT appear inside the Encrypted payload, only its payload type is 264 used to indicate that the content of the Encrypted payload was 265 compressed before encryption. 267 Since in this case the Next Payload field in the Encrypted payload no 268 longer indicates a type of the first inner payload, this information 269 is moved to the Next Payload field of the last inner payload (which 270 is set zero in the IKEv2 specification). This modification is done 271 before the payloads are compressed. 273 Uncompressed: SK(Next=P1) {P1(Next=P2), P2(Next=P3), ... Pn(Next=0)} 274 Compressed: SK(Next=C) {P1(Next=P2), P2(Next=P3), ... Pn(Next=P1)} 276 Preparing payloads for compression 278 This modification doesn't cause ambiguity on the receiver, since the 279 total size of the inner payloads can be easily determined after 280 decryption, and while walking through the list of them the receiver 281 always knows whether the current payload is the last or not. 283 After the use of compression is negotiated in the initial exchange 284 each endpoint is free to decide whether to apply compression or not 285 on per-message basis. However, if applying compression to the 286 content of the Encrypted payload doesn't reduce its size then the 287 compression MUST NOT be used for this message. Implementations MUST 288 be prepared to receive both compressed and uncompressed messages. 290 4. Payload Formats 292 4.1. Compressed Payload 294 The Compressed payload, denoted C!{...} in this document (the 295 exclamation mark means that this payload is critical), contains other 296 payloads in compressed form. The payload type for the Compressed 297 payload is XXX (TBA by IANA). 299 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Next Payload |C| RESERVED | Payload Length | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | First Payload | Algorithm | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 306 ~ Compressed Payloads ~ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Compressed Payload 311 o Next Payload (1 octet) - Identifier for the payload type of the 312 next payload in the message. 314 o Critical (1 bit) - MUST be set to 1. 316 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 317 receipt (as specified in [RFC7296]). 319 o Payload Length (2 octets, unsigned integer) - Length in octets of 320 the current payload, including the generic payload header. 322 o First Payload (1 octet) - Identifier for the payload type of the 323 first payload contained in Compressed Payloads field. 325 o Algorithm (1 octet) - ID of the algorithm used to compress inner 326 payloads. The possible values for compression algorithm ID are 327 listed in "IKEv2 Notification IPCOMP Transform IDs" registry in 328 [IKEV2-IANA]. 330 o Compressed Payloads (variable length) - This field contains IKEv2 331 payloads in compressed form. The Next Payload field of the last 332 included payload MUST be set to 0. 334 There MUST NOT be more than one Compressed payloads in a message. 335 The Compressed payload MUST NOT appear inside the Encrypted payload 336 and the Encrypted payload MUST NOT appear inside the Compressed 337 payload. 339 4.2. INVALID_COMPRESSION_ALGORITHM Notification 341 The INVALID_COMPRESSION_ALGORITHM notification is sent by Responder 342 if the compression algorithm chosen by Initiator is inappropriate. 343 The Notification Data contains the list of supported compression 344 algorithm IDs. 346 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Next Payload |C| RESERVED | Payload Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 ~ Supported Compression Algorithms ~ 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 INVALID_COMPRESSION_ALGORITHM Notification 358 o Protocol ID (1 octet) - MUST be 0. 360 o SPI Size (1 octet) - MUST be 0, meaning no SPI is present. 362 o Notify Message Type (2 octets) - MUST be XXX (TBA by IANA), the 363 value assigned for the INVALID_COMPRESSION_ALGORITHM notification. 365 o Supported Compression Algorithms (variable length) - List of 366 compression algorithm IDs supported by the Responder. Each 367 algorithm ID occupies one octet. The possible values for 368 compression algorithm IDs are listed in "IKEv2 Notification IPCOMP 369 Transform IDs" registry in [IKEV2-IANA]. 371 5. Interaction with other IKEv2 Extensions 373 IKEv2 Compression is compatible with most of the IKEv2 extensions, 374 since It neither affects their operation, nor is affected by them. 375 However, some IKEv2 extensions require special handling. 377 5.1. Interaction with IKEv2 Fragmentation 379 When compression is used with IKEv2 Fragmentation [RFC7383] the 380 compression MUST take place before splitting the original content of 381 the Encrypted payload into chunks. In other words, the content of 382 the Encrypted payload must be compressed as a whole, before it is 383 fragmented. 385 The Compressed payload MUST NOT appear inside the Encrypted Fragment 386 payload and the Encrypted Fragment payload MUST NOT appear inside the 387 Compressed payload. 389 5.2. Interaction with IKEv2 Resumption 391 The IKEv2 Session Resumption [RFC5723] defines a mechanism for 392 restoring an IKE SA state after a failure. The newly defined 393 IKE_SESSION_RESUME exchange in conjunction with the usual IKE_AUTH 394 exchange is used to create a new IKE SA that is based on the 395 information contained in the resumption ticket. 397 Implementations supporting compression MUST store the flag whether 398 the compression was negotiated and the negotiated compression 399 algorithm in the resumption ticket and MUST restore these values from 400 the ticket while resuming IKE SA. It means that the use of 401 compression must not be re-negotiated in the IKE_SESSION_RESUME 402 exchange and thus the Compressed payload MUST NOT appear in this 403 exchange. 405 5.3. Interaction with IKEv2 Redirect 407 The IKEv2 Redirect mechanism defined in [RFC5685] allows the 408 responder to redirect the initiator to a different host. The 409 redirect can take place either in the IKE_SA_INIT exchange or later, 410 when IKE SA is already created. 412 All notifications concerning IKEv2 Redirect that may appear in the 413 IKE_SA_INIT exchange, MUST be placed outside the Compressed payload. 414 This would allow the responder to make a decision whether to redirect 415 the initiator without spending additional resources on decompression. 417 5.4. Interaction with IKEv2 Puzzles 419 IKEv2 puzzles defined in [RFC8019] allow the Responder to mitigate 420 DoS attacks by requiring the Initiator to spend additional resources 421 for creating IKE SA. 423 When IKEv2 Compression is used with IKEv2 puzzles, the Puzzle 424 Solution payload MUST NOT be placed inside the Compressed payload. 426 The Responder MUST NOT use compression until the Initiator solves the 427 puzzle. 429 6. Security Considerations 431 It was shown in [COMP-LEAK] that using compression inside an 432 encrypted channel may result in a leakage of some information about a 433 plaintext. Recently some practical exploits were discovered that 434 rely on using compression in security protocols ([CRIME], [BREACH]). 435 However, it is believed that the way a compression is added to the 436 IKEv2 would not weaken the protocol security. The existing exploits 437 rely on ability for an attacker to insert data into an encrypted 438 stream, i.e. to perform a chosen-plaintext attack. IKEv2 messages 439 don't contain application data, which restricts attacker's ability to 440 perform chosen-plaintext attack. Moreover, the data usually 441 exchanged over the IKE SA contain no secret information and in most 442 cases no sensitive information. The possible exceptions could be 443 some weak Extensible Authentication Protocol (EAP) methods, which 444 might transfer secret information within an IKE SA. It is 445 RECOMMENDED that implementations don't use the IKEv2 Compression for 446 the messages containing the EAP payload if there is a possibility 447 that the EAP method transfers secret information. 449 7. IANA Considerations 451 This document defines new Payload in the "IKEv2 Payload Types" 452 registry: 454 Compressed C 456 This document also defines new Notify Message Type in the "Notify 457 Message Types - Error Types" registry: 459 INVALID_COMPRESSION_ALGORITHM 461 8. References 463 8.1. Normative References 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, 467 DOI 10.17487/RFC2119, March 1997, . 470 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 471 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 472 May 2017, . 474 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 475 the Internet Key Exchange Protocol Version 2 (IKEv2)", 476 RFC 5685, DOI 10.17487/RFC5685, November 2009, 477 . 479 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 480 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 481 DOI 10.17487/RFC5723, January 2010, . 484 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 485 Kivinen, "Internet Key Exchange Protocol Version 2 486 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 487 2014, . 489 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 490 (IKEv2) Message Fragmentation", RFC 7383, 491 DOI 10.17487/RFC7383, November 2014, . 494 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 495 Protocol Version 2 (IKEv2) Implementations from 496 Distributed Denial-of-Service Attacks", RFC 8019, 497 DOI 10.17487/RFC8019, November 2016, . 500 [IKEV2-IANA] 501 "Internet Key Exchange Version 2 (IKEv2) Parameters", 502 . 504 8.2. Informative References 506 [IPSEC-IOT-REQS] 507 Migault, D. and T. Guggemos, "Requirements for Diet-ESP 508 the IPsec/ESP protocol for IoT", draft-mglt-6lo-diet-esp- 509 requirements-01 (work in progress), February 2015. 511 [COMP-LEAK] 512 Kelsey, J., "Compression and Information Leakage of 513 Plaintext", . 516 [CRIME] Rizzo, J. and T. Duong, "The CRIME attack", 517 . 520 [BREACH] Prado, A., Harris, N., and Y. Gluck, "SSL, gone in 30 521 seconds: A BREACH beyond CRIME", 522 . 525 Author's Address 527 Valery Smyslov 528 ELVIS-PLUS 529 PO Box 81 530 Moscow (Zelenograd) 124460 531 RU 533 Phone: +7 495 276 0211 534 Email: svan@elvis.ru