JNX-GDOI-MIB

JnxGdoiIdentificationType1 = ipv4Address2 = domainName3 = userName4 = ipv4Subnet5 = ipv6Address6 = ipv6Subnet7 = ipv4Range8 = ipv6Range9 = caDistinguishedName10 = caGeneralName11 = groupNumberA textual convention indicating the type of value used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). Following are the Identification Type Values: ID Type Value ------- ----- RESERVED 0 -- Not Used ID_IPV4_ADDR 1 -- ipv4Address ID_FQDN 2 -- domainName ID_RFC822_ADDR 3 -- userName (ID_USER_FQDN) ID_IPV4_ADDR_SUBNET 4 -- ipv4Subnet - Not in RFC 4306 ID_IPV6_ADDR 5 -- ipv6Address ID_IPV6_ADDR_SUBNET 6 -- ipv6Subnet - Not in RFC 4306 ID_IPV4_ADDR_RANGE 7 -- ipv4Range - Not in RFC 4306 ID_IPV6_ADDR_RANGE 8 -- ipv6Range - Not in RFC 4306 ID_DER_ASN1_DN 9 -- caDistinguishedName ID_DER_ASN1_GN 10 -- caGeneralName ID_KEY_ID 11 -- groupNumber Following are the mappings to the type values above: 'ipv4Address' : a single four (4) octet IPv4 address. 'domainName' : a fully-qualified domain name string. An example is, 'example.com'. The string MUST not contain any terminators (e.g., NULL, CR, etc.). 'userName' : a fully-qualified RFC 822 username or email address string. An example is, 'jsmith@example.com'. The string MUST not contain any terminators. 'ipv4Subnet' : a range of IPv4 addresses, represented by two four (4) octet values concatenated together. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv6Address' : a single sixteen (16) octet IPv6 address. 'ipv6Subnet' : a range of IPv6 addresses, represented by two sixteen (16) octet values concatenated together. The first value is an IPv6 address. The second is an IPv network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv4Range' : a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'ipv6Range' : a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'caDistinguishedName' : the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]. 'caGeneralName' : the binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 'groupNumber' : a four (4) octet group identifier.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads · Integer32

Reference: RFC 3547 - Sections: 5.1.1. Identification Type Values 5.1.1.1. ID_KEY_ID RFC 4306 - Section: 3.5. Identification Payloads

The Identification Type Value used to parse a GDOI Group ID. The GDOI RFC 3547 defines the types that can be used as a GDOI Group ID, and RFC 4306 defines all valid types that can be used as an identifier. This Group ID type is sent as the 'ID Type' field of the Identification Payload for a GDOI GROUPKEY-PULL exchange.

Unsigned32 · Octets

Reference: RFC 3547 - Sections: 5.1.1. Identification Type Values 5.1.1.1. ID_KEY_ID RFC 4306 - Section: 3.5. Identification Payloads

The length (i.e. number of octets) of a Group ID. If no length is given (i.e. it has a value of 0), the default length of its jnxGdoiGroupIdType should be used as long as it is not reprsented by an ASCII string. If the value has a type that is represented by an ASCII string, a length MUST be included. If the length given is not 0, it should match the 'Payload Length' (subtracting the generic header length) of the Identification Payload for a GDOI GROUPKEY-PULL exchange.

JnxGdoiIdentificationValueA textual convention indicating the actual value of used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). The value of the JnxGdoiIdentificationValue object can be parsed based on the value of the associated JnxGdoiIdentificationType object. The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as a binary string of octets with the given lengths if a length is not associated with the object: ipv4Address(1) -- 4 octets ipv4Subnet(4) -- 8 octets ipv6Address(5) -- 16 octets ipv6Subnet(6) -- 32 octets ipv4Range(7) -- 8 octets ipv6Range(8) -- 32 octets groupNumber(11) -- 4 octets The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as an ASCII string of characters. Note that a length MUST be associated with the object in these cases: domainName(2) userName(3) caDistinguishedName(9) caGeneralName(10) Note that the length of 48 octets was chosen because the gdoiKsKekEntry, gdoiGmKekEntry, gdoiKsTekEntry, & gdoiGmTekEntry will exceed the OID size limit of 255 octets if this size is any larger than 48 octets.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads SIZE (0..48) · OCTET STRING · hint 255d

Reference: RFC 3547 - Sections: 5.1.1. Identification Type Values 5.1.1.1. ID_KEY_ID RFC 4306 - Section: 3.5. Identification Payloads

The value of a Group ID with its type indicated by the jnxGdoiGroupIdType. Use the jnxGdoiGroupIdType to parse the Group ID correctly. This Group ID value is sent as the 'Identification Data' field of the Identification Payload for a GDOI GROUPKEY-PULL exchange.

DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a

The string-readable name configured for or given to a GDOI Group.

JnxGdoiIdentificationType1 = ipv4Address2 = domainName3 = userName4 = ipv4Subnet5 = ipv6Address6 = ipv6Subnet7 = ipv4Range8 = ipv6Range9 = caDistinguishedName10 = caGeneralName11 = groupNumberA textual convention indicating the type of value used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). Following are the Identification Type Values: ID Type Value ------- ----- RESERVED 0 -- Not Used ID_IPV4_ADDR 1 -- ipv4Address ID_FQDN 2 -- domainName ID_RFC822_ADDR 3 -- userName (ID_USER_FQDN) ID_IPV4_ADDR_SUBNET 4 -- ipv4Subnet - Not in RFC 4306 ID_IPV6_ADDR 5 -- ipv6Address ID_IPV6_ADDR_SUBNET 6 -- ipv6Subnet - Not in RFC 4306 ID_IPV4_ADDR_RANGE 7 -- ipv4Range - Not in RFC 4306 ID_IPV6_ADDR_RANGE 8 -- ipv6Range - Not in RFC 4306 ID_DER_ASN1_DN 9 -- caDistinguishedName ID_DER_ASN1_GN 10 -- caGeneralName ID_KEY_ID 11 -- groupNumber Following are the mappings to the type values above: 'ipv4Address' : a single four (4) octet IPv4 address. 'domainName' : a fully-qualified domain name string. An example is, 'example.com'. The string MUST not contain any terminators (e.g., NULL, CR, etc.). 'userName' : a fully-qualified RFC 822 username or email address string. An example is, 'jsmith@example.com'. The string MUST not contain any terminators. 'ipv4Subnet' : a range of IPv4 addresses, represented by two four (4) octet values concatenated together. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv6Address' : a single sixteen (16) octet IPv6 address. 'ipv6Subnet' : a range of IPv6 addresses, represented by two sixteen (16) octet values concatenated together. The first value is an IPv6 address. The second is an IPv network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv4Range' : a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'ipv6Range' : a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'caDistinguishedName' : the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]. 'caGeneralName' : the binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 'groupNumber' : a four (4) octet group identifier.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads · Integer32

Reference: RFC 3547 - Sections: 5.3. SA KEK payload 5.4.1. PROTO_IPSEC_ESP RFC 4306 - Section: 3.5. Identification Payloads

The Identification Type Value used to parse the identity information for a Initiator or Group Member. RFC 4306 defines all valid types that can be used as an identifier. These identification types are sent as the 'SRC ID Type' and 'DST ID Type' of the KEK and TEK payloads for GDOI GROUPKEY-PULL and GROUPKEY-PUSH exchanges.

Unsigned32 · Octets

Reference: RFC 3547 - Sections: 5.3. SA KEK payload 5.4.1. PROTO_IPSEC_ESP

The length (i.e. number of octets) of a Group Member ID. If no length is given (i.e. it has a value of 0), the default length of its jnxGdoiGmIdType should be used as long as it is not reprsented by an ASCII string. If the value has a type that is represented by an ASCII string, a length MUST be included. If the length given is not 0, it should match the 'SRC ID Data Len' and 'DST ID Data Len' fields sent in the KEK and TEK payloads for GDOI GROUPKEY-PULL and GROUPKEY-PUSH exchanges.

JnxGdoiIdentificationValueA textual convention indicating the actual value of used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). The value of the JnxGdoiIdentificationValue object can be parsed based on the value of the associated JnxGdoiIdentificationType object. The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as a binary string of octets with the given lengths if a length is not associated with the object: ipv4Address(1) -- 4 octets ipv4Subnet(4) -- 8 octets ipv6Address(5) -- 16 octets ipv6Subnet(6) -- 32 octets ipv4Range(7) -- 8 octets ipv6Range(8) -- 32 octets groupNumber(11) -- 4 octets The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as an ASCII string of characters. Note that a length MUST be associated with the object in these cases: domainName(2) userName(3) caDistinguishedName(9) caGeneralName(10) Note that the length of 48 octets was chosen because the gdoiKsKekEntry, gdoiGmKekEntry, gdoiKsTekEntry, & gdoiGmTekEntry will exceed the OID size limit of 255 octets if this size is any larger than 48 octets.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads SIZE (0..48) · OCTET STRING · hint 255d

