idnits 2.17.1 draft-carrel-ipsecme-controller-ike-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2-IANA' == Outdated reference: A later version (-14) exists of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-qr-ikev2-07 == Outdated reference: A later version (-06) exists of draft-sajassi-bess-secure-evpn-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Carrel 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track B. Weis 5 Expires: September 12, 2019 Independent 6 March 11, 2019 8 IPsec Key Exchange using a Controller 9 draft-carrel-ipsecme-controller-ike-01 11 Abstract 13 This document presents a key exchange method allowing devices managed 14 by a controller (e.g., an SDN management station) to create private 15 pair-wise IPsec SAs without IKEv2 or any other direct peer-to-peer 16 session establishment messages. The method can be used when a full 17 mesh of IKEv2 sessions between IPsec devices is not appropriate. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 12, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Generating Initial IPsec SAs . . . . . . . . . . . . . . . . 5 57 4. Rekey of IPsec SAs . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. Single IPsec Device Rekey . . . . . . . . . . . . . . . . 8 59 4.2. Simultaneous Rekey of IPsec Devices . . . . . . . . . . . 10 60 5. IPsec Database Generation . . . . . . . . . . . . . . . . . . 13 61 5.1. The Security Policy Database (SPD) . . . . . . . . . . . 13 62 5.2. Security Association Database (SAD) . . . . . . . . . . . 13 63 5.2.1. Generating Keying Material for IPsec SAs . . . . . . 13 64 5.3. Peer Authorization Database (PAD) . . . . . . . . . . . . 16 65 6. Policy distributed through the Controller . . . . . . . . . . 16 66 6.1. IPsec policy negotiation . . . . . . . . . . . . . . . . 17 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 72 10.2. Informative References . . . . . . . . . . . . . . . . . 20 73 Appendix A. Example Controller protocols . . . . . . . . . . . . 21 74 A.1. Example: I2NSF . . . . . . . . . . . . . . . . . . . . . 21 75 A.2. Example: Network Controller . . . . . . . . . . . . . . . 21 76 A.3. Additional controller protocol considerations . . . . . . 22 77 A.3.1. Peer-to-peer distribution of IPsec policy . . . . . . 22 78 A.3.2. Ordering of messages distributed to a controller . . 23 79 Appendix B. Choosing whether to use IKEv2 or Controller IKE . . 23 80 Appendix C. Implementation Considerations . . . . . . . . . . . 25 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 83 1. Introduction 85 Network architectures typically have included network devices 86 directly communicating using network control protocols such as 87 routing and signaling protocols. Additionally, secured 88 communications between these network devices are usually accomplished 89 with a key agreement protocol such as IKEv2 [RFC7296], in which the 90 network devices directly authenticate each other and agree upon 91 security policy and keying material to protect communications between 92 themselves. However, controller-based network architectures 93 (sometimes called "Software-Defined Networking") are now being 94 defined [RFC7426] [RFC8192] and implemented. In controller-based 95 network architectures, control protocols --including key exchange 96 protocols -- are not implemented directly between the network 97 devices. Software-Defined Networks utilize the controller based 98 network design while maximizing the scalability that it provides. 99 The result is a significantly different trust model; rather than 100 apply a peer-to-peer trust model, the network applies a device-to- 101 controller trust model. 103 The use of IKEv2 in a device-to-controller trust model is not always 104 optimal. Instead, a new key management method is needed for these 105 models. Appendix B describes situations in which Controller IKE may 106 be a better choice than IKEv2. 108 +-------------+ 109 | | 110 | Controller | 111 | | 112 +-+----+-----++ 113 | | | 114 +---------------+ | +--------------+ 115 | Control Plane | 116 | | | 117 | | | 118 +--+--+ +--+--+ +--+--+ 119 | | | | | | 120 | A | | B | | C | 121 | | | | | | 122 +-+-+-+ ++--+-+ +-+-+-+ 123 | | | | | | 124 | +-----------------+ +------------------+ | 125 +-------------------------------------------+ 126 Secured Data Plane 128 Figure 1: Controller-based Secured Communications 130 Figure 1 shows an example controller based network design. Three 131 network devices (labeled A, B, and C) setup a protected control plane 132 connection to a Controller. The Controller distributes policy to the 133 network devices, which enables them to securely communicate in the 134 data plane. 136 When one considers adding a controller to a key exchange method, it 137 is tempting to give it the task of generating and distributing 138 session keys directly to network devices. However, such a design has 139 several security considerations. Because such a controller would 140 have all session keys it could become an active participant or a 141 passive monitor to the secured communications. Also, for scalability 142 reasons one might consider having a controller distribute session 143 keys that are group keys, either a single group key or a set of group 144 keys that devices use to protect communications between them. This 145 document does not specify the use of group session keys. 147 Many key exchange methods (such as IKEv2) use a Diffie-Hellman (DH) 148 algorithm to derive keys. When combined with an authentication 149 method, the key exchange method allows two network devices to 150 generate private pair-wise keys with each other. This document 151 presents a key exchange method making use of the device-to-controller 152 trust model, where a controller is used to distribute keying material 153 and policy between network devices, also resulting in the devices 154 generating private pair-wise keys with each other. DH public values 155 are provided to controllers from IPsec devices, where the controller 156 relays the DH public values to authorized peers of that IPsec device 157 as defined by a centralized policy. Network devices then create and 158 install private pair-wise IPsec session keys to be used to secure 159 communications with their peers. 161 Controller-based key exchange methods can be used to create a 162 Gateway-to-Gateway VPN [RFC7018] in either a Full-Mesh Topology or 163 Dynamic Full-Mesh Topology. 165 Although IKEv2 is not used in this approach, the key management 166 interfaces between IKEv2 and IPsec defined in RFC 7296 are maintained 167 as much as possible. 169 1.1. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 2. Overview 179 In Controller-IKE a controller acts as a trusted third party, which 180 relays policy and keying material between IPsec devices. The 181 controller can be a standalone device, or integrated into a 182 management station. Communications between the controller and the 183 IPsec devices MUST be authenticated, encrypted, and integrity- 184 protected. 186 All algorithms are selected by the controller or a management station 187 associated with the controller. The combination of a controller and 188 a set of IPsec devices comprises a cooperating group of devices that 189 make up a VPN, where each IPsec device is authorized to communicate 190 with other IPsec devices in the group. Controller policy may allow 191 an IPsec device to communicate with all other IPsec devices in the 192 group, or may restrict it to a subset of those devices. 194 DH public values are distributed to the controller from each IPsec 195 device and redistributed from the controller to each authorized peer 196 IPsec device. Each IPsec device creates and maintains a DH pair, 197 which it uses to communicate with other members of the VPN. This 198 distribution of DH public values (and other related values) is 199 intended to be embedded into an existing network device/controller 200 protocol. In particular, Controller-IKE provides a mechanism for 201 secure key management and only key management. It does not provide 202 policy information or configuration as that is assumed to be provided 203 by the controller. One such controller protocol 204 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] is being developed at this 205 time in the IETF I2NSF working group. Another controller protocol 206 [I-D.sajassi-bess-secure-evpn] is being developed by the IETF BESS 207 working group. 209 3. Generating Initial IPsec SAs 211 When an IPsec device begins operation, it generates a DH pair, using 212 an algorithm defined in the IKEv2 Diffie-Hellman Group Transform IDs 213 [IKEV2-IANA]. If the device does not have any active peers it simply 214 distributes its DH public value to the Controller, along with a nonce 215 to be used during SA creation. Whenever a DH pair is created, a new 216 nonce MUST also be created. Whenever DH public values are 217 transmitted, they are transmitted with the corresponding nonce. 218 Whenever a DH private or DH public value is used, it is used along 219 with the corresponding nonce. However, in the diagrams and 220 descriptions below, the nonces are often left out for the sake of 221 clarity. 223 Upon receiving a peer's DH public value and nonce, the receiver 224 creates IPsec SAs (as described in Section 5.2). For each peer, a 225 pair of IPsec SAs are created by combining the IPsec device's own DH 226 private value with the DH public number received from the Controller. 228 +---+ +----------+ +---+ 229 | A | |Controller| | B | 230 +-+-+ +-----+----+ +-+-+ 231 +----------+ | | | 232 |Generate | | | | +----------+ 233 |DH pair a1| | | | |Generate | 234 +----------+ | a1-pub | | |DH pair b1| 235 +----------> | b1-pub | +----------+ 236 | | <----------+ 237 | | | 238 | | a1-pub | 239 | b1-pub +----------> | +-----------+ 240 +-----------+ | <----------+ | |Create SA: | 241 |Create SAs:| | | | | Tx(b1-a1)| 242 | Tx(a1-b1)| | | | | Rx(a1-b1)| 243 | Rx(b1-a1)| | | | +-----------+ 244 +-----------+ | | | 245 | | | 246 | IPsec ESP Tx(a1-b1) | 247 +-----------------------> | 248 | | | 249 | IPsec ESP Tx(b1-a1) | 250 | <-----------------------+ 251 | | | 252 + + + 254 Figure 2: Generation of Initial IPsec SAs between two peers 256 Figure 2 shows IPsec SA generation between a pair of IPsec devices. 257 Two IPsec devices (A and B shown in Figure 1) join the network. Each 258 creates it's own DH pair (labelled "a1" on A and "b1" on B), and 259 distributes the DH public value (labelled a1-pub and b1-pub) to the 260 Controller. The controller forwards the DH public value to all 261 authorized peers, although for simplicity of exposition the figure 262 only shows the two IPsec devices. 264 When each device receives the peer's DH public value, a pair of IPsec 265 SAs are generated: one outbound and one inbound. As shown in the 266 figure, A generates an outbound SA labeled Tx(a1-b1), representing 267 that it has been generated using A's DH pair labeled a1 and B's DH 268 pair labeled b1. B generates the same IPsec SA as an inbound SA, 269 which is labeled Rx(a1-b1). Similarly, A generates an inbound IPsec 270 SA labelled Rx(b1-a1), which is the same IPsec SA on B labelled 271 Tx(b1-a1). 273 This process repeats on both A and B as they discover other IPsec 274 devices with which they are authorized to communicate. 276 4. Rekey of IPsec SAs 278 Any IPsec device may initiate a rekey at any time. Common reasons to 279 perform a rekey include a local time or volume based policy, or may 280 be the result of a cipher counter mode Initialization Vector (IV) 281 counter nearing its final value. The rekey process is performed 282 individually for each remote peer. If rekeying is performed with 283 multiple peers simultaneously, then the decision process and rules 284 described in this rekey are performed independently for each peer. 286 A decision process choosing an outbound IPsec SA is followed when 287 certain events occur, as described in the rules below. The same 288 decision process is followed regardless of whether the device is 289 performing a rekey or responding to a peer's rekey. The decision 290 process is: 292 1. Determine the outbound SAs with the remote peer's most recently 293 distributed DH public value. 295 2. Determine which of those outbound SAs are "live". A "live" 296 outbound SA is one built from a DH value from the local peer for 297 which it has observed inbound traffic using any SA based on the 298 same local DH pair. This proves that the remote peer is prepared 299 to receive traffic protected by that DH pair. 301 3. Choose the "live" outbound SA built from the local peer's most 302 recent DH public value. 304 A rekey operation follows these four basic rules. 306 Rule 1 When an IPsec device needs to perform a rekey with a remote 307 peer, it creates a new pair of IPsec SAs by combining the new DH 308 private value with the peer's DH public values. If the remote 309 peer is also in the midst of a rollover and its DH public value 310 has already been received, then this may result in creating two 311 sets of SAs: one pair with the remote peer's old DH public value, 312 and one pair with the remote peer's new DH public value. 314 Rule 2 When an IPsec device receives a new remote peer's DH public 315 value from the controller it creates and installs a new pair of 316 IPsec SAs by combining the remote peer's new DH public value with 317 its own current local DH private values. If both devices are in 318 the midst of a rollover, this may result in creating two sets of 319 SAs with the remote peer's new DH public value: one with the local 320 old DH private value, and one with the local new DH private value. 321 The outbound SA decision process is performed. 323 Rule 3 The first IPsec packet received by a rekeying IPsec device on 324 an inbound SA using its new DH pair causes it to perform the 325 outbound SA decision process. It may also shorten the lifetime of 326 IPsec SAs using its own old DH pair that are shared with this 327 peer, as they are no longer in use (other than the inbound SA 328 might receive packets in transit). 330 Rule 4 The first IPsec packet received from a remote rekeying IPsec 331 device using the remote peer's new DH pair allows the IPsec device 332 to shorten the lifetime of IPsec SAs shared with this peer using 333 unused remote DH pairs. 335 Two examples follow: a single IPsec device performing a rekey with 336 its peers, and two IPsec devices performing a simultaneous rekey. 337 The same rekey operations described above are exhibited in both 338 cases. 340 4.1. Single IPsec Device Rekey 342 When a single IPsec device begins a rekey, it first generates a new 343 DH pair and generates new IPsec SA pairs for each peer with which it 344 is communicating. It does this by combining the new DH private value 345 with each peer's existing DH public value. Only when the new IPsec 346 SAs have been installed and the device is prepared to receive on 347 those new SAs does it then distribute the new DH public value to the 348 Controller, which forwards the new DH public value to its authorized 349 peers. The rekeying IPsec device continues to transmit on the old 350 SAs for each peer until it observes that peer begin to transmit on 351 the new SAs. 353 +---+ +----------+ +---+ 354 | A | |Controller| | B | 355 +-+-+ +-----+----+ +-+-+ 356 +----------+ | | | 357 |Generate | | | | 358 |DH pair a2| | | | 359 +----------+ | | | 360 +--------------+ | | | 361 |Rule 1 | | | | 362 | Create SAs | | | | 363 | Tx(a2-b1) | | | | 364 | Rx(b1-a2) | | | | 365 | Use Tx(a1-b1)| | a2-pub | | 366 +--------------+ +----------> | | 367 | | | 368 | IPsec ESP Tx(a1-b1) | 369 +-----------------------> | 370 | IPsec ESP Tx(b1-a1) | 371 | <-----------------------+ 372 | | | 373 | | a2-pub | 374 | +----------> | +--------------+ 375 | | | |Rule 2 | 376 | | | | Create SAs | 377 | | | | Tx(b1-a2) | 378 | | | | Rx(a2-b1) | 379 | IPsec ESP Tx(b1-a2) | | Use Tx(b1-a2)| 380 +--------------+ | <-----------------------+ +--------------+ 381 |Rule 3 | | | | 382 | Use Tx(a2-b1)| | | | 383 | Shorten life | | | | 384 | Tx(a1-b1) | | IPsec ESP Tx(a2-b1) | 385 | Rx(b1-a1) | +----------------------> | +--------------+ 386 +--------------+ | | | |Rule 4 | 387 | | | | Shorten life | 388 | | | | Tx(b1-a1) | 389 | | | | Rx(a1-b1) | 390 | | | +--------------+ 391 + + + 393 Figure 3: Single IPsec Device Rekey Protocol Flow 395 In Figure 3, device A is shown as performing a rekey, and it creates 396 a DH pair labelled "a2". The following steps are followed. 398 1. Rule 1 requires creating new IPsec SAs for each peer. In this 399 example, A creates a new outbound IPsec SA to communicate with B 400 labelled Tx(a2-b1), and a new inbound IPsec SA labelled 401 Rx(b1-a2). A continues to transmit on Tx(a1-b1) (generated as 402 shown in Figure 2). 404 2. A distributes the new public value (a2-pub) to the Controller who 405 forwards it to A's authorized peers, which includes B. During 406 this time, both A and B continue to use the initial IPsec SAs 407 setup between them using a1 and b1. 409 3. When B receives a2 from the controller, B follows Rule 2 by 410 creating Tx(b1-a2), Rx(a2-b1). B also follows the outbound SA 411 decision process, which causes it to change its outbound IPsec SA 412 to A to Tx(b1-a2). 414 4. When A receives a packet protected by Rx(b1-a2), it follows Rule 415 3 and performs the outbound SA decision process. This causes it 416 to change its outbound IPsec SA to Use Tx(a2-b1). It also 417 optionally shortens the lifetime of the old IPsec SAs shared with 418 this peer. 420 5. When B receives a packet protected by Tx(a2-b1), it follows Rule 421 4, in which it may shorten the lifetime of the old IPsec SAs 422 shared with this peer using DH pairs that are no longer in use. 424 At the end of the rekey, both A and B retain a single DH pair, and a 425 single set of IPsec SAs between them. 427 4.2. Simultaneous Rekey of IPsec Devices 429 When two or more IPsec device simultaneously begin a rekey, they each 430 follow the rekeying method described in the previous section. Every 431 rekeying IPsec device generates a new DH pair and generates new IPsec 432 SA pairs for each peer with which it is communicating by combining 433 their new DH private value with each peer's existing DH public value. 434 When this completes on a particular IPsec device, it distributes the 435 new DH public value to the Controller, which forwards it to its 436 authorized peers. Each continues to transmit on the existing SAs for 437 each peer until it observes that peer transmitting on the new SAs. 438 During a simultaneous rekey up to four pairs of IPsec SAs may be 439 temporarily created, but the four rules ensure that they converge on 440 a single new set of IPsec SAs. 442 +---+ +----------+ +---+ 443 | A | |Controller| | B | 444 +-+-+ +-----+----+ +-+-+ 445 +---------------------+ | | | +--------------+ 446 |Generate DH pair a2 | | | | |Gen DH pair b2| 447 +---------------------+ | | | +--------------+ 448 +---------------------+ | | | +--------------+ 449 |Rule 1 | | | | |Rule 1 | 450 | Create SAs | | | | | Create SAs | 451 | Tx(a2-b1),Rx(b1-a2)| | | | | Tx(b2-a1) | 452 | Use Tx(a1-b1) | | a2-pub | | | Rx(a1-b2) | 453 +---------------------+ +----------> | b2-pub | | Use Tx(b1-a1)| 454 | | <----------+ +--------------+ 455 | IPsec ESP Tx(a1-b1) | 456 +-----------------------> | 457 | IPsec ESP Tx(b1-a1) | 458 | <-----------------------+ 459 | | a2-pub | 460 | b2-pub +----------> | +--------------+ 461 +---------------------+ | <----------+ | |Rule 2 | 462 |Rule 2 | | | | | Create SAs | 463 | Create SAs | | | | | Tx(b1-a2) | 464 | Tx(a1-b2),Rx(b2-a1)| | | | | Rx(a2-b1) | 465 | Tx(a2-b2),Rx(b2-a2)| | | | | Tx(b2-a2) | 466 | Use Tx(a1-b2) | | | | | Rx(a2-b2) | 467 +---------------------+ | IPsec ESP Tx(b1-a2) | | Use Tx(b1-a2)| 468 | <-----------------------+ +--------------+ 469 | IPsec ESP Tx(a1-b2) | 470 +---------------------+ +-----------------------> | +--------------+ 471 |Rule 3 | | | | |Rule 3 | 472 | Use Tx(a2-b2) | | | | | Use Tx(b2-a2)| 473 | Shorten life | | | | | Shorten life | 474 | Tx(a1-b1),Rx(b1-a1)| | | | | Tx(b1-a1) | 475 | Tx(a1-b2),Rx(b2-a1)| | | | | Rx(a1-b1) | 476 +---------------------+ | IPsec ESP Tx(a2-b2) | | Tx(b1-a2) | 477 +----------------------> | | Rx(a2-b1) | 478 | IPsec ESP Tx(b2-a2) | +--------------+ 479 +---------------------+ <-----------------------+ +--------------+ 480 | Rule 4 | | | | |Rule 4 | 481 | Shorten life | | | | | Shorten life | 482 | Tx(a2-b1),Rx(b1-a2)| | | | | Tx(b1-a2) | 483 +---------------------+ | | | | Rx(a2-b1) | 484 + + + +--------------+ 486 Figure 4: Simultaneous IPsec Device Rekey Protocol Flow 488 In Figure 4, device A and device B are both shown as performing a 489 rekey. Their initial state corresponds to the final state shown in 490 Figure 2 (i.e., they are communicating using a single pair of IPsec 491 SAs created from DH pairs "a1" and "b1". 493 1. A and B follow Rule 1, which includes creating new IPsec SAs for 494 each peer. In this example, A creates a new outbound IPsec SA to 495 communicate with B labelled Tx(a2-b1), and a new inbound IPsec SA 496 labelled Rx(b1-a2). B creates a new outbound IPsec SA to 497 communicate with B labelled Tx(a1-b2), and a new inbound IPsec SA 498 labelled Rx(b2-a1). A and B continue to transmit on IPsec SAs 499 previously created from DH pairs "a1" and "b1". 501 2. A distributes the new public value (a2-pub) to the Controller who 502 forwards it to A's authorized peers, which includes B. B also 503 distributes the new public value (b2-pub) to the Controller who 504 forwards it to B's authorized peers, which includes A. 506 3. When A and B receive each other's new peer DH public value from 507 the controller they follows Rule 2. But because now there are 508 four DH values that could be in used between A and B, they must 509 be prepared to use IPsec SAs using each permutation of DH values: 510 a1-b1, a1-b2, a2-b1, a2-b2. Prior to implementing Rule 2, each 511 has already created sets of IPsec SAs matching two of the 512 permutations, so just two more sets must be generated during Rule 513 2. 515 * One pair is created using the IPsec device's old DH pair with 516 the peer's new DH pair. This is necessary, because the peer 517 may transmit on this pair. 519 * One pair is created using the IPsec device's new DH pair with 520 the peer's new DH pair. This is the set of IPsec SAs that 521 will be used at the end of the rekey process. 523 Each peer begins transmitting on an IPsec SA that combines the 524 remote peer's new DH pair and its own old DH pair, which is the 525 most recent "live" SA on which it can transmit. I.e., A begins 526 transmitting on Tx(a1-b2) and B begins transmitting on Tx(b1-a2). 528 4. When A receives a packet protected by Rx(b1-a2), it understands 529 that the remote peer has received its new DH public value. A 530 also understands that because of Rule 2 that B must have created 531 IPsec SAs using a2-b2. This allows A to follow Rule 3 and change 532 its outbound IPsec SA to Use Tx(a2-b2). Similarly, when B 533 receives a packet protected by Rx(a1-b2), B recognizes that it 534 can also begin to transmit using Tx(b2-a2). Note that it also 535 possible that A will receive a packet protected by Rx(b2-a2) or B 536 will receive a packet protected by Rx(a2-b2), and then knows it 537 can transmit on an IPsec SA using both of the new DH pairs. 539 5. Also in Rule 3, Both A and B optionally shorten the lifetime of 540 older IPsec SAs shared with this peer derived from unused DH 541 pairs to be cleaned up. A shortens the lifetime of SAs based on 542 a1. B shortens the lifetime of SAs based on b1. 544 6. When A and B receive a packet protected by the remote peer's 545 latest DH pair, they shortens the lifetime of SAs based on the 546 remote peer's unused DH pair. 548 5. IPsec Database Generation 550 The PAD, SPD, and SAD all need to be setup as defined in the IPsec 551 Security Architecture [RFC4301]. 553 5.1. The Security Policy Database (SPD) 555 The SPD is implemented using methods outside the scope of this 556 document. The SPD describes the type of traffic that will be 557 protected between IPsec devices and the policy (e.g., ciphers) used 558 to create SAs. 560 5.2. Security Association Database (SAD) 562 The SAD is constructed from IPsec policy (e.g., ciphers) obtained 563 (depending on the controller protocol method) either from the 564 controller or distributed by a peer (see Section 6). 566 Keying Material is generated following the method defined in IKEv2, 567 and depends on SPIs, nonces, and the Diffie-Hellman shared secret. 569 The following sections describe how the necessary values are 570 determined. 572 5.2.1. Generating Keying Material for IPsec SAs 574 5.2.1.1. g^ir 576 A DH public value is distributed from the peer. 578 A DH shared secret (g^ir) is computed using the peer's public value, 579 and the device's private value. The DH group to be used must be 580 known by the device. Options include distribution by an SDN 581 controller, or distribution by the peer with the DH public value (see 582 Section 6). 584 5.2.1.2. Nonces 586 Nonces are distributed with a DH public value, and are used only with 587 that value. It is RECOMMENDED that nonces are generated as described 588 in Section 2.10 of [RFC7296]. 590 IKEv2 Key derivation specifies an initiator's nonce (Ni) and a 591 responder's nonce (Nr). While neither peer is truly initiating a 592 session), in order to fit the IKE key material models the roles must 593 be assigned. The initiator is chosen as the peer with the larger 594 nonce and the responder is the peer with the smaller. This does mean 595 that the roles can change for each rekey and for each SA within a 596 rekey. 598 5.2.1.3. SPIs 600 SPI values that are unique to each generation of keying material need 601 to be determined. While each peer could distribute its own inbound 602 SA value, the SPI value would be used by many peers. Although this 603 is not a problem for an SA lookup (lookup can include the source and 604 destination IP addresses), experience has shown that this is sub- 605 optimal for some hardware SA lookup algorithms. Instead, this 606 specification proposes generating values that are unpredictable and 607 indistinguishable from randomly-generated SPI values. 609 SPI values are generated using the IKEv2 prf+ function, where nonces 610 are used as the input to the prf. This produces a statistically 611 random SPI value that should be unique. However, with a 32 bit value 612 there is still a very small, but non-zero, chance of SPIs repeating 613 for a given pair of peers. To prevent this and ensure uniqueness in 614 the operational window, we also use the lower 2 bits from each peer's 615 rekey counter. 617 First the SPIs are taken from the prf+ function as 32 bit values and 618 assigned based on which peer is taking the role of initiator and 619 which is taking the role of responder. The p_SPI_i is taken by the 620 device providing Ni, where p_SPI_r is taken by the other device. 622 {p_SPI_i | p_SPI_r } = prf+(Ni | Nr, "SPI generation") 624 Next p_SPI_i and p_SPI_r are mapped from initiator and responder 625 roles to local and remote roles based on the choice of Ni and Nr in 626 5.2.1.2 and are renamed to p_SPI_local and p_SPI_remote. 628 Then, 2 2-bit Rotation Numbers (RN) are generated from the 2 least 629 significant bits (LSB) of the 2 rekey counter values (see Section 6). 630 These 4 bits replace the least significant bits of p_SPI_local and 631 p_SPI_remote with the local RN bits taking the least significant 632 position in p_SPI_local and the remote RN bits taking the least 633 significant position in p_SPI_remote. This shown in the following 634 two diagrams with RN_local shown as R_l and RN_remote shown as R_r. 636 (MSB) (LSB) 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | p_SPI_local bits from prf+ |R_r|R_l| 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 (MSB) (LSB) 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | p_SPI_remote bits from prf+ |R_l|R_r| 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 The reason for changing terminology from initiator/responder to 650 local/remote is because the roles of initiator/responder can change 651 in every rekey. The order of RN_local and RN_remote needs to remain 652 constant. If that order was based on initiator/responder, there's a 653 risk that if the initiator and responder roles changed and the two 654 peers re-keyed on different frequencies, they could end up with 655 identical RN values. 657 In some circumstances additional values may also need to be added to 658 the prf for peers to ensure that they have implemented the same 659 policy. Appendix A.3.1 includes a discussion of when this might be 660 needed. In these cases, only the prf+ inputs are modified and the 661 Rotation Numbers MUST still be added as above. 663 Because a device is not choosing its inbound SPI, its SA lookup 664 process needs to be aware that duplicates could occur across 665 different peers. In that case, the inbound SA Lookup SHOULD include 666 a source IP address in addition to the SPI value (see Section 4.1 of 667 [RFC4301]). 669 5.2.1.4. IPsec key generation 671 As described in previous sections, a DH public value and a nonce are 672 distributed by peers. These are used to generate IPsec keys 673 following the method defined in the IKEv2. SKEYSEED is generated 674 following Section 2.14 of [RFC7296]: 676 SKEYSEED = prf(Ni | Nr, g^ir) 678 KEYMAT can be similarly derived as defined by IKEv2 (Section 2.17 of 679 [RFC7296]), although only SK_d is required to be generated (shown in 680 Section 2.14 of [RFC7296]). 682 SK_d = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) 684 KEYMAT = prf+(SK_d, Ni | Nr) 686 However, with the simplification where only SK_d is generated, it can 687 be observed that the derivation of SK_d could be skipped entirely, 688 and an optimized derivation of KEYMAT could be as follows: 690 KEYMAT = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) 692 Note: A single specification for generating KEYMAT will be determined 693 in a future version of this document. 695 5.3. Peer Authorization Database (PAD) 697 The PAD identifies authorized peers. PAD entries are either 698 statically configured, or may be dynamically updated by the 699 controller. 701 The PAD omits authentication data for each peer, because it has 702 delegated authentication and authorization to the controller. 704 The controller protocol MUST be able to describe an identity that a 705 receiver can match against its local PAD database, to ensure that the 706 peer is an authorized peer. 708 6. Policy distributed through the Controller 710 An IPsec device distributes to a controller a DH public value and the 711 associated information and policy needed to create IPsec SAs in a 712 Device Information Message (DIM). The controller then distributes 713 the DIM to all authorized peers of that device. The following data 714 elements MUST be embedded in a DIM message: 716 o DH public number (used for key computation) 718 o Nonce (used for key computation and SPI generation) 720 o Peer identity (used to identify a peer in the PAD) 722 o An Indication whether this is the initial distributed policy 724 o A rekey counter, which increases for each unique DIM sent 725 In cases where a single fixed IPsec policy has been pre-distributed, 726 it is not necessary for the peer to send or receive that policy in a 727 DIM. However, in cases where an IPsec device needs to indicate the 728 policy it is willing to use, the following data elements SHOULD be 729 included in a DIM: 731 o An IPsec policy or policies 733 o A lifetime bounding the use of the DH public number. When this DH 734 public number is used to create an IPsec SA, the shortest lifetime 735 is used as an SA lifetime for the pair of generated IPsec SAs. 736 When the lifetime expires, the local version of the DIM and IPsec 737 SAs generated from it MUST be deleted. 739 Appendix A suggests different ways that this policy may be included 740 in a controller protocol. This document does not define a normative 741 protocol format, because the DIM very likely needs to be integrated 742 into an existing controller protocol rather than be an independent 743 key management protocol. However, the controller protocol MUST 744 provide a strong authentication between the device and the 745 controller, and integrity of the messages MUST be provided. 746 Confidentiality of the messages SHOULD also be provided. It is 747 important that the controller protocol be protected with algorithms 748 that are at least as strong as the algorithms used to protect the 749 IPsec packets. 751 6.1. IPsec policy negotiation 753 In many controller based networks, there is a single IPsec policy 754 used by all devices and there is no need to redistribute or select 755 policy details. However, in some circumstances, there may be a need 756 to have multiple policy options. This could happen when a controller 757 changes the policy and wants to smoothly migrate all devices to the 758 new policy. Or it could happen if a network supports devices with 759 different capabilities. In these cases, devices need to be able to 760 choose the correct policy to use for each other device, and must do 761 this without sending additional messages and without sending 762 individual messages to each peer. When a device supports multiple 763 policies, it MUST include those policies within the DIM. This is 764 done by sending multiple distinct policies, in order of preference, 765 where the first policy is the most preferred. The policy to use is 766 selected by taking the receiver's list of policies (i.e., the list 767 advertised by the device that generates Nr), starting with the first 768 policy, compare against the initiator's (device that generates Ni) 769 list, and choosing the first one found in common. The method 770 conforms to the IKEv2 Cryptographic Algorithm Negotiation described 771 in Section 2.7 of [RFC7296]. (However, see additional discussion 772 when IKEv2 payloads are used in Appendix A.3.1). 774 If there is no match, this indicates a controller configuration 775 error. These devices MUST NOT establish new SAs until a DIM is 776 received that does produce a match. 778 When a device supports more than one DH group, then a unique DH 779 public number MUST be specified for each in order of preference. The 780 selection of which DH group to use follows the same logic as Policy 781 selection, using the receiver's list order until a match is found in 782 the initiator's list. 784 7. Security Considerations 786 This document proposes that a device re-use an ephemeral Diffie- 787 Hellman exponential with multiple peers. There are some known 788 potential vulnerabilities to this approach, which can be mitigated by 789 the device first validating a peer's public value to be a safe public 790 value before combining its own private value with it. The tests 791 which MUST be performed are described in [RFC6989]. See [REUSE] for 792 additional security considerations when reusing ephemeral Diffie- 793 Hellman keys. 795 A controller acts as a "trusted third party", which asserts that a 796 particular Diffie-Hellman public value is associated with a 797 particular entity. A device receiving the public key is not required 798 to validate the assertion. 800 A subverted controller can act as a "man-in-the-middle" between a 801 pair of devices. The easiest attack would be for the attacker to 802 adjust the routing for the desired traffic through a compromised 803 gateway and directly observe the cleartext. It is also possible that 804 a subverted controller could provide a device with a Diffie-Hellman 805 public value that actually belongs to a compromised gateway rather 806 than the intended gateway, but doing so does not seem to be 807 necessary. Nonetheless, the attack of a subverted controller can be 808 mitigated by having a device sign its Diffie-Hellman public value 809 (e.g, as a CMS Signed data object), where the receiver validates the 810 digital signature on the object. However, this adds significant 811 processing cost to a rekey and does not fit the controller-based 812 network architecture model. 814 A subverted IPsec device whose DH pair has been compromised would be 815 vulnerable to all of its IPsec traffic using that DH pair being 816 compromised. Assuming the use of strong DH algorithms (including 817 quantum resistant algorithms as they become available), the 818 compromise would most likely be due to the device itself being 819 compromised. Such a compromised device is also vulnerable to a 820 direct plaintext compromise. 822 PFS is achieved between rekey periods, as DH pairs are required to be 823 generated independently. However, because a device uses the same 824 long-term key to generate session key with multiple peers, there is 825 no PFS between sessions within the same rekey period. To reduce key 826 exposure outside of a rekey period, when a connection is closed each 827 endpoint MUST forget not only the keys used by the connection but 828 also any information that could be used to recompute those keys. 829 However, the DH private key value and the nonce distributed with it 830 may be forgotten only once the last IPsec SA that uses the private 831 key value is removed from the SAD and there is no chance that a new 832 IPsec SA could be setup that requires the private key value. 834 If quantum resistance is considered to be an issue, the controller 835 can distribute a PSK, which could be used to create the SK_d in the 836 manner shown in [I-D.ietf-ipsecme-qr-ikev2]. 838 8. IANA Considerations 840 This memo specifies no IANA actions. 842 9. Acknowledgements 844 Graham Bartlett provided many useful comments and suggestions. Rafa 845 Marin-Lopez and Gabriel Lopez-Millan provided valuable reviews and 846 advice regarding SDN use cases. 848 10. References 850 10.1. Normative References 852 [IKEV2-IANA] 853 IANA, "Internet Key Exchange Version 2 (IKEv2) 854 Parameters", February 2016, 855 . 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, 860 DOI 10.17487/RFC2119, March 1997, 861 . 863 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 864 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 865 December 2005, . 867 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 868 Tests for the Internet Key Exchange Protocol Version 2 869 (IKEv2)", RFC 6989, DOI 10.17487/RFC6989, July 2013, 870 . 872 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 873 Kivinen, "Internet Key Exchange Protocol Version 2 874 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 875 2014, . 877 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 878 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 879 May 2017, . 881 10.2. Informative References 883 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] 884 Lopez, R. and G. Lopez-Millan, "Software-Defined 885 Networking (SDN)-based IPsec Flow Protection", draft-ietf- 886 i2nsf-sdn-ipsec-flow-protection-03 (work in progress), 887 October 2018. 889 [I-D.ietf-ipsecme-qr-ikev2] 890 Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov, 891 "Postquantum Preshared Keys for IKEv2", draft-ietf- 892 ipsecme-qr-ikev2-07 (work in progress), January 2019. 894 [I-D.sajassi-bess-secure-evpn] 895 Sajassi, A., Banerjee, A., Thoria, S., Carrel, D., and B. 896 Weis, "Secure EVPN", draft-sajassi-bess-secure-evpn-00 897 (work in progress), October 2018. 899 [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 900 Diffie-Hellman Key Agreement Protocols", December 2008, 901 . 904 [RFC7018] Manral, V. and S. Hanna, "Auto-Discovery VPN Problem 905 Statement and Requirements", RFC 7018, 906 DOI 10.17487/RFC7018, September 2013, 907 . 909 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 910 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 911 Defined Networking (SDN): Layers and Architecture 912 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 913 2015, . 915 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 916 and J. Jeong, "Interface to Network Security Functions 917 (I2NSF): Problem Statement and Use Cases", RFC 8192, 918 DOI 10.17487/RFC8192, July 2017, 919 . 921 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 922 Kumar, "Framework for Interface to Network Security 923 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 924 . 926 Appendix A. Example Controller protocols 928 This section contains suggestions of how a Controller protocol might 929 distribute policy for the Controller-based IKE. 931 A.1. Example: I2NSF 933 IPsec devices described in this document could be implemented as an 934 Network Security Function (NSF) in the I2NSF Framework [RFC8329]. An 935 I2NSF Controller or NSF Manager could distribute a DIM as a new type 936 of I2NSF Policy Rule. A YANG configuration data model would need to 937 be defined for this. This could be a new "Case 3" defined in 938 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. 940 A.2. Example: Network Controller 942 Site-to-site networks (e.g., an L2VPN or L3VPN) often use a network 943 controller to share networking state between routers. When those 944 routers use IPsec to protect the communications between themselves, 945 this same network controller could distribute DH public number and 946 nonces as well. For example, when a BGP Route Reflector (RR) is used 947 in a network, a new address family (AFI) could distribute the state 948 necessary for a controller-based IPsec key exchange. The BGP session 949 between BGP routers and the Route Reflector (RR) would need to at 950 least be integrity protected from a man in the middle and SHOULD be 951 protected for confidentiality to prevent identity leakage. 953 The controller protocol MUST provide for adequate synchronization of 954 the state. For example, when IPsec devices are synchronized with a 955 key management protocol it is often necessary for the protocol to 956 indicate when a device has rebooted and thinks that it is contacting 957 peers for the first time. This alerts peers to destroy earlier 958 keying state that they may still believe is current. 960 One possible method for distributing a DIM within a controller 961 protocol is to use a set of IKEv2 payloads. For example, when a 962 single set of IPsec policy has been distributed to all IPsec devices 963 by a configuration server then the following minimum required data 964 elements can be distributed using the following IKEv2 payloads. 966 ID, [N(INITIAL_CONTACT),] KE, Ni 968 When initiating a rekey, the IPsec device need only distribute its 969 new DH public number due to Rule 1. Existing peers receiving the new 970 DH public number need not be re-told about the previous DH public 971 number. Any new peer that receives and acts upon a "stale" 972 controller message (containing the old DH public number) will still 973 be able to setup IPsec SAs using the old DH public number, and can 974 use them until the new DH public number is received. 976 A.3. Additional controller protocol considerations 978 If the controller protocol is more complicated, there are some 979 additional considerations. 981 A.3.1. Peer-to-peer distribution of IPsec policy 983 In some cases an IPsec device may have more than one IPsec policy 984 under which it is willing to communicate. This would result in an 985 IPsec device using the decision process described in Section 6.1 to 986 determine which policy to use between itself and that peer. An IKEv2 987 SA payload could be used to distribute the policies, and the decision 988 process could be used to determine which single set of policy is to 989 be used. Note that the same decision process is followed by both 990 peers. It is important that when an SA payload is used, that each 991 proposal within the SA payload MUST contain at most a single 992 transform for each Transform type (e.g., ENCR and (optionally) ESN 993 for combined mode algorithms, ENCR, INTEG, and (optionally) ESN 994 otherwise). This is due to the absence of a direct peer-to-peer 995 reply message, which would alert the sender of which proposal was 996 chosen. 998 1. Determine the Responder (as defined in Section 5.2.1.2). 1000 2. Follow the negotiation rules defined in Section 2.7 of IKEv2 1001 [RFC7296] (with the restrictions that more than one transform of 1002 each type MUST NOT be present, and no error notifications are 1003 returned to the peer). Each peer will independently compare each 1004 Proposal in the Responder's SA payload to each Proposal in the 1005 Initiator's SA payload and choose the first match. 1007 3. If there is no match, then this is considered a controller error, 1008 and the IPsec devices SHOULD report the error to the controller. 1010 Payloads distributed in the controller protocol could be as follows: 1012 ID, [N(INITIAL_CONTACT),] SA, KE, Ni 1014 where the SA payload contains one or more Proposals, each of this 1015 includes a transform indicating the Diffie-Hellman group it is 1016 willing to use (D-H Transform), and IPsec transforms that it is 1017 willing to use (e.g., ENCR, INTEG, and ESN Transforms). The KE 1018 payload includes a DH public number matching the D-H Transform. 1020 Because there is no direct peer-to-peer IKE messages, there is a need 1021 for peers to reliably know which Proposal in the SA payload was 1022 chosen. That is, if they do not reliably follow the same decision 1023 process they may end up installing IPsec SAs with incompatible 1024 policy. A straightforward method to verify that a peer has chosen 1025 the same policy is to include the SA Proposal number (SPN) from the 1026 SA payload in the SPI calculation. 1028 {p_SPI_i|p_SPI_r} = prf+(Ni | Nr, "SPI generation" | SPNi | SPNr) 1030 If a device is willing to use more than one DH group, then a single 1031 SA payload should be distributed, but the included Proposals may 1032 contain different D-H Transforms. A KE payload must be included for 1033 each D-H Group that is offered in the SA payload. 1035 ID, [N(INITIAL_CONTACT),] [SA,] KE, [KE,] Ni 1037 A.3.2. Ordering of messages distributed to a controller 1039 A controller protocol may require a method of determining ordering of 1040 messages that are distributed, i.e. a Rekey Counter (RC). It is 1041 RECOMMENDED that the ordering be defined by a monotonically 1042 increasing counter value distributed with the IPsec policy. It is 1043 further RECOMMENDED that to ensure ordering after a device reboot 1044 that the counter include a "boot count", which increments after each 1045 reboot. For example, the counter could be a 64-bit counter where the 1046 high order 32 bits are a "boot count", followed by the counter that 1047 begins at 1 following the increment of the "boot count". 1049 Appendix B. Choosing whether to use IKEv2 or Controller IKE 1051 The following list describes the circumstances in which Controller 1052 IKE may be preferable to IKEv2. Note that Controller IKE does not 1053 replace IKEv2, but does provide an alternative for some network 1054 architectures where it is more optimal. 1056 Trust Model Controller IKE is optimal when a device-to- 1057 controller trust model is in use. IKEv2 is a 1058 better approach when IPsec devices require a 1059 peer-to-peer trust model. 1061 Latency Controller IKE reduces tunnel session setup 1062 latency in a device-to-controller trust model. 1063 Once controller communications hace commenced, a 1064 session can be initiated with any other IPsec 1065 device managed by that controller without 1066 requiring additional key management messages. 1067 This is optimal when a group of IPsec devices are 1068 sensitive to latency. 1070 Load Balancing In some network architectures a full mesh of 1071 IKEv2 sessions can occur without affecting the 1072 load of IPsec and IKEv2 processing on any of the 1073 communicating IPsec devices, including having 1074 protocol state machinery to handle an IPsec peer 1075 device that is overloaded and not reliably 1076 responding. But when a set of IPsec devices is 1077 very large, this can be problematic. Also, when 1078 an IPsec device is overloaded there may be re- 1079 transmissions of IKEv2 messages, which further 1080 complicates protocol state. The simplified 1081 control plane of Controller IKE makes load 1082 balancing a purely local matter, where the 1083 installation of IPsec IPsec SAs takes into 1084 consideration only available local resources. 1085 And because there are no peer-to-peer key 1086 management messages, no re-transmissions occur. 1088 Complexity Full attribute negotiation is not needed in a 1089 controller environment. Controllers enforce the 1090 SA policy details, moving complexity away from 1091 end nodes. This also reduces the attack surface 1092 on the end node. 1094 Network Shape In some network topologies a persistent bi- 1095 directional link does not exist between all 1096 peers. Sometimes one direction has significantly 1097 reduced capabilities or is even non-existent. 1098 This can be either temporary or permanent, and 1099 sometimes is a purposefully enforced restriction. 1100 Provided that both peers can communicate with the 1101 controller, Controller IKE allows for the 1102 establishment of SAs and rekeying in these 1103 scenarios. 1105 Appendix C. Implementation Considerations 1107 The system architecture of many implementations includes a separation 1108 between a data plane "fastpath" and a "control plane". The data 1109 plane performs IPsec encapsulation and decapsulation in the simplest 1110 and most expedient way possible, where the control plane handles the 1111 complexity of network protocols including state machines, timers, 1112 network communication, and managing the data plane. 1114 A typical IKEv2 implementation on Linux works this way, with IKEv2 1115 running in user space and IPSec packet processing happening in the 1116 kernel. The kernel, or other fast path implementation, provides an 1117 interface for the control plane to manage it. This interface 1118 includes a way to create SAs, delete SAs, and observe statistics for 1119 SAs. Controller IKE is designed to be able to work with these same 1120 interfaces. For example a user space implementation of Controller 1121 IKE could work with a Linux kernel implementation of the IPSec data 1122 plane without needing kernel modifications. SA creation and deletion 1123 remains the same. SA creation occurs with Rules 1 and 2. SA 1124 deletion happens with Rules 3 and 4. Additionally Rules 3 and 4 need 1125 to observe that traffic has arrived on a particular SA. This can be 1126 done by observing packet counts on an SA and seeing when they go from 1127 zero to any positive number. Due to the asynchronous nature of 1128 Controller IKE, Rules 3 and 4 do not require immediate action when 1129 the first packets arrive, but instead they can be implemented with 1130 relaxed polling. 1132 Authors' Addresses 1134 David Carrel 1135 Cisco Systems 1136 170 W. Tasman Drive 1137 San Jose, California 95134-1706 1138 USA 1140 Phone: +1-408-525-7852 1141 Email: carrel@cisco.com 1143 Brian Weis 1144 Independent 1145 USA 1147 Email: bew.stds@gmail.com