The CHILD_SA
The CHILD_SA in IKEv2 performs nearly the same function as Quick Mode in IKEv1, setting up the transformations and parameters for traffic protection. That is, the encryption and authentication algorithms to be used to protect network traffic, key lifetimes, and optionally another Diffie-Hellman-Merkel exchange if Perfect Forward Secrecy is enabled (PFS).
The first CHILD_SA starts to be setup by two peers bringing up an IKEv2 session during the initial exchanges. RFC4306 requires that the CHILD_SA exchange is cryptographically protected, so as soon as a IKEv2 speaker has the other peer's nonce and Diffie-Hellman-Merkel public value it can begin to encrypt the IKEv2 traffic (assuming the proposal for encryption and authentication are acceptable). As a result, the first CHILD_SA can be setup at the same time as the two IKEv2 peers are authenticating each others identities. This parallel nature means that the entire IKEv2 session can be setup in just four packets. IKEv1, with it's much more serial nature, requires 6 or 8 packets depending on if Aggressive or Main mode is being used.
Either peer in a CHILD_SA can be the inititaor in the CHILD_SA exchange. The initiator of the CHILD_SA does not have to be the initiator of the initial exchanges that established the secure channel.
To see what happens in a CHILD_SA, we'll look at two CHILD_SAs: one that happens during the initial establishment of an IKEv2 session, and another that occurs by itself.
The CHILD_SA during the IKEv2 Session Establishment
For this section, we'll be referring to the IKEv2 session that was used to explore the initial exchanges, focusing in on just the formation of the CHILD_SA.
As a refresher, this is an SA which is being setup between a Juniper SRX named SRX-13 and a Linux server box running strongSwan. Both boxes will be using their addresses on the 10.80.80.0/24 subnet for the IPSEC session, 10.80.80.13 and 10.80.80.80 respectively. We're using a strongSwan client as one side of the IKE session as we can get it to log all of the encryption and authentication keys, while Junos won't. We can use the sensitive data coughed up by strongSwan with the logging levels maxed out to use with Wireshark to decrypt any encrypted packets that are part of the IKE exchange.
Our inspection of the setup of a CHILD_SA during the initial exchanges starts when the initiator, SRX-13 with the IP address of 10.80.80.13 starts to prepare the third packet in the overall exchange. Up to this point, enough information has been exchanged by the two peers to start encrypting the rest of the IKEv2 exchanges. So after processing all of the necessary items to setup the secure channel, the initiator can start to prepare a proposal for the protection of network traffic.
Initiator beginning to prepare 3rd packet in IKEv2 initial exchange
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_packet_allocate: [8c38c00/8c9f400] Allocating reply packet [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_packet_allocate: Allocated packet 8c39000 from freelist [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_packet_allocate: [8c39000/0] Allocating [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ssh_set_thread_debug_info: ikev2_reply_packet_allocate: set thread debug info - local 10.80.80.13 remote 10.80.80.80 neg 0x0 neg->ike_sa 0x0 ike_sa 0x8c9f400 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_packet_allocate: [8c38c00/0] Allocated reply packet
It prepares to encrypt the rest of the IKEv2 communications, calculating the seed value for the rest of the keying material.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_skeyseed: Starting SKEYSEED calculation for SA 8c9f400 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_skeyseed_agree: SKEYSEED calculation done
The initiator prepares a few of the payloads that belong to the initial exchanges, which includes the indentities of the initiator and responder, and the authentication.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_cb_id: [8c39000/8c9f400] Adding IDi [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_cb_id: [8c39000/8c9f400] Adding IDr [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_add_auth: [8c39000/8c9f400] Adding AUTH
Next, it prepares a Security Association payload. This is the proposal or proposals that the initiator is wants to use for traffic protection. If there is more than one proposal, they have to be ordered from most preferred to least preferred. These SA parameters include the protocol to be used, IKE AH or ESP, the cryptographic transformations for encryption and authentication, a pseudo-random function (PRF) to be used for generating keying material, and optionally a set of Diffie-Hellman-Merkel constraints (group) to be used with PFS. The SA payload differs somewhat from what IKEv1 and ISAKMP use as it was modified to be able to encode multiple transforms into a single SA. IKEv2 is much more accommodating and flexible than the earlier version, allowing both sides a bit more freedom to come to an agreement on what parameters will be used.
The log entries on SRX-13, show that the SA values are coming from the [security ipsec] portion of the configuration for the peer. Here there is only one proposal. The values can be cross referenced using IANA Internet Key Exchange Version 2 (IKEv2) Parameters.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_out_fill_sa: Calling fill_ipsec_sa [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_cb_auth_initiator_fill_ipsec_sa: [8c39000/8c9f400] IPsec SA filled successfully [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_out_sa: [8c39000/8c9f400] Adding SAi2 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_encode_sa: [8c39000/8c9f400] SA([0](id = 1) protocol = ESP (3), AES CBC key len = 128, HMAC-SHA1-96, No ESN; ) [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_encode_sa: IPsec SPI = 0x81cb7deb
The next payload we find being created as part of the CHILD_SA is the Traffic Selector Payload. The traffic selector payload allows peers to identify traffic flows that should be protected by IPSEC. This takes the form of an IPv4 prefix, an IP protocol (TCP, UDP, etc) and a port range. The traffic selector plays much the same role as the proxy identities in IKEv1 Quick Mode. However, with IKEv2 the initiator and responder do not have to have the same values. The traffic selectors of the Responder only have to be a subset of the ones proposed by the initiator. A mismatch will not necessarily cause the setup of the CHILD_SA to fail. Here the SRX is proposing that all traffic be subject to IPSEC processing.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_out_ts: [8c39000/8c9f400] Adding TSi [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_encode_ts: [8c39000/8c9f400] TS(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 0.0.0.0 - 255.255.255.255; ) [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_out_ts: [8c39000/8c9f400] Adding TSr [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_encode_ts: [8c39000/8c9f400] TS(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 0.0.0.0 - 255.255.255.255; )
After that, we see the SRX prepares a couple of notification payloads to control and inform on some of the aspects of the ongoing IKEv2 exchange.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_add_notify: Calling notify_request [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Parsing notification payload for local:10.80.80.13, remote:10.80.80.80 IKEv2 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Ignoring notification of type 16404 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Ignoring notification of type 16389 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Ignoring notification of type 16388 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] iked_pm_ike_spd_notify_request: Sending Initial contact [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_cb_notify_request: [8c39000/8c9f400] Notify from policymanager = 16384 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_cb_notify_request: [8c39000/8c9f400] Adding N [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_encode_notify: [8c39000/8c9f400] N(type = Initial contact (16384), protocol = None (0), spi_len = 0, spi = , data_len = 0 data = ) [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Sending IKE window size notification for IKE SA of size 1 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_udp_window_configure: Reconfiguring transmission windows for SA 8c9f400 local 1 remote 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_cb_notify_request: [8c39000/8c9f400] Notify from policymanager = 16385 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_cb_notify_request: [8c39000/8c9f400] Adding N [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_encode_notify: [8c39000/8c9f400] N(type = Set window size (16385), protocol = None (0), spi_len = 0, spi = , data_len = 4 data = 00000001) [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_cb_notify_request: [8c39000/8c9f400] No more notifies
At this point, the initiator is finished with it's end of the processing, and simply needs to inform the responder what it would like to do in terms of the CHILD_SA. Keep in mind, it's still engaged in the initial exchanges as well -- trading identities and authenticating the peer. A Finite State machine model of this step, focusing on the CHILD_SA looks like the following:
Initiator sets up secure channel and starts to negotiate traffic protection.
Then the SRX encrypts the packet and sends it out.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_udp_send_packet: [8c39000/8c9f400] Sending packet using VR id 0
Packet #3: ISAKMP packet sent to responder.
We see our first CHILD_SA payload in packet #3 of the packet capture of the session; a SA payload which is Payload Type 33. We've decrypted the packet using Wireshark and the keys logged by strongSwan.
The next step in the formation of the CHILD_SA starts with the responder, the Linux box running strongSwan, receiving the third packet.
Mar 7 19:43:54 16[NET] received packet: from 10.80.80.13[500] to 10.80.80.80[500]
It quickly finds out that everything contained within is encrypted.
Mar 7 19:43:54 16[ENC] parsing body of message, first payload is ENCRYPTED
Once it decrypts the payloads, it finds all of the initial exchange related payloads that were discussed previously.
Mar 7 19:43:54 16[ENC] parsing ID_INITIATOR payload, 164 bytes left Mar 7 19:43:54 16[ENC] parsing ID_RESPONDER payload, 152 bytes left Mar 7 19:43:54 16[ENC] parsing AUTHENTICATION payload, 140 bytes left
Then we find the SA payload that belongs to the CHILD_SA exchange. Referencing RFC4306 Section 3.3, the rules corresponding bit, flags and fields in the log message below correspond to the payload header structure. Analysing the log excerpt below and cross referencing it with the values in IANA Internet Key Exchange Version 2 (IKEv2) Parameters we can decode the values. The next payload, 44, that we can expect is a TSi -- Traffic Selector of the initiator. The SA payload is hierarchical in nature, with several sub-payloads nested inside. The data portion of the proposal payload carries proposal substrures (one or more).
Mar 7 19:43:54 16[ENC] parsing SECURITY_ASSOCIATION payload, 112 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 112 bytes @ 0x7fc23c000a64 Mar 7 19:43:54 16[ENC] parsing rule 0 U_INT_8 Mar 7 19:43:54 16[ENC] => 44 Mar 7 19:43:54 16[ENC] parsing rule 1 FLAG Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 2 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 3 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 4 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 5 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 6 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 7 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 8 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 9 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => 44 Mar 7 19:43:54 16[ENC] parsing rule 10 PROPOSALS
We can continue on, referring to RFC4306 Section 3.3.1 and the IANA IKEv2 document to decode the proposal substructure. The first field is a flag that indicates if this proposal substructure is the last one, with a zero indicating that it is the last. This field is redundant in IKEv2, but was carried over from the ISAKMP packet structure. The interesting fields here are rule 3, which corresponds to the proposal number, rule 4 which is the protocol to be used (IKE, ESP or AH). A 3 indicates that this proposal is to use ESP. Rule 5 indicates the SPI_SIZE, which goes along with the actual SPI listed in rule 7. The proposal substructure is also a nested structure, and rule 6 corresponds to the number of transform substructures which are nested inside the proposal substructure.
Mar 7 19:43:54 16[ENC] 40 bytes left, parsing recursively PROPOSAL_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] parsing PROPOSAL_SUBSTRUCTURE payload, 108 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 108 bytes @ 0x7fc23c000a68 Mar 7 19:43:54 16[ENC] parsing rule 0 U_INT_8 Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 1 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 2 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => 40 Mar 7 19:43:54 16[ENC] parsing rule 3 U_INT_8 Mar 7 19:43:54 16[ENC] => 1 Mar 7 19:43:54 16[ENC] parsing rule 4 U_INT_8 Mar 7 19:43:54 16[ENC] => 3 Mar 7 19:43:54 16[ENC] parsing rule 5 SPI_SIZE Mar 7 19:43:54 16[ENC] => 4 Mar 7 19:43:54 16[ENC] parsing rule 6 U_INT_8 Mar 7 19:43:54 16[ENC] => 3 Mar 7 19:43:54 16[ENC] parsing rule 7 SPI Mar 7 19:43:54 16[ENC] => => 4 bytes @ 0x7fc23c000da0 Mar 7 19:43:54 16[ENC] 0: 81 CB 7D EB
The transform substructure format can be found in RFC4306 Section 3.3.2. The first byte in the header is either a 0 or a 3, and indicates if it is the last transform substructure. A 3, as seen here indicates that there are more transform substructures to follow. The fourth field in the header (rule 3) indicates the transform type, and may indicate that the substructure contains an encryption algorithm, a pseudo-random function, an integrity algorithm or a Diffie-Hellman group. In this transform, a value of 1 indicates that it is an encryption algorithm transform. Skipping the reserved byte which must be 0, the last rule listed in the log excerpt below is an ID which is assigned to the transform. Each transform ID corresponds to a particular implementation of an algorithm such as using Blowfish for encryption or not using an integrity algorithm. These are all found at IANA IKEv2 Transform Attribute Types listing. A value of 12 as shown below is AES in CBC mode.
Mar 7 19:43:54 16[ENC] parsing rule 8 TRANSFORMS Mar 7 19:43:54 16[ENC] 28 bytes left, parsing recursively TRANSFORM_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] parsing TRANSFORM_SUBSTRUCTURE payload, 96 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 96 bytes @ 0x7fc23c000a74 Mar 7 19:43:54 16[ENC] parsing rule 0 U_INT_8 Mar 7 19:43:54 16[ENC] => 3 Mar 7 19:43:54 16[ENC] parsing rule 1 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 2 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => 12 Mar 7 19:43:54 16[ENC] parsing rule 3 U_INT_8 Mar 7 19:43:54 16[ENC] => 1 Mar 7 19:43:54 16[ENC] parsing rule 4 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 5 U_INT_16 Mar 7 19:43:54 16[ENC] => 12
In keeping with the hierarchical nature of the SA payload, there is yet another level of nesting which contains all of the attributes of the aforementioned transform. This contains a TV type structure which is normally just used to specify key lengths when needed. This particular attribute is specifying a key length of 128 bits to be used with the transformation substructure that it's attached to.
Mar 7 19:43:54 16[ENC] parsing rule 6 TRANSFORM_ATTRIBUTES Mar 7 19:43:54 16[ENC] 4 bytes left, parsing recursively TRANSFORM_ATTRIBUTE Mar 7 19:43:54 16[ENC] parsing TRANSFORM_ATTRIBUTE payload, 88 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 88 bytes @ 0x7fc23c000a7c Mar 7 19:43:54 16[ENC] parsing rule 0 ATTRIBUTE_FORMAT Mar 7 19:43:54 16[ENC] => 1 Mar 7 19:43:54 16[ENC] parsing rule 1 ATTRIBUTE_TYPE Mar 7 19:43:54 16[ENC] => 14 Mar 7 19:43:54 16[ENC] parsing rule 2 ATTRIBUTE_LENGTH_OR_VALUE Mar 7 19:43:54 16[ENC] => 128 Mar 7 19:43:54 16[ENC] parsing rule 3 ATTRIBUTE_VALUE Mar 7 19:43:54 16[ENC] parsing TRANSFORM_ATTRIBUTE payload finished
We find another transform substructure, this one for an integrity algorithm which is AUTH_HMAC_SHA1_96.
Mar 7 19:43:54 16[ENC] parsing TRANSFORM_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] 16 bytes left, parsing recursively TRANSFORM_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] parsing TRANSFORM_SUBSTRUCTURE payload, 84 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 84 bytes @ 0x7fc23c000a80 Mar 7 19:43:54 16[ENC] parsing rule 0 U_INT_8 Mar 7 19:43:54 16[ENC] => 3 Mar 7 19:43:54 16[ENC] parsing rule 1 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 2 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => 8 Mar 7 19:43:54 16[ENC] parsing rule 3 U_INT_8 Mar 7 19:43:54 16[ENC] => 3 Mar 7 19:43:54 16[ENC] parsing rule 4 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 5 U_INT_16 Mar 7 19:43:54 16[ENC] => 2
This transform substructure has no attributes.
Mar 7 19:43:54 16[ENC] parsing rule 6 TRANSFORM_ATTRIBUTES Mar 7 19:43:54 16[ENC] parsing TRANSFORM_SUBSTRUCTURE payload finished
The last transform specifies if Extended Sequence Numbers (ESN) are to be used or not. In this case they will not be used (rule 5 = 0). This transform substructure also has no attributes.
Mar 7 19:43:54 16[ENC] 8 bytes left, parsing recursively TRANSFORM_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] parsing TRANSFORM_SUBSTRUCTURE payload, 76 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 76 bytes @ 0x7fc23c000a88 Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 1 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 2 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => 8 Mar 7 19:43:54 16[ENC] parsing rule 3 U_INT_8 Mar 7 19:43:54 16[ENC] => 5 Mar 7 19:43:54 16[ENC] parsing rule 4 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 5 U_INT_16 Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 6 TRANSFORM_ATTRIBUTES Mar 7 19:43:54 16[ENC] parsing TRANSFORM_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] parsing PROPOSAL_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] parsing SECURITY_ASSOCIATION payload finished
Next the responder comes to the traffic selector payloads, starting first with the initiator's side. The traffic selector payload is structured in a way that it can carry multiple traffic selectors. Rule 10 in the log excerpt below corresponds with the "Number of TSs" field in the payload header, which in this case is one.
Mar 7 19:43:54 16[ENC] parsing TRAFFIC_SELECTOR_INITIATOR payload, 68 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 68 bytes @ 0x7fc23c000a90 Mar 7 19:43:54 16[ENC] parsing rule 0 U_INT_8 Mar 7 19:43:54 16[ENC] => 45 Mar 7 19:43:54 16[ENC] parsing rule 1 FLAG Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 2 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 3 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 4 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 5 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 6 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 7 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 8 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 9 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => 24 Mar 7 19:43:54 16[ENC] parsing rule 10 U_INT_8 Mar 7 19:43:54 16[ENC] => 1 Mar 7 19:43:54 16[ENC] parsing rule 11 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 12 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 13 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 14 TRAFFIC_SELECTORS
Each traffic selector is identified in it's own separate subpayload, the traffic selector substructure as defined in RFC4306 Section 3.13.1. The payload here really a range of traffic that will match the Traffic Selector. It starts with a type, which identifies the Traffic Selector as using IPv4, IPv6 or even Fibre Channel. The range starts with the IP protocol (TCP, UDP, ICMP, etc), then the start port and end port and finally a starting and ending address range. The addresses can be either IPv4 or IPv6. Decoding the following values, we find this is a specifies a TY_TYPE of 7 which is an IPv4 address range. A zero value for the IP protocol means that it is not relevent for this particular Traffic Selector and can carry all protocols. We see that the port range specifies the entire range of ports from 0 to 65535; and the address range covers all IPv4 addresses.
Mar 7 19:43:54 16[ENC] 16 bytes left, parsing recursively TRAFFIC_SELECTOR_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] parsing TRAFFIC_SELECTOR_SUBSTRUCTURE payload, 60 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 60 bytes @ 0x7fc23c000a98 Mar 7 19:43:54 16[ENC] parsing rule 0 TS_TYPE Mar 7 19:43:54 16[ENC] => 7 Mar 7 19:43:54 16[ENC] parsing rule 1 U_INT_8 Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 2 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => 16 Mar 7 19:43:54 16[ENC] parsing rule 3 U_INT_16 Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 4 U_INT_16 Mar 7 19:43:54 16[ENC] => 65535 Mar 7 19:43:54 16[ENC] parsing rule 5 ADDRESS Mar 7 19:43:54 16[ENC] => => 4 bytes @ 0x7fc23c005440 Mar 7 19:43:54 16[ENC] 0: 00 00 00 00 .... Mar 7 19:43:54 16[ENC] parsing rule 6 ADDRESS Mar 7 19:43:54 16[ENC] => => 4 bytes @ 0x7fc23c005460 Mar 7 19:43:54 16[ENC] 0: FF FF FF FF .... Mar 7 19:43:54 16[ENC] parsing TRAFFIC_SELECTOR_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] parsing TRAFFIC_SELECTOR_INITIATOR payload finished
Next we come to the traffic selector for the responder as specified by the initiator. We find that aside from a different payload type that indicates it is for the responder, all of the values match the previous TS payload.
Mar 7 19:43:54 16[ENC] parsing TRAFFIC_SELECTOR_RESPONDER payload, 44 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 44 bytes @ 0x7fc23c000aa8 Mar 7 19:43:54 16[ENC] parsing rule 0 U_INT_8 Mar 7 19:43:54 16[ENC] => 41 Mar 7 19:43:54 16[ENC] parsing rule 1 FLAG Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 2 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 3 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 4 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 5 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 6 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 7 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 8 RESERVED_BIT Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 9 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => 24 Mar 7 19:43:54 16[ENC] parsing rule 10 U_INT_8 Mar 7 19:43:54 16[ENC] => 1 Mar 7 19:43:54 16[ENC] parsing rule 11 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 12 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 13 RESERVED_BYTE Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 14 TRAFFIC_SELECTORS Mar 7 19:43:54 16[ENC] 16 bytes left, parsing recursively TRAFFIC_SELECTOR_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] parsing TRAFFIC_SELECTOR_SUBSTRUCTURE payload, 36 bytes left Mar 7 19:43:54 16[ENC] parsing payload from => 36 bytes @ 0x7fc23c000ab0 Mar 7 19:43:54 16[ENC] parsing rule 0 TS_TYPE Mar 7 19:43:54 16[ENC] => 7 Mar 7 19:43:54 16[ENC] parsing rule 1 U_INT_8 Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 2 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => 16 Mar 7 19:43:54 16[ENC] parsing rule 3 U_INT_16 Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] parsing rule 4 U_INT_16 Mar 7 19:43:54 16[ENC] => 65535 Mar 7 19:43:54 16[ENC] parsing rule 5 ADDRESS Mar 7 19:43:54 16[ENC] => => 4 bytes @ 0x7fc23c0056c0 Mar 7 19:43:54 16[ENC] 0: 00 00 00 00 .... Mar 7 19:43:54 16[ENC] parsing rule 6 ADDRESS Mar 7 19:43:54 16[ENC] => => 4 bytes @ 0x7fc23c0056e0 Mar 7 19:43:54 16[ENC] 0: FF FF FF FF .... Mar 7 19:43:54 16[ENC] parsing TRAFFIC_SELECTOR_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] parsing TRAFFIC_SELECTOR_RESPONDER payload finished
Next the responder parses through the remaining couple of nofications.
Mar 7 19:43:54 16[ENC] parsing NOTIFY payload, 20 bytes left Mar 7 19:43:54 16[ENC] parsing NOTIFY payload finished Mar 7 19:43:54 16[ENC] parsing NOTIFY payload, 12 bytes left Mar 7 19:43:54 16[ENC] parsing NOTIFY payload finished
Next the responder begins to note items it needs in it's response. This will be the final packet in the initial child SA, and will be packaged together with the final response of the initial exchganes as well. First the last of the initial exchanges are prepared: the identity of the responder and it's authentication payload.
Mar 7 19:43:54 16[ENC] added payload of type ID_RESPONDER to message Mar 7 19:43:54 16[ENC] added payload of type AUTHENTICATION to message
At this time the responder has officially declared it's end of the IKEv2 initial session established and ready to use!
Mar 7 19:43:54 16[IKE] IKE_SA srx-13[1] established between 10.80.80.80[10.80.80.80]...10.80.80.13[10.80.80.13] Mar 7 19:43:54 16[IKE] IKE_SA srx-13[1] state change: CONNECTING => ESTABLISHED
Next we can see strongSwan actually settting up the Security Association Database (SAD)in the Linux kernel to protect related traffic that matches the traffic selctors with the algorightms agreed upon. The traffic selctors that the responder is using is a subset of the ones the initiator is using, so they are installed witout a problem in the SAD.
Mar 7 19:43:54 16[KNL] sending XFRM_MSG_ALLOCSPI: => 248 bytes @ 0x7fc24d693660
Mar 7 19:43:54 16[KNL] got SPI c9c54fcc for reqid {1}
Mar 7 19:43:54 16[KNL] adding SAD entry with SPI c9c54fcc and reqid {1}
Mar 7 19:43:54 16[KNL] sending XFRM_MSG_UPDSA: => 420 bytes @ 0x7fc24d6935c0
Mar 7 19:43:54 16[CHD] adding outbound ESP SA
Mar 7 19:43:54 16[CHD] SPI 0x81cb7deb, src 10.80.80.80 dst 10.80.80.13
Mar 7 19:43:54 16[KNL] adding SAD entry with SPI 81cb7deb and reqid {1}
Mar 7 19:43:54 16[KNL] sending XFRM_MSG_NEWSA: => 420 bytes @ 0x7fc24d6935c0
Mar 7 19:43:54 16[KNL] adding policy 1.0.0.0/8 === 2.0.0.0/8 out
Mar 7 19:43:54 16[KNL] sending XFRM_MSG_NEWPOLICY: => 252 bytes @ 0x7fc24d693640
Mar 7 19:43:54 16[KNL] adding policy 2.0.0.0/8 === 1.0.0.0/8 in
Mar 7 19:43:54 16[KNL] sending XFRM_MSG_NEWPOLICY: => 252 bytes @ 0x7fc24d693640
Mar 7 19:43:54 16[KNL] adding policy 2.0.0.0/8 === 1.0.0.0/8 fwd
Mar 7 19:43:54 16[KNL] sending XFRM_MSG_NEWPOLICY: => 252 bytes @ 0x7fc24d693640
Mar 7 19:43:54 16[KNL] getting a local address in traffic selector 1.0.0.0/8
Mar 7 19:43:54 16[KNL] no local address found in traffic selector 1.0.0.0/8
Mar 7 19:43:54 16[ENC] added payload of type SECURITY_ASSOCIATION to message
Mar 7 19:43:54 16[ENC] added payload of type TRAFFIC_SELECTOR_INITIATOR to message
Mar 7 19:43:54 16[ENC] added payload of type TRAFFIC_SELECTOR_RESPONDER to message
And after installing the transformations into the Kernel structures via the SAD, it declares the Child SA established.
Mar 7 19:43:54 16[IKE] CHILD_SA srx-13{1} established with SPIs c9c54fcc_i 81cb7deb_o and TS 1.0.0.0/8 === 2.0.0.0/8
Now the only thing left to do is formulate the response packet. The Security Association message and the Traffic Selectors are part of the initial CHILD_SA, and the ID and Authentication are part of the AUTH exchange.
Mar 7 19:43:54 16[ENC] added payload of type NOTIFY to message Mar 7 19:43:54 16[ENC] added payload of type ID_RESPONDER to message Mar 7 19:43:54 16[ENC] added payload of type AUTHENTICATION to message Mar 7 19:43:54 16[ENC] added payload of type SECURITY_ASSOCIATION to message Mar 7 19:43:54 16[ENC] added payload of type TRAFFIC_SELECTOR_INITIATOR to message Mar 7 19:43:54 16[ENC] added payload of type TRAFFIC_SELECTOR_RESPONDER to message Mar 7 19:43:54 16[ENC] added payload of type NOTIFY to message Mar 7 19:43:54 16[ENC] generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) ] Mar 7 19:43:54 16[ENC] insert payload ID_RESPONDER to encryption payload Mar 7 19:43:54 16[ENC] insert payload AUTHENTICATION to encryption payload Mar 7 19:43:54 16[ENC] insert payload SECURITY_ASSOCIATION to encryption payload Mar 7 19:43:54 16[ENC] insert payload TRAFFIC_SELECTOR_INITIATOR to encryption payload Mar 7 19:43:54 16[ENC] insert payload TRAFFIC_SELECTOR_RESPONDER to encryption payload Mar 7 19:43:54 16[ENC] insert payload NOTIFY to encryption payload
The header of the packet, and the remaining payloads that belong to the Auth portion of the initial exchanges are generated.
Mar 7 19:43:54 16[ENC] generating HEADER payload finished Mar 7 19:43:54 16[ENC] generating payload of type ID_RESPONDER Mar 7 19:43:54 16[ENC] generating ID_RESPONDER payload finished Mar 7 19:43:54 16[ENC] generating payload of type AUTHENTICATION Mar 7 19:43:54 16[ENC] generating AUTHENTICATION payload finished
And then the SA payload is created, echoing back to the initiator the proposal which was selected for use.
Mar 7 19:43:54 16[ENC] generating payload of type SECURITY_ASSOCIATION Mar 7 19:43:54 16[ENC] generating rule 10 PROPOSALS Mar 7 19:43:54 16[ENC] generating payload of type PROPOSAL_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] generating rule 8 TRANSFORMS Mar 7 19:43:54 16[ENC] generating payload of type TRANSFORM_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] generating rule 6 TRANSFORM_ATTRIBUTES Mar 7 19:43:54 16[ENC] generating payload of type TRANSFORM_ATTRIBUTE Mar 7 19:43:54 16[ENC] generating TRANSFORM_ATTRIBUTE payload finished Mar 7 19:43:54 16[ENC] generating TRANSFORM_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] generating payload of type TRANSFORM_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] generating rule 6 TRANSFORM_ATTRIBUTES Mar 7 19:43:54 16[ENC] generating TRANSFORM_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] generating payload of type TRANSFORM_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] generating rule 6 TRANSFORM_ATTRIBUTES Mar 7 19:43:54 16[ENC] generating TRANSFORM_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] generating PROPOSAL_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] generating SECURITY_ASSOCIATION payload finished
And then the Traffic Selectors that the initiator will be using are generated. Decoding the values, we find that the traffic selector is the same, except that the range only covers the 2.0.0.0/8 subnet.
Mar 7 19:43:54 16[ENC] generating payload of type TRAFFIC_SELECTOR_INITIATOR Mar 7 19:43:54 16[ENC] generating rule 14 TRAFFIC_SELECTORS Mar 7 19:43:54 16[ENC] generating payload of type TRAFFIC_SELECTOR_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] generating rule 0 TS_TYPE Mar 7 19:43:54 16[ENC] => 7 Mar 7 19:43:54 16[ENC] generating rule 1 U_INT_8 Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] generating rule 2 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => => 2 bytes @ 0x7fc24d69388e Mar 7 19:43:54 16[ENC] 0: 00 10 .. Mar 7 19:43:54 16[ENC] generating rule 3 U_INT_16 Mar 7 19:43:54 16[ENC] => => 2 bytes @ 0x7fc24d69388e Mar 7 19:43:54 16[ENC] 0: 00 00 .. Mar 7 19:43:54 16[ENC] generating rule 4 U_INT_16 Mar 7 19:43:54 16[ENC] => => 2 bytes @ 0x7fc24d69388e Mar 7 19:43:54 16[ENC] 0: FF FF .. Mar 7 19:43:54 16[ENC] generating rule 5 ADDRESS Mar 7 19:43:54 16[ENC] => => 4 bytes @ 0x7fc23c008dc0 Mar 7 19:43:54 16[ENC] 0: 02 00 00 00 .... Mar 7 19:43:54 16[ENC] generating rule 6 ADDRESS Mar 7 19:43:54 16[ENC] => => 4 bytes @ 0x7fc23c008de0 Mar 7 19:43:54 16[ENC] 0: 02 FF FF FF .... Mar 7 19:43:54 16[ENC] generating TRAFFIC_SELECTOR_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] generated data for this payload => 16 bytes @ 0x7fc23c007abc Mar 7 19:43:54 16[ENC] 0: 07 00 00 10 00 00 FF FF 02 00 00 00 02 FF FF FF ................ Mar 7 19:43:54 16[ENC] generating TRAFFIC_SELECTOR_INITIATOR payload finished
We find much the same thing with the Traffic Selector for the responder, except that the range is just the 1.0.0.0/8 subnet.
Mar 7 19:43:54 16[ENC] generating payload of type TRAFFIC_SELECTOR_RESPONDER Mar 7 19:43:54 16[ENC] generating rule 14 TRAFFIC_SELECTORS Mar 7 19:43:54 16[ENC] generating payload of type TRAFFIC_SELECTOR_SUBSTRUCTURE Mar 7 19:43:54 16[ENC] generating rule 0 TS_TYPE Mar 7 19:43:54 16[ENC] => 7 Mar 7 19:43:54 16[ENC] generating rule 1 U_INT_8 Mar 7 19:43:54 16[ENC] => 0 Mar 7 19:43:54 16[ENC] generating rule 2 PAYLOAD_LENGTH Mar 7 19:43:54 16[ENC] => => 2 bytes @ 0x7fc24d69388e Mar 7 19:43:54 16[ENC] 0: 00 10 .. Mar 7 19:43:54 16[ENC] generating rule 3 U_INT_16 Mar 7 19:43:54 16[ENC] => => 2 bytes @ 0x7fc24d69388e Mar 7 19:43:54 16[ENC] 0: 00 00 .. Mar 7 19:43:54 16[ENC] generating rule 4 U_INT_16 Mar 7 19:43:54 16[ENC] => => 2 bytes @ 0x7fc24d69388e Mar 7 19:43:54 16[ENC] 0: FF FF .. Mar 7 19:43:54 16[ENC] generating rule 5 ADDRESS Mar 7 19:43:54 16[ENC] => => 4 bytes @ 0x7fc23c009040 Mar 7 19:43:54 16[ENC] 0: 01 00 00 00 .... Mar 7 19:43:54 16[ENC] generating rule 6 ADDRESS Mar 7 19:43:54 16[ENC] => => 4 bytes @ 0x7fc23c009060 Mar 7 19:43:54 16[ENC] 0: 01 FF FF FF .... Mar 7 19:43:54 16[ENC] generating TRAFFIC_SELECTOR_SUBSTRUCTURE payload finished Mar 7 19:43:54 16[ENC] generated data for this payload => 16 bytes @ 0x7fc23c007ad4 Mar 7 19:43:54 16[ENC] 0: 07 00 00 10 00 00 FF FF 01 00 00 00 01 FF FF FF ................ Mar 7 19:43:54 16[ENC] generating TRAFFIC_SELECTOR_RESPONDER payload finished
And finally a notify payload is created indicating the lifetime of the SA, which converted from hex is 85395 seconds.
Mar 7 19:43:54 16[ENC] generating payload of type NOTIFY Mar 7 19:43:54 16[ENC] generating NOTIFY payload finished
Next the responder encrypts the packet and the sensitive information within such as the ID of the responder and the authentication payload.
Mar 7 19:43:54 16[ENC] generated content in encryption payload Mar 7 19:43:54 16[ENC] encryption payload encryption: Mar 7 19:43:54 16[ENC] generating payload of type ENCRYPTED
At this point, the finite state machine actions at this phase are:
The responder processes authentication, identities, selects a proposal and installs the SA.
And finally the responder sends the fourth and final packet back to the intiiator.
Mar 7 19:43:54 16[NET] sending packet: from 10.80.80.80[500] to 10.80.80.13[500]
Packet #4: IKEv2 packet sent to initiator.
We finish things up with the formation of this particular Child SA with the receipt of the last packet in the exchange by the initiator.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] *** Processing received packet from 10.80.80.80:500 to 10.80.80.13:0 VR 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_packet_st_input_start: [8c39400/0] Processing received [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Found IKEv2 P1 SA 3283989 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ssh_ikev2_ike_sa_take_ref: Calling ike_sa_take_ref [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Taking reference to P1 SA 3283989 to ref count 3 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_packet_st_input_get_or_create_sa: [8c39400/8c9f400] Packet to existing v2 SA
The SRX decrypts the encrypted payloads, finds the last tidbits of the auth exchange, namely the ID of the responder and a proof that it indeed the correct endpoint via an authentication check.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_packet: [8c39400/8c9f400] Decoding packet [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_packet: [8c39400/8c9f400] Encrypted packet [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_encr: Mac input [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_encr: [8c39400/8c9f400] Packet decrypted successfully [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_packet: [8c39400/8c9f400] We have old context [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_id: [8c39400/8c9f400] IDr(type = ipv4 (1), len = 4, value = 10.80.80.80) [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_auth: [8c39400/8c9f400] AUTH(method = Shared key (2), len = 20, data = 2b970008 6630c552 566a469f dd8ee5e7 07a46fc5)
The initiating SRX receives confirmation that it's proposal for traffic protection has been accepted, and it receives the traffic selectors from the responder as well.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_sa: [8c39400/8c9f400] SA([0](id = 1) protocol = ESP (3), spi_len = 4, spi = 0xc9c54fcc, AES CBC key len = 128, HMAC-SHA1-96, No ESN; ) [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ssh_ikev2_ts_allocate: Allocated ts 0x8bf34c0, ref_cnt 1 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_ts: [8c39400/8c9f400] TSi(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 2.0.0.0 - 2.255.255.255; ) [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ssh_ikev2_ts_allocate: Allocated ts 0x8bf3e20, ref_cnt 1 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_decode_ts: [8c39400/8c9f400] TSr(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 1.0.0.0 - 1.255.255.255; )
Before the initiator does anything else, it needs to verify the identity of the responder, which checks out fine.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_reply_cb_shared_key_auth_verify: [8c39400/8c9f400] Auth payload ok [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_in_eap: [8c39400/8c9f400] State = AUTH_LAST
Since the authentication check passed, it can proceed with finishing off the establishment of the child SA. This is done afterwards so as not to waste any precious CPU cycles on a bad exchange. It checks out the security association payload, and the two traffic selector payloads. Seeing no problems, it goes ahead and installs the SA.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_in_eap: [8c39400/8c9f400] SAr2, TSi, or TSr, so this is final packet [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_in_sa: [8c39400/8c9f400] Verify SAr2 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_in_sa: [8c39400/8c9f400] SAr2 was ok [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ssh_ikev2_ts_free: ts 0x8bf33c0, ref_cnt 1 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ssh_ikev2_ts_free: ts 0x8bf33e0, ref_cnt 1 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_in_ts: [8c39400/8c9f400] TSi and TSr were ok [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ikev2_state_auth_initiator_in_done: Calling ipsec_sa_install [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] iked_pm_ipsec_sa_install: local:10.80.80.13, remote:10.80.80.80 IKEv2 for SA-CFG SERVER-BOX [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Parsing notification payload for local:10.80.80.13, remote:10.80.80.80 IKEv2
In the log messages below, we can see the initiator actually installing the traffic protection parameters into the forwarding tables and binding them to the secure tunnel interface st0.80.
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Setting lifetime 1200 and lifesize 0 for IPSec SA [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] iked_pm_ipsec_sa_create: encr key len 16, auth key len: 20, salt len: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Creating a SA spi=0x81cb7deb, proto=ESP pair_index = 1 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Added (spi=0x81cb7deb, protocol=ESP dst=10.80.80.13) entry to the peer hash table [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] iked_sa_cfg_update_sa_cfg_child_sa_count Parent not found for sa_cfg SERVER-BOX [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] iked_lookup_peer_entry: Peer entry 0x8c95200 FOUND for local 10.80.80.13:500 and remote 10.80.80.80:500 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Peer entry exist for local 10.80.80.13:500 and remote 10.80.80.80:500 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] iked_peer_insert_sa_cfg_entry: insert sa_cfg tunnel_id entry 131074 into peer entry 0x8c95200 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Creating a SA spi=0xc9c54fcc, proto=ESP pair_index = 1 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Added (spi=0xc9c54fcc, protocol=ESP dst=10.80.80.80) entry to the peer hash table [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] iked_sa_cfg_update_sa_cfg_child_sa_count Parent not found for sa_cfg SERVER-BOX [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] iked_nhtb_update_on_sa_create: Interface st0.80 is P2P for sa_cfg SERVER-BOX. Thus ignoring NHTB notification message
And finally we get the celebratory message, declaring the entire IKEv2 session up!
[Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ----------------Voyager ipsec SA BUNDLE------------------- [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] SA pair update request for: Tunnel index: 131074 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Local Gateway address: 10.80.80.13 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Primary remote Gateway address: 10.80.80.80 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Backup remote Gateway State: Active [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Anti replay: counter-based enabled [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Window_size: 64 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Server Time: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Peer : Static [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Mode : Tunnel [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] VPN Type : route-based [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Tunnel mtu: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] DF bit: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] local-if ifl idx: 1207959552 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] tunnel-if ifl idx: 1291845632 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Tunnel mtu: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] DPD interval: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] policy id: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] NATT enabled: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] NATT version: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] NAT position: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] SA Idle time: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] SA Outbound install delay time: 1 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] IKED ID: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] DIST ID: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Keepalive interval: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] VPN monitoring interval: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] VPN monitoring optimized: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Respond-bad-SPI: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] seq_out: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Local port: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Remote port: 500 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] SA CFG name: SERVER-BOX [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Dial-up IKE ID: [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] RG ID: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Group template tunnel ID: 0 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ----------------Incoming SA ------------------- [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] SPI: 0x81cb7deb Protocol: 2 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Algorithm: 130 Auth key. length: 20 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Encr key. length; 16 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] ----------------Outgoing SA ------------------- [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] SPI: 0xc9c54fcc Protocol: 2 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Algorithm: 130 Auth key. length: 20 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Encr key. length; 16 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] In iked_ipsec_sa_pair_add Adding GENCFG msg with key; Tunnel = 131074;SPI-In = 0x81cb7deb [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Added dependency on SA config blob with tunnelid = 131074 [Mar 5 06:43:53][10.80.80.13 <-> 10.80.80.80] Successfully added ipsec SA PAIR
So at this point, both peers are ready to start encrypting and decrypting network traffic to each other. Our last finite state machine box for the exchange is:
The final step of the IKEv2 finite state machine.
Initiator verifies responder's identity, installs CHILD_SA .
The REKEY Security Association (REKEY_SA)
Child SA's can also exist outside of the initial exchanges. One of these is use for rekeying an existing SA, that is generating a fresh set of keying material for a traffic protection profile. Rekeying cuts down on the chance that an eavesdropper has managed to figure out what the secret key for the session is. If an eavesdropper has happened upon it, changing the secret keys will limit the amount of network traffic that can be examined.
We'll take a quick look through an IKEv2 session that performed a REKEY to see some of the mechanics.
[edit security] juniper@SRX-13# run show security ipsec security-associations Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <131074 ESP:aes-cbc-128/sha1 2ad4c0a2 159/ unlim - root 500 10.80.80.80 >131074 ESP:aes-cbc-128/sha1 cae7019f 159/ unlim - root 500 10.80.80.80 [edit security] juniper@SRX-13#
An IKEv2 exchange with a REKEY_SA between our two peers, 10.80.80.13 and 10.80.80.80, has been captured with tcpdump in this pcap file.. The initiator of the exchange is 10.80.80.13 again, and has logged it's debug data to IKEv2_REKEY_SA.log. The responder has logged it's session to charon_REKEY_SA.log.
Since all CHILD_SAs occurr through the secure channel setup by the intitial exchanges, we need to decrypt the payloads in the packet capture in order to see anything interesting. Pulling the keys from the strongSwan logs, we find the following parameters that can be plugged into Wireshark:
Secret values to decrypt IKEv2_CHILD_SA_REKEY.pcap with Wireshark
| SPIi | 5f54bf6d8b48e6e1 |
| SPIr | 909232b3d1edcb5c |
| Sk_ai | 554FBF5A05B7F511E05A30CE23D874DB9EF55E51 |
| Sk_ar | 36D83420788337CA32ECAA46892C48808DCD58B1 |
| Sk_ei | 5CBFD33F75796C0188C4A3A546AEC4A1 |
| Sk_er | C33B35FCF29514CD9D8B4A695E1A816E |
Once we plug these values into the IKEv2 decryption table in Wireshark, we can peer inside the CHILD_SA packet and see what makes up the REKEY_SA.
RFC4306 section 2.8 outlines the rekeying procedure for IKEv2. Rekeying is an option in IKEv2 that should be supported by an IKEv2 implementation. If it is not supported, an SA can expire an a new one can be renegotiated by the peers but this can lead to some interruptions in network traffic while the new SA is being set up. To avoid this and ensure continuous operations, SAs can be refreshed with new keying material by establishing a new CHILD_SA that is equivalent to an existing one, and once it's established the old one can be deleted.
A big difference between IKEv1 and IKEv2 comes into play with the REKEY_SA as well. In IKEv1, SA lifetimes are a negotiated parameter that both keys have to agree upon. In IKEv2, each peer can have a different idea of the lifetime of the SA. In practice, the peer with the shorter SA lifetime will wind up initiating most of the rekeying operations. Each is also supposed to stagger and jitter their lifetimes in order to avoid any collisions if both peers have the same SA lifetime thus avoiding the chance of duplicate SAs.
Looking at this particular exchange, examining the logs and configuration files we find that the both the SRX and the strongSwan client have a lifetime of 180 seconds. The peer that becomes the initiator of the SA, will be the one that jitters earliest -- which happens to be the SRX which starts the rekey procedure about 88 seconds into the life of the SA.
[Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] IPSec rekey initiated for sa_cfg SERVER-BOX with inbound spi 0x2ad4c0a2
The rekey uses a notification payload to indicate that an existing SA will be replaced. The notification payalod type for a REKEY_SA is 16393, and the SPI indicates which existing SA will be replaced. The notification data is empty for a REKEY_SA.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We can see below that the SRX is creating the notify payload, referencing SPI 2ad4c0a2.
[Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_state_child_initiator_out_rekey_n: [8c3c000/8c76800] Adding N(REKEY_SA) [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_encode_notify: [8c3c000/8c76800] N(type = Rekey SA (16393), protocol = ESP (3), spi_len = 4, spi = 2ad4c0a2, data_len = 0 data = )
Next, the initiator of the rekey, proceeds to process the creation of a CHILD_SA as normal, filling in an SA payload, calculating a new nonce and optionally including Traffic Selector payloads. If Perfect Forward Secrecy (PFS) is in use, a completely new Diffie-Hellman-Merkel key exchange will also take place and a new Key Exchange payload will be included as well. Since all keying material is derived from exisiting keying material if an eavesdropper actually figures out all of the parameters needed to generate SKEYSEED it could then derive all of the new keying material as well. SKEYSEED if you recall is generated by running the Nonces from the initiator and responder and the Diffie-Hellman-Merkel shared secret value through the pseudo-random function. PFS will help guard against the eavesdropper being able to further derive the new keying material as every time an SA is rekeyed, the eavesdropper would also have to figure out what the new shared Diffie-Hellman secret. From the logs we can see that the SRX creates an SA payload, a new nonce and adds the traffic selectors. PFS was not configured for this session, so there is no new Key Exchange packet. Note that a new SPI has been generated to differentiate this SA from any previous ones.
[Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_state_child_initiator_out_sa: [8c3c000/8c76800] Adding SAi [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_encode_sa: [8c3c000/8c76800] SA([0](id = 1) protocol = ESP (3), AES CBC key len = 128, HMAC-SHA1-96, No ESN; ) [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_encode_sa: IPsec SPI = 0x57a09b0f [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_create_nonce_and_add: [8c3c000/8c76800] Adding NONCE [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_encode_nonce: [8c3c000/8c76800] NONCE(len = 32, data = b96503e9 fa0d492b a993c7eb 0b69e161 610aa032 d2782ebc dd554865 ed439b18) [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_find_policy_group: [8c3c000/8c76800] N(INVALID_KE_PAYLOAD) found, with invalid group = 2 [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_state_child_initiator_out_ts: [8c3c000/8c76800] Adding TSi [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_encode_ts: [8c3c000/8c76800] TS(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 0.0.0.0 - 255.255.255.255; ) [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_state_child_initiator_out_ts: [8c3c000/8c76800] Adding TSr [Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_encode_ts: [8c3c000/8c76800] TS(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 0.0.0.0 - 255.255.255.255; )
A finite state machine representation of the REKEY_SA, starting with the initiator's actions is summarized by the following:
Initiator Requess a Rekey.
And the SRX sends the packet containing the REKEY message off to the responder.
[Mar 17 20:06:01][10.80.80.13 <-> 10.80.80.80] ikev2_udp_send_packet: [8c3c000/8c76800] Sending packet using VR id 0
Packet #5: REKEY_SA request sent to responder.
The responder recieves the rekey request from the initiator in the form of a CREATE_CHILD_SA request.
Mar 17 20:06:02 09[ENC] parsing header of message Mar 17 20:06:02 09[ENC] parsing HEADER payload, 204 bytes left Mar 17 20:06:02 09[ENC] parsing payload from => 204 bytes @ 0x7f94e4002a60 Mar 17 20:06:02 09[ENC] parsing rule 0 IKE_SPI Mar 17 20:06:02 09[ENC] parsing rule 1 IKE_SPI Mar 17 20:06:02 09[ENC] parsed a CREATE_CHILD_SA request Mar 17 20:06:02 13[NET] received packet: from 10.80.80.13[500] to 10.80.80.80[500]
It decrypts the encrypted payloads to see what's inside and first finds the notify payload.
Mar 17 20:06:02 13[ENC] parsing body of message, first payload is ENCRYPTED Mar 17 20:06:02 13[ENC] starting parsing a ENCRYPTED payload Mar 17 20:06:02 13[ENC] parsing ENCRYPTED payload finished Mar 17 20:06:02 13[ENC] verifying payload of type ENCRYPTED Mar 17 20:06:02 13[ENC] ENCRYPTED payload verified. Adding to payload list Mar 17 20:06:02 13[ENC] ENCRYPTED payload found. Stop parsing Mar 17 20:06:02 13[ENC] process payload of type ENCRYPTED Mar 17 20:06:02 13[ENC] found an encryption payload Mar 17 20:06:02 13[ENC] encryption payload decryption: Mar 17 20:06:02 13[ENC] parsing NOTIFY payload, 140 bytes left
It parses the contents of the notification payload. Matching up the values in the header of the nofication payload from RFC4306 Section 3.10 and bouncing the values off the IANA IKEv2 Notify Message Types we find that the notify message type is 16393, which is the REKEY_SA for the SPI contained in rule 13, 0x2AD4C0A2.
Mar 17 20:06:02 13[ENC] parsing NOTIFY payload, 140 bytes left Mar 17 20:06:02 13[ENC] parsing payload from => 140 bytes @ 0x7f94ec000af0 Mar 17 20:06:02 13[ENC] parsing rule 0 U_INT_8 Mar 17 20:06:02 13[ENC] => 33 Mar 17 20:06:02 13[ENC] parsing rule 1 FLAG Mar 17 20:06:02 13[ENC] => 0 Mar 17 20:06:02 13[ENC] parsing rule 2 RESERVED_BIT Mar 17 20:06:02 13[ENC] => 0 Mar 17 20:06:02 13[ENC] parsing rule 3 RESERVED_BIT Mar 17 20:06:02 13[ENC] => 0 Mar 17 20:06:02 13[ENC] parsing rule 4 RESERVED_BIT Mar 17 20:06:02 13[ENC] => 0 Mar 17 20:06:02 13[ENC] parsing rule 5 RESERVED_BIT Mar 17 20:06:02 13[ENC] => 0 Mar 17 20:06:02 13[ENC] parsing rule 6 RESERVED_BIT Mar 17 20:06:02 13[ENC] => 0 Mar 17 20:06:02 13[ENC] parsing rule 7 RESERVED_BIT Mar 17 20:06:02 13[ENC] => 0 Mar 17 20:06:02 13[ENC] parsing rule 8 RESERVED_BIT Mar 17 20:06:02 13[ENC] => 0 Mar 17 20:06:02 13[ENC] parsing rule 9 PAYLOAD_LENGTH Mar 17 20:06:02 13[ENC] => 12 Mar 17 20:06:02 13[ENC] parsing rule 10 U_INT_8 Mar 17 20:06:02 13[ENC] => 3 Mar 17 20:06:02 13[ENC] parsing rule 11 SPI_SIZE Mar 17 20:06:02 13[ENC] => 4 Mar 17 20:06:02 13[ENC] parsing rule 12 U_INT_16 Mar 17 20:06:02 13[ENC] => 16393 Mar 17 20:06:02 13[ENC] parsing rule 13 SPI Mar 17 20:06:02 13[ENC] => => 4 bytes @ 0x7f94ec000c20 Mar 17 20:06:02 13[ENC] 0: 2A D4 C0 A2 *... Mar 17 20:06:02 13[ENC] parsing rule 14 NOTIFICATION_DATA Mar 17 20:06:02 13[ENC] => => 0 bytes @ (nil) Mar 17 20:06:02 13[ENC] parsing NOTIFY payload finished
Next it loads in the security association payload, the nonce, and the traffic selectors.
Mar 17 20:06:02 13[ENC] parsing SECURITY_ASSOCIATION payload, 128 bytes left Mar 17 20:06:02 13[ENC] parsing SECURITY_ASSOCIATION payload finished Mar 17 20:06:02 13[ENC] parsing NONCE payload, 84 bytes left Mar 17 20:06:02 13[ENC] parsing NONCE payload finished Mar 17 20:06:02 13[ENC] parsing TRAFFIC_SELECTOR_INITIATOR payload, 48 bytes left Mar 17 20:06:02 13[ENC] parsing TRAFFIC_SELECTOR_INITIATOR payload finished Mar 17 20:06:02 13[ENC] parsing TRAFFIC_SELECTOR_RESPONDER payload, 24 bytes left Mar 17 20:06:02 13[ENC] parsing TRAFFIC_SELECTOR_RESPONDER payload finished Mar 17 20:06:02 13[ENC] parsed content of encryption payload Mar 17 20:06:02 13[ENC] process payload of type NOTIFY Mar 17 20:06:02 13[ENC] process payload of type SECURITY_ASSOCIATION Mar 17 20:06:02 13[ENC] process payload of type NONCE Mar 17 20:06:02 13[ENC] process payload of type TRAFFIC_SELECTOR_INITIATOR Mar 17 20:06:02 13[ENC] process payload of type TRAFFIC_SELECTOR_RESPONDER Mar 17 20:06:02 13[ENC] parsed CREATE_CHILD_SA request 2 [ N(REKEY_SA) SA No TSi TSr ]
Acknowleging it has a rekey request, strongSwan creates a new SIP, generates some new keying material and updates all of it's security databases and kernel structures to use the SPIs for the freshly rekeyed SA.
Mar 17 20:06:02 13[KNL] got SPI cd1736b3 for reqid {1}
Mar 17 20:06:02 13[CHD] seed => 64 bytes @ 0x7f94ff99ea30
Mar 17 20:06:02 13[CHD] using AES_CBC for encryption
Mar 17 20:06:02 13[CHD] using HMAC_SHA1_96 for integrity
Mar 17 20:06:02 13[CHD] encryption initiator key => 16 bytes @ 0x7f94ec002530
Mar 17 20:06:02 13[CHD] 0: F9 4F 99 C9 0C C7 77 51 BE 4D 61 FE 3C 38 61 91 .O....wQ.Ma.<8a.
Mar 17 20:06:02 13[CHD] encryption responder key => 16 bytes @ 0x7f94ec002400
Mar 17 20:06:02 13[CHD] 0: E7 6B 52 BC 52 D2 0E C6 AA 5C DD 7B B5 97 38 58 .kR.R....\.{..8X
Mar 17 20:06:02 13[CHD] integrity initiator key => 20 bytes @ 0x7f94ec003c10
Mar 17 20:06:02 13[CHD] 0: 59 29 E4 80 AC 01 B1 26 72 1E 85 BF F7 18 3A 1E Y).....&r.....:.
Mar 17 20:06:02 13[CHD] 16: 2D 55 F1 79 -U.y
Mar 17 20:06:02 13[CHD] integrity responder key => 20 bytes @ 0x7f94ec002420
Mar 17 20:06:02 13[CHD] 0: 07 D3 AA 12 27 49 24 A1 13 20 A4 54 82 6C 12 A4 ....'I$.. .T.l..
Mar 17 20:06:02 13[CHD] 16: 03 15 B7 B7 ....
Mar 17 20:06:02 13[CHD] adding inbound ESP SA
Mar 17 20:06:02 13[CHD] SPI 0xcd1736b3, src 10.80.80.13 dst 10.80.80.80
Mar 17 20:06:02 13[KNL] adding SAD entry with SPI cd1736b3 and reqid {1}
Mar 17 20:06:02 13[KNL] using encryption algorithm AES_CBC with key size 128
Mar 17 20:06:02 13[KNL] using integrity algorithm HMAC_SHA1_96 with key size 160
Mar 17 20:06:02 13[CHD] adding outbound ESP SA
Mar 17 20:06:02 13[CHD] SPI 0x57a09b0f, src 10.80.80.80 dst 10.80.80.13
Mar 17 20:06:02 13[KNL] adding SAD entry with SPI 57a09b0f and reqid {1}
Mar 17 20:06:02 13[KNL] using encryption algorithm AES_CBC with key size 128
Mar 17 20:06:02 13[KNL] using integrity algorithm HMAC_SHA1_96 with key size 160
Mar 17 20:06:02 13[KNL] policy 1.0.0.0/8 === 2.0.0.0/8 out already exists, increasing refcount
Mar 17 20:06:02 13[KNL] adding policy 1.0.0.0/8 === 2.0.0.0/8 out
Mar 17 20:06:02 13[KNL] policy 2.0.0.0/8 === 1.0.0.0/8 in already exists, increasing refcount
Mar 17 20:06:02 13[KNL] adding policy 2.0.0.0/8 === 1.0.0.0/8 in
Mar 17 20:06:02 13[KNL] policy 2.0.0.0/8 === 1.0.0.0/8 fwd already exists, increasing refcount
Mar 17 20:06:02 13[KNL] adding policy 2.0.0.0/8 === 1.0.0.0/8 fwd
Then it formulates a reply back to the initiator, letting it know that the rekey has been accomplished and the SA has been updated with the one that is echoed back to the SRX. It also includes a new nonce, and it's traffic selectors.
>
Mar 17 20:06:02 13[KNL] getting a local address in traffic selector 1.0.0.0/8
Mar 17 20:06:02 13[KNL] no local address found in traffic selector 1.0.0.0/8
Mar 17 20:06:02 13[ENC] added payload of type SECURITY_ASSOCIATION to message
Mar 17 20:06:02 13[ENC] added payload of type NONCE to message
Mar 17 20:06:02 13[ENC] added payload of type TRAFFIC_SELECTOR_INITIATOR to message
Mar 17 20:06:02 13[ENC] added payload of type TRAFFIC_SELECTOR_RESPONDER to message
Mar 17 20:06:02 13[IKE] CHILD_SA srx-13{1} established with SPIs cd1736b3_i 57a09b0f_o and TS 1.0.0.0/8 === 2.0.0.0/8
Mar 17 20:06:02 13[ENC] added payload of type SECURITY_ASSOCIATION to message
Mar 17 20:06:02 13[ENC] added payload of type NONCE to message
Mar 17 20:06:02 13[ENC] added payload of type TRAFFIC_SELECTOR_INITIATOR to message
Mar 17 20:06:02 13[ENC] added payload of type TRAFFIC_SELECTOR_RESPONDER to message
Mar 17 20:06:02 13[ENC] generating CREATE_CHILD_SA response 2 [ SA No TSi TSr ]
Mar 17 20:06:02 13[ENC] insert payload SECURITY_ASSOCIATION to encryption payload
Mar 17 20:06:02 13[ENC] insert payload NONCE to encryption payload
Mar 17 20:06:02 13[ENC] insert payload TRAFFIC_SELECTOR_INITIATOR to encryption payload
Mar 17 20:06:02 13[ENC] insert payload TRAFFIC_SELECTOR_RESPONDER to encryption payload
To summarize the responders steps in a rekey, the finite state machine acommplishes the following.
Responder updates keying material, and sends feedback and a new noce back to the responder.
And the responder sends it's reply, packet #2, the last packet in the REKEY_SA back to the intitiator.
Mar 17 20:06:02 13[NET] sending packet: from 10.80.80.80[500] to 10.80.80.13[500]
Packet #6: IKEv2 packet sent back to initiator.
The final stage in the REKEY_SA starts when the initiator recieves the responder's reply packet.
[Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] *** Processing received packet from 10.80.80.80:500 to 10.80.80.13:0 VR 0
The SRX decrypts the packet so see the juicy payload inside in their unscrambled form.
[Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Found IKEv2 P1 SA 3971005 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_decode_packet: [8c3c400/8c76800] Decoding packet [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_decode_packet: [8c3c400/8c76800] Encrypted packet [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_decode_encr: [8c3c400/8c76800] Packet decrypted successfully [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_decode_packet: [8c3c400/8c76800] We have old context
Looking inside, the SRX finds an SA payload referencing the responders new SPI. It also finds a new nonce, and the traffic selectors.
[Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_decode_sa: [8c3c400/8c76800] SA([0](id = 1) protocol = ESP (3), spi_len = 4, spi = 0xcd1736b3, AES CBC key len = 128, HMAC-SHA1-96, No ESN; ) [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_decode_nonce: [8c3c400/8c76800] NONCE(len = 32, data = 7039f586 74b66f20 0d257a76 6d3662b8 e2e76914 bd06b723 5d110b35 0287cbe3) [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ssh_ikev2_ts_allocate: Allocated ts 0x8bf3e00, ref_cnt 1 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_decode_ts: [8c3c400/8c76800] TSi(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 2.0.0.0 - 2.255.255.255; ) [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ssh_ikev2_ts_allocate: Allocated ts 0x8bf3ea0, ref_cnt 1 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_decode_ts: [8c3c400/8c76800] TSr(# ts = 1, [0] type = ipv4 range (7), protocol = 0, port = any, ip range = 1.0.0.0 - 1.255.255.255; ) [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_decode_packet: [8c3c400/8c76800] Received packet: HDR, SA, Nonce, TSi, TSr [Mar 17 20:06:02]
The SRX checks out the packet contents.
[Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_state_dispatch: [8c3c400/8c76800] Initiator side CREATE_CHILD_SA [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_state_child_initiator_in_sa: [8c3c400/8c76800] Verify SAr2 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_state_child_initiator_in_sa: [8c3c400/8c76800] SAr2 was ok [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ssh_ikev2_ts_free: ts 0x8bf3d40, ref_cnt 1 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ssh_ikev2_ts_free: ts 0x8bf3dc0, ref_cnt 1 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_state_child_initiator_in_ts: [8c3c400/8c76800] TSi and TSr were ok
And finding no problems, it installs the new SA so it can be used.
[Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ikev2_state_child_initiator_in_done: Calling ipsec_sa_install [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] iked_pm_ipsec_sa_install: local:10.80.80.13, remote:10.80.80.80 IKEv2 for SA-CFG SERVER-BOX [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Parsing notification payload for local:10.80.80.13, remote:10.80.80.80 IKEv2 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] iked_update_sa_cfg_port sa_cfg(SERVER-BOX) local_port(0)and remote_port(500) [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Setting lifetime 180 and lifesize 0 for IPSec SA [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] iked_pm_ipsec_sa_create: encr key len 16, auth key len: 20, salt len: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Creating a SA spi=0x57a09b0f, proto=ESP pair_index = 2 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Added (spi=0x57a09b0f, protocol=ESP dst=10.80.80.13) entry to the peer hash table [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] iked_sa_cfg_update_sa_cfg_child_sa_count Parent not found for sa_cfg SERVER-BOX [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] iked_lookup_peer_entry: Peer entry 0x8bf4400 FOUND for local 10.80.80.13:500 and remote 10.80.80.80:500 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Peer entry exist for local 10.80.80.13:500 and remote 10.80.80.80:500 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Creating a SA spi=0xcd1736b3, proto=ESP pair_index = 2 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Added (spi=0xcd1736b3, protocol=ESP dst=10.80.80.80) entry to the peer hash table [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] iked_sa_cfg_update_sa_cfg_child_sa_count Parent not found for sa_cfg SERVER-BOX [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] iked_pm_ipsec_sa_install: SA LIFE CREATED time 1395039962 with HARD LIFETIME SECONDS 180 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Hardlife timer started for inbound SERVER-BOX with 180 seconds/0 kilobytes [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Softlife timer started for inbound SERVER-BOX with 81 seconds/0 kilobytes [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] iked_pm_handle_rekeyed_ipsec_sa: Look up passed (spi=0x2ad4c0a2, protocol=ESP dst=10.80.80.13) entry in dynamic sa spi hash table [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Rekey was initiated by us. So restart timer so that we can send delete notification [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Hardlife timer restarted for rekeyed sa of outbound SERVER-BOX with 5 seconds/0 kilobytes [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] kmd_update_sa_in_kernel [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] kmd_update_sa_in_kernel [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] kmd_update_sa_in_kernel [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] In iked_fill_sa_bundle
Completing this, it creates a new happy message that it has a newly functional SA.
[Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ----------------Voyager ipsec SA BUNDLE------------------- [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] SA pair update request for: Tunnel index: 131074 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Local Gateway address: 10.80.80.13 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Primary remote Gateway address: 10.80.80.80 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Backup remote Gateway State: Active [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Anti replay: counter-based enabled [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Window_size: 64 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Server Time: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Peer : Static [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Mode : Tunnel [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] VPN Type : route-based [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Tunnel mtu: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] DF bit: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] local-if ifl idx: 1207959552 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] tunnel-if ifl idx: 1291845632 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Tunnel mtu: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] DPD interval: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] policy id: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] NATT enabled: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] NATT version: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] NAT position: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] SA Idle time: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] SA Outbound install delay time: 1 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] IKED ID: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] DIST ID: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Keepalive interval: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] VPN monitoring interval: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] VPN monitoring optimized: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Respond-bad-SPI: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] seq_out: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Local port: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Remote port: 500 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] SA CFG name: SERVER-BOX [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Dial-up IKE ID: [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] RG ID: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Group template tunnel ID: 0 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ----------------Incoming SA ------------------- [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] SPI: 0x57a09b0f Protocol: 2 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Algorithm: 130 Auth key. length: 20 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Encr key. length; 16 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] ----------------Outgoing SA ------------------- [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] SPI: 0xcd1736b3 Protocol: 2 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Algorithm: 130 Auth key. length: 20 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Encr key. length; 16 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] In iked_ipsec_sa_pair_add Adding GENCFG msg with key; Tunnel = 131074;SPI-In = 0x57a09b0f [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Added dependency on SA config blob with tunnelid = 131074 [Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] Successfully added ipsec SA PAIR
And finally it issues one last message that it's done with the new SA.
[Mar 17 20:06:02][10.80.80.13 <-> 10.80.80.80] IPSec negotiation done successfully for SA-CFG SERVER-BOX for local:10.80.80.13, remote:10.80.80.80 IKEv2
The last box on our finite state machine for the REKEY_SA processing by the intiator takes the following.
Responder updates SA.
And we can see the newly installed SA being used by examining the SA through the cli.
[edit security] juniper@SRX-13# run show security ipsec security-associations Total active tunnels: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <131074 ESP:aes-cbc-128/sha1 57a09b0f 168/ unlim - root 500 10.80.80.80 >131074 ESP:aes-cbc-128/sha1 cd1736b3 168/ unlim - root 500 10.80.80.80 [edit security] juniper@SRX-13#
A Potential Problem
One problem I stumbled across with IKEv2 that doesn't occur as readily with IKEv1 due to the fact the IKEv2 is more flexible and forgiving at some stages of the of the SA negotiations, and at other stages it's not. Whereas IKEv1 is really not flexible, and never forgiving.
In particular, by accident I had an SA fully formed between the SRX and secureSwan box, complete with an operational Child SA.
[edit security ipsec]
juniper@SRX-13# run show security ipsec security-associations
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<131074 ESP:aes-cbc-128/sha1 41e767bf 176/ unlim - root 500 10.80.80.80
>131074 ESP:aes-cbc-128/sha1 c29a1bd0 176/ unlim - root 500 10.80.80.80
[edit security ipsec]
juniper@SRX-13# run show security ike security-associations detail
IKE peer 10.80.80.80, Index 3971004, Gateway Name: SERVER-BOX
Role: Initiator, State: UP
Initiator cookie: 592ae6f2f88b9268, Responder cookie: 030df8a7af18184c
Exchange type: IKEv2, Authentication method: Pre-shared-keys
Local: 10.80.80.13:500, Remote: 10.80.80.80:500
Lifetime: Expires in 86270 seconds
Peer ike-id: 10.80.80.80
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-sha1-96
Encryption : aes128-cbc
Pseudo random function: hmac-sha1
Diffie-Hellman group : DH-group-2
Traffic statistics:
Input bytes : 1288
Output bytes : 2940
Input packets: 10
Output packets: 10
Flags: IKE SA is created
IPSec security associations: 4 created, 1 deleted
Phase 2 negotiations in progress: 0
Negotiation type: Quick mode, Role: Initiator, Message ID: 0
Local: 10.80.80.13:500, Remote: 10.80.80.80:500
Local identity: 10.80.80.13
Remote identity: 10.80.80.80
Flags: IKE SA is created
[edit security ipsec]
juniper@SRX-13#
However, on the
SRX I had Perfect Forward Secrecy (PFS) configured, and on the secureSwan box I did not. This didn't stop the Child SA from completing
during the initial exchanges as a Key Exchange (KE) is mandated. But when the Child SA's lifetime of 180 seconds began to tick away, and the
SRX tried to rekey the Child SA problems arose. The SRX, using PFS, included another transform for a Key Exchange as well as a KE payload which it is optionally allowed to do; however
the strongSwan client which didn't have PFS configured rejected this configuration during the rekey. The strongSwan client was perfectly
happy with all of the parameters of of the Child SA during the initial exchange, but the inclusion of another Diffie-Hellman-Merkel key
exchange during the rekeying effort was unacceptable. As a result, the clock kept ticking down on the lifetime of the Child SA until the
SRX was reconfigured not to use PFS, making it leave out the KEY payload as it tried to bring up a new Child SA.
This can be seen in the captured packet exchange. The values needed to decrypt the protected payloads are in the table below.
Secret values to decrypt IKEv2_CHILD_SA_issue.pcap with Wireshark
| SPIi | 592ae6f2f88b9268 |
| SPIr | 030df8a7af18184c |
| Sk_ai | A85877BEB2A841641C0896735070E3D8F05CB781 |
| Sk_ar | CDB42638EE7931E4EA3C03D32DD9C8E4869AE35A |
| Sk_ei | A474CD99120A392EEAF6836F2AA4A3B7 |
| Sk_er | 52E410E861C57C7B39E9A6F4E4FB6F65 |
Once the packet exchange is decrypted, you can peer into each of the packets and see what went wrong.
Starting with packet 5, the SRX started to try to REKEY the SA that was in place.
Packet 5 Dissected
No. Time Source Destination Protocol Length Info
5 81.677522 10.80.80.13 10.80.80.80 ISAKMP 390 CREATE_CHILD_SA
Frame 5: 390 bytes on wire (3120 bits), 390 bytes captured (3120 bits)
Ethernet II, Src: Private_00:13:03 (ac:de:48:00:13:03), Dst: Private_00:80:01 (ac:de:48:00:80:01)
Internet Protocol Version 4, Src: 10.80.80.13 (10.80.80.13), Dst: 10.80.80.80 (10.80.80.80)
User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500)
Internet Security Association and Key Management Protocol
Initiator cookie: 592ae6f2f88b9268
Responder cookie: 030df8a7af18184c
Next payload: Encrypted and Authenticated (46)
Version: 2.0
Exchange type: CREATE_CHILD_SA (36)
Message ID: 0x00000002
Length: 348
Type Payload: Encrypted and Authenticated (46)
Next payload: Notify (41)
0... .... = Critical Bit: Not Critical
Payload length: 320
Initialization Vector: ea6df90da9eaa8b9b2efe31376619b39 (16 bytes)
Encrypted Data (288 bytes)
Decrypted Data (288 bytes)
Contained Data (284 bytes)
Type Payload: Notify (41)
Next payload: Security Association (33)
0... .... = Critical Bit: Not Critical
Payload length: 12
Protocol ID: ESP (3)
SPI Size: 4
Notify Message Type: REKEY_SA (16393)
SPI Size: e7ef4bca
Notification DATA:
Type Payload: Security Association (33)
Next payload: Nonce (40)
0... .... = Critical Bit: Not Critical
Payload length: 52
Type Payload: Proposal (2) # 1
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 48
Proposal number: 1
Protocol ID: ESP (3)
SPI Size: 4
Proposal transforms: 4
SPI Size: 7e33b107
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 12
Transform Type: Encryption Algorithm (ENCR) (1)
Transform ID (ENCR): ENCR_AES_CBC (12)
Transform IKE2 Attribute Type (t=14,l=2) Key-Length : 128
1... .... .... .... = Transform IKE2 Format: Type/Value (TV)
Transform IKE2 Attribute Type: Key-Length (14)
Value: 0080
Key Length: 128
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Integrity Algorithm (INTEG) (3)
Transform ID (INTEG): AUTH_HMAC_SHA1_96 (2)
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Diffie-Hellman Group (D-H) (4)
Transform ID (D-H): Alternate 1024-bit MODP group (2)
Type Payload: Transform (3)
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Extended Sequence Numbers (ESN) (5)
Transform ID (ESN): No Extended Sequence Numbers (0)
Type Payload: Nonce (40)
Type Payload: Key Exchange (34)
Type Payload: Traffic Selector - Initiator (44) # 1
Type Payload: Traffic Selector - Responder (45) # 1
Padding (3 bytes)
Pad Length: 3
Integrity Checksum Data: 501f229b5f2770550f25fa39 (12 bytes)[correct]
The strongSwan client rejects the proposal due to the inclusion of a Diffie-Hellman Group transform in in the proposal (MODP_1024).
Mar 17 19:50:43 15[ENC] parsed CREATE_CHILD_SA request 2 [ N(REKEY_SA) SA No KE TSi TSr ] Mar 17 19:50:43 15[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ Mar 17 19:50:43 15[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ Mar 17 19:50:43 15[IKE] no acceptable proposal found Mar 17 19:50:43 15[ENC] added payload of type NOTIFY to message Mar 17 19:50:43 15[ENC] added payload of type NOTIFY to message Mar 17 19:50:43 15[ENC] generating CREATE_CHILD_SA response 2 [ N(NO_PROP) ]
Packet #6 Dissected
No. Time Source Destination Protocol Length Info
6 81.859953 10.80.80.80 10.80.80.13 ISAKMP 118 CREATE_CHILD_SA
Frame 6: 118 bytes on wire (944 bits), 118 bytes captured (944 bits)
Ethernet II, Src: Private_00:80:01 (ac:de:48:00:80:01), Dst: Private_00:13:03 (ac:de:48:00:13:03)
Internet Protocol Version 4, Src: 10.80.80.80 (10.80.80.80), Dst: 10.80.80.13 (10.80.80.13)
User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500)
Internet Security Association and Key Management Protocol
Initiator cookie: 592ae6f2f88b9268
Responder cookie: 030df8a7af18184c
Next payload: Encrypted and Authenticated (46)
Version: 2.0
Exchange type: CREATE_CHILD_SA (36)
Flags: 0x20
.... 0... = Initiator: Responder
...0 .... = Version: No higher version
..1. .... = Response: Response
Message ID: 0x00000002
Length: 76
Type Payload: Encrypted and Authenticated (46)
Next payload: Notify (41)
0... .... = Critical Bit: Not Critical
Payload length: 48
Initialization Vector: a6a78522b7cd35a163fac2e751faa6cc (16 bytes)
Encrypted Data (16 bytes)
Decrypted Data (16 bytes)
Contained Data (8 bytes)
Type Payload: Notify (41)
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 8
Protocol ID: RESERVED (0)
SPI Size: 0
Notify Message Type: NO_PROPOSAL_CHOSEN (14)
Notification DATA:
Padding (7 bytes)
Pad Length: 7
Integrity Checksum Data: 3ad15225843045901362d007 (12 bytes)[correct]
The SRX was reconfigured, and sent a request for a new CHILD_SA without mentioning another Diffie-Hellman-Merkle exchange in packet #19.
Packet #19 Dissected
No. Time Source Destination Protocol Length Info
19 118.656692 10.80.80.13 10.80.80.80 ISAKMP 246 CREATE_CHILD_SA
Frame 19: 246 bytes on wire (1968 bits), 246 bytes captured (1968 bits)
Ethernet II, Src: Private_00:13:03 (ac:de:48:00:13:03), Dst: Private_00:80:01 (ac:de:48:00:80:01)
Internet Protocol Version 4, Src: 10.80.80.13 (10.80.80.13), Dst: 10.80.80.80 (10.80.80.80)
User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500)
Internet Security Association and Key Management Protocol
Initiator cookie: 592ae6f2f88b9268
Responder cookie: 030df8a7af18184c
Next payload: Encrypted and Authenticated (46)
Version: 2.0
Exchange type: CREATE_CHILD_SA (36)
Message ID: 0x00000009
Length: 204
Type Payload: Encrypted and Authenticated (46)
Next payload: Security Association (33)
0... .... = Critical Bit: Not Critical
Payload length: 176
Initialization Vector: ab8f326447ff0eb9111c6d54c86a7f7c (16 bytes)
Encrypted Data (144 bytes)
Decrypted Data (144 bytes)
Contained Data (128 bytes)
Type Payload: Security Association (33)
Next payload: Nonce (40)
0... .... = Critical Bit: Not Critical
Payload length: 44
Type Payload: Proposal (2) # 1
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 40
Proposal number: 1
Protocol ID: ESP (3)
SPI Size: 4
Proposal transforms: 3
SPI Size: 41e767bf
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 12
Transform Type: Encryption Algorithm (ENCR) (1)
Transform ID (ENCR): ENCR_AES_CBC (12)
Transform IKE2 Attribute Type (t=14,l=2) Key-Length : 128
1... .... .... .... = Transform IKE2 Format: Type/Value (TV)
Transform IKE2 Attribute Type: Key-Length (14)
Value: 0080
Key Length: 128
Type Payload: Transform (3)
Next payload: Transform (3)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Integrity Algorithm (INTEG) (3)
Transform ID (INTEG): AUTH_HMAC_SHA1_96 (2)
Type Payload: Transform (3)
Next payload: NONE / No Next Payload (0)
0... .... = Critical Bit: Not Critical
Payload length: 8
Transform Type: Extended Sequence Numbers (ESN) (5)
Transform ID (ESN): No Extended Sequence Numbers (0)
Type Payload: Nonce (40)
Type Payload: Traffic Selector - Initiator (44) # 1
Type Payload: Traffic Selector - Responder (45) # 1
Padding (15 bytes)
Pad Length: 15
Integrity Checksum Data: 9e3431fd71c883be61f1f4ae (12 bytes)[correct]
Then the strongSwan client accepted the proposal, and a new child SA was established.
Mar 17 19:51:20 14[CHD] adding inbound ESP SA Mar 17 19:51:20 14[CHD] SPI 0xc29a1bd0, src 10.80.80.13 dst 10.80.80.80 Mar 17 19:51:20 14[CHD] adding outbound ESP SA Mar 17 19:51:20 14[CHD] SPI 0x41e767bf, src 10.80.80.80 dst 10.80.80.13
If this mismatch in the REKEY_SA hadn't been cleared up by adjusting the configuration on the SRX, the child SA would have expired and the two IPSEC peers wouldn't be able to send protected traffic to one another until the IKEv2 secure channel setup by the initial SA was interrupted and was forced to renegotiate. This would have allowed another Child SA to be formed during the initial exchange, only to expire later on when it couldn’t be rekeyd, continuing the cycle ad infinitum. Definately something to watch out for.