Reference: RFC 3547 - Sections: 5.3. SA KEK payload 5.4.1. PROTO_IPSEC_ESP

The value of the identity information for a Group Member with its type indicated by the jnxGdoiGmIdType. Use the jnxGdoiGmIdType to parse the Group Member ID correctly. This Group Member ID value is sent as the 'SRC Identification Data' and 'DST Identification Data' of the KEK and TEK payloads for GDOI GROUPKEY-PULL and GROUPKEY-PUSH exchanges.

JnxGdoiIdentificationType1 = ipv4Address2 = domainName3 = userName4 = ipv4Subnet5 = ipv6Address6 = ipv6Subnet7 = ipv4Range8 = ipv6Range9 = caDistinguishedName10 = caGeneralName11 = groupNumberA textual convention indicating the type of value used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). Following are the Identification Type Values: ID Type Value ------- ----- RESERVED 0 -- Not Used ID_IPV4_ADDR 1 -- ipv4Address ID_FQDN 2 -- domainName ID_RFC822_ADDR 3 -- userName (ID_USER_FQDN) ID_IPV4_ADDR_SUBNET 4 -- ipv4Subnet - Not in RFC 4306 ID_IPV6_ADDR 5 -- ipv6Address ID_IPV6_ADDR_SUBNET 6 -- ipv6Subnet - Not in RFC 4306 ID_IPV4_ADDR_RANGE 7 -- ipv4Range - Not in RFC 4306 ID_IPV6_ADDR_RANGE 8 -- ipv6Range - Not in RFC 4306 ID_DER_ASN1_DN 9 -- caDistinguishedName ID_DER_ASN1_GN 10 -- caGeneralName ID_KEY_ID 11 -- groupNumber Following are the mappings to the type values above: 'ipv4Address' : a single four (4) octet IPv4 address. 'domainName' : a fully-qualified domain name string. An example is, 'example.com'. The string MUST not contain any terminators (e.g., NULL, CR, etc.). 'userName' : a fully-qualified RFC 822 username or email address string. An example is, 'jsmith@example.com'. The string MUST not contain any terminators. 'ipv4Subnet' : a range of IPv4 addresses, represented by two four (4) octet values concatenated together. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv6Address' : a single sixteen (16) octet IPv6 address. 'ipv6Subnet' : a range of IPv6 addresses, represented by two sixteen (16) octet values concatenated together. The first value is an IPv6 address. The second is an IPv network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv4Range' : a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'ipv6Range' : a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'caDistinguishedName' : the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]. 'caGeneralName' : the binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 'groupNumber' : a four (4) octet group identifier.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads · Integer32

Reference: RFC 3547 - Sections: 5.3. SA KEK payload 5.4.1. PROTO_IPSEC_ESP RFC 4306 - Section: 3.5. Identification Payloads

The Identification Type Value used to parse the identity information of this Group Member's registered Key Server. RFC 4306 defines all valid types that can be used as an identifier. These identification types are sent as the 'SRC ID Type' and 'DST ID Type' of the KEK and TEK payloads for GDOI GROUPKEY-PULL and GROUPKEY-PUSH exchanges.

Unsigned32 · Octets

Reference: RFC 3547 - Sections: 5.3. SA KEK payload 5.4.1. PROTO_IPSEC_ESP

The length (i.e. number of octets) of the registered Key Server's ID. If no length is given (i.e. it has a value of 0), the default length of its jnxGdoiGmRegKeyServerIdType should be used as long as it is not reprsented by an ASCII string. If the value has a type that is represented by an ASCII string, a length MUST be included. If the length given is not 0, it should match the 'SRC ID Data Len' and 'DST ID Data Len' fields sent in the KEK and TEK payloads for GDOI GROUPKEY-PULL and GROUPKEY-PUSH exchanges.

JnxGdoiIdentificationValueA textual convention indicating the actual value of used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). The value of the JnxGdoiIdentificationValue object can be parsed based on the value of the associated JnxGdoiIdentificationType object. The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as a binary string of octets with the given lengths if a length is not associated with the object: ipv4Address(1) -- 4 octets ipv4Subnet(4) -- 8 octets ipv6Address(5) -- 16 octets ipv6Subnet(6) -- 32 octets ipv4Range(7) -- 8 octets ipv6Range(8) -- 32 octets groupNumber(11) -- 4 octets The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as an ASCII string of characters. Note that a length MUST be associated with the object in these cases: domainName(2) userName(3) caDistinguishedName(9) caGeneralName(10) Note that the length of 48 octets was chosen because the gdoiKsKekEntry, gdoiGmKekEntry, gdoiKsTekEntry, & gdoiGmTekEntry will exceed the OID size limit of 255 octets if this size is any larger than 48 octets.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads SIZE (0..48) · OCTET STRING · hint 255d

Reference: RFC 3547 - Sections: 5.3. SA KEK payload 5.4.1. PROTO_IPSEC_ESP

The value of the identity information for this Group Member's registered Key Server with its type indicated by the jnxGdoiGmRegKeyServerIdType. Use the jnxGdoiGmRegKeyServerIdType to parse the registered Key Server's ID correctly. This Key Server ID value is sent as the 'SRC Identification Data' and 'DST Identification Data' of the KEK and TEK payloads for GDOI GROUPKEY-PULL and GROUPKEY-PUSH exchanges.

JnxGdoiKekSPIA textual convention indicating a SPI (Security Parameter Index) of sixteen (16) octets for a KEK. The SPI must be the ISAKMP Header cookie pair where the first 8 octets become the 'Initiator Cookie' field of the GROUPKEY-PUSH message ISAKMP HDR, and the second 8 octets become the 'Responder Cookie' in the same HDR. These cookies are assigned by the Key Server.Reference: RFC 3547 - Section: 5.3. SA KEK Payload SIZE (16) · OCTET STRING · hint 16x

The SPI of the Key Encryption Key (KEK) that is currently being used by the Group Member to authenticate & decrypt a rekey from a GROUPKEY-PUSH message.

Counter32 · GROUPKEY-PUSH Messages

Reference: RFC 3547 - Sections: 3.2. Messages 3.3. Initiator Operations 4. GROUPKEY-PUSH Message 4.8. Group Member Operations 5.6. Sequence Number Payload

The sequence number of the last rekey successfully received from this Group Member's registered Key Server.

Counter32 · Number of traffic encryption keys

The number of active traffic encryption keys (TEKS) currently being used by the Group Member to encrypt/decrypt/authenticate dataplane traffic.

Unsigned32

The index of the GM KEK in table.The value of the index is a number which begins at one and is incremented with each KEK that is used by the GM for that GDOI group.

JnxGdoiKekSPIA textual convention indicating a SPI (Security Parameter Index) of sixteen (16) octets for a KEK. The SPI must be the ISAKMP Header cookie pair where the first 8 octets become the 'Initiator Cookie' field of the GROUPKEY-PUSH message ISAKMP HDR, and the second 8 octets become the 'Responder Cookie' in the same HDR. These cookies are assigned by the Key Server.Reference: RFC 3547 - Section: 5.3. SA KEK Payload SIZE (16) · OCTET STRING · hint 16x

The value of the Security Parameter Index (SPI) of a KEK SA. The SPI must be the ISAKMP Header cookie pair where the first 8 octets become the 'Initiator Cookie' field of the GROUPKEY-PUSH message ISAKMP HDR, and the second 8 octets become the 'Responder Cookie' in the same HDR. As described above, these cookies are assigned by the GCKS.

