| Internet-Draft | Abbreviated Title | April 2023 |
| Davletshina, et al. | Expires 5 October 2023 | [Page] |
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.¶
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 5 October 2023.¶
Copyright (c) 2023 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.¶
The IPlir protocol may be used to protect IP packets during their transmission via communication channels. IP packet protection means ensuring data integrity and authenticity of the data source of the packets. For this purpose, when IPlir is applied, encapsulation of original IP packets, calculation of message authentication codes for the encapsulated packets and service information are used. IP packet protection also means option of ensuring their confidentiality and uses packet encryption for this purpose. 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 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.¶
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.¶
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.¶
The following notations are used in this document:¶
An IPlir packet is an IP packet protected by IPlir. Its format is shown in Figure 1.¶
+------------+------------+--------------------+ | IP header | UDP header | IPlir message | +------------+------------+--------------------+
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 original IP packet and plaintext data required for the IPlir message processing.¶
The IPlir message contains:¶
The IPlir message structure is shown in Figure 2.¶
+---+---------------+---------------+---------------+---------------+ | | 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 (IV) | +---+---------------+---------------+-------------------------------+ | | Type_1 | Length_1 | Value_1 (Length_1 bytes) | | +---------------+---------------+-------------------------------+ | I | ... | | P +---------------+---------------+-------------------------------+ | l | Type_n | Length_n | Value_n (Length_n bytes) | | 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 (TIV) | |r e+---------------------------------------------------------------+ | r| TransitIntegrityCheckValue (TICV) | +---+---------------------------------------------------------------+
The IPlir message fields have a big-endian order of bytes. The numbering is left-to-right, the high bytes have lower numbers. Numbering of bits inside bytes is right-to-left, the high bits have higher numbers.¶
IPlir header version. This document describes the IPlir header of Version = 1. The field length is 8 bit.¶
Cryptographic suite identifier determining the contents of cryptographic mechanisms and their parameters used to create the IPlir packet. The field length is 8 bit.¶
The transit MAC flag. If T = 1, the IPlir trailer contains fields TransitIdentifier, TransitIntegrityCheckValue and TransitInitValue, otherwise the fields are absent. T field has to be set to 0 when calculating and checking the end-to-end MAC (ICV). The field length is 1 bit.¶
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.¶
The extended network host identifiers flag. If ExtID = 0, the SourceIdentifier field and, if available, DestinationIdentifier and TransitIdentifier fields are 32 bits long. If ExtID = 1, all these network host identifiers are 64 bits long. The field length is 1 bit.¶
The packet extended sequence number flag. If ExtSN=0, the SequenceNumber field is 32 bits long. If ExtSN = 1, the SequenceNumber field is 64 bits long. The field length is 1 bit.¶
The flag of disabling the anti-replay mechanism. The use of the flag is regulated by security policies. The field length is 1 bit.¶
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.¶
The number of the exchange key used to encrypt and calculate the end-to-end MAC. The field length is 4 bits.¶
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.¶
Packet send time. The field contains the send time value based on the astronomical clock of the source host in the POSIX time format less 0x40000000 seconds. The estimated overflow time is the year 2140. The field length is 32 bits.¶
The source host identifier used by the destination host to identify the IPlir packet source and the related context of the source host for packet processing. The field length is 32 bits with ExtID = 0, or 64 bits with ExtID = 1.¶
The destination host identifier required for routing of IPlir packets. The field is available, if D = 0. The field length is 32 bits with ExtID = 0, or 64 bits with ExtID = 1.¶
The packet sequence number; an unsigned integer. The field length is 32 bits with ExtSN = 0, or 64 bits with ExtSN = 1.¶
An end-to-end initialization 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.¶
Tuples (Type, Length, Value) enable transmission of additional information within the IPlir message. The Type field contains the type of the value in the Value field. The Type field length is 8 bit. The Length field contains the byte length of the Value field. The Length field length is 8 bit. The Value field contains a data of the Type field type. The Value field length of any tuple should be divisible by 8 bits and be less than 255 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 |
The last tuple in the message always has type 0. The length of this tuple should be chosen so as to ensure effective IPlir message processing.¶
The Value field of the tuple of this type contains a pair of IPv4 addresses. The source address comes first, followed by the destination address. The addresses are transmitted in the big-endian order of bytes.¶
The main function of the tuple of this type is to preserve the IPv4 addresses from the original IP packet in the light tunnel mode.¶
The tuple structure is shown in Figure 3.¶
+------+--------------+--------------+--------------+--------------+ |Bytes | 0 | 1 | 2 | 3 | +------+--------------+--------------+--------------+--------------+ | | | |Source IPv4 | | | | Type = 1 | Length = 8 |address, byte | ... | | | | |No.1 (high) | | | +--------------+--------------+--------------+--------------+ | TLV | |Source IPv4 |Destination | | | | ... |address, byte |IPv4 address, | ... | | area | |No.4 (low) |byte No.1 | | | | | |(high) | | | +--------------+--------------+--------------+--------------+ | | |Destination | | | | | ... |IPv4 address, | Not in use | Not in use | | | |byte No.4 | | | | | |(low) | | | +------+--------------+--------------+--------------+--------------+
Note: Bytes labeled “not in use” contain information related to the following tuple.¶
The Value field of the tuple of this type contains a pair of IPv6 addresses. The source address comes first, followed by the destination address. The addresses are transmitted in the big-endian order of bytes.¶
The main function of the tuple of this type is to preserve the IPv6 addresses from the original IP packet in the light tunnel mode.¶
The tuple structure is shown in Figure 4.¶
+------+--------------+--------------+--------------+--------------+ |Bytes | 0 | 1 | 2 | 3 | +------+--------------+--------------+--------------+--------------+ | | | |Source IPv6 | | | | Type = 2 | Length = 32 |address, byte | ... | | | | |No.1 (high) | | | +--------------+--------------+--------------+--------------+ | | ... | | +--------------+--------------+--------------+--------------+ | TLV | |Source IPv6 |Destination | | | | ... |address, byte |IPv6 address, | ... | | area | |No.16 (low) |byte No.1 | | | | | |(high) | | | +--------------+--------------+--------------+--------------+ | | |Destination | | | | | ... |IPv6 address, | Not in use | Not in use | | | |byte No.16 | | | | | |(low) | | | +------+--------------+--------------+--------------+--------------+
Note: Bytes labeled “not in use” contain information related to the following tuple.¶
A variable-length field containing the original IP packet or its part, depending on the IPlir operation mode.¶
A (network) filler to make the length of the IPlir message more suitable for efficient processing. The Staffing field contains a sequence of integers in a binary form: the first byte contains 1, the second one contains 2, etc. The field length is determined by the SL field value, if SL is absent (S = 0) or has the value 0, there is no Staffing field.¶
The number of bytes in the Staffing field. The field is available, if S = 1. The field length is 8 bit.¶
Type, Length and Value fields flag. If TLV = 1, the IPlir body begins with tuples (Type, Length, Value), otherwise there are no tuples. The field length is 1 bit.¶
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.¶
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.¶
The original IP packet protocol number. The field length is 8 bit.¶
An end-to-end MAC calculated for the data from the IPlir message start to the NextHeader field inclusive. The field length is determined by the used cryptographic suite.¶
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.¶
The transit initialization value used to calculate a transit MAC and derive keys for this operation. The field is available, if T = 1. The field length is determined by the used cryptographic suite.¶
A transit MAC calculated for the data from the IPlir message start to the TransitInitValue field inclusive. The field is available, if T = 1. The field length is determined by the used cryptographic suite.¶
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 original IP packet.¶
The receiving end determines based on the value of the Mode field in what mode the packet was sent. Possible field values are shown in Table 2.¶
| Mode field value | Mode description |
|---|---|
| 0 | transport mode |
| 1 | light tunnel mode |
| 2 | tunnel mode |
| 3 | reserved for future needs |
In the transport mode, the IPlir header and (Type, Length, Value)-tuples follow the IP header and precede the header of the next layer (e.g., TCP, UDP, ICMP, etc.). For IPv4 it means that the IPlir header is located after the IP header, including all options in the original IP packet, but before the header of the next level protocol.¶
For IPv6 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 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 destination options should follow the IPlir header.¶
Figure 5 shows an example of IP packet protection using the IPlir in the transport mode.¶
+-------------------------+ +--------------------------+
| Original IP packet | | IPlir packet |
| +-------------------+ | | +--------------------+ |
| | IP header |---------->| IP header | |
| +-------------------+ | | +--------------------+ |
| | IP packet data |-----+ | | IPlir header | |
| +-------------------+ | | | +--------------------+ |
+-------------------------+ | | | IPlir body | |
| | | +----------------+ | |
+------>| IP packet data | | |
| | +----------------+ | |
| +--------------------+ |
| | IPlir trailer | |
| +--------------------+ |
+--------------------------+
Location of the IPlir header and (Type, Length, Value)-tuples in the light tunnel mode is the same as in the transport mode. An exception is that the set of tuples in the IPlir body must include a type 1 tuple (two IPv4 addresses) or a type 2 tuple (two IPv6 addresses), wherein the source and destination addresses are specified from the IP header of the original IP packet. The tuple type is defined by the version of the IP header of the original IP packet.¶
The destination 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.¶
+--------------------------+ +------------------------------+
| Original 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 | |
| +------------------------+ |
+------------------------------+
Unlike the other modes, the tunnel mode protects the entire original 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 original 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.¶
+-------------------------+ +--------------------------+
| Original IP packet | | IPlir packet |
| +-------------------+ | | +--------------------+ |
| | IP header |-------+ | | IP header | |
| +-------------------+ | | | +--------------------+ |
| | IP packet data |----+ | | | IPlir header | |
| +-------------------+ | | | | +--------------------+ |
+-------------------------+ | | | | IPlir body | |
| | | | +----------------+ | |
| +----->| IP header | | |
| | | +----------------+ | |
+-------->| IP packet data | | |
| | +----------------+ | |
| +--------------------+ |
| | IPlir trailer | |
| +--------------------+ |
+--------------------------+
To ensure the confidentiality of the packet, the IPlir protocol is possible to encrypt it using a symmetric cryptographic algorithm. 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 source and destination hosts regardless of the transfer network topology and existence of transit hosts.¶
To ensure packet integrity and authenticity of the data source, the IPlir protocol allows for MAC which can be end-to-end and transit. End-to-end MAC is applied between the source and destination hosts. It is mandatory. Transit MAC is applied between two neighbor hosts in a packet transfer chain. It is optional.¶
To ensure confidentiality, packet integrity and authenticity of the data source, either separate encryption and MAC algorithms or AEAD algorithms to encrypt and calculate MAC simultaneously can be used.¶
It is implied that there is a key system that provides the interacting hosts with necessary exchange keys and controls their synchronization. Exchange key is a key known only to the specified pair of hosts used to derive keys. Keys can be managed manually or automatically.¶
The exchange keys required to process a specific packet with all their mandatory attributes (meta data) must be available when packet processing starts.¶
The packet encryption keys, end-to-end MAC keys and transit MAC keys are derived from the exchange key to protect each IP packet. Each exchange key related to the specific pair of hosts is indexed with the corresponding pair of their identifiers. It is possible to use key systems in which several exchange keys exist (up to 16) simultaneously for two hosts. 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 source and destination 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 limits arising during IPlir implementation.¶
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.¶
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 |
The list of main mechanisms and parameters specified in the cryptographic suite is shown in Table 4:¶
| Parameter | Description | Purpose |
|---|---|---|
| EncAlg | encryption algorithm | the algorithm is used to encrypt the packet |
| MACAlg | end-to-end MAC algorithm | the algorithm is used to calculate packet end-to-end MAC |
| TMACAlg | transit MAC algorithm | the algorithm is used to calculate packet transit MAC |
| MACLen | end-to-end MAC length | |
| TMACLen | transit MAC length | |
| IVLen | end-to-end initialization value length | the initialization value can be used for packet encryption, end-to-end 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 initialization value length | the transit initialization value can be used for packet transit MAC and derivation of packet transit MAC keys |
| KDAlg | algorithms of deriving packet protection keys from exchange keys | the algorithms are used to derive packet encryption keys and packet end-to-end MAC keys (or packet encryption and end-to-end MAC keys), and to derive packet transit MAC keys |
MAGMA-MGM Cryptographic Suite Description is shown in Table 5:¶
| 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 |
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.¶
The end-to-end initialization 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 source host using the same exchange key.¶
The transit initialization 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 exchange key.¶
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 ISO/IEC 9797-1:2011 [ISO9797-1], wherein¶
a binary string as shown below is used as the data: IntToVec_8(i)||Label||aL||IV_KDF||SN||Node||cL||oL, where¶
The packet transit MAC key K_TMAC of 256 bit length is calculated as follows:¶
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 R 34.12–2015 (Magma) [RFC8891] in the CMAC mode, as per ISO/IEC 9797-1:2011 [ISO9797-1], wherein¶
a binary string as shown below is used as the data: IntToVec_8(i)||Label||aL||TIV_KDF||SN||Node||cL||oL, where¶
Encryption of the IPlir body and calculation of the end-to-end MAC ICV in the IntegrityCheckValue field of the IPlir message are implemented as per GOST R 34.12–2015 (Magma) [RFC8891] in the MGM mode [RFC9058], wherein¶
the value of IV_AEAD \in V_63 is used as the initial counter nonce:¶
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 as per | +------+ | in the MGM mode |
| ISO/IEC 9797-1:2011 [ISO9797-1] | | [RFC9058] |
+---------------------------------+ +-------------------+
^ | |
| | |
+-----------------------+ | |
| Exchange key between | | |
| source and destination| | |
| hosts | | |
+-----------------------+ | |
| |
+-----------------------------------+ | |
| IPlir header | | |
| ... | | |
| +---------------------------+ | | |
| | SourceIdentifier | | | |
| +---------------------------+ | | |
| ... | | |
| +---------------------------+ | | |
| | SequenceNumber | | | |
| +---------------------------+ | | |
| | InitValue | | | |
| +---------------------------+ | | |
+-----------------------------------+ | |
| Encrypted IPlir body |<--+ |
+-----------------------------------+ |
| IPlir trailer | |
| +---------------------------+ | |
| | IntegrityCheckValue |<-----------+
| +---------------------------+ |
| ... |
+-----------------------------------+
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue field of the IPlir message is implemented as per the GOST R 34.12–2015 (Magma) [RFC8891] in the MGM mode [RFC9058], wherein¶
the value of TIV_AEAD \in V_63 is used as the initial counter nonce:¶
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 as per | +------+ | in the MGM mode |
| ISO/IEC 9797-1:2011 [ISO9797-1] | | [RFC9058] |
+---------------------------------+ +-------------------+
^ | |
| v |
+-----------------------+ +------+ |
| Exchange key between | | null | |
| transit hosts | +------+ |
+-----------------------+ |
|
+------------------------------------+ |
| IPlir header | |
| ... | |
| +----------------------------+ | |
| | SequenceNumber | | |
| +----------------------------+ | |
| ... | |
+------------------------------------+ |
| Encrypted IPlir body | |
+------------------------------------+ |
| IPlir trailer | |
| ... | |
| +----------------------------+ | |
| | TransitIdentifier | | |
| +----------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +----------------------------+ | |
| | TransitIntegrityCheckValue |<----------+
| +----------------------------+ |
+------------------------------------+
KUZN-CTR-CMAC Cryptographic Suite Description is shown in Table 6:¶
| Parameter | Value |
|---|---|
| EncAlg | GOST R 34.12-2015 (Kuznyechik) [RFC7801] in the CTR mode [ISO10116] |
| MACAlg | GOST R 34.12-2015 (Kuznyechik) [RFC7801] in the CMAC mode [ISO9797-1] |
| TMACAlg | GOST R 34.12-2015 (Kuznyechik) [RFC7801] in the CMAC mode [ISO9797-1] |
| MACLen | 64 bits |
| TMACLen | 64 bits |
| IVLen | 64 bits |
| TIVLen | 64 bits |
| KDAlg | see the description below |
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.¶
The end-to-end initialization 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 source host using the same exchange key.¶
The transit initialization 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 exchange key.¶
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 as per ISO/IEC 9797-1:2011 [ISO9797-1], wherein¶
a binary string as shown below is used as the data: IntToVec_8(i)||Label||aL||IV_KDF||SN||Node||cL||oL, where¶
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 as per ISO/IEC 9797-1:2011 [ISO9797-1], wherein¶
a binary string as shown below is used as the data: IntToVec_8(i)||Label||aL||TIV_KDF||SN||Node||cL||oL, where¶
The IPlir body is encrypted as per the GOST R 34.12-2015 (Kuznyechik) [RFC7801] in the CTR mode as per ISO/IEC 10116:2017 [ISO10116] without padding, wherein¶
the value of SV \in V_128 is used as the initialization value:¶
Calculation of the end-to-end MAC ICV in the IntegrityCheckValue field of the IPlir message is implemented as per the GOST R 34.12-2015 (Kuznyechik) [RFC7801] in the CMAC mode as per ISO/IEC 9797-1:2011 [ISO9797-1], wherein¶
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 as per | | [RFC7801] in the |
| ISO/IEC 9797-1:2011 [ISO9797-1] | +------+ | CTR mode |
| |->|K_MAC | | [ISO10116] |
+---------------------------------+ +------+ +-------------------+
^ | |
| v |
+-----------------------+ +-------------------+ |
| Exchange key between | | GOST R 34.12-2015 | |
| source and destination| +---| (Kuznyechik) | |
| hosts | | | [RFC7801] in the | |
+-----------------------+ | | CMAC mode | |
| | [ISO9797-1] | |
| +-------------------+ |
+-----------------------+ ^ |
| | |
| +---------------------------------+ |
| | |
| | +---+-----------------------------------+ |
| | | | IPlir header | |
| | | | ... | |
| | | | +---------------------------+ | |
| | | | | SourceIdentifier | | |
| | | | +---------------------------+ | |
| | | | ... | |
| +---| | +---------------------------+ | |
| | | | SequenceNumber | | |
| | | +---------------------------+ | |
| | | | InitValue | | |
| | | +---------------------------+ | |
| | +-----------------------------------+ |
| | | Encrypted IPlir body |<---+
| +---+-----------------------------------+
| | IPlir trailer |
| | +---------------------------+ |
+-------------->| IntegrityCheckValue | |
| +---------------------------+ |
| ... |
+-----------------------------------+
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue field of the IPlir message is implemented as per the GOST R 34.12-2015 (Kuznyechik) [RFC7801] in the CMAC mode as per ISO/IEC 9797-1:2011 [ISO9797-1], wherein¶
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 as per | +------+ | [RFC7801] in the |
| ISO/IEC 9797-1:2011 [ISO9797-1] | | CMAC mode |
+---------------------------------+ | [ISO9797-1] +
^ +-------------------+
| |
| |
+----------------------+ |
| Exchange key between | |
| transit hosts | |
+----------------------+ |
|
+------------------------------------+ |
| IPlir header | |
| ... | |
| +----------------------------+ | |
| | SequenceNumber | | |
| +----------------------------+ | |
| ... | |
+------------------------------------+ |
| Encrypted IPlir body | |
+------------------------------------+ |
| IPlir trailer | |
| ... | |
| +----------------------------+ | |
| | TransitIdentifier | | |
| +----------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +----------------------------+ | |
| | TransitIntegrityCheckValue |<------+
| +----------------------------+ |
+------------------------------------+
AES-128-GCM Cryptographic Suite Description is shown in Table 7:¶
| Parameter | Value |
|---|---|
| EncAlg | AES-128 [ISO18033-3] in the GCM mode [ISO19772] |
| MACAlg | AES-128 [ISO18033-3] in the GCM mode [ISO19772] |
| TMACAlg | AES-128 [ISO18033-3] in the GCM mode [ISO19772] |
| MACLen | 64 bits |
| TMACLen | 64 bits |
| IVLen | 96 bits |
| TIVLen | 96 bits |
| KDAlg | see the description below |
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.¶
The end-to-end initialization 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 source host using the same exchange key.¶
The transit initialization 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 exchange key.¶
The packet encryption and end-to-end MAC key K_AEAD of 128 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 using AES-128 [ISO18033-3] in the CMAC mode [RFC4493] as the PRF, wherein¶
a binary string as shown below is used as the input data for the PRF: IntToVec_8(1)||Label||aL||IV_KDF||SN||Node||cL||oL, where¶
The packet transit MAC key K_TMAC of 128 bit length is calculated as follows:¶
K_TMAC = K_1,¶
where value of K_1 \in V_128 is calculated as per KDF in Counter Mode using AES-128 [ISO18033-3] in the CMAC mode [RFC4493] as the PRF, wherein¶
a binary string as shown below is used as the input data for the PRF: IntToVec_8(1)||Label||aL||TIV_KDF||SN||Node||cL||oL, where¶
Encryption of the IPlir body and calculation of the end-to-end MAC ICV in the IntegrityCheckValue field of the IPlir message are implemented as per the AES-128 [ISO18033-3] in the GCM mode [ISO19772], wherein¶
the value of IV_AEAD \in V_96 is used as initialization vector:¶
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|->| [ISO18033-3] |
| AES-128 [ISO18033-3] in the | +------+ | in the GCM mode |
| CMAC mode [RFC4493] | | [ISO19772] |
+---------------------------------+ +-------------------+
^ | |
| | |
+-----------------------+ | |
| Exchange key between | | |
| source and destination| | |
| hosts | | |
+-----------------------+ | |
| |
+-----------------------------------+ | |
| IPlir header | | |
| ... | | |
| +---------------------------+ | | |
| | SourceIdentifier | | | |
| +---------------------------+ | | |
| ... | | |
| +---------------------------+ | | |
| | SequenceNumber | | | |
| +---------------------------+ | | |
| | InitValue | | | |
| +---------------------------+ | | |
+-----------------------------------+ | |
| Encrypted IPlir body |<--+ |
+-----------------------------------+ |
| IPlir trailer | |
| +---------------------------+ | |
| | IntegrityCheckValue |<-----------+
| +---------------------------+ |
| ... |
+-----------------------------------+
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue field of the IPlir message is implemented as per the AES-128 [ISO18033-3] in the GCM mode [ISO19772], wherein¶
the value of TIV_AEAD \in V_96 is used as initialization vector:¶
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|->| [ISO18033-3] |
| AES-128 [ISO18033-3] in the | +------+ | in the GCM mode |
| CMAC mode [RFC4493] | | [ISO19772] |
+---------------------------------+ +-------------------+
^ | |
| v |
+-----------------------+ +------+ |
| Exchange key between | | null | |
| transit hosts | +------+ |
+-----------------------+ |
|
+------------------------------------+ |
| IPlir header | |
| ... | |
| +----------------------------+ | |
| | SequenceNumber | | |
| +----------------------------+ | |
| ... | |
+------------------------------------+ |
| Encrypted IPlir body | |
+------------------------------------+ |
| IPlir trailer | |
| ... | |
| +----------------------------+ | |
| | TransitIdentifier | | |
| +----------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +----------------------------+ | |
| | TransitIntegrityCheckValue |<----------+
| +----------------------------+ |
+------------------------------------+
AES-256-CTR-CMAC Cryptographic Suite Description is shown in Table 8:¶
| Parameter | Value |
|---|---|
| EncAlg | AES-256 [ISO18033-3] in the CTR mode [ISO10116] |
| MACAlg | AES-256 [ISO18033-3] in the CMAC mode [RFC4493] |
| TMACAlg | AES-256 [ISO18033-3] in the CMAC mode [RFC4493] |
| MACLen | 64 bits |
| TMACLen | 64 bits |
| IVLen | 64 bits |
| TIVLen | 64 bits |
| KDAlg | see the description below |
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.¶
The end-to-end initialization 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 source host using the same exchange key.¶
The transit initialization 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 exchange key.¶
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 using AES-256 [ISO18033-3] in the CMAC mode [RFC4493] as the PRF, wherein¶
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¶
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 using AES-256 [ISO18033-3] in the CMAC mode [RFC4493] as the PRF, wherein¶
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¶
The IPlir body is encrypted as per the AES-256 [ISO18033-3] in the CTR mode as per ISO/IEC 10116:2017[ISO10116] without padding, wherein¶
the values of CTR_i \in V_128 are used as counters in CTR mode:¶
Calculation of the end-to-end MAC ICV in the IntegrityCheckValue field of the IPlir message is implemented as per the AES-256 [ISO18033-3] in the CMAC mode [RFC4493], wherein¶
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 | +------+ | [ISO18033-3] |
| AES-256 [ISO18033-3] in the | | in the CTR mode |
| CMAC mode [RFC4493] | +------+ | [ISO10116] |
| |->|K_MAC | | |
+---------------------------------+ +------+ +-------------------+
^ | |
| v |
+-----------------------+ +-------------------+ |
| Exchange key between | | AES-256 | |
| source and destination| +---| [ISO18033-3] | |
| hosts | | | in the CMAC mode | |
+-----------------------+ | | [RFC4493] | |
| +-------------------+ |
+-----------------------+ ^ |
| | |
| +---------------------------------+ |
| | |
| | +---+-----------------------------------+ |
| | | | IPlir header | |
| | | | ... | |
| | | | +---------------------------+ | |
| | | | | SourceIdentifier | | |
| | | | +---------------------------+ | |
| | | | ... | |
| +---| | +---------------------------+ | |
| | | | SequenceNumber | | |
| | | +---------------------------+ | |
| | | | InitValue | | |
| | | +---------------------------+ | |
| | +-----------------------------------+ |
| | | Encrypted IPlir body |<---+
| +---+-----------------------------------+
| | IPlir trailer |
| | +---------------------------+ |
+-------------->| IntegrityCheckValue | |
| +---------------------------+ |
| ... |
+-----------------------------------+
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue field of the IPlir message is implemented as per the AES-256 [ISO18033-3] in the CMAC mode [RFC4493], wherein¶
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|->| [ISO18033-3] |
| AES-256 [ISO18033-3] in the | +------+ | in the CMAC mode |
| CMAC mode [RFC4493] | | [RFC4493] |
+---------------------------------+ +-------------------+
^ |
| |
+-----------------------+ |
| Exchange key between | |
| transit hosts | |
+-----------------------+ |
|
+------------------------------------+ |
| IPlir header | |
| ... | |
| +----------------------------+ | |
| | SequenceNumber | | |
| +----------------------------+ | |
| ... | |
+------------------------------------+ |
| Encrypted IPlir body | |
+------------------------------------+ |
| IPlir trailer | |
| ... | |
| +----------------------------+ | |
| | TransitIdentifier | | |
| +----------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +----------------------------+ | |
| | TransitIntegrityCheckValue |<------+
| +----------------------------+ |
+------------------------------------+
AES-256-CTR-CMAC Cryptographic Suite Description is shown in Table 9:¶
| Parameter | Value |
|---|---|
| EncAlg | AES-256 [ISO18033-3] in the CFB mode [ISO10116] |
| MACAlg | AES-256 [ISO18033-3] in the CMAC mode [RFC4493] |
| TMACAlg | AES-256 [ISO18033-3] in the CMAC mode [RFC4493] |
| MACLen | 64 bits |
| TMACLen | 64 bits |
| IVLen | 128 bits |
| TIVLen | 64 bits |
| KDAlg | see the description below |
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.¶
The end-to-end initialization value InitValue in the InitValue field of the IPlir message should have a length of 128 bits and be random.¶
The transit initialization 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 exchange key.¶
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 using AES-256 [ISO18033-3] in the CMAC mode [RFC4493] as the PRF, wherein¶
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¶
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 using AES-256 [ISO18033-3] in the CMAC mode [RFC4493] as the PRF, wherein¶
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¶
The IPlir body is encrypted as per the AES-256 [ISO18033-3] in the CFB mode as per ISO/IEC 10116:2017 [ISO10116], wherein¶
the value of SV \in V_128 is used as the initialization value:¶
Calculation of the end-to-end MAC ICV in the IntegrityCheckValue field of the IPlir message is implemented as per the AES-256 [ISO18033-3] in the CMAC mode [RFC4493], wherein¶
The diagram of encryption and end-to-end MAC is shown in Figure 16.¶
+-----------------------------------+
| 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 | +------+ | [ISO18033-3] |
| AES-256 [ISO18033-3] in the | | in the CFB mode |
| CMAC mode [RFC4493] | +------+ | [ISO10116] |
| |->|K_MAC | | |
+---------------------------------+ +------+ +-------------------+
^ | |
| v |
+-----------------------+ +-------------------+ |
| Exchange key between | | AES-256 | |
| source and destination| +---| [ISO18033-3] | |
| hosts | | | in the CMAC mode | |
+-----------------------+ | | [RFC4493] | |
| +-------------------+ |
+-----------------------+ ^ |
| | |
| +---------------------------------+ |
| | |
| | +---+-----------------------------------+ |
| | | | IPlir header | |
| | | | ... | |
| | | | +---------------------------+ | |
| | | | | SourceIdentifier | | |
| | | | +---------------------------+ | |
| | | | ... | |
| +---| | +---------------------------+ | |
| | | | SequenceNumber | | |
| | | +---------------------------+ | |
| | | | InitValue | | |
| | | +---------------------------+ | |
| | +-----------------------------------+ |
| | | Encrypted IPlir body |<---+
| +---+-----------------------------------+
| | IPlir trailer |
| | +---------------------------+ |
+-------------->| IntegrityCheckValue | |
| +---------------------------+ |
| ... |
+-----------------------------------+
Calculation of the transit MAC TICV in the TransitIntegrityCheckValue field of the IPlir message is implemented as per the AES-256 [ISO18033-3] in the CMAC mode [RFC4493], wherein¶
The diagram of transit MAC is shown in Figure 17.¶
+-----------------------------------+--+
| 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|->| [ISO18033-3] |
| AES-256 [ISO18033-3] in the | +------+ | in the CMAC mode |
| CMAC mode [RFC4493] | | [RFC4493] |
+---------------------------------+ +-------------------+
^ |
| |
+----------------------+ |
| Exchange key between | |
| transit hosts | |
+----------------------+ |
|
+------------------------------------+ |
| IPlir header | |
| ... | |
| +----------------------------+ | |
| | SequenceNumber | | |
| +----------------------------+ | |
| ... | |
+------------------------------------+ |
| Encrypted IPlir body | |
+------------------------------------+ |
| IPlir trailer | |
| ... | |
| +----------------------------+ | |
| | TransitIdentifier | | |
| +----------------------------+ | |
| | | | |
| | TransitInitValue | | |
| | | | |
| +----------------------------+ | |
| | TransitIntegrityCheckValue |<------+
| +----------------------------+ |
+------------------------------------+
The algorithms used for cryptographic processing of network packets are determined by the cryptographic suite for .¶
The cryptographic suite for protection of the original IP packet is chosen depending on the corresponding security policy of the source host and the destination host context on the source host. The logic and procedure of processing IPlir packets protected using a certain cryptographic suite depend on the IPlir packet reception policy and the source host context on the destination host. The necessity and procedure of using transit MAC are determined based on the source host security policy and IPlir packet reception policies of transit hosts and the destination host.¶
Depending on security policies and other requirements, protection of the destination host or transit host against replay of previously transmitted IPlir packets 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 destination 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.¶
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 destination or transit host, the IPlir packet must be defragmented.¶
If the source host decides to protect a specific IP packet, an IPlir packet is created as follows:¶
The destination and transit hosts contexts along with the applied security policy determine:¶
Based on the destination and transit hosts contexts along with the cryptographic suite:¶
After receiving an IPlir packet, the transit host processes the IPlir packet as follows:¶
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:¶
After receiving the IPlir packet, the destination host recovers the original IP packet as follows:¶
There may be cases when the security policies do not require transit MAC checking by the destination host. Then steps 3, 4 of the algorithm are skipped.¶
This document has no IANA actions.¶