IPlir network layer security protocol

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.

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 when, and only when, they appear in all capitals, as shown here.

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, 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, 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.

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 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 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 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, 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 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 MAC. The field is available, if T = 1. The field length is determined by the used cryptographic suite TransitIntegrityCheckValue (TICV) a transit MAC calculated for the 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

The IPlir packet structure 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 source IP packet and plaintext data required for IPlir packet processing.

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; IPlir trailer containing MACs, the transit host identifier, and the transit initializing value. 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 | +---+---------------+---------------+-------------------------------+ | | 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) | +---+---------------------------------------------------------------+ 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.

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 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.

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. 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) | | | +------+--------------+--------------+--------------+--------------+ 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 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.

+------+--------------+--------------+--------------+--------------+ |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) | | | +------+--------------+--------------+--------------+--------------+ Note: Bytes labeled “not in use” contain information related to the following tuple.

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. Mode field value Mode description 0 transport mode 1 light tunnel mode (“light tunnel”) 2 tunnel mode (“tunnel” mode) 3 reserved for future needs

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 | | | +--------------------+ | +--------------------------+ 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 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.

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.

+--------------------------+ +------------------------------+ | 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 | | | +------------------------+ | +------------------------------+

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.

+-------------------------+ +--------------------------+ | Source IP packet | | IPlir packet | | +-------------------+ | | +--------------------+ | | | IP header |-------+ | | IP header | | | +-------------------+ | | | +--------------------+ | | | IP packet data |----+ | | | IPlir header | | | +-------------------+ | | | | +--------------------+ | +-------------------------+ | | | | IPlir body | | | | | | +----------------+ | | | +----->| IP header | | | | | | +----------------+ | | +-------->| IP packet data | | | | | +----------------+ | | | +--------------------+ | | | IPlir trailer | | | +--------------------+ | +--------------------------+

Possible values of function arguments in the algorithms above are limited by whether they can be used as conversion input parameters.

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.

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. 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 defined and/or described 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 initializing value length the initializing 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 initializing value length the initializing 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 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.

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

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.

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. 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.

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: 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.

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, 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 | | | | source and destination| | | | hosts | | | +-----------------------+ | | | | +-----------------------------------+ | | | IPlir header | | | | ... | | | | +---------------------------+ | | | | | SourceIdentifier | | | | | +---------------------------+ | | | | ... | | | | +---------------------------+ | | | | | SequenceNumber | | | | | +---------------------------+ | | | | | InitValue | | | | | +---------------------------+ | | | +-----------------------------------+ | | | Encrypted IPlir body |<--+ | +-----------------------------------+ | | IPlir trailer | | | +---------------------------+ | | | | InterityCheckValue |<-----------+ | +---------------------------+ | | ... | +-----------------------------------+ 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, 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 | | | ... | | | +---------------------------+ | | | | SequenceNumber | | | | +---------------------------+ | | | ... | | +-----------------------------------+ | | Encrypted IPlir body | | +-----------------------------------+ | | IPlir trailer | | | ... | | | +---------------------------+ | | | | TransitIdentifier | | | | +---------------------------+ | | | | | | | | | TransitInitValue | | | | | | | | | +---------------------------+ | | | | TransitInterityCheckValue |<-----------+ | +---------------------------+ | +-----------------------------------+

AES-256-CTR-CMAC Cryptographic Suite Description: 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

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.

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. 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.

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, 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 | | |->|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 | | | +---------------------------+ | | ... | +-----------------------------------+ 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, 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 | | | ... | | | +---------------------------+ | | | | SequenceNumber | | | | +---------------------------+ | | | ... | | +-----------------------------------+ | | Encrypted IPlir body | | +-----------------------------------+ | | IPlir trailer | | | ... | | | +---------------------------+ | | | | TransitIdentifier | | | | +---------------------------+ | | | | | | | | | TransitInitValue | | | | | | | | | +---------------------------+ | | | | TransitInterityCheckValue |<-------+ | +---------------------------+ | +-----------------------------------+

AES-128-GCM Cryptographic Suite Description: 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

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.

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. 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.

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: 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.

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, 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 | | | | source and destination| | | | hosts | | | +-----------------------+ | | | | +-----------------------------------+ | | | IPlir header | | | | ... | | | | +---------------------------+ | | | | | SourceIdentifier | | | | | +---------------------------+ | | | | ... | | | | +---------------------------+ | | | | | SequenceNumber | | | | | +---------------------------+ | | | | | InitValue | | | | | +---------------------------+ | | | +-----------------------------------+ | | | Encrypted IPlir body |<--+ | +-----------------------------------+ | | IPlir trailer | | | +---------------------------+ | | | | InterityCheckValue |<-----------+ | +---------------------------+ | | ... | +-----------------------------------+ 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, 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 | | | ... | | | +---------------------------+ | | | | SequenceNumber | | | | +---------------------------+ | | | ... | | +-----------------------------------+ | | Encrypted IPlir body | | +-----------------------------------+ | | IPlir trailer | | | ... | | | +---------------------------+ | | | | TransitIdentifier | | | | +---------------------------+ | | | | | | | | | TransitInitValue | | | | | | | | | +---------------------------+ | | | | TransitInterityCheckValue |<-----------+ | +---------------------------+ | +-----------------------------------+

AES-256-CTR-CMAC Cryptographic Suite Description: 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

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. 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.

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, 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 | | | +---------------------------------+ +------+ +-------------------+ ^ | | | 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 | | | +---------------------------+ | | ... | +-----------------------------------+ 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 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 | | | | +---------------------------+ | | | ... | | +-----------------------------------+ | | Encrypted IPlir body | | +-----------------------------------+ | | IPlir trailer | | | ... | | | +---------------------------+ | | | | TransitIdentifier | | | | +---------------------------+ | | | | | | | | | TransitInitValue | | | | | | | | | +---------------------------+ | | | | TransitInterityCheckValue |<-------+ | +---------------------------+ | +-----------------------------------+

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

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.

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_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, 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.

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 | | | | +---------------------------+ | | | ... | | | +---------------------------+ | +--------| 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 |<---+ | +---+-----------------------------------+ | | IPlir trailer | | | +---------------------------+ | +-------------->| InterityCheckValue | | | +---------------------------+ | | ... | +-----------------------------------+ 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 +---------------------------------+ +-------------------+ | 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 |<-------+ | +---------------------------+ | +-----------------------------------+

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 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.

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.

If the sender host decides to protect a specific IP packet, an IPlir packet is created as follows. 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, 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, The IPlir packet fields are filled in considering the data from the source IP packet and the data generated previously. 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. 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. An IPlir packet is generated, wherein parts of the source IP packet are located according to the rules specified in Section 4.4.

After receiving an IPlir packet, the transit host processes the IPlir packet as follows. 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. If the IPlir version in the IPlir header is not supported by the host, the packet is blocked. 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. If the suite from the IPlir header does not imply transit MAC, the packet is blocked. 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. 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. If the found context contains cryptographic suites not matching the set from the IPlir header, the packet is blocked. 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. The transit MAC value is calculated and placed in the corresponding field of the IPlir trailer. 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.

After receiving the IPlir packet, the recipient host restores the source IP packet as follows. 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. If the IPlir version in the IPlir header is not supported by the host, the packet is blocked. 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. 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. 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. 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. 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. 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.

This document has no IANA actions.