JnxGdoiIdentificationType1 = ipv4Address2 = domainName3 = userName4 = ipv4Subnet5 = ipv6Address6 = ipv6Subnet7 = ipv4Range8 = ipv6Range9 = caDistinguishedName10 = caGeneralName11 = groupNumberA textual convention indicating the type of value used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). Following are the Identification Type Values: ID Type Value ------- ----- RESERVED 0 -- Not Used ID_IPV4_ADDR 1 -- ipv4Address ID_FQDN 2 -- domainName ID_RFC822_ADDR 3 -- userName (ID_USER_FQDN) ID_IPV4_ADDR_SUBNET 4 -- ipv4Subnet - Not in RFC 4306 ID_IPV6_ADDR 5 -- ipv6Address ID_IPV6_ADDR_SUBNET 6 -- ipv6Subnet - Not in RFC 4306 ID_IPV4_ADDR_RANGE 7 -- ipv4Range - Not in RFC 4306 ID_IPV6_ADDR_RANGE 8 -- ipv6Range - Not in RFC 4306 ID_DER_ASN1_DN 9 -- caDistinguishedName ID_DER_ASN1_GN 10 -- caGeneralName ID_KEY_ID 11 -- groupNumber Following are the mappings to the type values above: 'ipv4Address' : a single four (4) octet IPv4 address. 'domainName' : a fully-qualified domain name string. An example is, 'example.com'. The string MUST not contain any terminators (e.g., NULL, CR, etc.). 'userName' : a fully-qualified RFC 822 username or email address string. An example is, 'jsmith@example.com'. The string MUST not contain any terminators. 'ipv4Subnet' : a range of IPv4 addresses, represented by two four (4) octet values concatenated together. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv6Address' : a single sixteen (16) octet IPv6 address. 'ipv6Subnet' : a range of IPv6 addresses, represented by two sixteen (16) octet values concatenated together. The first value is an IPv6 address. The second is an IPv network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv4Range' : a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'ipv6Range' : a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'caDistinguishedName' : the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]. 'caGeneralName' : the binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 'groupNumber' : a four (4) octet group identifier.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads · Integer32

Reference: RFC 3547 - Sections: 5.3. SA KEK payload RFC 4306 - Section: 3.5. Identification Payloads

The Identification Type Value used to parse the identity information for the source of a KEK SA. RFC 4306 defines all valid types that can be used as an identifier. This identification type is sent as the 'SRC ID Type' of the KEK payload.

Unsigned32 · Octets

Reference: RFC 3547 - Sections: 5.3. SA KEK payload

The length (i.e. number of octets) of the source ID of a KEK SA. If no length is given (i.e. it has a value of 0), the default length of its jnxGdoiGmKekSrcIdType should be used as long as it is not reprsented by an ASCII string. If the value has a type that is represented by an ASCII string, a length MUST be included. If the length given is not 0, it should match the 'SRC ID Data Len' field sent in the KEK payload.

JnxGdoiIdentificationValueA textual convention indicating the actual value of used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). The value of the JnxGdoiIdentificationValue object can be parsed based on the value of the associated JnxGdoiIdentificationType object. The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as a binary string of octets with the given lengths if a length is not associated with the object: ipv4Address(1) -- 4 octets ipv4Subnet(4) -- 8 octets ipv6Address(5) -- 16 octets ipv6Subnet(6) -- 32 octets ipv4Range(7) -- 8 octets ipv6Range(8) -- 32 octets groupNumber(11) -- 4 octets The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as an ASCII string of characters. Note that a length MUST be associated with the object in these cases: domainName(2) userName(3) caDistinguishedName(9) caGeneralName(10) Note that the length of 48 octets was chosen because the gdoiKsKekEntry, gdoiGmKekEntry, gdoiKsTekEntry, & gdoiGmTekEntry will exceed the OID size limit of 255 octets if this size is any larger than 48 octets.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads SIZE (0..48) · OCTET STRING · hint 255d

Reference: RFC 3547 - Sections: 5.3. SA KEK payload

The value of the identity information for the source of a KEK SA with its type indicated by the jnxGdoiGmKekSrcIdType. Use the jnxGdoiGmKekSrcIdType to parse the KEK Source ID correctly. This ID value is sent as the 'SRC Identification Data' of a KEK payload.

JnxGdoiUnsigned16A textual convention indicating a 16-bit unsigned integer value. SIZE (2) · OCTET STRING · hint 2d

Reference: RFC 3547 - Sections: 5.3. SA KEK payload

The value specifying a port associated with the source ID of a KEK SA. A value of zero means that the port should be ignored. This port value is sent as the `SRC ID Port` field of a KEK payload.

JnxGdoiIdentificationType1 = ipv4Address2 = domainName3 = userName4 = ipv4Subnet5 = ipv6Address6 = ipv6Subnet7 = ipv4Range8 = ipv6Range9 = caDistinguishedName10 = caGeneralName11 = groupNumberA textual convention indicating the type of value used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). Following are the Identification Type Values: ID Type Value ------- ----- RESERVED 0 -- Not Used ID_IPV4_ADDR 1 -- ipv4Address ID_FQDN 2 -- domainName ID_RFC822_ADDR 3 -- userName (ID_USER_FQDN) ID_IPV4_ADDR_SUBNET 4 -- ipv4Subnet - Not in RFC 4306 ID_IPV6_ADDR 5 -- ipv6Address ID_IPV6_ADDR_SUBNET 6 -- ipv6Subnet - Not in RFC 4306 ID_IPV4_ADDR_RANGE 7 -- ipv4Range - Not in RFC 4306 ID_IPV6_ADDR_RANGE 8 -- ipv6Range - Not in RFC 4306 ID_DER_ASN1_DN 9 -- caDistinguishedName ID_DER_ASN1_GN 10 -- caGeneralName ID_KEY_ID 11 -- groupNumber Following are the mappings to the type values above: 'ipv4Address' : a single four (4) octet IPv4 address. 'domainName' : a fully-qualified domain name string. An example is, 'example.com'. The string MUST not contain any terminators (e.g., NULL, CR, etc.). 'userName' : a fully-qualified RFC 822 username or email address string. An example is, 'jsmith@example.com'. The string MUST not contain any terminators. 'ipv4Subnet' : a range of IPv4 addresses, represented by two four (4) octet values concatenated together. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv6Address' : a single sixteen (16) octet IPv6 address. 'ipv6Subnet' : a range of IPv6 addresses, represented by two sixteen (16) octet values concatenated together. The first value is an IPv6 address. The second is an IPv network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv4Range' : a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'ipv6Range' : a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'caDistinguishedName' : the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]. 'caGeneralName' : the binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 'groupNumber' : a four (4) octet group identifier.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads · Integer32

Reference: RFC 3547 - Sections: 5.3. SA KEK payload RFC 4306 - Section: 3.5. Identification Payloads

The Identification Type Value used to parse the identity information for the dest. (multicast rekey address) of a KEK SA. RFC 4306 defines all valid types that can be used as an identifier. This identification type is sent as the 'DST ID Type' of the KEK payload.

Unsigned32 · Octets

Reference: RFC 3547 - Sections: 5.3. SA KEK payload

The length (i.e. number of octets) of the destination ID of a KEK SA. If no length is given (i.e. it has a value of 0), the default length of its jnxGdoiGmKekDstIdType should be used as long as it is not reprsented by an ASCII string. If the value has a type that is represented by an ASCII string, a length MUST be included. If the length given is not 0, it should match the 'DST ID Data Len' field sent in the KEK payload.

JnxGdoiIdentificationValueA textual convention indicating the actual value of used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). The value of the JnxGdoiIdentificationValue object can be parsed based on the value of the associated JnxGdoiIdentificationType object. The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as a binary string of octets with the given lengths if a length is not associated with the object: ipv4Address(1) -- 4 octets ipv4Subnet(4) -- 8 octets ipv6Address(5) -- 16 octets ipv6Subnet(6) -- 32 octets ipv4Range(7) -- 8 octets ipv6Range(8) -- 32 octets groupNumber(11) -- 4 octets The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as an ASCII string of characters. Note that a length MUST be associated with the object in these cases: domainName(2) userName(3) caDistinguishedName(9) caGeneralName(10) Note that the length of 48 octets was chosen because the gdoiKsKekEntry, gdoiGmKekEntry, gdoiKsTekEntry, & gdoiGmTekEntry will exceed the OID size limit of 255 octets if this size is any larger than 48 octets.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads SIZE (0..48) · OCTET STRING · hint 255d

Reference: RFC 3547 - Sections: 5.3. SA KEK payload

The value of the identity information for the destination of a KEK SA (multicast rekey address) with its type indicated by jnxGdoiGmKekDstIdType. Use the jnxGdoiGmKekDstIdType to parse the KEK Dest. ID correctly. This ID value is sent as the 'DST Identification Data' of a KEK payload.

JnxGdoiUnsigned16A textual convention indicating a 16-bit unsigned integer value. SIZE (2) · OCTET STRING · hint 2d

Reference: RFC 3547 - Sections: 5.3. SA KEK payload

The value specifying a port associated with the dest. ID of a KEK SA. A value of zero means that the port should be ignored. This port value is sent as the `DST ID Port` field of a KEK payload.

