IPlir network layer security protocol
draft-iplir-protocol-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Davletshina Alexandra , Urivskiy Alexey , Rybkin Andrey , Tychina Leonid , Parshin Ilia | ||
| Last updated | 2022-06-16 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-iplir-protocol-01
Network Working Group A. Davletshina, Ed.
Internet-Draft A. Urivskiy
Intended status: Informational A. Rybkin
Expires: 18 December 2022 L. Tychina
I. Parshin
InfoTeCS
16 June 2022
IPlir network layer security protocol
draft-iplir-protocol-01
Abstract
This document specifies the IPlir network layer security protocol.
It describes how to provide a set of security services for traffic
over public and corporate networks using the TCP/IP stack.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 18 December 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Davletshina, et al. Expires 18 December 2022 [Page 1]
Internet-Draft Abbreviated Title June 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Definitions and Notations . . . . . . . . . . . . . . . . . . 4
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6
4. System overview . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. IPlir packet contents . . . . . . . . . . . . . . . . . . 12
4.2. IPlir message content . . . . . . . . . . . . . . . . . . 12
4.3. Tuples (type, length, value) . . . . . . . . . . . . . . 15
4.3.1. Pair of IPv4 addresses . . . . . . . . . . . . . . . 15
4.3.2. Pair of IPv6 addresses . . . . . . . . . . . . . . . 16
4.4. IPlir packet structure and IPlir header location . . . . 17
4.4.1. Transport mode . . . . . . . . . . . . . . . . . . . 18
4.4.2. Light tunnel . . . . . . . . . . . . . . . . . . . . 19
4.4.3. Tunnel mode . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.1. Encryption and MAC . . . . . . . . . . . . . . . . . . . 21
5.2. Cryptographic keys . . . . . . . . . . . . . . . . . . . 22
5.3. Cryptographic suites . . . . . . . . . . . . . . . . . . 23
5.3.1. MAGMA-MGM cryptographic suite: CS = 1 . . . . . . . . 25
5.3.1.1. Exchange keys . . . . . . . . . . . . . . . . . . 25
5.3.1.2. Requirements for initializing values . . . . . . 25
5.3.1.3. Key derivation algorithms . . . . . . . . . . . . 26
5.3.1.4. Encryption and MAC algorithms . . . . . . . . . . 27
5.3.2. KUZN-CTR-CMAC cryptographic suite: CS=2 . . . . . . . 31
5.3.2.1. Exchange keys . . . . . . . . . . . . . . . . . . 32
5.3.2.2. Requirements for initializing values . . . . . . 32
5.3.2.3. Key derivation algorithms . . . . . . . . . . . . 33
5.3.2.4. Encryption and MAC algorithms . . . . . . . . . . 34
5.3.3. AES-128-GCM cryptographic suite: CS = 129 . . . . . . 38
5.3.3.1. Exchange keys . . . . . . . . . . . . . . . . . . 39
5.3.3.2. Requirements for initializing values . . . . . . 39
5.3.3.3. Key derivation algorithms . . . . . . . . . . . . 40
5.3.3.4. Encryption and MAC algorithms . . . . . . . . . . 41
5.3.4. AES-256-CTR-CMAC cryptographic suite: CS = 132 . . . 45
5.3.4.1. Exchange keys . . . . . . . . . . . . . . . . . . 46
5.3.4.2. Requirements for initializing values . . . . . . 46
5.3.4.3. Key derivation algorithms . . . . . . . . . . . . 47
5.3.4.4. Encryption and MAC algorithms . . . . . . . . . . 48
5.3.5. AES-256-CFB-CMAC cryptographic suite: CS = 134 . . . 52
5.3.5.1. Exchange keys . . . . . . . . . . . . . . . . . . 53
5.3.5.2. Requirements for initializing values . . . . . . 53
5.3.5.3. Key derivation algorithms . . . . . . . . . . . . 53
5.3.5.4. Encryption and MAC algorithms . . . . . . . . . . 55
Davletshina, et al. Expires 18 December 2022 [Page 2]
Internet-Draft Abbreviated Title June 2022
6. IPlir packet processing . . . . . . . . . . . . . . . . . . . 58
6.1. IP and IPlir packet fragmentation . . . . . . . . . . . . 59
6.2. Source IP packet protection by the sender host . . . . . 59
6.3. IPlir packet processing on the forward host . . . . . . . 60
6.4. Source IP packet recovery by the recipient host . . . . . 61
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.1. Normative References . . . . . . . . . . . . . . . . . . 62
8.2. Informative References . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction
1.1. Scope
The IPlir protocol may be used to protect IP packets during their
transmission via communication channels. IP packet protection means
ensuring integrity and authenticity of the data source of the packets
with an option of also ensuring their confidentiality. For this
purpose, when IPlir is applied, encapsulation of source IP packets,
calculation of message authentication codes for the encapsulated
packets and service information along with optional packet encryption
are used. In addition, the IPlir protocol allows for protection
against replay attacks based on the use of counter values and/or
timestamps.
The IPlir protocol can be used to create Virtual Private Networks at
the 3rd (network) layer of the basic ISO OSI reference model. Data
is protected during transfer of IP packets between any two hosts
supporting the IPlir protocol, including options of data exchange
between two end hosts, an end host and a security gateway, and two
security gateways. All protection mechanisms are implemented without
establishing a connection (in terms of network) between the two
interacting hosts.
This document is not a Security Architecture for the Internet; it
addresses security only at the network layer, provided through the
use of a combination of cryptographic and protocol security
mechanisms.
This document does not have IETF consensus and does not imply IETF
support for IPlir.
Davletshina, et al. Expires 18 December 2022 [Page 3]
Internet-Draft Abbreviated Title June 2022
1.2. Audience
The target audience for this document is primarily individuals who
implement this network layer security technology or who architect
systems that will use this technology. Technically adept users of
this technology (end users or system administrators) also are part of
the target audience.
This document assumes that the reader is familiar with the Internet
Protocol (IP), related networking technology, and general information
system security terms and concepts.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Definitions and Notations
3.1. Definitions
This document uses the following terms and definitions:
AEAD: Authenticated Encryption with Associated Data,
cryptographic suite: a set of cryptographic algorithms and
parameters used in the IPlir,
CTR mode: a block cipher mode of operation when a cipher key
stream is applied to plaintext data under a specific law,
derived key: a key derived from the shared secret (original key)
and random and/or fixed mutually known data,
end-to-end MAC: MAC implemented between the source and destination
hosts,
exchange key: a key known only to the specified pair of hosts used
to derive keys,
host (network host): a network device with a unique ID and IPlir
support,
Davletshina, et al. Expires 18 December 2022 [Page 4]
Internet-Draft Abbreviated Title June 2022
initializing value: a value transmitted over the communication
channel and used in defining the starting point of a symmetric
cryptographic technique,
IP packet (network packet): a logically indivisible data block at
the network layer of the basic ISO OSI reference model relating to
the IP,
IPlir message: the data contained in the IPlir packet body,
IPlir operation mode: one of the three IPlir operating modes:
transport, light tunnel, and tunnel,
IPlir packet: an IP packet protected by IPlir,
IPlir packets reception policy: a set of rules for processing
incoming IPlir packets,
key: a sequence of symbols that controls the operation of a
cryptographic transformation,
key system: a set of keys, their deployment and management
subsystems,
MAC (message authentication code): a fixed-length string of bits
(tag) computed by applying a symmetric cryptographic technique to
the message and appended to that message in order to provide its
integrity and authenticity of the data source,
network host context: the information necessary to process/create
IPlir packets from/to the network host logically related to the
given one,
security policy: a set of rules for IP traffic processing by the
network host,
sender host: the host creating an IPlir packet from a source IP
packet,
source IP packet: an IP packet before it was protected by the
IPlir,
symmetric cryptographic technique: a cryptographic technique that
uses the same key for both the originator's and recipient's
transformation,
recipient host: the host recovering the source IP packet from an
IPlir packet,
Davletshina, et al. Expires 18 December 2022 [Page 5]
Internet-Draft Abbreviated Title June 2022
routing of IPlir packets: a function of forwarding IPlir packets
by a network host during reception of IPlir packets addressed to
this network host from the IP perspective, but for which it is not
the recipient host,
transit MAC: MAC implemented between two neighbor hosts in a
packet transfer chain,
transit host: the host implementing the function of routing IPlir
packets.
3.2. Notations
The following notations are used in this document:
+============================+====================================+
+============================+====================================+
| V^{*} | a set of all finite length binary |
| | strings, including an empty string |
+----------------------------+------------------------------------+
| |x| | the length (number of components) |
| | of the string x \in V^{*} |
+----------------------------+------------------------------------+
| V_s | a set of all binary strings with a |
| | length of s, where s is a non- |
| | negative integer; numbering of |
| | substrings and components is |
| | right-to-left, starting with zero |
+----------------------------+------------------------------------+
| x||y | concatenation of binary strings x |
| | and y from V^{*}, i.e., a string |
| | from V_{|x|+|y|}, wherein the left |
| | substring from V_{|x|} is the same |
| | as string x, and the right |
| | substring from V_{|y|} is the same |
| | as string y |
+----------------------------+------------------------------------+
| 0^r | a binary string consisting of r |
| | zeros |
+----------------------------+------------------------------------+
| LSB_s(x) | truncation of binary string x with |
| | a length of m, m >= s, to a binary |
| | string with a length of s |
| | according to the following rule: |
| | LSB_s(x_{m-1} || ... || x_1 || |
| | x_0) = x_{s-1} || ... || x_1 || |
| | x_0, xi \in V_1, i = 0,1,...,m-1 |
+----------------------------+------------------------------------+
Davletshina, et al. Expires 18 December 2022 [Page 6]
Internet-Draft Abbreviated Title June 2022
| IntToVec_s(x) | representation of the ring element |
| | x \in Z_{2^s} as a binary string |
| | with a length of s: for x = x_0 + |
| | 2 * x_1 + ... + 2^{s-1} * x_{s-1}, |
| | where x_i \in V_1, i = |
| | 0,1,...,s-1, the following |
| | equation is true IntToVec_s(x) = |
| | x_{s-1} || ... || x_1 || x_0 |
+----------------------------+------------------------------------+
| CharToByte(c) | representation of the c symbol as |
| | a binary string of length 8 |
| | calculated according to the |
| | following rule: CharToByte(c) = |
| | 0 || IntToVec_7(ASCII(c)), where |
| | ASCII(c) \in Z_{2^7} is the ASCII |
| | representation of the c symbol |
+----------------------------+------------------------------------+
| StrToVec_s(string) | representation of the string of |
| | symbols string = |
| | 'c_{m-1}c_{m-2}...c_0' consisting |
| | of m symbols as a binary string |
| | with a length of s, s >= 8*m |
| | according to the following rule: |
| | StrToVec_s('c_{m-1}c_{m-2}...c_0') |
| | = 0^{s-8*m} || |
| | CharToByte(c_{m-1}) || |
| | CharToByte(c_{m-2}) || ... || |
| | CharToByte(c_0) |
+----------------------------+------------------------------------+
| K_ENC | packet encryption key. The length |
| | of the value is determined by the |
| | used cryptographic suite |
+----------------------------+------------------------------------+
| K_MAC | packet end-to-end MAC key. The |
| | length of the value is determined |
| | by the used cryptographic suite |
+----------------------------+------------------------------------+
| K_AEAD | packet encryption and end-to-end |
| | MAC key. The length of the value |
| | is determined by the used |
| | cryptographic suite |
+----------------------------+------------------------------------+
| K_TMAC | packet transit MAC key. The |
| | length of the value is determined |
| | by the used cryptographic suite |
+----------------------------+------------------------------------+
| Version | IPlir header version. This |
| | document describes the IPlir |
Davletshina, et al. Expires 18 December 2022 [Page 7]
Internet-Draft Abbreviated Title June 2022
| | header of Version = 1. The field |
| | length is 8 bit |
+----------------------------+------------------------------------+
| CS | cryptographic suite identifier |
| | determining the contents of |
| | cryptographic mechanisms and their |
| | parameters used to create the |
| | IPlir packet. The field length is |
| | 8 bit |
+----------------------------+------------------------------------+
| T | the transit MAC field flag. If T |
| | = 1, the IPlir trailer contains |
| | fields TransitIdentifier, |
| | TransitIntegrityCheckValue and |
| | TransitInitValue, otherwise the |
| | fields are absent. When |
| | calculating and checking the end- |
| | to-end MAC (ICV) insert the T |
| | field has to be set to 0. The |
| | field length is 1 bit |
+----------------------------+------------------------------------+
| D | the DestinationIdentifier field |
| | flag. If D = 1, the header |
| | contains the DestinationIdentifier |
| | field, otherwise the field is |
| | absent. The destination host |
| | identifier is required for routing |
| | of IPlir packets. The field |
| | length is 1 bit |
+----------------------------+------------------------------------+
| ExtID | the flag of extended network host |
| | identifiers. If ExtID = 0, all |
| | the network host identifiers (the |
| | SourceIdentifier field and, if |
| | available, DestinationIdentifier |
| | and TransitIdentifier fields) are |
| | 32 bits long. If ExtID = 1, all |
| | the network host identifiers are |
| | 64 bits long. The field length is |
| | 1 bit |
+----------------------------+------------------------------------+
| ExtSN | the packet extended sequence |
| | number flag. If ExtSN=0, the |
| | packet SequenceNumber field is 32 |
| | bits long. If ExtSN = 1, the |
| | SequenceNumber field is 64 bits |
| | long. The field length is 1 bit |
+----------------------------+------------------------------------+
Davletshina, et al. Expires 18 December 2022 [Page 8]
Internet-Draft Abbreviated Title June 2022
| DAR | the flag of disabling the anti- |
| | replay mechanism. The use of the |
| | flag is regulated by security |
| | policies. The field length is 1 |
| | bit |
+----------------------------+------------------------------------+
| R1 | the field reserved for future use. |
| | When IPlir header is generated, |
| | the field must contain all zeros. |
| | The receiving end must not analyze |
| | the field content. The field |
| | length is 3 bits |
+----------------------------+------------------------------------+
| KN | the number of the exchange key |
| | used to encrypt and calculate the |
| | end-to-end MAC, but not the |
| | transit MAC. The field length is |
| | 4 bits |
+----------------------------+------------------------------------+
| TKN | the number of the exchange key |
| | used to calculate the transit MAC. |
| | If the transit MAC is not used, |
| | i.e., T = 0, the field value |
| | should be 0. When calculating and |
| | checking the end-to-end MAC (ICV), |
| | the TKN field must be filled with |
| | zeros. The field length is 4 bits |
+----------------------------+------------------------------------+
| Timestamp | packet send time. The field |
| | contains the send time value based |
| | on the astronomical clock of the |
| | sender host in the POSIX time |
| | format less 0x40000000 seconds. |
| | The estimated overflow time is the |
| | year 2140. The field length is 32 |
| | bits |
+----------------------------+------------------------------------+
| SourceIdentifier | the source host identifier used by |
| | the destination host to identify |
| | the IPlir packet sender and the |
| | related context of the sender host |
| | for packet processing. The field |
| | length is 32 bits with ExtID = 0, |
| | or 64 bits with ExtID = 1 |
+----------------------------+------------------------------------+
| DestinationIdentifier | the destination host identifier |
| | required for routing of IPlir |
| | packets. The field is available, |
Davletshina, et al. Expires 18 December 2022 [Page 9]
Internet-Draft Abbreviated Title June 2022
| | if D = 0. The field length is 32 |
| | bits with ExtID = 0, or 64 bits |
| | with ExtID = 1 |
+----------------------------+------------------------------------+
| SequenceNumber | the packet sequence number; an |
| | unsigned integer. The field |
| | length is 32 bits with ExtSN = 0, |
| | or 64 bits with ExtSN = 1 |
+----------------------------+------------------------------------+
| InitValue (IV) | an end-to-end initializing value |
| | that can be used to execute |
| | encryption operations and |
| | calculate an end-to-end MAC, as |
| | well as to derive keys for these |
| | operations. The field length is |
| | determined by the used |
| | cryptographic suite |
+----------------------------+------------------------------------+
| Type, Length, Value | (type, length, value) tuples |
| | enabling transmission of |
| | additional information within the |
| | IPlir packet. Type is the type of |
| | the value in the Value field. The |
| | field length is 8 bit. Length is |
| | the byte length of the Value |
| | field. The field length is 8 bit. |
| | Value is random data of the Type |
| | type |
+----------------------------+------------------------------------+
| PayloadData | a variable-length field containing |
| | the source IP packet or its part, |
| | depending on the IPlir operation |
| | mode |
+----------------------------+------------------------------------+
| Staffing | a (network) filler to make the |
| | length of the IPlir suitable for |
| | more efficient providing of the |
| | IPlir message processing. The |
| | Staffing field contains a sequence |
| | of integers in a binary form: the |
| | first byte contains digit 1, the |
| | second one contains 2, etc. The |
| | value length is determined by the |
| | SL field value, if SL is absent (S |
| | = 0) or has the value 0, there is |
| | no Staffing field |
+----------------------------+------------------------------------+
| SL | the number of bytes in the |
Davletshina, et al. Expires 18 December 2022 [Page 10]
Internet-Draft Abbreviated Title June 2022
| | Staffing field. The field is |
| | available, if S = 1. The field |
| | length is 8 bit |
+----------------------------+------------------------------------+
| Mode | the mode in which the IPlir packet |
| | was generated in. The field |
| | length is 2 bits |
+----------------------------+------------------------------------+
| TLV | Type, Length and Value field flag. |
| | If TLV = 1, the IPlir body begins |
| | with tuples (Type, Length, Value), |
| | otherwise there are no tuples. |
| | The field length is 1 bit |
+----------------------------+------------------------------------+
| S | the SL field flag. If S = 1, the |
| | IPlir body contains the SL field, |
| | otherwise this field is absent. |
| | The field length is 1 bit |
+----------------------------+------------------------------------+
| R2 | the field reserved for future use. |
| | When an IPlir message is |
| | generated, the field must contain |
| | all zeros. The receiving end must |
| | not analyze the field content. |
| | The field length is 4 bits |
+----------------------------+------------------------------------+
| NextHeader | the source IP packet protocol |
| | number. The field length is 8 bit |
+----------------------------+------------------------------------+
| IntegrityCheckValue (ICV) | an end-to-end MAC calculated for |
| | the data from the IPlir message |
| | start and to the NextHeader field |
| | inclusive. The field length is |
| | determined by the used |
| | cryptographic suite |
+----------------------------+------------------------------------+
| TransitIdentifier | the identifier of the transit host |
| | that routed the IPlir packet last. |
| | Each transit host updates the |
| | field value with its identifier. |
| | The field is available, if T = 1. |
| | The field length is 32 bits with |
| | ExtID = 0, or 64 bits with ExtID = |
| | 1 |
+----------------------------+------------------------------------+
| TransitInitValue (TIV) | the transit initializing value |
| | used to calculate a transit MAC |
| | and derive keys for packet transit |
Davletshina, et al. Expires 18 December 2022 [Page 11]
Internet-Draft Abbreviated Title June 2022
| | MAC. The field is available, if T |
| | = 1. The field length is |
| | determined by the used |
| | cryptographic suite |
+----------------------------+------------------------------------+
| TransitIntegrityCheckValue | a transit MAC calculated for the |
| (TICV) | data from the IPlir message start |
| | and to the TransitInitValue field |
| | inclusive. The field is |
| | available, if T = 1. The field |
| | length is determined by the used |
| | cryptographic suite |
+----------------------------+------------------------------------+
Table 1
4. System overview
4.1. IPlir packet contents
The IPlir packet structure is shown in Figure 1.
+------------+------------+--------------------+
| IP header | UDP header | IPlir message |
+------------+------------+--------------------+
Figure 1: IPlir packet structure
The IP header is the header of a standard IP packet.
The UDP header is a standard UDP header only existing when additional
encapsulation of the IPlir message in a UDP message is used. The
IPlir protocol uses UDP destination port number 55777 as a default
port.
The IPlir message is the main part of the IPlir packet that includes
protected data from the source IP packet and plaintext data required
for IPlir packet processing.
4.2. IPlir message content
The IPlir message contains:
* IPlir header containing plaintext information related to
encapsulation and protection of the source IP packet;
* IPlir body containing information the encryption of which is
optional;
Davletshina, et al. Expires 18 December 2022 [Page 12]
Internet-Draft Abbreviated Title June 2022
* IPlir trailer containing MACs, the transit host identifier, and
the transit initializing value.
The IPlir message structure is shown in Figure 2.
Davletshina, et al. Expires 18 December 2022 [Page 13]
Internet-Draft Abbreviated Title June 2022
+---+---------------+---------------+---------------+---------------+
| | 0 | 1 | 2 | 3 |
+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Bit|7|6|5|4|3|2|1|0|7|6|5|4|3|2|1|0|7|6|5|4|3|2|1|0|7|6|5|4|3|2|1|0|
+---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |E|E| | | | |
| I | | | | |x|x|D| | | |
| P | Version | CS |T|D|t|t|A| R1 | KN | TKN |
| l | | | | |I|S|R| | | |
| i | | | | |D|N| | | | |
| r +---------------+---------------+-+-+-+-+-+-----+-------+-------+
| | Timestamp |
| +---------------------------------------------------------------+
| h | SourceIdentifier |
| e +---------------------------------------------------------------+
| a | DestinationIdentifier |
| d +---------------------------------------------------------------+
| e | SequenceNumber |
| r +---------------------------------------------------------------+
| | InitValue |
+---+---------------+---------------+-------------------------------+
| | Type_1 | Length_1 | Value_1 (Length_1 byte) |
| +---------------+---------------+-------------------------------+
| I | ... |
| P +---------------+---------------+-------------------------------+
| l | Type_n | Length_n | Value_n (Length_n byte) |
| i +---------------+---------------+-------------------------------+
| r | PayloadData |
| +---------------------------------------------------------------+
| b | Staffing |
| o | +---------------+---+-+-+-------+---------------+
| d | | | M |T| | | |
| y | | SL | o |L|S| R2 | NextHeader |
| | | | d |V| | | |
| | | | e | | | | |
+---+---------------+---------------+---+-+-+-------+---------------+
| t| IntegrityCheckValue (ICV) |
|I r+---------------------------------------------------------------+
|P a| TransitIdentifier |
|l i+---------------------------------------------------------------+
|i l| TransitInitValue |
|r e+---------------------------------------------------------------+
| r| TransitIntegrityCheckValue (TICV) |
+---+---------------------------------------------------------------+
Figure 2: IPlir message structure
Davletshina, et al. Expires 18 December 2022 [Page 14]
Internet-Draft Abbreviated Title June 2022
The IPlir message fields have a big-endian order of bytes. The
numbering is left-to-right, the lead bytes have lower numbers.
Numbering of bits inside bytes is right-to-left, the high bits have
higher numbers.
4.3. Tuples (type, length, value)
Tuples (Type, Length, Value) enable transmission of additional
information within the IPlir message. The TLV field value indicates
whether there are tuples. If its value is 1, there is one or more
tuples in the beginning of the IPlir body.
The Value field of any tuple should be divisible by 8 bits. The
Length field indicates the Value field length in bytes.
Permissible Type field values for the tuples are provided in Table 1.
+============+==========================================+
| Type value | Description |
+============+==========================================+
| 0 | the last tuple in the IPlir message; can |
| | be used by the vendor for its own needs |
+------------+------------------------------------------+
| 1 | a pair of IPv4 addresses |
+------------+------------------------------------------+
| 2 | a pair of IPv6 addresses |
+------------+------------------------------------------+
| 3-128 | not in use |
+------------+------------------------------------------+
| 129-254 | can be used by the vendor for its own |
| | needs |
+------------+------------------------------------------+
| 255 | not in use |
+------------+------------------------------------------+
Table 2: Type Field Values for Tuples
The last tuple in the message is always type 0. The length of this
tuple should be chosen so as to ensure effective IPlir message
processing.
4.3.1. Pair of IPv4 addresses
The Value field of the tuple of this type contains a pair of IPv4
addresses. The sender's address comes first, followed by the
recipient's address. The addresses are transmitted in the network
byte order.
Davletshina, et al. Expires 18 December 2022 [Page 15]
Internet-Draft Abbreviated Title June 2022
The main function of the tuple of this type is to preserve the IPv4
addresses from the source IP packet in the "Light tunnel" mode.
The tuple structure is shown in Figure 3.
+------+--------------+--------------+--------------+--------------+
|Bytes | 0 | 1 | 2 | 3 |
+------+--------------+--------------+--------------+--------------+
| | | |Sender IPv4 | |
| | Type = 1 | Length = 8 |address, byte | ... |
| | | |No.1 (MSB) | |
| +--------------+--------------+--------------+--------------+
| TLV | |Sender IPv4 |Recipient IPv4| |
| | ... |address, byte |address, byte | ... |
| area | |No.4 (LSB) |No.1 (MSB) | |
| +--------------+--------------+--------------+--------------+
| | |Recipient IPv4| | |
| | ... |address, byte | Not in use | Not in use |
| | |No.4 (LSB) | | |
+------+--------------+--------------+--------------+--------------+
Figure 3: Type = 1 Tuple Structure
Note: Bytes labeled "not in use" contain information related to the
following tuple.
4.3.2. Pair of IPv6 addresses
The Value field of the tuple of this type contains a pair of IPv6
addresses. The sender's address comes first, followed by the
recipient's address. The addresses are transmitted in the network
byte order.
The main function of the tuple of this type is to preserve the IPv6
addresses from the source IP packet in the "Light tunnel" mode.
The tuple structure is shown in Figure 4.
Davletshina, et al. Expires 18 December 2022 [Page 16]
Internet-Draft Abbreviated Title June 2022
+------+--------------+--------------+--------------+--------------+
|Bytes | 0 | 1 | 2 | 3 |
+------+--------------+--------------+--------------+--------------+
| | | |Sender IPv6 | |
| | Type = 2 | Length = 32 |address, byte | ... |
| | | |No.1 (MSB) | |
| +--------------+--------------+--------------+--------------+
| | ... |
| +--------------+--------------+--------------+--------------+
| TLV | |Sender IPv6 |Recipient IPv6| |
| | ... |address, byte |address, byte | ... |
| area | |No.16 (LSB) |No.1 (MSB) | |
| +--------------+--------------+--------------+--------------+
| | ... |
| +--------------+--------------+--------------+--------------+
| | |Recipient IPv6| | |
| | ... |address, byte | Not in use | Not in use |
| | |No.16 (LSB) | | |
+------+--------------+--------------+--------------+--------------+
Figure 4: Type = 2 Tuple Structure
Note: Bytes labeled "not in use" contain information related to the
following tuple.
4.4. IPlir packet structure and IPlir header location
The IPlir protocol can operate in three modes: transport, tunnel, and
light tunnel. The transport and light tunnel modes ensure protection
of the data generated by protocols above the IP level in the basic
ISO OSI reference model, in particular, by the transport layer. The
tunnel mode ensures protection of the entire source IP packet.
The receiving end determines what mode the packet was sent in based
on the Mode field value. Possible field values are shown in Table 2.
Davletshina, et al. Expires 18 December 2022 [Page 17]
Internet-Draft Abbreviated Title June 2022
+==================+====================================+
| Mode field value | Mode description |
+==================+====================================+
| 0 | transport mode |
+------------------+------------------------------------+
| 1 | light tunnel mode ("light tunnel") |
+------------------+------------------------------------+
| 2 | tunnel mode ("tunnel" mode) |
+------------------+------------------------------------+
| 3 | reserved for future needs |
+------------------+------------------------------------+
Table 3: Table 2 - Mode Field Values
4.4.1. Transport mode
In the transport mode, the IPlir header and (Type, Length, Value)-
tupples follow the IP header and precede the header of the next layer
(e.g., TCP, UDP, ICMP, etc.). In the IPv4 context, it means that the
IPlir header is located after the IP header, including all options in
the source IP packet, but before the header of the next level
protocol.
Figure 5 shows an example of IP packet protection using the IPlir in
the transport mode.
+-------------------------+ +--------------------------+
| Source IP packet | | IPlir packet |
| +-------------------+ | | +--------------------+ |
| | IP header |---------->| IP header | |
| +-------------------+ | | +--------------------+ |
| | IP packet data |-----+ | | IPlir header | |
| +-------------------+ | | | +--------------------+ |
+-------------------------+ | | | IPlir body | |
| | | +----------------+ | |
+------>| IP packet data | | |
| | +----------------+ | |
| +--------------------+ |
| | IPlir trailer | |
| +--------------------+ |
+--------------------------+
Figure 5: IP Packet Protection Using IPlir in the Transport Mode
In the IPv6 context, the IPlir header is addressed to the destination
endpoint. Therefore, it should be placed after the Hop-by-hop,
Routing, and Fragmentation extension headers. The Destination
Options extension headers can be located before, after, or on both
Davletshina, et al. Expires 18 December 2022 [Page 18]
Internet-Draft Abbreviated Title June 2022
sides of the IPlir header, depending on the required semantics.
However, since the IPlir protocol can ensure privacy of only the
fields following the IPlir header, the recipient options should
follow the IPlir header.
4.4.2. Light tunnel
Location of the IPlir header and (Type, Length, Value)-tuples in the
light tunnel mode is the same as in the transport mode, except that
the set of tuples in the IPlir body must include type 1 tuple (two
IPv4 addresses) or type 2 tuple (two IPv6 addresses), wherein the
sender and recipient's addresses from the IP header of the source IP
packet. The tuple type is dictated by the version of the IP header
of the source IP packet.
The recipient host can restore the initial IP addresses from the
available tuple Value field.
Unlike the transport mode, the light tunnel mode makes it possible to
change addresses in the IPlir packet IP header.
Figure 6 shows an example of IP packet protection using the IPlir in
the light tunnel mode.
Davletshina, et al. Expires 18 December 2022 [Page 19]
Internet-Draft Abbreviated Title June 2022
+--------------------------+ +------------------------------+
| Source IP packet | | IPlir packet |
| +--------------------+ | | +------------------------+ |
| | IP header | | | | IP header | |
| | +----------------+ | | | | +--------------------+ | |
| | | Source IP | | | | | | Source IP | | |
| | +----------------+ |---------->| +--------------------+-------+
| | | Destination IP | | | | | | Destination IP | | | |
| | +----------------+ | | | | +--------------------+ | | |
| +--------------------+ | | +------------------------+ | |
| | IP packet data |-----+ | | IPlir header | | |
| +--------------------+ | | | +------------------------+ | |
+--------------------------+ | | | IPlir body | | |
| | | +--------------------+ | | |
| | | | TLV | | | |
| | | | +----------------+ | | | |
| | | | | Source IP | | | | |
| | | | +----------------+<--------+
| | | | | Destination IP | | | |
| | | | +----------------+ | | |
| | | +--------------------+ | |
+------>| IP packet data | | |
| | +--------------------+ | |
| +------------------------+ |
| | IPlir trailer | |
| +------------------------+ |
+------------------------------+
Figure 6: IP Packet Protection Using IPlir in the Light Tunnel Mode
4.4.3. Tunnel mode
Unlike the other modes, the tunnel mode protects the entire source IP
packet, including its IP header.
In the tunnel mode, a new IP header is generated with its contents
based on the destination host context and the source host IP routing
table, followed by the IPlir header and tuples (Type, Length, Value).
This is followed by the source IP packet.
Versions of the source and new IP headers can be different. It means
that IPv6 packets can be transmitted via the IPv4 protocol and vice
versa.
Figure 7 shows an example of IP packet protection using the IPlir in
the tunnel mode.
Davletshina, et al. Expires 18 December 2022 [Page 20]
Internet-Draft Abbreviated Title June 2022
+-------------------------+ +--------------------------+
| Source IP packet | | IPlir packet |
| +-------------------+ | | +--------------------+ |
| | IP header |-------+ | | IP header | |
| +-------------------+ | | | +--------------------+ |
| | IP packet data |----+ | | | IPlir header | |
| +-------------------+ | | | | +--------------------+ |
+-------------------------+ | | | | IPlir body | |
| | | | +----------------+ | |
| +----->| IP header | | |
| | | +----------------+ | |
+-------->| IP packet data | | |
| | +----------------+ | |
| +--------------------+ |
| | IPlir trailer | |
| +--------------------+ |
+--------------------------+
Figure 7: IP Packet Protection Using IPlir in the Tunnel Mode
5. Security Considerations
Possible values of function arguments in the algorithms above are
limited by whether they can be used as conversion input parameters.
5.1. Encryption and MAC
To ensure packet confidentiality, the IPlir protocol provides for a
possibility to encrypt it using a symmetric cryptographic technique.
Packet encryption in IPlir is recommended, but not required.
Encryption can be disabled by selecting a separate cryptographic
suite clearly indicating that there is no encryption. In case of
encryption, it is applied between the sender and recipient hosts
regardless of the transfer network topology and existence of
intermediate hosts.
To ensure packet integrity and authenticity of the data source, the
IPlir protocol allows for MAC. Packet MAC can be end-to-end and
transit. End-to-end MAC is applied between the sender and recipient
hosts, and is mandatory. Transit MAC is applied between two neighbor
hosts in a packet transfer chain, and is optional.
To ensure both confidentiality, and integrity and authenticity of the
data source of the packet at the same time, either separate
encryption and MAC algorithms may be used, or AEAD algorithms to
encrypt and calculate MAC simultaneously.
Davletshina, et al. Expires 18 December 2022 [Page 21]
Internet-Draft Abbreviated Title June 2022
5.2. Cryptographic keys
It is implied that there is a key system that provides the
interacting hosts with necessary exchange keys and controls their
synchronization. Keys can be managed manually or automatically.
The exchange keys required to process a specific packet with all
their mandatory attributes (meta data) are available when packet
processing starts.
Correct functioning of the IPlir protocol requires a host numbering
system where each host is assigned a unique identifier. Each
exchange key related to the specific pair of hosts is indexed with
the corresponding pair of their identifiers. Key systems where
several exchange keys (not more than 16) exist simultaneously for the
two hosts can be used. To make it possible, each exchange key in the
IPlir protocol is additionally indexed with an integer value between
0 and 15 (inclusive) located in the KN or TKN field of the IPlir
message and allowing to unambiguously determine the exchange key for
the two hosts.
The peculiarity of IPlir is that unique packet encryption, end-to-end
MAC and transit MAC keys used in the corresponding cryptographic
algorithms are derived for each IP packet based on the exchange keys.
The packet encryption, end-to-end MAC, and transit MAC keys derived
for the same IP packet should be different, except when AEAD
algorithms are used, where one packet encryption and end-to-end MAC
key is used for encryption and end-to-end MAC of the packet.
The exchange key used to derive packet encryption and end-to-end MAC
keys (or packet encryption and end-to-end MAC key) is determined by
the KN field value of the IPlir message and identifiers of the sender
and recipient hosts. The exchange key used to derive the packet
transit MAC key is determined by the TKN field value of the IPlir
message and identifiers of the interacting (transit) hosts.
Exchange key types and methods to derive packet protection keys from
them are determined by the cryptographic suite.
For any unique key used in the IPlir protocol at any time it should
be impossible to calculate it from the other keys, except for
calculation of derived keys for packet protection from a specific
exchange key.
The maximum quantity of material that can be processed using the same
key should be determined considering theoretical limits arising from
the use of particular cryptographic algorithms and practical
limitations arising during IPlir implementation.
Davletshina, et al. Expires 18 December 2022 [Page 22]
Internet-Draft Abbreviated Title June 2022
The maximum number of keys (packet encryption, end-to-end MAC,
transit MAC keys or packet encryption and end-to-end MAC keys)
derived from one exchange key should be determined considering
theoretical limits arising from the use of particular cryptographic
algorithms and practical limitations arising during IPlir
implementation.
When the allowed limit for a specific key is reached, the interacting
parties should stop using it. For protection of further
interactions, the parties should use a key for which the allowed
limit has not been achieved, e.g., a new key.
5.3. Cryptographic suites
The cryptographic algorithms and parameters used in the IPlir
protocol make up a cryptographic suite designated by its CS number in
the CS field of each IPlir message. There can be up to 256 different
cryptographic suites in total.
Permissible CS field values are provided in Table 3:
+==========+=============================================+
| CS value | Description |
+==========+=============================================+
| 0 | not in use |
+----------+---------------------------------------------+
| 1 | MAGMA-MGM cryptographic suite |
+----------+---------------------------------------------+
| 2 | KUZN-CTR-CMAC cryptographic suite |
+----------+---------------------------------------------+
| 3-128 | not in use |
+----------+---------------------------------------------+
| 129 | AES-128-GCM cryptographic suite |
+----------+---------------------------------------------+
| 130-131 | can be used by the vendor for its own needs |
+----------+---------------------------------------------+
| 132 | AES-256-CTR-CMAC cryptographic suite |
+----------+---------------------------------------------+
| 133 | can be used by the vendor for its own needs |
+----------+---------------------------------------------+
| 134 | AES-256-CFB-CMAC cryptographic suite |
+----------+---------------------------------------------+
| 135-254 | can be used by the vendor for its own needs |
+----------+---------------------------------------------+
| 255 | Not in use |
+----------+---------------------------------------------+
Table 4: Permissible CS Field Values
Davletshina, et al. Expires 18 December 2022 [Page 23]
Internet-Draft Abbreviated Title June 2022
The list of main mechanisms and parameters defined and/or described
in the cryptographic suite is shown in Table 4:
+===========+===============+====================================+
| Parameter | Description | Purpose |
+===========+===============+====================================+
| EncAlg | encryption | the algorithm is used to encrypt |
| | algorithm | the packet |
+-----------+---------------+------------------------------------+
| MACAlg | end-to-end | the algorithm is used to calculate |
| | MAC algorithm | packet end-to-end MAC |
+-----------+---------------+------------------------------------+
| TMACAlg | transit MAC | the algorithm is used to calculate |
| | algorithm | packet transit MAC |
+-----------+---------------+------------------------------------+
| MACLen | end-to-end | |
| | MAC length | |
+-----------+---------------+------------------------------------+
| TMACLen | transit MAC | |
| | length | |
+-----------+---------------+------------------------------------+
| IVLen | end-to-end | the initializing value can be used |
| | initializing | for packet encryption, end-to-end |
| | value length | MAC, and derivation of packet |
| | | encryption keys and packet end-to- |
| | | end MAC keys (or packet encryption |
| | | and end-to-end MAC keys) |
+-----------+---------------+------------------------------------+
| TIVLen | transit | the initializing value can be used |
| | initializing | for packet transit MAC and |
| | value length | derivation of packet transit MAC |
| | | keys |
+-----------+---------------+------------------------------------+
| KDAlg | algorithms of | the algorithms are used to derive |
| | deriving | packet encryption keys and packet |
| | packet | end-to-end MAC keys (or packet |
| | protection | encryption and end-to-end MAC |
| | keys from | keys), and to derive packet |
| | exchange keys | transit MAC keys |
+-----------+---------------+------------------------------------+
Table 5: Main Mechanisms And Parameters In The Cryptographic Suite
All necessary parameters should be included in the cryptographic
suite description. Interpretation of values of specific
cryptographic suite parameters is determined by the cryptographic
suite. If any parameter in the cryptographic suite is inapplicable
or must be ignored, it should be specified clearly.
Davletshina, et al. Expires 18 December 2022 [Page 24]
Internet-Draft Abbreviated Title June 2022
5.3.1. MAGMA-MGM cryptographic suite: CS = 1
MAGMA-MGM Cryptographic Suite Description:
+===========+=====================================+
| Parameter | Value |
+===========+=====================================+
| EncAlg | GOST R 34.12-2015 (Magma) [RFC8891] |
| | in the MGM mode [RFC9058] |
+-----------+-------------------------------------+
| MACAlg | GOST R 34.12-2015 (Magma) [RFC8891] |
| | in the MGM mode [RFC9058] |
+-----------+-------------------------------------+
| TMACAlg | GOST R 34.12-2015 (Magma) [RFC8891] |
| | in the MGM mode [RFC9058] |
+-----------+-------------------------------------+
| MACLen | 32 bits |
+-----------+-------------------------------------+
| TMACLen | 32 bits |
+-----------+-------------------------------------+
| IVLen | 64 bits |
+-----------+-------------------------------------+
| TIVLen | 64 bits |
+-----------+-------------------------------------+
| KDAlg | see the description below |
+-----------+-------------------------------------+
Table 6
5.3.1.1. Exchange keys
For each pair of interacting hosts, there is a single exchange key
with a length of 256 bits used for deriving of packet encryption and
end-to-end MAC keys, as well as packet transit MAC keys.
There may be several exchange keys for a pair of interacting hosts.
The KN field value of the IPlir message (for derivation of packet
encryption and end-to-end MAC keys) or the TKN field value of the
IPlir message (for derivation of packet transit MAC keys) is used to
determine a specific single exchange key.
5.3.1.2. Requirements for initializing values
The end-to-end initializing value InitValue in the InitValue field of
the IPlir message should have a length of 64 bits and be unique for
each IPlir packet the encryption and end-to-end MAC of which are
implemented by the same sender host using the same single exchange
key.
Davletshina, et al. Expires 18 December 2022 [Page 25]
Internet-Draft Abbreviated Title June 2022
The transit initializing value TransitInitValue in the
TransitInitValue field of the IPlir message should have a length of
64 bits and be unique for each IPlir packet the transit MAC of which
is implemented by the same (transit) host using the same single
exchange key.
5.3.1.3. Key derivation algorithms
The packet encryption and end-to-end MAC key K_AEAD of-256 bit length
is calculated as follows:
K_AEAD = K_1 || K_2 || K_3 || K_4,
where each value of K_i \in V_64, i = 1,2,3,4 is calculated as per
GOST R 34.12-2015 (Magma) [RFC8891] in the CMAC mode, as per GOST R
34.13-2015 [GOST3413-2015], wherein
* the single exchange key corresponding to the specified sender and
recipient hosts, and the KN field value of the IPlir message is
used as the key,
* a binary string as shown below is used as the data:
IntToVec_8(i)||Label||aL||IV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('AEAD'),
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- IV_KDF = InitValue, where InitValue is initialized by the
InitValue field value of the IPlir message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
- Node = SourceIdentifier, where SourceIdentifier is initialized
by the SourceIdentifier field value of the IPlir message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the InitValue, SequenceNumber and
SourceIdentifier fields of the IPlir message,
- oL = IntToVec_16(OutputBitLength), where OutputBitLength = 256,
* the MAC length s is 64 bits.
The packet transit MAC key K_TMAC of 256-bit length is calculated as
follows:
Davletshina, et al. Expires 18 December 2022 [Page 26]
Internet-Draft Abbreviated Title June 2022
K_TMAC = K_1 || K_2 || K_3 || K_4,
where each value of K_i \in V_64, i = 1,2,3,4 is calculated as per
GOST 34.12-2018 GOST R 34.12-2015 (Magma) [RFC8891] in the CMAC mode,
as per GOST R 34.13-2015 [GOST3413-2015], wherein
* the single exchange key corresponding to the specified (transit)
hosts the IPlir packet passes through and the TKN field value of
the IPlir message is used as the key,
* a binary string as shown below is used as the data:
IntToVec_8(i)||Label||aL||TIV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('TMAC'),
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- TIV_KDF = TransitInitValue, where TransitInitValue is
initialized by the TransitInitValue field value of the IPlir
message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
- Node = TransitIdentifier, where TransitIdentifier is
initialized by the TransitIdentifier field value of the IPlir
message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the TransitInitValue, SequenceNumber
and TransitIdentifier fields of the IPlir message,
- oL = IntToVec_16(OutputBitLength), where OutputBitLength = 256,
* the MAC length s is 64 bits.
5.3.1.4. Encryption and MAC algorithms
Encryption of the IPlir body and calculation of the end-to-end MAC
ICV in the IntegrityCheckValue field of the IPlir message are
implemented according to the GOST R 34.12-2015 (Magma) [RFC8891] in
the MGM mode [RFC9058], wherein
* the packet encryption and end-to-end MAC key K_AEAD is used as the
key,
Davletshina, et al. Expires 18 December 2022 [Page 27]
Internet-Draft Abbreviated Title June 2022
* data in the IPlir header fields in the order of their appearance
in the IPlir message are used as associated authenticated data
protected by MAC,
* data in the IPlir body fields in the order of their appearance in
the IPlir message are used as plaintext,
* the value of IV_AEAD \in V_63 is used as a unique vector:
- IV_AEAD = LSB_63(InitValue),
- where InitValue is initialized by the InitValue field value of
the IPlir message,
* the MAC length s is 32 bits.
The diagram of encryption and end-to-end MAC is shown in Figure 8.
+-----------------------------------+
| IPlir header |
| ... |
| +---------------------------+ |
+--------| SourceIdentifier | |
| | +---------------------------+ |
| | ... |--------+
| | +---------------------------+ | |
+--------| SequenceNumber | | |
| | +---------------------------+ | |
+--------| InitValue |---------+ |
| | +---------------------------+ | | |
| +-----------------------------------+ | |
| | IPlir body |--+ | |
| +-----------------------------------+ | | |
| | IPlir trailer | | | |
| | ... | | | |
| +-----------------------------------+ | | |
| | | |
v v v v
+---------------------------------+ +-------------------+
| KDF based on GOST R 34.12-2015 | +------+ | GOST R 34.12-2015 |
| (Magma) [RFC8891] in the CMAC |->|K_AEAD|->| (Magma) [RFC8891] |
| mode according to | +------+ | in the MGM mode |
|GOST R 34.13-2015 [GOST3413-2015]| | [RFC9058] |
+---------------------------------+ +-------------------+
^ | |
| | |
+-----------------------+ | |
| Exchange keys between | | |
Davletshina, et al. Expires 18 December 2022 [Page 28]
Internet-Draft Abbreviated Title June 2022
| source and destination| | |
| hosts | | |
+-----------------------+ | |
| |
+-----------------------------------+ | |
| IPlir header | | |
| ... | | |
| +---------------------------+ | | |
| | SourceIdentifier | | | |
| +---------------------------+ | | |
| ... | | |
| +---------------------------+ | | |
| | SequenceNumber | | | |
| +---------------------------+ | | |
| | InitValue | | | |
| +---------------------------+ | | |
+-----------------------------------+ | |
| Encrypted IPlir body |<--+ |
+-----------------------------------+ |
| IPlir trailer | |
| +---------------------------+ | |
| | InterityCheckValue |<-----------+
| +---------------------------+ |
| ... |
+-----------------------------------+
Figure 8: Diagram of Encryption and End-to-End MAC Using the
MAGMA-MGM Cryptographic Suite
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue
field of the IPlir message is implemented according to the GOST R
34.12-2015 (Magma) [RFC8891] in the MGM mode [RFC9058], wherein
* the packet transit MAC key K_TMAC is used as the key,
* data in the IPlir header fields, the encrypted IPlir body and
IntegrityCheckValue, TransitIdentifier, TransitInitValue fields
data in the order of their appearance in the IPlir message are
used as associated authenticated data protected by MAC,
* plaintext is an empty string,
* the value of TIV_AEAD \in V_63 is used as a unique vector:
- TIV_AEAD = LSB_63(TransitInitValue),
- where TransitInitValue is initialized by the TransitInitValue
field value of the IPlir message,
Davletshina, et al. Expires 18 December 2022 [Page 29]
Internet-Draft Abbreviated Title June 2022
* the MAC length s is 32 bits.
The diagram of transit MAC is shown in Figure 9. The "null" value
means an empty binary string.
+-----------------------------------+--+
| IPlir header | |
| ... | |
| +---------------------------+ | |
+--------| SequenceNumber | | |
| | +---------------------------+ | |
| | ... | |
| +-----------------------------------+ |
| | Encrypted IPlir body | |-------+
| +-----------------------------------+ | |
| | IPlir trailer | | |
| | ... | | |
| | +---------------------------+ | | |
+--------| TransitIdentifier | | | |
| | +---------------------------+ | | |
+--------| | | | |
| | | TransitInitValue | | | |
| | +-| | | | |
| | | +---------------------------+---|--+ |
| | | ... | |
| +-|---------------------------------+ |
| | |
| +--------------------------------------+ |
| +------+ | |
| | null |----+ | |
| +------+ | | |
v v v v
+---------------------------------+ +-------------------+
| KDF based on GOST R 34.12-2015 | +------+ | GOST R 34.12-2015 |
| (Magma) [RFC8891] in the CMAC |->|K_TMAC|->| (Magma) [RFC8891] |
| mode according to | +------+ | in the MGM mode |
|GOST R 34.13-2015 [GOST3413-2015]| | [RFC9058] |
+---------------------------------+ +-------------------+
^ | |
| v |
+-----------------------+ +------+ |
| Exchange keys between | | null | |
| transit hosts | +------+ |
+-----------------------+ |
|
+-----------------------------------+ |
| IPlir header | |
| ... | |
Davletshina, et al. Expires 18 December 2022 [Page 30]
Internet-Draft Abbreviated Title June 2022
| +---------------------------+ | |
| | SequenceNumber | | |
| +---------------------------+ | |
| ... | |
+-----------------------------------+ |
| Encrypted IPlir body | |
+-----------------------------------+ |
| IPlir trailer | |
| ... | |
| +---------------------------+ | |
| | TransitIdentifier | | |
| +---------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +---------------------------+ | |
| | TransitInterityCheckValue |<-----------+
| +---------------------------+ |
+-----------------------------------+
Figure 9: Diagram of Transit MAC Using the MAGMA-MGM
Cryptographic Suite
5.3.2. KUZN-CTR-CMAC cryptographic suite: CS=2
AES-256-CTR-CMAC Cryptographic Suite Description:
Davletshina, et al. Expires 18 December 2022 [Page 31]
Internet-Draft Abbreviated Title June 2022
+===========+==========================================+
| Parameter | Value |
+===========+==========================================+
| EncAlg | GOST R 34.12-2015 (Kuznyechik) [RFC7801] |
| | in the CTR mode [GOST3413-2015] |
+-----------+------------------------------------------+
| MACAlg | GOST R 34.12-2015 (Kuznyechik) [RFC7801] |
| | in the CMAC mode [GOST3413-2015] |
+-----------+------------------------------------------+
| TMACAlg | GOST R 34.12-2015 (Kuznyechik) [RFC7801] |
| | in the CMAC mode [GOST3413-2015] |
+-----------+------------------------------------------+
| MACLen | 64 bits |
+-----------+------------------------------------------+
| TMACLen | 64 bits |
+-----------+------------------------------------------+
| IVLen | 64 bits |
+-----------+------------------------------------------+
| TIVLen | 64 bits |
+-----------+------------------------------------------+
| KDAlg | see the description below |
+-----------+------------------------------------------+
Table 7
5.3.2.1. Exchange keys
For each pair of interacting hosts, there is a single exchange key
with a length of 256 bits designed for derivation of packet
encryption keys, end-to-end MAC keys, and transit MAC keys.
There may be several exchange keys for a pair of interacting hosts.
The KN field value of the IPlir message (for derivation of packet
encryption keys and packet end-to-end MAC keys) or the TKN field
value of the IPlir message (for derivation of packet transit MAC
keys) is used to determine a specific single exchange key.
5.3.2.2. Requirements for initializing values
The end-to-end initializing value InitValue in the InitValue field of
the IPlir message should have a length of 64 bits and be unique for
each IPlir packet the encryption and end-to-end MAC of which are
implemented by the same sender host using the same single exchange
key.
Davletshina, et al. Expires 18 December 2022 [Page 32]
Internet-Draft Abbreviated Title June 2022
The transit initializing value TransitInitValue in the
TransitInitValue field of the IPlir message should have a length of
64 bits and be unique for each IPlir packet the transit MAC of which
is implemented by the same (transit) host using the same single
exchange key.
5.3.2.3. Key derivation algorithms
The packet encryption key K_ENC of 256-bit length and the packet end-
to-end MAC key K_MAC of 256-bit length are calculated as follows:
K_ENC = K_1 || K_2,
K_MAC = K_3 || K_4,
where each value of K_i \in V_128, i = 1,2,3,4 is calculated as per
GOST R 34.12-2015 (Kuznyechik) [RFC7801] in the CMAC mode
[GOST3413-2015], wherein
* the single exchange key corresponding to the specified sender and
recipient hosts, and the KN field value of the IPlir message is
used as the key,
* a binary string as shown below is used as the data:
IntToVec_8(i)||Label||aL||IV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('ENCMAC'),
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- IV_KDF = InitValue, where InitValue is initialized by the
InitValue field value of the IPlir message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
- Node = SourceIdentifier, where SourceIdentifier is initialized
by the SourceIdentifier field value of the IPlir message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the InitValue, SequenceNumber and
SourceIdentifier fields of the IPlir message,
- oL = IntToVec_16(OutputBitLength), where OutputBitLength = 512,
* the MAC length s is 128 bits.
Davletshina, et al. Expires 18 December 2022 [Page 33]
Internet-Draft Abbreviated Title June 2022
The packet transit MAC key K_TMAC of 256-bit length is calculated as
follows:
K_TMAC = K_1 || K_2,
where each value of K_i \in V_128, i = 1,2 is calculated as per GOST
R 34.12-2015 (Kuznyechik) [RFC7801] in the CMAC mode [GOST3413-2015],
wherein
* the single exchange key corresponding to the specified (transit)
hosts the IPlir packet passes through and the TKN field value of
the IPlir message is used as the key,
* a binary string as shown below is used as the data:
IntToVec_8(i)||Label||aL||TIV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('TMAC'),
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- TIV_KDF = TransitInitValue, where TransitInitValue is
initialized by the TransitInitValue field value of the IPlir
message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
- Node = TransitIdentifier, where TransitIdentifier is
initialized by the TransitIdentifier field value of the IPlir
message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the TransitInitValue, SequenceNumber
and TransitIdentifier fields of the IPlir message,
- oL = IntToVec_16(OutputBitLength), where OutputBitLength = 256,
* the MAC length s is 128 bits.
5.3.2.4. Encryption and MAC algorithms
The IPlir body is encrypted according to the GOST R 34.12-2015
(Kuznyechik) [RFC7801] in the CTR mode [GOST3413-2015], wherein
* the packet encryption key K_ENC is used as the key,
* data in the IPlir body fields in the order of their appearance in
the IPlir message are used as plaintext,
Davletshina, et al. Expires 18 December 2022 [Page 34]
Internet-Draft Abbreviated Title June 2022
* the value of IV_ENC \in V_64 is used as the initializing value:
- IV_ENC = InitValue,
- where InitValue is initialized by the InitValue field value of
the IPlir message,
* the s key stream block length is 128 bits.
Calculation of the end-to-end MAC ICV in the IntegrityCheckValue
field of the IPlir message is implemented according to the GOST R
34.12-2015 (Kuznyechik) [RFC7801] in the CMAC mode [GOST3413-2015],
wherein
* the packet end-to-end MAC key K_MAC is used as the key,
* data in the IPlir body fields in the order of their appearance in
the IPlir message are used as plaintext,
* the MAC length s is 64 bits.
The diagram of encryption and end-to-end MAC is shown in Figure 10.
+-----------------------------------+
| IPlir header |
| ... |
| +---------------------------+ |
+--------| SourceIdentifier | |
| | +---------------------------+ |
| | ... |
| | +---------------------------+ |
+--------| SequenceNumber | |
| | +---------------------------+ |
+--------| InitValue |----------+
| | +---------------------------+ | |
| +-----------------------------------+ |
| | IPlir body |--+ |
| +-----------------------------------+ | |
| | IPlir trailer | | |
| | ... | | |
| +-----------------------------------+ | |
| | |
v v v
+---------------------------------+ +------+ +-------------------+
| KDF based on GOST R 34.12-2015 |->|K_ENC |->| GOST R 34.12-2015 |
| (Kuznyechik) [RFC7801] in the | +------+ | (Kuznyechik) |
| CMAC mode according to | | [RFC7801] in the |
|GOST R 34.13-2015 [GOST3413-2015]| +------+ | CTR mode |
Davletshina, et al. Expires 18 December 2022 [Page 35]
Internet-Draft Abbreviated Title June 2022
| |->|K_MAC | | [GOST3413-2015] |
+---------------------------------+ +------+ +-------------------+
^ | |
| v |
+-----------------------+ +-------------------+ |
| Exchange keys between | | GOST R 34.12-2015 | |
| source and destination| +---| (Kuznyechik) | |
| hosts | | | [RFC7801] in the | |
+-----------------------+ | | CMAC mode | |
| | [GOST3413-2015] | |
| +-------------------+ |
+-----------------------+ ^ |
| | |
| +---------------------------------+ |
| | |
| | +---+-----------------------------------+ |
| | | | IPlir header | |
| | | | ... | |
| | | | +---------------------------+ | |
| | | | | SourceIdentifier | | |
| | | | +---------------------------+ | |
| | | | ... | |
| +---| | +---------------------------+ | |
| | | | SequenceNumber | | |
| | | +---------------------------+ | |
| | | | InitValue | | |
| | | +---------------------------+ | |
| | +-----------------------------------+ |
| | | Encrypted IPlir body |<---+
| +---+-----------------------------------+
| | IPlir trailer |
| | +---------------------------+ |
+-------------->| InterityCheckValue | |
| +---------------------------+ |
| ... |
+-----------------------------------+
Figure 10: Diagram of Encryption and End-to-End MAC Using the
KUZN-CTR-CMAC Cryptographic Suite
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue
field of the IPlir message is implemented according to the GOST R
34.12-2015 (Kuznyechik) [RFC7801] in the CMAC mode [GOST3413-2015],
wherein
* the packet transit MAC key K_TMAC is used as the key,
Davletshina, et al. Expires 18 December 2022 [Page 36]
Internet-Draft Abbreviated Title June 2022
* data in the IPlir header fields, the encrypted IPlir body and
IntegrityCheckValue, TransitIdentifier, TransitInitValue fields
data in the order of their appearance in the IPlir message are
used as associated authenticated data protected by MAC,
* the MAC length s is 64 bits.
The diagram of transit MAC is shown in Figure 11.
+-----------------------------------+--+
| IPlir header | |
| ... | |
| +---------------------------+ | |
+--------| SequenceNumber | | |
| | +---------------------------+ | |
| | ... | |
| +-----------------------------------+ |
| | Encrypted IPlir body | |---+
| +-----------------------------------+ | |
| | IPlir trailer | | |
| | ... | | |
| | +---------------------------+ | | |
+--------| TransitIdentifier | | | |
| | +---------------------------+ | | |
+--------| | | | |
| | | TransitInitValue | | | |
| | | | | | |
| | +---------------------------+---|--+ |
| | ... | |
| +-----------------------------------+ |
| |
v v
+---------------------------------+ +-------------------+
| KDF based on GOST R 34.12-2015 | +------+ | GOST R 34.12-2015 |
| (Kuznyechik) [RFC7801] in the |->|K_TMAC|->| (Kuznyechik) |
| CMAC mode according to | +------+ | [RFC7801] in the |
|GOST R 34.13-2015 [GOST3413-2015]| | CMAC mode |
+---------------------------------+ | [GOST3413-2015] +
^ +-------------------+
| |
| |
+-----------------------+ |
| Exchange keys between | |
| transit hosts | |
+-----------------------+ |
|
+-----------------------------------+ |
| IPlir header | |
Davletshina, et al. Expires 18 December 2022 [Page 37]
Internet-Draft Abbreviated Title June 2022
| ... | |
| +---------------------------+ | |
| | SequenceNumber | | |
| +---------------------------+ | |
| ... | |
+-----------------------------------+ |
| Encrypted IPlir body | |
+-----------------------------------+ |
| IPlir trailer | |
| ... | |
| +---------------------------+ | |
| | TransitIdentifier | | |
| +---------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +---------------------------+ | |
| | TransitInterityCheckValue |<-------+
| +---------------------------+ |
+-----------------------------------+
Figure 11: Diagram of Transit MAC Using the KUZN-CTR-CMAC
Cryptographic Suite
5.3.3. AES-128-GCM cryptographic suite: CS = 129
AES-128-GCM Cryptographic Suite Description:
Davletshina, et al. Expires 18 December 2022 [Page 38]
Internet-Draft Abbreviated Title June 2022
+===========+================================+
| Parameter | Value |
+===========+================================+
| EncAlg | AES-128 [NIST.FIPS.197] in the |
| | GCM mode [NIST.SP.800-38d] |
+-----------+--------------------------------+
| MACAlg | AES-128 [NIST.FIPS.197] in the |
| | GCM mode [NIST.SP.800-38d] |
+-----------+--------------------------------+
| TMACAlg | AES-128 [NIST.FIPS.197] in the |
| | GCM mode [NIST.SP.800-38d] |
+-----------+--------------------------------+
| MACLen | 64 bits |
+-----------+--------------------------------+
| TMACLen | 64 bits |
+-----------+--------------------------------+
| IVLen | 96 bits |
+-----------+--------------------------------+
| TIVLen | 96 bits |
+-----------+--------------------------------+
| KDAlg | see the description below |
+-----------+--------------------------------+
Table 8
5.3.3.1. Exchange keys
For each pair of interacting hosts, there is a single exchange key
with a length of 128 bits used for deriving of packet encryption and
end-to-end MAC keys, as well as packet transit MAC keys.
There may be several exchange keys for a pair of interacting hosts.
The KN field value of the IPlir message (for derivation of packet
encryption and end-to-end MAC keys) or the TKN field value of the
IPlir message (for derivation of packet transit MAC keys) is used to
determine a specific single exchange key.
5.3.3.2. Requirements for initializing values
The end-to-end initializing value InitValue in the InitValue field of
the IPlir message should have a length of 96 bits and be unique for
each IPlir packet the encryption and end-to-end MAC of which are
implemented by the same sender host using the same single exchange
key.
Davletshina, et al. Expires 18 December 2022 [Page 39]
Internet-Draft Abbreviated Title June 2022
The transit initializing value TransitInitValue in the
TransitInitValue field of the IPlir message should have a length of
96 bits and be unique for each IPlir packet the transit MAC of which
is implemented by the same (transit) host using the same single
exchange key.
5.3.3.3. Key derivation algorithms
The packet encryption and end-to-end MAC key K_AEAD of-256 bit length
is calculated as follows:
K_AEAD = K_1,
where value of K_1 \in V_128 is calculated as per KDF in Counter Mode
[NIST.SP.800-108] using AES-128 [NIST.FIPS.197] in the CMAC mode
[NIST.SP.800-38b] as the PRF, wherein
* the single exchange key corresponding to the specified sender and
recipient hosts, and the KN field value of the IPlir message is
used as the key for the PRF,
* a binary string as shown below is used as the input data for the
PRF: IntToVec_8(i)||Label||aL||IV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('AEAD'),
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- IV_KDF = InitValue, where InitValue is initialized by the
InitValue field value of the IPlir message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
- Node = SourceIdentifier, where SourceIdentifier is initialized
by the SourceIdentifier field value of the IPlir message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the InitValue, SequenceNumber and
SourceIdentifier fields of the IPlir message,
- oL = IntToVec_8(OutputBitLength), where OutputBitLength = 128,
* the PRF output length is 128 bits.
The packet transit MAC key K_TMAC of 128-bit length is calculated as
follows:
Davletshina, et al. Expires 18 December 2022 [Page 40]
Internet-Draft Abbreviated Title June 2022
K_TMAC = K_1,
where value of K_1 \in V_128 is calculated as per KDF in Counter Mode
[NIST.SP.800-108] using AES-128 [NIST.FIPS.197] in the CMAC mode
[NIST.SP.800-38b] as the PRF, wherein
* the single exchange key corresponding to the specified (transit)
hosts the IPlir packet passes through and the TKN field value of
the IPlir message is used as the key for the PRF,
* a binary string as shown below is used as the input data for the
PRF: IntToVec_8(i)||Label||aL||TIV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('TMAC'),
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- TIV_KDF = TransitInitValue, where TransitInitValue is
initialized by the TransitInitValue field value of the IPlir
message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
- Node = TransitIdentifier, where TransitIdentifier is
initialized by the TransitIdentifier field value of the IPlir
message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the TransitInitValue, SequenceNumber
and TransitIdentifier fields of the IPlir message,
- oL = IntToVec_8(OutputBitLength), where OutputBitLength = 128,
* the PRF output length is 128 bits.
5.3.3.4. Encryption and MAC algorithms
Encryption of the IPlir body and calculation of the end-to-end MAC
ICV in the IntegrityCheckValue field of the IPlir message are
implemented according to the AES-128 [NIST.FIPS.197] in the GCM mode
[NIST.SP.800-38d], wherein
* the packet encryption and end-to-end MAC key K_AEAD is used as the
key,
Davletshina, et al. Expires 18 December 2022 [Page 41]
Internet-Draft Abbreviated Title June 2022
* data in the IPlir header fields in the order of their appearance
in the IPlir message are used as associated authenticated data
protected by MAC,
* data in the IPlir body fields in the order of their appearance in
the IPlir message are used as plaintext,
* the value of IV_AEAD \in V_96 is used as a unique vector:
- IV_AEAD = InitValue,
- where InitValue is initialized by the InitValue field value of
the IPlir message,
* the MAC length s is 64 bits.
The diagram of encryption and end-to-end MAC is shown in Figure 12.
+-----------------------------------+
| IPlir header |
| ... |
| +---------------------------+ |
+--------| SourceIdentifier | |
| | +---------------------------+ |
| | ... |--------+
| | +---------------------------+ | |
+--------| SequenceNumber | | |
| | +---------------------------+ | |
+--------| InitValue |---------+ |
| | +---------------------------+ | | |
| +-----------------------------------+ | |
| | IPlir body |--+ | |
| +-----------------------------------+ | | |
| | IPlir trailer | | | |
| | ... | | | |
| +-----------------------------------+ | | |
| | | |
v v v v
+---------------------------------+ +-------------------+
| KDF in Counter Mode | +------+ | AES-128 |
| [NIST.SP.800-108] based on |->|K_AEAD|->| [NIST.FIPS.197] |
| AES-128 [NIST.FIPS.197] in the | +------+ | in the GCM mode |
| CMAC mode [NIST.SP.800-38b] | | [NIST.SP.800-38d] |
+---------------------------------+ +-------------------+
^ | |
| | |
+-----------------------+ | |
| Exchange keys between | | |
Davletshina, et al. Expires 18 December 2022 [Page 42]
Internet-Draft Abbreviated Title June 2022
| source and destination| | |
| hosts | | |
+-----------------------+ | |
| |
+-----------------------------------+ | |
| IPlir header | | |
| ... | | |
| +---------------------------+ | | |
| | SourceIdentifier | | | |
| +---------------------------+ | | |
| ... | | |
| +---------------------------+ | | |
| | SequenceNumber | | | |
| +---------------------------+ | | |
| | InitValue | | | |
| +---------------------------+ | | |
+-----------------------------------+ | |
| Encrypted IPlir body |<--+ |
+-----------------------------------+ |
| IPlir trailer | |
| +---------------------------+ | |
| | InterityCheckValue |<-----------+
| +---------------------------+ |
| ... |
+-----------------------------------+
Figure 12: Figure 12 - Diagram of Encryption and End-to-End MAC
Using the AES- 128-GCM Cryptographic Suite
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue
field of the IPlir message is implemented according to the AES-128
[NIST.FIPS.197] in the GCM mode [NIST.SP.800-38d], wherein
* the packet transit MAC key K_TMAC is used as the key,
* data in the IPlir header fields, the encrypted IPlir body and
IntegrityCheckValue, TransitIdentifier, TransitInitValue fields
data in the order of their appearance in the IPlir message are
used as associated authenticated data protected by MAC,
* plaintext is an empty string,
* the value of TIV_AEAD \in V_96 is used as a unique vector:
- TIV_AEAD = TransitInitValue,
- where TransitInitValue is initialized by the TransitInitValue
field value of the IPlir message,
Davletshina, et al. Expires 18 December 2022 [Page 43]
Internet-Draft Abbreviated Title June 2022
* the MAC length s is 64 bits.
The diagram of transit MAC is shown in Figure 13. The "null" value
means an empty binary string.
+-----------------------------------+--+
| IPlir header | |
| ... | |
| +---------------------------+ | |
+--------| SequenceNumber | | |
| | +---------------------------+ | |
| | ... | |
| +-----------------------------------+ |
| | Encrypted IPlir body | |-------+
| +-----------------------------------+ | |
| | IPlir trailer | | |
| | ... | | |
| | +---------------------------+ | | |
+--------| TransitIdentifier | | | |
| | +---------------------------+ | | |
+--------| | | | |
| | | TransitInitValue | | | |
| | +-| | | | |
| | | +---------------------------+---|--+ |
| | | ... | |
| +-|---------------------------------+ |
| | |
| +--------------------------------------+ |
| +------+ | |
| | null |----+ | |
| +------+ | | |
v v v v
+---------------------------------+ +-------------------+
| KDF in Counter Mode | +------+ | AES-128 |
| [NIST.SP.800-108] based on |->|K_TMAC|->| [NIST.FIPS.197] |
| AES-128 [NIST.FIPS.197] in the | +------+ | in the GCM mode |
| CMAC mode [NIST.SP.800-38b] | | [NIST.SP.800-38d] |
+---------------------------------+ +-------------------+
^ | |
| v |
+-----------------------+ +------+ |
| Exchange keys between | | null | |
| transit hosts | +------+ |
+-----------------------+ |
|
+-----------------------------------+ |
| IPlir header | |
| ... | |
Davletshina, et al. Expires 18 December 2022 [Page 44]
Internet-Draft Abbreviated Title June 2022
| +---------------------------+ | |
| | SequenceNumber | | |
| +---------------------------+ | |
| ... | |
+-----------------------------------+ |
| Encrypted IPlir body | |
+-----------------------------------+ |
| IPlir trailer | |
| ... | |
| +---------------------------+ | |
| | TransitIdentifier | | |
| +---------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +---------------------------+ | |
| | TransitInterityCheckValue |<-----------+
| +---------------------------+ |
+-----------------------------------+
Figure 13: Figure 13 - Diagram of Transit MAC Using the AES-128-GCM
Cryptographic Suite
5.3.4. AES-256-CTR-CMAC cryptographic suite: CS = 132
AES-256-CTR-CMAC Cryptographic Suite Description:
Davletshina, et al. Expires 18 December 2022 [Page 45]
Internet-Draft Abbreviated Title June 2022
+===========+================================+
| Parameter | Value |
+===========+================================+
| EncAlg | AES-256 [NIST.FIPS.197] in the |
| | CTR mode [NIST.SP.800-38a] |
+-----------+--------------------------------+
| MACAlg | AES-256 [NIST.FIPS.197] in the |
| | CMAC mode [NIST.SP.800-38b] |
+-----------+--------------------------------+
| TMACAlg | AES-256 [NIST.FIPS.197] in the |
| | CMAC mode [NIST.SP.800-38b] |
+-----------+--------------------------------+
| MACLen | 64 bits |
+-----------+--------------------------------+
| TMACLen | 64 bits |
+-----------+--------------------------------+
| IVLen | 64 bits |
+-----------+--------------------------------+
| TIVLen | 64 bits |
+-----------+--------------------------------+
| KDAlg | see the description below |
+-----------+--------------------------------+
Table 9
5.3.4.1. Exchange keys
For each pair of interacting hosts, there is a single exchange key
with a length of 256 bits designed for derivation of packet
encryption keys, end-to-end MAC keys, and transit MAC keys.
There may be several exchange keys for a pair of interacting hosts.
The KN field value of the IPlir message (for derivation of packet
encryption keys and packet end-to-end MAC keys) or the TKN field
value of the IPlir message (for derivation of packet transit MAC
keys) is used to determine a specific single exchange key.
5.3.4.2. Requirements for initializing values
The end-to-end initializing value InitValue in the InitValue field of
the IPlir message should have a length of 64 bits and be unique for
each IPlir packet the encryption and end-to-end MAC of which are
implemented by the same sender host using the same single exchange
key.
Davletshina, et al. Expires 18 December 2022 [Page 46]
Internet-Draft Abbreviated Title June 2022
The transit initializing value TransitInitValue in the
TransitInitValue field of the IPlir message should have a length of
64 bits and be unique for each IPlir packet the transit MAC of which
is implemented by the same (transit) host using the same single
exchange key.
5.3.4.3. Key derivation algorithms
The packet encryption key K_ENC of 256-bit length and the packet end-
to-end MAC key K_MAC of 256-bit length are calculated as follows:
K_ENC = K_1 || K_2,
K_MAC = K_3 || K_4,
where each value of K_i \in V_128, i = 1,2,3,4 is calculated as per
KDF in Counter Mode [NIST.SP.800-108] using AES-256 [NIST.FIPS.197]
in the CMAC mode [NIST.SP.800-38b] as the PRF, wherein
* the single exchange key corresponding to the specified sender and
recipient hosts, and the KN field value of the IPlir message is
used as the key for the PRF,
* a binary string as shown below is used as the input data for the
PRF: IntToVec_8(i)||Label||aL||IV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('ENCMAC'),
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- IV_KDF = InitValue, where InitValue is initialized by the
InitValue field value of the IPlir message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
- Node = SourceIdentifier, where SourceIdentifier is initialized
by the SourceIdentifier field value of the IPlir message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the InitValue, SequenceNumber and
SourceIdentifier fields of the IPlir message,
- oL = IntToVec_8(OutputBitLength), where OutputBitLength = 512,
* the PRF output length is 128 bits.
Davletshina, et al. Expires 18 December 2022 [Page 47]
Internet-Draft Abbreviated Title June 2022
The packet transit MAC key K_TMAC of 256-bit length is calculated as
follows:
K_TMAC = K_1 || K_2,
where each value of K_i \in V_128, i = 1,2 is calculated as per KDF
in Counter Mode [NIST.SP.800-108] using AES-256 [NIST.FIPS.197] in
the CMAC mode [NIST.SP.800-38b] as the PRF, wherein
* the single exchange key corresponding to the specified (transit)
hosts the IPlir packet passes through and the TKN field value of
the IPlir message is used as the key for the PRF,
* a binary string as shown below is used as the input data for the
PRF: IntToVec_8(i)||Label||aL||TIV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('TMAC'),
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- TIV_KDF = TransitInitValue, where TransitInitValue is
initialized by the TransitInitValue field value of the IPlir
message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
- Node = TransitIdentifier, where TransitIdentifier is
initialized by the TransitIdentifier field value of the IPlir
message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the TransitInitValue, SequenceNumber
and TransitIdentifier fields of the IPlir message,
- oL = IntToVec_16(OutputBitLength), where OutputBitLength = 256,
* the PRF output length is 128 bits.
5.3.4.4. Encryption and MAC algorithms
The IPlir body is encrypted according to the AES-256 [NIST.FIPS.197]
in the CTR mode [NIST.SP.800-38a], wherein
* the packet encryption key K_ENC is used as the key,
* data in the IPlir body fields in the order of their appearance in
the IPlir message are used as plaintext,
Davletshina, et al. Expires 18 December 2022 [Page 48]
Internet-Draft Abbreviated Title June 2022
* the values of T_1, T_2, ... , T_n \in V_128 are used as counters
in CTR mode:
- T_i = InitValue || IntToVec_64(i), i = 1, 2, ... , n,
- where InitValue is initialized by the InitValue field value of
the IPlir message.
Calculation of the end-to-end MAC ICV in the IntegrityCheckValue
field of the IPlir message is implemented according to the AES-256
[NIST.FIPS.197] in the CMAC mode [NIST.SP.800-38b], wherein
* the packet end-to-end MAC key K_MAC is used as the key,
* data in the IPlir body fields in the order of their appearance in
the IPlir message are used as plaintext,
* the MAC length s is 64 bits.
The diagram of encryption and end-to-end MAC is shown in Figure 14.
+-----------------------------------+
| IPlir header |
| ... |
| +---------------------------+ |
+--------| SourceIdentifier | |
| | +---------------------------+ |
| | ... |
| | +---------------------------+ |
+--------| SequenceNumber | |
| | +---------------------------+ |
+--------| InitValue |----------+
| | +---------------------------+ | |
| +-----------------------------------+ |
| | IPlir body |--+ |
| +-----------------------------------+ | |
| | IPlir trailer | | |
| | ... | | |
| +-----------------------------------+ | |
| | |
v v v
+---------------------------------+ +------+ +-------------------+
| KDF in Counter Mode |->|K_ENC |->| AES-256 |
| [NIST.SP.800-108] based on | +------+ | [NIST.FIPS.197] |
| AES-256 [NIST.FIPS.197] in the | | in the CTR mode |
| CMAC mode [NIST.SP.800-38b] | +------+ | [NIST.SP.800-38a] |
| |->|K_MAC | | |
+---------------------------------+ +------+ +-------------------+
Davletshina, et al. Expires 18 December 2022 [Page 49]
Internet-Draft Abbreviated Title June 2022
^ | |
| v |
+-----------------------+ +-------------------+ |
| Exchange keys between | | AES-256 | |
| source and destination| +---| [NIST.FIPS.197] | |
| hosts | | | in the CMAC mode | |
+-----------------------+ | | [NIST.SP.800-38b] | |
| +-------------------+ |
+-----------------------+ ^ |
| | |
| +---------------------------------+ |
| | |
| | +---+-----------------------------------+ |
| | | | IPlir header | |
| | | | ... | |
| | | | +---------------------------+ | |
| | | | | SourceIdentifier | | |
| | | | +---------------------------+ | |
| | | | ... | |
| +---| | +---------------------------+ | |
| | | | SequenceNumber | | |
| | | +---------------------------+ | |
| | | | InitValue | | |
| | | +---------------------------+ | |
| | +-----------------------------------+ |
| | | Encrypted IPlir body |<---+
| +---+-----------------------------------+
| | IPlir trailer |
| | +---------------------------+ |
+-------------->| InterityCheckValue | |
| +---------------------------+ |
| ... |
+-----------------------------------+
Figure 14: Figure 14 - Diagram of Encryption and End-to-End MAC
Using the AES- 256-CTR-CMAC Cryptographic Suite
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue
field of the IPlir message is implemented according to the AES-256
[NIST.FIPS.197] in the CMAC mode [NIST.SP.800-38b], wherein
* the packet transit MAC key K_TMAC is used as the key,
* data in the IPlir header fields, the encrypted IPlir body and
IntegrityCheckValue, TransitIdentifier, TransitInitValue fields
data in the order of their appearance in the IPlir message are
used as associated authenticated data protected by MAC,
Davletshina, et al. Expires 18 December 2022 [Page 50]
Internet-Draft Abbreviated Title June 2022
* the MAC length s is 64 bits.
The diagram of transit MAC is shown in Figure 15.
+-----------------------------------+--+
| IPlir header | |
| ... | |
| +---------------------------+ | |
+--------| SequenceNumber | | |
| | +---------------------------+ | |
| | ... | |
| +-----------------------------------+ |
| | Encrypted IPlir body | |---+
| +-----------------------------------+ | |
| | IPlir trailer | | |
| | ... | | |
| | +---------------------------+ | | |
+--------| TransitIdentifier | | | |
| | +---------------------------+ | | |
+--------| | | | |
| | | TransitInitValue | | | |
| | | | | | |
| | +---------------------------+---|--+ |
| | ... | |
| +-----------------------------------+ |
| |
v v
+---------------------------------+ +-------------------+
| KDF in Counter Mode | +------+ | AES-256 |
| [NIST.SP.800-108] based on |->|K_TMAC|->| [NIST.FIPS.197] |
| AES-256 [NIST.FIPS.197] in the | +------+ | in the CMAC mode |
| CMAC mode [NIST.SP.800-38b] | | [NIST.SP.800-38b] |
+---------------------------------+ +-------------------+
^ |
| |
+-----------------------+ |
| Exchange keys between | |
| transit hosts | |
+-----------------------+ |
|
+-----------------------------------+ |
| IPlir header | |
| ... | |
| +---------------------------+ | |
| | SequenceNumber | | |
| +---------------------------+ | |
| ... | |
+-----------------------------------+ |
Davletshina, et al. Expires 18 December 2022 [Page 51]
Internet-Draft Abbreviated Title June 2022
| Encrypted IPlir body | |
+-----------------------------------+ |
| IPlir trailer | |
| ... | |
| +---------------------------+ | |
| | TransitIdentifier | | |
| +---------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +---------------------------+ | |
| | TransitInterityCheckValue |<-------+
| +---------------------------+ |
+-----------------------------------+
Figure 15: Figure 15 - Diagram of Transit MAC Using the AES-256-
CTR-CMAC Cryptographic Suite
5.3.5. AES-256-CFB-CMAC cryptographic suite: CS = 134
AES-256-CTR-CMAC Cryptographic Suite Description:
+===========+================================+
| Parameter | Value |
+===========+================================+
| EncAlg | AES-256 [NIST.FIPS.197] in the |
| | CFB mode [NIST.SP.800-38a] |
+-----------+--------------------------------+
| MACAlg | AES-256 [NIST.FIPS.197] in the |
| | CMAC mode [NIST.SP.800-38b] |
+-----------+--------------------------------+
| TMACAlg | AES-256 [NIST.FIPS.197] in the |
| | CMAC mode [NIST.SP.800-38b] |
+-----------+--------------------------------+
| MACLen | 64 bits |
+-----------+--------------------------------+
| TMACLen | 64 bits |
+-----------+--------------------------------+
| IVLen | 128 bits |
+-----------+--------------------------------+
| TIVLen | 64 bits |
+-----------+--------------------------------+
| KDAlg | see the description below |
+-----------+--------------------------------+
Table 10
Davletshina, et al. Expires 18 December 2022 [Page 52]
Internet-Draft Abbreviated Title June 2022
5.3.5.1. Exchange keys
For each pair of interacting hosts, there is a single exchange key
with a length of 256 bits designed for derivation of packet
encryption keys, end-to-end MAC keys, and transit MAC keys.
There may be several exchange keys for a pair of interacting hosts.
The KN field value of the IPlir message (for derivation of packet
encryption keys and packet end-to-end MAC keys) or the TKN field
value of the IPlir message (for derivation of packet transit MAC
keys) is used to determine a specific single exchange key.
5.3.5.2. Requirements for initializing values
The end-to-end initializing value InitValue in the InitValue field of
the IPlir message should have a length of 128 bits and be unique for
each IPlir packet the encryption and end-to-end MAC of which are
implemented by the same sender host using the same single exchange
key.
The transit initializing value TransitInitValue in the
TransitInitValue field of the IPlir message should have a length of
64 bits and be unique for each IPlir packet the transit MAC of which
is implemented by the same (transit) host using the same single
exchange key.
5.3.5.3. Key derivation algorithms
The packet encryption key K_ENC of 256-bit length and the packet end-
to-end MAC key K_MAC of 256-bit length are calculated as follows:
K_ENC = K_1 || K_2,
K_MAC = K_3 || K_4,
where each value of K_i \in V_128, i = 1,2,3,4 is calculated as per
KDF in Counter Mode [NIST.SP.800-108] using AES-256 [NIST.FIPS.197]
in the CMAC mode [NIST.SP.800-38b] as the PRF, wherein
* the single exchange key corresponding to the specified sender and
recipient hosts, and the KN field value of the IPlir message is
used as the key for the PRF,
* a binary string as shown below is used as the input data for the
PRF: IntToVec_8(i)||Label||aL||IV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('ENCMAC'),
Davletshina, et al. Expires 18 December 2022 [Page 53]
Internet-Draft Abbreviated Title June 2022
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- IV_KDF = InitValue, where InitValue is initialized by the
InitValue field value of the IPlir message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
- Node = SourceIdentifier, where SourceIdentifier is initialized
by the SourceIdentifier field value of the IPlir message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the InitValue, SequenceNumber and
SourceIdentifier fields of the IPlir message,
- oL = IntToVec_16(OutputBitLength), where OutputBitLength = 512,
* the PRF output length is 128 bits.
The packet transit MAC key K_TMAC of 256-bit length is calculated as
follows:
K_TMAC = K_1 || K_2,
where each value of K_i \in V_128, i = 1,2 is calculated as per KDF
in Counter Mode [NIST.SP.800-108] using AES-256 [NIST.FIPS.197] in
the CMAC mode [NIST.SP.800-38b] as the PRF, wherein
* the single exchange key corresponding to the specified (transit)
hosts the IPlir packet passes through and the TKN field value of
the IPlir message is used as the key for the PRF,
* a binary string as shown below is used as the input data for the
PRF: IntToVec_8(i)||Label||aL||TIV_KDF||SN||Node||cL||oL, where
- Label = StrToVec_48('TMAC'),
- aL = IntToVec_8(LabelByteLength), where LabelByteLength = 6,
- TIV_KDF = TransitInitValue, where TransitInitValue is
initialized by the TransitInitValue field value of the IPlir
message,
- SN = SequenceNumber, where SequenceNumber is initialized by the
SequenceNumber field value of the IPlir message,
Davletshina, et al. Expires 18 December 2022 [Page 54]
Internet-Draft Abbreviated Title June 2022
- Node = TransitIdentifier, where TransitIdentifier is
initialized by the TransitIdentifier field value of the IPlir
message,
- cL = IntToVec_16(ContextByteLength), where ContextByteLength is
the sum of byte lengths of the TransitInitValue, SequenceNumber
and TransitIdentifier fields of the IPlir message,
- oL = IntToVec_16(OutputBitLength), where OutputBitLength = 256,
* the PRF output length is 128 bits.
5.3.5.4. Encryption and MAC algorithms
The IPlir body is encrypted according to the AES-256 [NIST.FIPS.197]
in the CFB mode [NIST.SP.800-38a], wherein
* the packet encryption key K_ENC is used as the key,
* data in the IPlir body fields in the order of their appearance in
the IPlir message are used as plaintext,
* the value of IV_ENC \in V_128 is used as the initializing value:
- IV_ENC = InitValue,
- where InitValue is initialized by the InitValue field value of
the IPlir message.
Calculation of the end-to-end MAC ICV in the IntegrityCheckValue
field of the IPlir message is implemented according to the AES-256
[NIST.FIPS.197] in the CMAC mode [NIST.SP.800-38b], wherein
* the packet end-to-end MAC key K_MAC is used as the key,
* data in the IPlir body fields in the order of their appearance in
the IPlir message are used as plaintext,
* the MAC length s is 64 bits.
The diagram of encryption and end-to-end MAC is shown in Figure 16.
+-----------------------------------+
| IPlir header |
| ... |
| +---------------------------+ |
+--------| SourceIdentifier | |
| | +---------------------------+ |
Davletshina, et al. Expires 18 December 2022 [Page 55]
Internet-Draft Abbreviated Title June 2022
| | ... |
| | +---------------------------+ |
+--------| SequenceNumber | |
| | +---------------------------+ |
+--------| InitValue |----------+
| | +---------------------------+ | |
| +-----------------------------------+ |
| | IPlir body |--+ |
| +-----------------------------------+ | |
| | IPlir trailer | | |
| | ... | | |
| +-----------------------------------+ | |
| | |
v v v
+---------------------------------+ +------+ +-------------------+
| KDF in Counter Mode |->|K_ENC |->| AES-256 |
| [NIST.SP.800-108] based on | +------+ | [NIST.FIPS.197] |
| AES-256 [NIST.FIPS.197] in the | | in the CFB mode |
| CMAC mode [NIST.SP.800-38b] | +------+ | [NIST.SP.800-38a] |
| |->|K_MAC | | |
+---------------------------------+ +------+ +-------------------+
^ | |
| v |
+-----------------------+ +-------------------+ |
| Exchange keys between | | AES-256 | |
| source and destination| +---| [NIST.FIPS.197] | |
| hosts | | | in the CMAC mode | |
+-----------------------+ | | [NIST.SP.800-38b] | |
| +-------------------+ |
+-----------------------+ ^ |
| | |
| +---------------------------------+ |
| | |
| | +---+-----------------------------------+ |
| | | | IPlir header | |
| | | | ... | |
| | | | +---------------------------+ | |
| | | | | SourceIdentifier | | |
| | | | +---------------------------+ | |
| | | | ... | |
| +---| | +---------------------------+ | |
| | | | SequenceNumber | | |
| | | +---------------------------+ | |
| | | | InitValue | | |
| | | +---------------------------+ | |
| | +-----------------------------------+ |
| | | Encrypted IPlir body |<---+
| +---+-----------------------------------+
Davletshina, et al. Expires 18 December 2022 [Page 56]
Internet-Draft Abbreviated Title June 2022
| | IPlir trailer |
| | +---------------------------+ |
+-------------->| InterityCheckValue | |
| +---------------------------+ |
| ... |
+-----------------------------------+
Figure 16: Figure 16 - Diagram of Encryption and End-to-End MAC
Using the AES- 256-CFB-CMAC Cryptographic Suite
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue
field of the IPlir message is implemented according to the AES-256
[NIST.FIPS.197] in the CMAC mode [NIST.SP.800-38b], wherein
* the packet transit MAC key K_TMAC is used as the key,
* data in the IPlir header fields, the encrypted IPlir body and
IntegrityCheckValue, TransitIdentifier, TransitInitValue fields
data in the order of their appearance in the IPlir message are
used as associated authenticated data protected by MAC,
* the MAC length s is 64 bits.
The diagram of transit MAC is shown in Figure 17.
+-----------------------------------+--+
| IPlir header | |
| ... | |
| +---------------------------+ | |
+--------| SequenceNumber | | |
| | +---------------------------+ | |
| | ... | |
| +-----------------------------------+ |
| | Encrypted IPlir body | |---+
| +-----------------------------------+ | |
| | IPlir trailer | | |
| | ... | | |
| | +---------------------------+ | | |
+--------| TransitIdentifier | | | |
| | +---------------------------+ | | |
+--------| | | | |
| | | TransitInitValue | | | |
| | | | | | |
| | +---------------------------+---|--+ |
| | ... | |
| +-----------------------------------+ |
| |
v v
Davletshina, et al. Expires 18 December 2022 [Page 57]
Internet-Draft Abbreviated Title June 2022
+---------------------------------+ +-------------------+
| KDF in Counter Mode | +------+ | AES-256 |
| [NIST.SP.800-108] based on |->|K_TMAC|->| [NIST.FIPS.197] |
| AES-256 [NIST.FIPS.197] in the | +------+ | in the CMAC mode |
| CMAC mode [NIST.SP.800-38b] | | [NIST.SP.800-38b] |
+---------------------------------+ +-------------------+
^ |
| |
+-----------------------+ |
| Exchange keys between | |
| transit hosts | |
+-----------------------+ |
|
+-----------------------------------+ |
| IPlir header | |
| ... | |
| +---------------------------+ | |
| | SequenceNumber | | |
| +---------------------------+ | |
| ... | |
+-----------------------------------+ |
| Encrypted IPlir body | |
+-----------------------------------+ |
| IPlir trailer | |
| ... | |
| +---------------------------+ | |
| | TransitIdentifier | | |
| +---------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +---------------------------+ | |
| | TransitInterityCheckValue |<-------+
| +---------------------------+ |
+-----------------------------------+
Figure 17: Figure 17 - Diagram of Transit MAC Using the AES-256-
CFB-CMAC Cryptographic Suite
6. IPlir packet processing
For cryptographic processing of network packets, the algorithms used
and their application procedure are determined by the cryptographic
suite.
The cryptographic suite for protection of the source IP packet is
chosen depending on the corresponding security policy of the sender
host and the destination host context on the recipient end. The
Davletshina, et al. Expires 18 December 2022 [Page 58]
Internet-Draft Abbreviated Title June 2022
logic and procedure of processing IPlir packets protected using a
certain cryptographic suite depend on the IPlir packet reception
policy and the sender host context on the recipient end. The
necessity and procedure of using transit MAC are determined based on
the sender host security policy and IPlir packet reception policies
of transit hosts and the recipient host.
Depending on security policies and other requirements, protection of
the recipient host or transit host against replay of previously
transmitted IPlir packets for reprocessing may be required. The
IPlir protocol makes it possible to arrange such protection by using
counter values and/or timestamps, as well as by tracking the history
of their change on transit hosts and the recipient host. As an
example, SequenceNumber, InitValue, TransitInitValue field values can
be used as counter values, Timestamp field values can be used as
timestamps. Description of specific mechanisms designed for
protection against replay of previously transmitted IPlir packets is
beyond the scope of this document.
6.1. IP and IPlir packet fragmentation
When packing data in IP packets, the IP protocol can fragment (break
down into fragments) messages of the higher transport layer protocols
UDP, TCP, etc. This processing results in several (linked) IP
packets, each called an IP fragment.
The IPlir protocol in transport and light tunnel modes should only be
applied to whole (non-fragmented) IP packets, but not IP fragments.
In the tunnel mode, the IPlir protocol can be applied to both whole
IP packets and IP fragments.
In case of encapsulation in IPv4, the IPlir packet, just like any
other IPv4 packet, can be fragmented by routers during transmission.
Before the IPlir packet is processed on the end of the recipient or
transit host, the IPlir packet must be defragmented.
6.2. Source IP packet protection by the sender host
If the sender host decides to protect a specific IP packet, an IPlir
packet is created as follows.
1. The recipient and transit host contexts along with the applied
security policy determine:
* TIV_AEAD = LSB_63(TransitInitValue),
* where TransitInitValue is initialized by the TransitInitValue
field value of the IPlir message,
Davletshina, et al. Expires 18 December 2022 [Page 59]
Internet-Draft Abbreviated Title June 2022
2. Based on the recipient and transit host contexts along with the
cryptographic suite:
* TIV_AEAD = LSB_63(TransitInitValue),
* where TransitInitValue is initialized by the TransitInitValue
field value of the IPlir message,
3. The IPlir packet fields are filled in considering the data from
the source IP packet and the data generated previously.
4. The IPlir body is encrypted (if required by the security policy)
and the end-to-end MAC value is calculated as prescribed by the
cryptographic suite. The end-to-end MAC value is placed in the
corresponding field of the IPlir trailer.
5. If transit integrity control is required, the corresponding
fields and flags of the IPlir header and IPlir trailer are filled
in, the transit MAC value is calculated. The transit MAC value
is placed in the corresponding field of the IPlir trailer.
6. An IPlir packet is generated, wherein parts of the source IP
packet are located according to the rules specified in
Section 4.4.
6.3. IPlir packet processing on the forward host
After receiving an IPlir packet, the transit host processes the IPlir
packet as follows.
1. It checks whether the received IPlir packet corresponds to the
IPlir packet reception policy. If the packet does not comply
with the policy, it is blocked.
2. If the IPlir version in the IPlir header is not supported by the
host, the packet is blocked.
3. The IPlir packet is matched to the context of the sender host or
the previous transit host. If the context is not found or
contains cryptographic suites not matching the set from the
IPlir header, the packet is blocked.
4. If the suite from the IPlir header does not imply transit MAC,
the packet is blocked.
Davletshina, et al. Expires 18 December 2022 [Page 60]
Internet-Draft Abbreviated Title June 2022
5. Based on the context of the previous transit host and the IPlir
header, the packet transit MAC key is derived. The IPlir packet
integrity is verified by checking the transit MAC. If the
transit MAC is not correct, the packet is blocked.
6. Based on the recipient host context, the next transit host is
determined on the transit host (or it is determined that the
IPlir packet can be delivered to the recipient host directly).
If the context of the next transit host (or recipient host) is
not found, the packet is blocked.
7. If the found context contains cryptographic suites not matching
the set from the IPlir header, the packet is blocked.
8. Based on the context of the next transit host, IPlir header and
IPlir trailer, the packet transit MAC key and transit
initializing value are generated. The necessary number of the
packet transit MAC key and the transit host identifier are
established in the IPlir message. The transit initializing
value is located in the TransitInitValue field.
9. The transit MAC value is calculated and placed in the
corresponding field of the IPlir trailer.
10. An IPlir packet is generated, wherein parts of the source IP
packet are located according to the rules specified in
Section 4.4.
There may be cases when the security policies require a transit MAC
to be added to the routed packet without checking the previous value
or, vice versa, the received IPlir packet integrity to be checked
without calculating a new transit MAC value, as well as cases when no
transit protection is required. In this case:
* If no integrity verification of the received transit IPlir packet
is required, steps 3, 4, 5 of the algorithm are skipped,
* If no transit MAC calculation is required, steps 7, 8, 9 of the
above algorithm are skipped,
* If transit protection is not required, steps 3, 4, 5, 7, 8, 9 of
the above algorithm are skipped.
6.4. Source IP packet recovery by the recipient host
After receiving the IPlir packet, the recipient host restores the
source IP packet as follows.
Davletshina, et al. Expires 18 December 2022 [Page 61]
Internet-Draft Abbreviated Title June 2022
1. It checks whether the received IPlir packet corresponds to the
IPlir packet reception policy. If the packet does not comply
with the policy, it is blocked.
2. If the IPlir version in the IPlir header is not supported by the
host, the packet is blocked.
3. The IPlir packet is matched to the context of the previous
transit host. If the context is not found or contains
cryptographic suites not matching the set from the IPlir header,
the packet is blocked.
4. Based on the context of the previous transit host and the IPlir
header, the packet transit MAC key is derived. The IPlir packet
integrity is verified by checking the transit MAC. If the
transit MAC is not correct, the packet is blocked.
5. The IPlir packet is matched to the context of the sender host.
If the context is not found or contains cryptographic suites not
matching the suite from the IPlir header, the packet is blocked.
6. Based on the context of the sender host and the IPlir header, the
packet encryption key and packet end-to-end MAC key are derived.
7. The end-to-end MAC is checked and, if the IPlir body was
encrypted, the packet IPlir body is decrypted as defined by the
cryptographic suite. If the end-to-end MAC is not correct, the
packet is blocked.
8. The IP packet is restored according to the rules of Section 4.4.
There may be cases when the security policies do not require transit
MAC checking by the recipient host. Then steps 3, 4 of the algorithm
are skipped.
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[NIST.FIPS.197]
NIST, "Advanced encryption standard (AES)", NIST NIST FIPS
197, DOI 10.6028/NIST.FIPS.197, November 2001,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.197.pdf>.
Davletshina, et al. Expires 18 December 2022 [Page 62]
Internet-Draft Abbreviated Title June 2022
[NIST.SP.800-108]
Chen, L., "Recommendation for key derivation using
pseudorandom functions (revised)", NIST NIST SP 800-108,
DOI 10.6028/NIST.SP.800-108, 2009,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-108.pdf>.
[NIST.SP.800-38a]
Dworkin, M J., "Recommendation for block cipher modes of
operation :methods and techniques", NIST NIST SP 800-38a,
DOI 10.6028/NIST.SP.800-38a, 2001,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-38a.pdf>.
[NIST.SP.800-38b]
Dworkin, M J., "Recommendation for block cipher modes of
operation :the CMAC mode for authentication", NIST NIST SP
800-38b, DOI 10.6028/NIST.SP.800-38b, 2016,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-38b.pdf>.
[NIST.SP.800-38d]
Dworkin, M J., "Recommendation for block cipher modes of
operation :GaloisCounter Mode (GCM) and GMAC", NIST NIST
SP 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-38d.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher
"Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,
<https://www.rfc-editor.org/info/rfc7801>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015:
Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891,
September 2020, <https://www.rfc-editor.org/info/rfc8891>.
Davletshina, et al. Expires 18 December 2022 [Page 63]
Internet-Draft Abbreviated Title June 2022
[RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E.
Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058,
DOI 10.17487/RFC9058, June 2021,
<https://www.rfc-editor.org/info/rfc9058>.
8.2. Informative References
[GOST3413-2015]
Federal Agency on Technical Regulating and Metrology,
"Information technology. Cryptographic data security.
Modes of operation for block ciphers", GOST R 34.13-2015,
2015.
Authors' Addresses
Davletshina Alexandra (editor)
InfoTeCS
2B stroenie 1, ul. Otradnaya
Moscow
127273
Russian Federation
Phone: +7 (495) 737-61-92
Email: Aleksandra.Davletshina@infotecs.ru
Urivskiy Alexey
InfoTeCS
2B stroenie 1, ul. Otradnaya
Moscow
127273
Russian Federation
Phone: +7 (495) 737-61-92
Email: urivskiy@infotecs.ru
Rybkin Andrey
InfoTeCS
2B stroenie 1, ul. Otradnaya
Moscow
127273
Russian Federation
Phone: +7 (495) 737-61-92
Email: Andrey.Rybkin@infotecs.ru
Tychina Leonid
InfoTeCS
2B stroenie 1, ul. Otradnaya
Davletshina, et al. Expires 18 December 2022 [Page 64]
Internet-Draft Abbreviated Title June 2022
Moscow
127273
Russian Federation
Phone: +7 (495) 737-61-92
Email: tychina@infotecs.ru
Parshin Ilia
InfoTeCS
2B stroenie 1, ul. Otradnaya
Moscow
127273
Russian Federation
Phone: +7 (495) 737-61-92
Email: Parshin.Ilia@infotecs.ru
Davletshina, et al. Expires 18 December 2022 [Page 65]