JnxGdoiIpProtocolId0 = ipProtocolUnknown1 = ipProtocolTCP2 = ipProtocolUDPA textual convention indicating the identifier of the IP Protocol being used for the rekey datagram. Some possible values are: ID Value ID Type -------- ------- 06 TCP -- ipProtocolTCP 17 UDP -- ipProtocolUDPReference: RFC 3547 - Section: 5.3. SA KEK Payload · Integer32

Reference: RFC 3547 - Section: 5.3. SA KEK payload

The value of the IP protocol ID (e.g. UDP/TCP) being used for the rekey datagram.

JnxGdoiKeyManagementAlgorithm0 = keyMgmtNone1 = keyMgmtLkhA textual convention indicating the identifier of the key/KEK management algorithm being used to provide forward or backward access control (i.e. used to exclude group members). Following are the possible KEK management algorithm values & JnxGdoiKeyManagementAlgorithm mappings: KEK Management Type Value ------------------- ----- LKH 1 -- keyMgmtLkhReference: RFC 3547 - Section: 5.3. SA KEK Payload · Integer32

Reference: RFC 3547 - Section: 5.3.2. KEK_MANAGEMENT_ALGORITHM

The value of the KEK_MANAGEMENT_ALGORITHM which specifies the group KEK management algorithm used to provide forward or backward access control (i.e. used to exclude group members). KEK Management Type Value ------------------- ----- RESERVED 0 LKH 1 RESERVED 2-127 Private Use 128-255

JnxGdoiEncryptionAlgorithm0 = encrAlgNone1 = encrAlgDes642 = encrAlgDes3 = encrAlg3Des4 = encrAlgRc55 = encrAlgIdea6 = encrAlgCast7 = encrAlgBlowfish8 = encrAlg3Idea9 = encrAlgDes3210 = encrAlgRc411 = encrAlgNull12 = encrAlgAesCbc13 = encrAlgAesCtr14 = encrAlgAesCcm815 = encrAlgAesCcm1216 = encrAlgAesCcm1618 = encrAlgAesGcm819 = encrAlgAesGcm1220 = encrAlgAesGcm1621 = encrAlgNullAuthAesGmac23 = encrAlgCamelliaCbc24 = encrAlgCamelliaCtr25 = encrAlgCamelliaCcm826 = encrAlgCamelliaCcm1227 = encrAlgCamelliaCcm128 = encrAlgSeedCbcA textual convention indicating the identifier of the encryption algorithm being used. Following are the possible updated encryption algorithm values & JnxGdoiEncryptionAlgorithm mappings after RFC 4306: Encryption Algorithm Type Value --------------------------------- ----- ENCR_DES_IV64 1 -- encrAlgDes64 ENCR_DES 2 -- encrAlgDes ENCR_3DES 3 -- encrAlg3Des ENCR_RC5 4 -- encrAlgRc5 ENCR_IDEA 5 -- encrAlgIdea ENCR_CAST 6 -- encrAlgCast ENCR_BLOWFISH 7 -- encrAlgBlowfish ENCR_3IDEA 8 -- encrAlg3Idea ENCR_DES_IV32 9 -- encrAlgDes32 ENCR_NULL 11 -- encrAlgNull ENCR_AES_CBC 12 -- encrAlgAesCbc ENCR_AES_CTR 13 -- encrAlgAesCtr ENCR_AES-CCM_8 14 -- encrAlgAesCcm8 ENCR_AES-CCM_12 15 -- encrAlgAesCcm12 ENCR_AES-CCM_16 16 -- encrAlgAesCcm16 AES-GCM (8-octet ICV) 18 -- encrAlgAesGcm8 AES-GCM (12-octet ICV) 19 -- encrAlgAesGcm12 AES-GCM (16-octet ICV) 20 -- encrAlgAesGcm16 ENCR_NULL_AUTH_AES_GMAC 21 -- encrAlgNullAuthAesGmac ENCR_CAMELLIA_CBC 23 -- encrAlgCamelliaCbc ENCR_CAMELLIA_CTR 24 -- encrAlgCamelliaCtr ENCR_CAMELLIA_CCM (8-octet ICV) 25 -- encrAlgCamelliaCcm8 ENCR_CAMELLIA_CCM (12-octet ICV) 26 -- encrAlgCamelliaCcm12 ENCR_CAMELLIA_CCM (16-octet ICV) 27 -- encrAlgCamelliaCcm16 Following are the possible ESP transform identifiers & JnxGdoiEncryptionAlgorithm mappings from RFC 2407: IPsec ESP Transform ID Value ------------------------ ----- ESP_DES_IV64 1 -- encrAlgDes64 ESP_DES 2 -- encrAlgDes ESP_3DES 3 -- encrAlg3Des ESP_RC5 4 -- encrAlgRc5 ESP_IDEA 5 -- encrAlgIdea ESP_CAST 6 -- encrAlgCast ESP_BLOWFISH 7 -- encrAlgBlowfish ESP_3IDEA 8 -- encrAlg3Idea ESP_DES_IV32 9 -- encrAlgDes32 ESP_RC4 10 -- encrAlgRc4 ESP_NULL 11 -- encrAlgNull ESP_AES-CBC 12 -- encrAlgAesCbc ESP_AES-CTR 13 -- encrAlgAesCtr ESP_AES-CCM_8 14 -- encrAlgAesCcm8 ESP_AES-CCM_12 15 -- encrAlgAesCcm12 ESP_AES-CCM_16 16 -- encrAlgAesCcm16 ESP_AES-GCM_8 18 -- encrAlgAesGcm8 ESP_AES-GCM_12 19 -- encrAlgAesGcm12 ESP_AES-GCM_16 20 -- encrAlgAesGcm16 ESP_SEED_CBC 21 -- encrAlgSeedCbc ESP_CAMELLIA 22 -- encrAlgCamelliaCbc, Ctr, Ccm8, Ccm12, Ccm16 ESP_NULL_AUTH_AES-GMAC 23 -- encrAlgNullAuthAesGmac Following are the possible KEK_ALGORITHM values specifying the encryption algorithm used with a KEK & JnxGdoiEncryptionAlgorithm mappings from the GDOI RFC 3547: Algorithm Type Value -------------- ----- KEK_ALG_DES 1 -- encrAlgDes KEK_ALG_3DES 2 -- encrAlg3Des KEK_ALG_AES 3 -- encrAlgAesCbcReference: IANA IKEv2 Parameters Section: Encryption Algorithm Transform IDs http://www.iana.org/assignments/ikev2-parameters IANA 'Magic Numbers' for ISAMP Protocol Section: IPSEC ESP Transform Identifiers http://www.iana.org/assignments/isakmp-registry RFC 2407 - Section: 4.4.4. IPSEC ESP Transform Identifiers RFC 3547 - Section: 5.3.3. KEK_ALGORITHM RFC 4306 - Section: 3.3.2. Transform Substructure RFC 4106, 4309, 4543, 5282, 5529 · Integer32

Reference: RFC 3547 - Section 5.3.3. KEK_ALGORITHM

The value of the KEK_ALGORITHM which specifies the encryption algorithm used with the KEK SA. A GDOI implementaiton must support KEK_ALG_3DES. Following are the KEK encryption algoritm values defined in the GDOI RFC 3547, however the JnxGdoiEncryptionAlgorithm TC defines all possible values. Algorithm Type Value -------------- ----- RESERVED 0 KEK_ALG_DES 1 KEK_ALG_3DES 2 KEK_ALG_AES 3 RESERVED 4-127 Private Use 128-255

Unsigned32 · Bits

Reference: RFC 3547 - Section: 5.3.4. KEK_KEY_LENGTH

The value of the KEK_KEY_LENGTH which specifies the KEK Algorithm key length (in bits).

JnxGdoiPseudoRandomFunction0 = prfNone1 = prfMd5Hmac2 = prfSha1Hmac3 = prfTigerHmac4 = prfAes128Xcbc5 = prfSha2Hmac2566 = prfSha2Hmac3847 = prfSha2Hmac5128 = prfAes128CmacA textual convention indicating the identifier of the pseudo-random function (PRF) being used. Following are the possible updated PRF values & JnxGdoiPseudoRandomFunction mappings after RFC 4306: Pseudo-Random Function Type Value --------------------------------- ----- PRF_HMAC_MD5 1 -- prfMd5Hmac PRF_HMAC_SHA1 2 -- prfSha1Hmac PRF_HMAC_TIGER 3 -- prfTigerHmac PRF_AES128_XCBC 4 -- prfAes128Xcbc PRF_HMAC_SHA2_256 5 -- prfSha2Hmac256 PRF_HMAC_SHA2_384 6 -- prfSha2Hmac384 PRF_HMAC_SHA2_512 7 -- prfSha2Hmac512 PRF_AES128_CMAC 8 -- prfAes128Cmac Following are the possible SIG_HASH_ALGORITHM values & JnxGdoiPseudoRandomFunction mappings from the GDOI RFC 3547: Algorithm Type Value -------------- ----- SIG_HASH_MD5 1 -- prfMd5Hmac SIG_HASH_SHA1 2 -- prfSha1HmacReference: IANA IKEv2 Parameters Section: Pseudo-random Function Transform IDs http://www.iana.org/assignments/ikev2-parameters RFC 3547 - Section: 5.3.6. SIG_HASH_ALGORITHM RFC 4306 - Section: 3.3.2. Transform Substructure RFC 4615, 4868 · Integer32

Reference: RFC 3547 - Section: 5.3.6. SIG_HASH_ALGORITHM

The value of the SIG_HASH_ALGORITHM which specifies the SIG payload hash algorithm. This is not required (i.e. could have a value of zero) if the SIG_ALGORITHM is SIG_ALG_DSS or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1 (i.e. must have a value of zero or SIG_HASH_SHA1). Following are the Signature Hash Algorithm values defined in the GDOI RFC 3547, however the JnxGdoiPseudoRandomFunction TC defines all possible values. Algorithm Type Value -------------- ----- RESERVED 0 SIG_HASH_MD5 1 SIG_HASH_SHA1 2 RESERVED 3-127 Private Use 128-255

JnxGdoiSignatureMethod0 = sigNone1 = sigRsa2 = sigSharedKey3 = sigDss4 = sigEncryptRsa5 = sigRevEncryptRsa9 = sigEcdsa25610 = sigEcdsa38411 = sigEcdsa512A textual convention indicating the identifier of the integirty algorithm being used. Following are the possible updated authentication method values & JnxGdoiSignatureMethod mappings after RFC 4306: Authentication Method Value ----------------------------------- ----- RSA Digital Signature 1 -- sigRsa Shared Key Message Integrity Code 2 -- sigSharedKey DSS Digital Signature 3 -- sigDss ECDSA w/ SHA-256 (P-256 curve) 9 -- sigEcdsa256 ECDSA w/ SHA-384 (P-384 curve) 10 -- sigEcdsa384 ECDSA w/ SHA-512 (P-521 curve) 11 -- sigEcdsa512 Following are the possible legacy IPsec authentication method values & JnxGdoiSignatureMethod mappings from RFC 2409: Authentication Method Value -------------------------------- ----- Pre-Shared Key 1 -- sigSharedKey DSS Signature 2 -- sigDss RSA Signature 3 -- sigRsa Encryption w/ RSA 4 -- sigEncryptRsa Revised Encryption w/ RSA 5 -- sigRevEncryptRsa ECDSA w/ SHA-256 (P-256 curve) 9 -- sigEcdsa256 ECDSA w/ SHA-384 (P-384 curve) 10 -- sigEcdsa384 ECDSA w/ SHA-512 (P-521 curve) 11 -- sigEcdsa512 Following are the possible POP algorithm values & JnxGdoiSignatureMethod mappings from the GDOI RFC 3547: Algorithm Type Value -------------- ----- POP_ALG_RSA 1 -- sigRsa POP_ALG_DSS 2 -- sigDss POP_ALG_ECDSS 3 -- sigEcdsa256, 384, 512 Following are the possible SIG_ALGORITHM values & JnxGdoiSignatureMethod mappings from the GDOI RFC 3547: Algorithm Type Value -------------- ----- SIG_ALG_RSA 1 -- sigRsa SIG_ALG_DSS 2 -- sigDss SIG_ALG_ECDSS 3 -- sigEcdsa256, 384, 512Reference: IANA IKEv2 Parameters Section: Integrity Algorithm Transform IDs http://www.iana.org/assignments/ikev2-parameters RFC 2409 - Section: Appendix A. Authentication Method RFC 3547 - Sections: 5.3.SA KEK payload 5.3.7. SIG_ALGORITHM RFC 4306 - Section: 3.8.Authentication Payload RFC 4754 · Integer32

Reference: RFC 3547 - Section: 5.3.7. SIG_ALGORITHM

The value of the SIG_ALGORITHM which specifies the SIG payload signature algorithm. A GDOI implementation must support SIG_ALG_RSA. Following are the Signature Algorithm values defined in the GDOI RFC 3547, however the JnxGdoiSignatureMethod TC defines all possible values. Algorithm Type Value -------------- ----- RESERVED 0 SIG_ALG_RSA 1 SIG_ALG_DSS 2 SIG_ALG_ECDSS 3 RESERVED 4-127 Private Use 128-255

Unsigned32 · Bits

Reference: RFC 3547 - Section 5.3.8. SIG_KEY_LENGTH

The value of the SIG_KEY_LENGTH which specifies the length of the SIG payload key.

JnxGdoiDiffieHellmanGroup0 = dhNone1 = dhGroup12 = dhGroup23 = dhEc2nGp1554 = dhEc2nGp1855 = dh1536Modp14 = dh2048Modp15 = dh3072Modp16 = dh4096Modp17 = dh6144Modp18 = dh8192Modp19 = dhEcp25620 = dhEcp8421 = dhEcp52122 = dh1024Modp16023 = dh2048Modp22424 = dh2048Modp25625 = dhEcp19226 = dhEcp224A textual convention indicating the identifier of the Diffie-Hellman Group being used. Following are the possible updated Diffie-Hellman Group values & JnxGdoiDiffieHellmanGroup mappings after RFC 4306: Diffie-Hellman Group Type Value ------------------------- ----- NONE 0 -- dhNone Group 1 - 768 Bit MODP 1 -- dhGroup1 Group 2 - 1024 Bit MODP 2 -- dhGroup2 1536-bit MODP Group 5 -- dh1536Modp 2048-bit MODP Group 14 -- dh2048Modp 3072-bit MODP Group 15 -- dh3072Modp 4096-bit MODP Group 16 -- dh4096Modp 6144-bit MODP Group 17 -- dh6144Modp 8192-bit MODP Group 18 -- dh8192Modp 256-bit random ECP group 19 -- dhEcp256 84-bit random ECP group 20 -- dhEcp84 521-bit random ECP group 21 -- dhEcp521 1024-bit MODP w/ 160-bit 22 -- dh1024Modp160 Prime Order Subgroup 2048-bit MODP w/ 224-bit 23 -- dh2048Modp224 Prime Order Subgroup 2048-bit MODP w/ 256-bit 24 -- dh2048Modp256 Prime Order Subgroup 192-bit Random ECP Group 25 -- dhEcp192 224-bit Random ECP Group 26 -- dhEcp224 Following are the possible legacy Diffie-Hellman Group values & JnxGdoiDiffieHellmanGroup mappings from RFC 2409: Diffie-Hellman Group Type Value ------------------------- ----- Group 1 - 768 Bit MODP 1 -- dhGroup1 Group 2 - 1024 Bit MODP 2 -- dhGroup2 EC2N group on GP[2^155] 3 -- dhEc2nGp155 EC2N group on GP[2^185] 4 -- dhEc2nGp185Reference: IANA IKEv2 Parameters Section: Diffie-Hellman Group Transform IDs http://www.iana.org/assignments/ikev2-parameters RFC 2409 - Sections: 6.1. First Oakley Default Group 6.2. Second Oakley Default Group 6.3. Third Oakley Default Group 6.4. Fourth Oakley Default Group · Integer32

Reference: RFC 3547 - Section 5.3.9. KE_OAKLEY_GROUP

The value of the KE_OAKLEY_GROUP which specifies the OAKLEY or Diffie-Hellman Group used to compute the PFS secret in the optional KE payload of the GDOI GROUPKEY-PULL exchange.

Unsigned32 · Seconds

Reference: RFC 3547 - Section 5.3.5. KEK_KEY_LIFETIME

The value of the KEK_KEY_LIFETIME which specifies the maximum time for which a KEK is valid. The GCKS may refresh the KEK at any time before the end of the valid period. The value is a four (4) octet (32-bit) number defining a valid time period in seconds.

Unsigned32 · Seconds

Reference: RFC 3547 - Section 5.3.5. KEK_KEY_LIFETIME

The value of the remaining time for which a KEK is valid. The value is a four (4) octet (32-bit) number which begins at the value of jnxGdoiGmKekOriginalLifetime and counts down to 0 in seconds. If the lifetime has already expired, this value should remain at zero (0) until the GCKS refreshes the KEK.

JnxGdoiKekStatus1 = inUse2 = new3 = oldA textual convention indicating the status of a GDOI KEK and its corresponding Security Association (SA). 'inUse' : KEK currently being used to encrypt new KEK/TEKs 'new' : KEK currently being sent to all peers 'old' : KEK that has expired and is no longer being used · Integer32

The status of the KEK SA. When this status value is queried, one of the following is returned: inUse(1), new(2), old(3).

Unsigned32

The index of the Source/Destination pair secured by the GM TEK.The value of the index is a number which begins at one and is incremented with each Source/Destination pair that is secured by the GM TEK policy for that GDOI group.

JnxGdoiIdentificationType1 = ipv4Address2 = domainName3 = userName4 = ipv4Subnet5 = ipv6Address6 = ipv6Subnet7 = ipv4Range8 = ipv6Range9 = caDistinguishedName10 = caGeneralName11 = groupNumberA textual convention indicating the type of value used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). Following are the Identification Type Values: ID Type Value ------- ----- RESERVED 0 -- Not Used ID_IPV4_ADDR 1 -- ipv4Address ID_FQDN 2 -- domainName ID_RFC822_ADDR 3 -- userName (ID_USER_FQDN) ID_IPV4_ADDR_SUBNET 4 -- ipv4Subnet - Not in RFC 4306 ID_IPV6_ADDR 5 -- ipv6Address ID_IPV6_ADDR_SUBNET 6 -- ipv6Subnet - Not in RFC 4306 ID_IPV4_ADDR_RANGE 7 -- ipv4Range - Not in RFC 4306 ID_IPV6_ADDR_RANGE 8 -- ipv6Range - Not in RFC 4306 ID_DER_ASN1_DN 9 -- caDistinguishedName ID_DER_ASN1_GN 10 -- caGeneralName ID_KEY_ID 11 -- groupNumber Following are the mappings to the type values above: 'ipv4Address' : a single four (4) octet IPv4 address. 'domainName' : a fully-qualified domain name string. An example is, 'example.com'. The string MUST not contain any terminators (e.g., NULL, CR, etc.). 'userName' : a fully-qualified RFC 822 username or email address string. An example is, 'jsmith@example.com'. The string MUST not contain any terminators. 'ipv4Subnet' : a range of IPv4 addresses, represented by two four (4) octet values concatenated together. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv6Address' : a single sixteen (16) octet IPv6 address. 'ipv6Subnet' : a range of IPv6 addresses, represented by two sixteen (16) octet values concatenated together. The first value is an IPv6 address. The second is an IPv network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv4Range' : a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'ipv6Range' : a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'caDistinguishedName' : the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]. 'caGeneralName' : the binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 'groupNumber' : a four (4) octet group identifier.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads · Integer32

Reference: RFC 3547 - Sections: 5.4.1. PROTO_IPSEC_ESP RFC 4306 - Section: 3.5. Identification Payloads

The Identification Type Value used to parse the identity information for the source of a TEK Policy/SA. RFC 4306 defines all valid types that can be used as an identifier. This identification type is sent as the 'SRC ID Type' of the TEK payload.

Unsigned32 · Octets

Reference: RFC 3547 - Sections: 5.4.1. PROTO_IPSEC_ESP

The length (i.e. number of octets) of the source ID of a TEK Policy/SA. If no length is given (i.e. it has a value of 0), the default length of its jnxGdoiGmTekSrcIdType should be used as long as it is not reprsented by an ASCII string. If the value has a type that is represented by an ASCII string, a length MUST be included. If the length given is not 0, it should match the 'SRC ID Data Len' field sent in the TEK payload.

JnxGdoiIdentificationValueA textual convention indicating the actual value of used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). The value of the JnxGdoiIdentificationValue object can be parsed based on the value of the associated JnxGdoiIdentificationType object. The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as a binary string of octets with the given lengths if a length is not associated with the object: ipv4Address(1) -- 4 octets ipv4Subnet(4) -- 8 octets ipv6Address(5) -- 16 octets ipv6Subnet(6) -- 32 octets ipv4Range(7) -- 8 octets ipv6Range(8) -- 32 octets groupNumber(11) -- 4 octets The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as an ASCII string of characters. Note that a length MUST be associated with the object in these cases: domainName(2) userName(3) caDistinguishedName(9) caGeneralName(10) Note that the length of 48 octets was chosen because the gdoiKsKekEntry, gdoiGmKekEntry, gdoiKsTekEntry, & gdoiGmTekEntry will exceed the OID size limit of 255 octets if this size is any larger than 48 octets.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads SIZE (0..48) · OCTET STRING · hint 255d

Reference: RFC 3547 - Sections: 5.4.1. PROTO_IPSEC_ESP

The value of the identity information for the source of a TEK Policy/SA with its type indicated by the jnxGdoiGmTekSrcIdType. Use the jnxGdoiGmTekSrcIdType to parse the TEK Source ID correctly. This ID value is sent as the 'SRC Identification Data' of a TEK payload.

JnxGdoiUnsigned16A textual convention indicating a 16-bit unsigned integer value. SIZE (2) · OCTET STRING · hint 2d

Reference: RFC 3547 - Sections: 5.4.1. PROTO_IPSEC_ESP

The value specifying a port associated with the source ID of a TEK Policy/SA. A value of zero means that the port should be ignored. This port value is sent as the `SRC ID Port` field of a TEK payload.

JnxGdoiIdentificationType1 = ipv4Address2 = domainName3 = userName4 = ipv4Subnet5 = ipv6Address6 = ipv6Subnet7 = ipv4Range8 = ipv6Range9 = caDistinguishedName10 = caGeneralName11 = groupNumberA textual convention indicating the type of value used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). Following are the Identification Type Values: ID Type Value ------- ----- RESERVED 0 -- Not Used ID_IPV4_ADDR 1 -- ipv4Address ID_FQDN 2 -- domainName ID_RFC822_ADDR 3 -- userName (ID_USER_FQDN) ID_IPV4_ADDR_SUBNET 4 -- ipv4Subnet - Not in RFC 4306 ID_IPV6_ADDR 5 -- ipv6Address ID_IPV6_ADDR_SUBNET 6 -- ipv6Subnet - Not in RFC 4306 ID_IPV4_ADDR_RANGE 7 -- ipv4Range - Not in RFC 4306 ID_IPV6_ADDR_RANGE 8 -- ipv6Range - Not in RFC 4306 ID_DER_ASN1_DN 9 -- caDistinguishedName ID_DER_ASN1_GN 10 -- caGeneralName ID_KEY_ID 11 -- groupNumber Following are the mappings to the type values above: 'ipv4Address' : a single four (4) octet IPv4 address. 'domainName' : a fully-qualified domain name string. An example is, 'example.com'. The string MUST not contain any terminators (e.g., NULL, CR, etc.). 'userName' : a fully-qualified RFC 822 username or email address string. An example is, 'jsmith@example.com'. The string MUST not contain any terminators. 'ipv4Subnet' : a range of IPv4 addresses, represented by two four (4) octet values concatenated together. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv6Address' : a single sixteen (16) octet IPv6 address. 'ipv6Subnet' : a range of IPv6 addresses, represented by two sixteen (16) octet values concatenated together. The first value is an IPv6 address. The second is an IPv network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a 'wildcard' bit. 'ipv4Range' : a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'ipv6Range' : a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 'caDistinguishedName' : the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]. 'caGeneralName' : the binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. 'groupNumber' : a four (4) octet group identifier.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads · Integer32

Reference: RFC 3547 - Sections: 5.4.1. PROTO_IPSEC_ESP RFC 4306 - Section: 3.5. Identification Payloads

The Identification Type Value used to parse the identity information for the dest. of a TEK Policy/SA. RFC 4306 defines all valid types that can be used as an identifier. This identification type is sent as the 'DST ID Type' of the TEK payload.

Unsigned32 · Octets

Reference: RFC 3547 - Sections: 5.4.1. PROTO_IPSEC_ESP

The length (i.e. number of octets) of the destination ID of a TEK Policy/SA. If no length is given (i.e. it has a value of 0), the default length of its jnxGdoiGmTekDstIdType should be used as long as it is not reprsented by an ASCII string. If the value has a type that is represented by an ASCII string, a length MUST be included. If the length given is not 0, it should match the 'DST ID Data Len' field sent in the TEK payload.

JnxGdoiIdentificationValueA textual convention indicating the actual value of used to identify a GDOI entity (i.e. Group, Key Server, or Group Member). The value of the JnxGdoiIdentificationValue object can be parsed based on the value of the associated JnxGdoiIdentificationType object. The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as a binary string of octets with the given lengths if a length is not associated with the object: ipv4Address(1) -- 4 octets ipv4Subnet(4) -- 8 octets ipv6Address(5) -- 16 octets ipv6Subnet(6) -- 32 octets ipv4Range(7) -- 8 octets ipv6Range(8) -- 32 octets groupNumber(11) -- 4 octets The following JnxGdoiIdentificationType values indicate that the JnxGdoiIdentificationValue object should be parsed as an ASCII string of characters. Note that a length MUST be associated with the object in these cases: domainName(2) userName(3) caDistinguishedName(9) caGeneralName(10) Note that the length of 48 octets was chosen because the gdoiKsKekEntry, gdoiGmKekEntry, gdoiKsTekEntry, & gdoiGmTekEntry will exceed the OID size limit of 255 octets if this size is any larger than 48 octets.Reference: IANA ISAKMP Registry - 'Magic Numbers' for ISAKMP Protocol Section: IPSEC Identification Type http://www.iana.org/assignments/isakmp-registry RFC 4306 - Section: 3.5. Identification Payloads SIZE (0..48) · OCTET STRING · hint 255d

Reference: RFC 3547 - Sections: 5.4.1. PROTO_IPSEC_ESP

The value of the identity information for the destination of a TEK Policy/SA with its type indicated by the jnxGdoiGmTekDstIdType. Use the jnxGdoiGmTekDstIdType to parse the TEK Dest. ID correctly. This ID value is sent as the 'DST Identification Data' of a TEK payload.

JnxGdoiUnsigned16A textual convention indicating a 16-bit unsigned integer value. SIZE (2) · OCTET STRING · hint 2d

Reference: RFC 3547 - Sections: 5.4.1. PROTO_IPSEC_ESP

The value specifying a port associated with the dest. ID of a TEK Policy/SA. A value of zero means that the port should be ignored. This port value is sent as the `DST ID Port` field of a TEK payload.

JnxGdoiSecurityProtocol0 = secProtocolUnknown1 = secProtocolIpsecEspA textual convention indicating the identifier of the Security Protocol being used. Following are the possible Security Protocol ID values & JnxGdoiSecurityProtocol mappings from the GDOI RFC 3547: Security Protocol ID Value ---------------------- ----- GDOI_PROTO_IPSEC_ESP 1 -- secProtocolIpsecEspReference: RFC 3547 - Section: 5.4. SA TEK Payload · Integer32

Reference: RFC 3547 - Section: 5.4. SA TEK Payload

The value of the Protocol-ID field of a SA TEK (SAT) payload which specifies the Security Protocol for a TEK. Following are the Security Protocol values defined in the GDOI RFC 3547, however the JnxGdoiSecurityProtocol TC defines all possible values. Protocol ID Value ---------------------- ----- RESERVED 0 GDOI_PROTO_IPSEC_ESP 1 RESERVED 2-127 Private Use 128-255

JnxGdoiPolicyMismatchAction1 = drop2 = forward3 = unknownA textual convention indicating the default action for packets that does not match TEK policy/SA. 'drop' : Drop packets that do not match the TEK policy/SA. 'forward': Forward the packets as received that do not match the TEK policy/SA 'unknown': The default action for TEK policy/SA mismatch is unknown. · Integer32

Default action for packets that does not match TEK Policy/SA received from group key server

Unsigned32

The index of the SPI used to secure the GM TEK.The value of the index is a number which begins at one and is incremented with each row of the GM TEK SPI table.

JnxGdoiTekSPIA textual convention indicating a SPI (Security Parameter Index) of four (4) octets for a TEK using ESP.Reference: RFC 3547 - Section: 5.4.1. PROTO_IPSEC_ESP SIZE (4) · OCTET STRING · hint 4x

Reference: RFC 3547 - Section: 5.4.1. PROTO_IPSEC_ESP

The value of the Security Parameter Index (SPI) of a TEK Policy/SA. The SPI must be the SPI for ESP.

JnxGdoiEncapsulationMode0 = encapUnknown1 = encapTunnel2 = encapTransport3 = encapUdpTunnel4 = encapUdpTransportA textual convention indicating the identifier of the Encapsulation Mode being used. Following are the possible Encapsulation Mode values & JnxGdoiEncapsulationMode mappings from RFC 2407: Encapsulation Mode Value ---------------------------- ----- Tunnel 1 -- encapTunnel Transport 2 -- encapTransport UDP-Encapsulated-Tunnel 3 -- encapUdpTunnel UDP-Encapsulated-Transport 4 -- encapUdpTransportReference: IANA 'Magic Numbers' for ISAKMP Protocol Section: Encapsulation Mode http://www.iana.org/assignments/isakmp-registry RFC 2407 - Section: 4.5. IPSEC Security Assoc. Attributes RFC 3947 · Integer32

Reference: RFC 2407 - Section: 4.5. IPSEC Security Assoc. Attributes RFC 3547 - Section: 5.4.1. PROTO_IPSEC_ESP

The value of the Encapsulation Mode of a TEK (IPsec SA). Following are the Encapsulation Mode values defined in RFC 2407, however the JnxGdoiEncapsulationMode TC defines all possible values. Encapsulation Mode Value ------------------ ----- RESERVED 0 Tunnel 1 Transport 2

JnxGdoiEncryptionAlgorithm0 = encrAlgNone1 = encrAlgDes642 = encrAlgDes3 = encrAlg3Des4 = encrAlgRc55 = encrAlgIdea6 = encrAlgCast7 = encrAlgBlowfish8 = encrAlg3Idea9 = encrAlgDes3210 = encrAlgRc411 = encrAlgNull12 = encrAlgAesCbc13 = encrAlgAesCtr14 = encrAlgAesCcm815 = encrAlgAesCcm1216 = encrAlgAesCcm1618 = encrAlgAesGcm819 = encrAlgAesGcm1220 = encrAlgAesGcm1621 = encrAlgNullAuthAesGmac23 = encrAlgCamelliaCbc24 = encrAlgCamelliaCtr25 = encrAlgCamelliaCcm826 = encrAlgCamelliaCcm1227 = encrAlgCamelliaCcm128 = encrAlgSeedCbcA textual convention indicating the identifier of the encryption algorithm being used. Following are the possible updated encryption algorithm values & JnxGdoiEncryptionAlgorithm mappings after RFC 4306: Encryption Algorithm Type Value --------------------------------- ----- ENCR_DES_IV64 1 -- encrAlgDes64 ENCR_DES 2 -- encrAlgDes ENCR_3DES 3 -- encrAlg3Des ENCR_RC5 4 -- encrAlgRc5 ENCR_IDEA 5 -- encrAlgIdea ENCR_CAST 6 -- encrAlgCast ENCR_BLOWFISH 7 -- encrAlgBlowfish ENCR_3IDEA 8 -- encrAlg3Idea ENCR_DES_IV32 9 -- encrAlgDes32 ENCR_NULL 11 -- encrAlgNull ENCR_AES_CBC 12 -- encrAlgAesCbc ENCR_AES_CTR 13 -- encrAlgAesCtr ENCR_AES-CCM_8 14 -- encrAlgAesCcm8 ENCR_AES-CCM_12 15 -- encrAlgAesCcm12 ENCR_AES-CCM_16 16 -- encrAlgAesCcm16 AES-GCM (8-octet ICV) 18 -- encrAlgAesGcm8 AES-GCM (12-octet ICV) 19 -- encrAlgAesGcm12 AES-GCM (16-octet ICV) 20 -- encrAlgAesGcm16 ENCR_NULL_AUTH_AES_GMAC 21 -- encrAlgNullAuthAesGmac ENCR_CAMELLIA_CBC 23 -- encrAlgCamelliaCbc ENCR_CAMELLIA_CTR 24 -- encrAlgCamelliaCtr ENCR_CAMELLIA_CCM (8-octet ICV) 25 -- encrAlgCamelliaCcm8 ENCR_CAMELLIA_CCM (12-octet ICV) 26 -- encrAlgCamelliaCcm12 ENCR_CAMELLIA_CCM (16-octet ICV) 27 -- encrAlgCamelliaCcm16 Following are the possible ESP transform identifiers & JnxGdoiEncryptionAlgorithm mappings from RFC 2407: IPsec ESP Transform ID Value ------------------------ ----- ESP_DES_IV64 1 -- encrAlgDes64 ESP_DES 2 -- encrAlgDes ESP_3DES 3 -- encrAlg3Des ESP_RC5 4 -- encrAlgRc5 ESP_IDEA 5 -- encrAlgIdea ESP_CAST 6 -- encrAlgCast ESP_BLOWFISH 7 -- encrAlgBlowfish ESP_3IDEA 8 -- encrAlg3Idea ESP_DES_IV32 9 -- encrAlgDes32 ESP_RC4 10 -- encrAlgRc4 ESP_NULL 11 -- encrAlgNull ESP_AES-CBC 12 -- encrAlgAesCbc ESP_AES-CTR 13 -- encrAlgAesCtr ESP_AES-CCM_8 14 -- encrAlgAesCcm8 ESP_AES-CCM_12 15 -- encrAlgAesCcm12 ESP_AES-CCM_16 16 -- encrAlgAesCcm16 ESP_AES-GCM_8 18 -- encrAlgAesGcm8 ESP_AES-GCM_12 19 -- encrAlgAesGcm12 ESP_AES-GCM_16 20 -- encrAlgAesGcm16 ESP_SEED_CBC 21 -- encrAlgSeedCbc ESP_CAMELLIA 22 -- encrAlgCamelliaCbc, Ctr, Ccm8, Ccm12, Ccm16 ESP_NULL_AUTH_AES-GMAC 23 -- encrAlgNullAuthAesGmac Following are the possible KEK_ALGORITHM values specifying the encryption algorithm used with a KEK & JnxGdoiEncryptionAlgorithm mappings from the GDOI RFC 3547: Algorithm Type Value -------------- ----- KEK_ALG_DES 1 -- encrAlgDes KEK_ALG_3DES 2 -- encrAlg3Des KEK_ALG_AES 3 -- encrAlgAesCbcReference: IANA IKEv2 Parameters Section: Encryption Algorithm Transform IDs http://www.iana.org/assignments/ikev2-parameters IANA 'Magic Numbers' for ISAMP Protocol Section: IPSEC ESP Transform Identifiers http://www.iana.org/assignments/isakmp-registry RFC 2407 - Section: 4.4.4. IPSEC ESP Transform Identifiers RFC 3547 - Section: 5.3.3. KEK_ALGORITHM RFC 4306 - Section: 3.3.2. Transform Substructure RFC 4106, 4309, 4543, 5282, 5529 · Integer32

Reference: RFC 2407 - Section: 4.4.4. IPSEC ESP Transform Identifiers RFC 3547 - Section: 5.4.1. PROTO_IPSEC_ESP

The value of the Transform ID field of a PROTO_IPSEC_ESP payload which specifies the ESP transform to be used. If no encryption is used, this value will be zero (0). Following are the ESP Transform values defined in RFC 2407, however the JnxGdoiEncryptionAlgorithm TC defines all possible values. IPsec ESP Transform ID Value ------------------------ ----- RESERVED 0 ESP_DES_IV64 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 ESP_IDEA 5 ESP_CAST 6 ESP_BLOWFISH 7 ESP_3IDEA 8 ESP_DES_IV32 9 ESP_RC4 10 ESP_NULL 11

Unsigned32 · Bits

Reference: RFC 2407 - Section: 4.5 IPSEC Security Assoc. Attributes RFC 3547 - Section: 5.4.1. PROTO_IPSEC_ESP

The length of the key used for encryption in a TEK (in bits).

JnxGdoiIntegrityAlgorithm0 = authAlgNone1 = authAlgMd5Hmac962 = authAlgSha1Hmac963 = authAlgDesMac4 = authAlgMd5Kpdk5 = authAlgAesXcbc966 = authAlgMd5Hmac1287 = authAlgSha1Hmac1608 = authAlgAesCmac969 = authAlgAes128Gmac10 = authAlgAes192Gmac11 = authAlgAes256Gmac12 = authAlgSha2Hmac256to12813 = authAlgSha2Hmac384to19214 = authAlgSha2Hmac512to256A textual convention indicating the identifier of the integirty algorithm being used. Following are the possible updated integrity algorithm values & JnxGdoiIntegrityAlgorithm mappings after RFC 4306: Integrity Algorithm Type Value ------------------------ ----- AUTH_HMAC_MD5_96 1 -- authAlgMd5Hmac96 AUTH_HMAC_SHA1_96 2 -- authAlgSha1Hmac96 AUTH_DES_MAC 3 -- authAlgDesMac AUTH_KPDK_MD5 4 -- authAlgMd5Kpdk AUTH_AES_XCBC_96 5 -- authAlgAesXcbc96 AUTH_HMAC_MD5_128 6 -- authAlgMd5Hmac128 AUTH_HMAC_SHA1_160 7 -- authAlgSha1Hmac160 AUTH_AES_CMAC_96 8 -- authAlgAesCmac96 AUTH_AES_128_GMAC 9 -- authAlgAes128Gmac AUTH_AES_192_GMAC 10 -- authAlgAes192Gmac AUTH_AES_256_GMAC 11 -- authAlgAes256Gmac AUTH_HMAC_SHA2_256_128 12 -- authAlgSha2Hmac256to128 AUTH_HMAC_SHA2_384_192 13 -- authAlgSha2Hmac384to192 AUTH_HMAC_SHA2_512_256 14 -- authAlgSha2Hmac512to256 Following are the possible legacy authentication algorithm values & JnxGdoIntegrityAlgorithm mappings from RFC 2407: Algorithm Type Value -------------- ----- HMAC-MD5 1 -- authAlgMd5Hmac96 HMAC-SHA 2 -- authAlgSha1Hmac96 DES-MAC 3 -- authAlgDesMac KPDK 4 -- authAlgMd5KpdkReference: IANA IKEv2 Parameters Section: Integrity Algorithm Transform IDs http://www.iana.org/assignments/ikev2-parameters RFC 2407 - Section: 4.5. IPSEC Security Assoc. Attributes RFC 3547 - Section: 5.3.6. SIG_HASH_ALGORITHM RFC 4306 - Section: 3.3.2. Transform Substructure RFC 4494, 4543, 4595, 4868 · Integer32

Reference: RFC 2407 - Section: 4.5. IPSEC Security Assoc. Attributes RFC 3547 - Section: 5.4.1. PROTO_IPSEC_ESP

The value of the Authentication Algorithm for a TEK IPsec ESP SA. If no authentication is used, this value will be zero (0). Following are the Authentication Algorithm values defined in RFC 2407, however the JnxGdoiEncryptionAlgorithm TC defines all possible values. Algorithm Type Value -------------- ----- HMAC-MD5 1 HMAC-SHA 2 DES-MAC 3 KPDK 4

Unsigned32 · Bits

Reference: RFC 2407 - Section: 4.5 IPSEC Security Assoc. Attributes RFC 3547 - Section: 5.4.1. PROTO_IPSEC_ESP

The length of the key used for integrity/authentication in a TEK (in bits).

Unsigned32 · GROUPKEY-PUSH Messages

Reference: RFC 2407 - Section: 4.6.3.2. REPLAY-STATUS RFC 3547 - Section: 6.3.4. Replay/Reflection Attack Protection

The size of the Time Based Anti-Replay (TBAR) window used by this TEK Policy/SA.

Unsigned32 · Seconds

Reference: RFC 2407 - Section: 4.5 IPSEC Security Assoc. Attributes RFC 3547 - Section: 5.4.1. PROTO_IPSEC_ESP

The value of the SA Life Type defined in RFC 2407 which specifies the maximum time for which a TEK IPsec SA is valid. The GCKS may refresh the TEK at any time before the end of the valid period. The value is a four (4) octet (32-bit) number defining a valid time period in seconds.

Unsigned32 · Seconds

Reference: RFC 2407 - Section: 4.5 IPSEC Security Assoc. Attributes RFC 3547 - Section: 5.4.1. PROTO_IPSEC_ESP

The value of the remaining time for which a TEK is valid. The value is a four (4) octet (32-bit) number which begins at the value of jnxGdoiGmTekOriginalLifetime and counts down to 0 in seconds.

JnxGdoiTekStatus1 = inbound2 = outbound3 = biDirectionalA textual convention indicating the status of a GDOI TEK and its corresponding Security Association (SA). 'inbound' : TEK is being used as inbound (receive) SA 'outbound' : TEK is being used as outbound (transmit) SA 'biDirectional' : TEK is being used as both inbound and outbound SA · Integer32

The status of the TEK Policy/SA. When this status value is queried, one of the following is returned: inbound(1), outbound(2), biDirectional(3).