idnits 2.17.1 draft-pwouters-ipsecme-multi-sa-performance-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 October 2021) is 925 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) == Missing Reference: 'TBD1' is mentioned on line 522, but not defined == Missing Reference: 'TBD2' is mentioned on line 523, but not defined == Missing Reference: 'TBD3' is mentioned on line 531, but not defined == Missing Reference: 'TO DO' is mentioned on line 386, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2367 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network A. Antony 3 Internet-Draft secunet 4 Intended status: Standards Track T. Brunner 5 Expires: 16 April 2022 codelabs 6 S. Klassert 7 secunet 8 P. Wouters 9 Aiven 10 13 October 2021 12 IKEv2 support for per-queue Child SAs 13 draft-pwouters-ipsecme-multi-sa-performance-02 15 Abstract 17 This document defines three Notify Message Type Payloads for the 18 Internet Key Exchange Protocol Version 2 (IKEv2) indicating support 19 for the negotiation of multiple identical Child SAs to optimize 20 performance. 22 The CPU_QUEUES notification indicates support for multiple queues or 23 CPUs. The CPU_QUEUE_INFO notification is used to confirm and 24 optionally convey information about the specific queue. The 25 TS_MAX_QUEUE notify conveys that the peer is unwilling to create more 26 additional Child SAs for this particular Traffic Selector set. 28 Using multiple identical Child SAs has the benefit that each stream 29 has its own Sequence Number Counter, ensuring that CPUs don't have to 30 synchronize their crypto state or disable their packet replay 31 protection. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 16 April 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2. Performance bottlenecks . . . . . . . . . . . . . . . . . . . 3 69 3. Negotiation of CPU specific Child SAs . . . . . . . . . . . . 3 70 4. Implementation Considerations . . . . . . . . . . . . . . . . 5 71 5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 6 72 5.1. CPU_QUEUES Notify Status Message Payload . . . . . . . . 6 73 5.2. CPU_QUEUE_INFO Notify Status Message Payload . . . . . . 7 74 5.3. TS_MAX_QUEUE Notify Error Message Payload . . . . . . . . 7 75 6. Operational Considerations . . . . . . . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Linux XFRM . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.2. Libreswan . . . . . . . . . . . . . . . . . . . . . . . . 10 80 8.3. strongSwan . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.4. iproute2 . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 IPsec implementations are currently limited to using one queue or CPU 91 per Child SA. The result is that a machine with many queues/CPUs is 92 limited to only using one of these per Child SA. This severely 93 limits the throughput that can be attained. An unencrypted link of 94 10Gbps or more is commonly reduced to 2-5Gbps when IPsec is used to 95 encrypt the link using AES-GCM. By using the implementation 96 specified in this document, aggregate throughput increased from 5Gbps 97 using 1 CPU to 40-60 Gbps using 25-30 CPUs 98 While this could be (partially) mitigated by setting up multiple 99 narrowed Child SAs, for example using Populate From Packet (PFP) as 100 specified in [RFC4301], this IPsec feature is not widely implemented. 101 Some route based IPsec implementations might be able to implement 102 this with specific rules into separate network interfaces, but these 103 methods might not be available for policy based IPsec 104 implementations. 106 To make better use of multiple network queues and CPUs, it can be 107 beneficial to negotiate and install multiple identical Child SAs. 108 IKEv2 [RFC7296] already allows installing multiple identical Child 109 SAs, it offers no method to negotiate the number of Child SAs or 110 indicate the purpose for the multiple Child SAs that are requested. 112 When two IKEv2 peers want to negotiate multiple Child SAs, it is 113 useful to be able to convey how many Child SAs are required for 114 optimized traffic. This avoids triggering CREATE_CHILD_SA exchanges 115 that will only be rejected by the peer. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 2. Performance bottlenecks 127 Currently, most IPsec implementations are limited by using one CPU or 128 network queue per Child SA. There are a number of practical reasons 129 for this, but a key limitation is that sharing the crypto state, 130 counters and sequence numbers between multiple CPUs is not feasible 131 without a significant performance penalty. There is a need to 132 negotiate and establish multiple Child SAs with identical TSi/TSr on 133 a per-queue or per-CPU basis. 135 3. Negotiation of CPU specific Child SAs 137 When negotiating CPU specific Child SAs, the first SA negotiated 138 either in an IKE_AUTH exchange or CREATE_CHILD_SA is called Fallback 139 SA. This Child SA is similar to a regular Child SA in that it is not 140 bound to a single CPU. This Fallback Child SA (or its rekeyed 141 successors) MUST remain active for the lifetime of the IPsec session 142 to ensure that there is always a Child SA that can be selected to 143 send traffic over, in case a per-resource Child SA is not available. 144 Additional Child SAs are installed bound to a specific CPU. These 145 Child SAs are responsible for the bulk of the traffic. 147 The CPU_QUEUES notification payload is sent in the IKE_AUTH or 148 CREATE_CHILD_SA Exchange indicating the negotiated Child SA is a 149 Fallback SA. 151 The CPU_QUEUES notification value refers to the number of additional 152 resource-specific Child SAs that may be installed for this particular 153 TSi/TSr combination excluding the Fallback Child SA. Both peers send 154 the preferred minimum number of additional Child SAs to install. 155 Both peers pick the maximum of the two numbers (within reason). That 156 is, if the initiator prefers 16 and the responder prefers 48, then 157 the number negotiated is 48. The responder may at any time reject 158 additional Child SAs by returning TS_MAX_QUEUE. It should not return 159 NO_ADDITIONAL_SAS, as there might be another Child SAs with different 160 Traffic Selectors that would still be allowed by the peer. 162 CPU-specific Child SAs are negotiated as regular Child SAs using the 163 CREATE_CHILD_SA exchange and are identified by a CPU_QUEUE_INFO 164 notification. Upon installation, each Child SA is associated with an 165 additional local selector, such as CPU or queue. These additional 166 Child SAs MUST be negotiated with identical Child SA properties that 167 were negotiated for the Fallback SA. This includes cryptographic 168 algorithms, Traffic Selectors, Mode (e.g. transport mode), 169 compression usage, etc. However, the Child SAs do have their own 170 individual keying material that is derived according to the regular 171 IKEv2 process. The CPU_QUEUE_INFO can be empty or contain some 172 identifying data that could be useful for debugging purposes. 174 Additional Child SAs can be started on-demand or can be started all 175 at once. Peers may also delete specific per-resource Child SAs if 176 they deem the associated resource to be idle. The Fallback SA MUST 177 NOT be deleted while any per-resource Child SAs are still present. 179 During the CREATE_CHILD_SA rekey for the Child SA, the CPU_QUEUE_INFO 180 notification MAY be included, but regardless of whether or not it is 181 included, the rekeyed Child SA MUST be bound to the same resource(s) 182 as the Child SA that is being rekeyed. 184 As with regular Child SA rekeying, the new Child SA may not be 185 different from the rekeyed Child SA with respect to cryptographic 186 algorithms and MUST cover the original Traffic Selector ranges. 188 If a CREATE_CHILD_SA exchange request containing both a 189 CPU_QUEUE_INFO and a CPU_QUEUES notification is received, the 190 responder MUST ignore the CPU_QUEUE_INFO payload. If a 191 CREATE_CHILD_SA exchange reply is received with both CPU_QUEUE_INFO 192 and CPU_QUEUES notifications, the initiator MUST ignore the 193 notification that it did not send in the request. 195 The CPU_QUEUES notification, even when it is sent in the IKE_AUTH 196 exchange, is not an attribute of the IKE peer. It is an attribute of 197 the Child SA, similar to the USE_TRANSPORT notification. That is, an 198 IKE peer can have multiple Child SAs covering different traffic 199 selectors and selectively decide whether or not to enable additional 200 per-resource Child SAs for each of these Child SAs covering different 201 Traffic Selectors. 203 4. Implementation Considerations 205 There are various considerations that an implementation can use to 206 determine the best way to install multiple Child SAs. Below are 207 examples of such strategies. 209 A simple distribution could be to install one additional Child SA on 210 each CPU. The Fallback Child SA ensures that any CPU generating 211 traffic to be encrypted has an available (if not optimal) Child SA to 212 use. Any subsequent Child SAs with identical TSi/TSr Traffic 213 Selectors are installed in such a way to only be used by a single CPU 214 or network queue. 216 Performing per-CPU Child SA negotiations can result in both peers 217 initiating additional Child SAs at once. This is especially likely 218 if per-CPU Child SAs are triggered by individual SADB_ACQUIRE 219 [RFC2367] messages. Responders should install the additional Child 220 SA on a CPU with the least amount of additional Child SAs for this 221 TSi/TSr pair. It should count outstanding SADB_ACQUIREs as an 222 assigned additional Child SA. It is still possible that when the 223 peers only have one slot left to assign, that both peers send a 224 CREATE_CHILD_SA request at the same time. 226 As an optimization, additional Child SAs that see little traffic MAY 227 be deleted. The Fallback Child SA MUST NOT be deleted when idle, as 228 it is likely to be idle if enough per-CPU Child SAs are installed. 229 However, if one of those per-CPU child SAs is deleted because it was 230 idle, and subsequently that CPU starts to generate traffic again, 231 that traffic does not have a per-CPU Child SA and will be encrypted 232 using the Fallback Child SA. Meanwhile, the IKE daemon might be 233 negotiating to bring up a new per-CPU Child SA. 235 When the number of queues or CPUs are different between the peers, 236 the peer with the least amount of queues or CPUs MAY decide to not 237 install a second outbound Child SA for the same resource as it will 238 never use it to send traffic. However, it MUST install all inbound 239 Child SAs as it has committed to receiving traffic on these 240 negotiated Child SAs. 242 If per-CPU SADB_ACQUIRE messages are implemented (see Section 6), the 243 Traffic Selector (TSi) entry containing the information of the 244 trigger packet should still be included in the TS set. This 245 information MAY be used by the peer to select the most optimal target 246 CPU to install the additional Child SA on. For example, if the 247 trigger packet was for a TCP destination to port 25 (SMTP), it might 248 be able to install the Child SA on the CPU that is also running the 249 mail server process. Trigger packet Traffic Selectors are documented 250 in [RFC7296] Section 2.9. 252 As per RFC 7296, rekeying a Child SA SHOULD use the same (or wider) 253 Traffic Selectors to ensure that the new Child SA covers everything 254 that the rekeyed Child SA covers. This includes Traffic Selectors 255 negotiated via Configuration Payloads (CP) such as 256 INTERNAL_IP4_ADDRESS which may use the original wide TS set or use 257 the narrowed TS set. 259 5. Payload Format 261 All multi-octet fields representing integers are laid out in big 262 endian order (also known as "most significant byte first", or 263 "network byte order"). 265 5.1. CPU_QUEUES Notify Status Message Payload 267 1 2 3 268 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 269 +-+-----------------------------+-------------------------------+ 270 ! Next Payload !C! RESERVED ! Payload Length ! 271 +---------------+---------------+-------------------------------+ 272 ! Protocol ID ! SPI Size ! Notify Message Type ! 273 +---------------+---------------+-------------------------------+ 274 ! Minimum number of IPsec SAs ! 275 +-------------------------------+-------------------------------+ 277 * Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0. 279 * SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0. 281 * Notify Status Message Type (2 octets) - set to [TBD1] 283 * Minimum number of per-CPU IPsec SAs (4 octets). MUST be greater 284 than 0. If 0 is received, it MUST be interpreted as 1. 286 Note: The Fallback Child SA that is not bound to a single CPU is not 287 counted as part of these numbers. 289 5.2. CPU_QUEUE_INFO Notify Status Message Payload 291 1 2 3 292 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 293 +-+-----------------------------+-------------------------------+ 294 ! Next Payload !C! RESERVED ! Payload Length ! 295 +---------------+---------------+-------------------------------+ 296 ! Protocol ID ! SPI Size ! Notify Message Type ! 297 +---------------+---------------+-------------------------------+ 298 ! ! 299 ~ Optional queue identifier ~ 300 ! ! 301 +-------------------------------+-------------------------------+ 303 * Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0. 305 * SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0. 307 * Notify Status Message Type (2 octets) - set to [TBD2] 309 * Optional Payload Data. This value MAY be set to convey the local 310 identity of the queue. The value SHOULD be a unique identifier 311 and the peer SHOULD only use it for debugging purposes. 313 5.3. TS_MAX_QUEUE Notify Error Message Payload 315 1 2 3 316 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 317 +-+-----------------------------+-------------------------------+ 318 ! Next Payload !C! RESERVED ! Payload Length ! 319 +---------------+---------------+-------------------------------+ 320 ! Protocol ID ! SPI Size ! Notify Message Type ! 321 +---------------+---------------+-------------------------------+ 323 * Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0. 325 * SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0. 327 * Notify Error Message Type (2 octets) - set to [TBD3] 329 * Optional Payload Data. Must be 0. 331 6. Operational Considerations 333 Implementations supporting per-CPU SAs SHOULD extend their local SPD 334 selector, and the mechanism of on-demand negotiation that is 335 triggered by traffic to include a CPU (or queue) identifier in their 336 SADB_ACQUIRE message from the SPD to the IKE daemon. If the IKEv2 337 extension defined in this document is negotiated with the peer, a 338 node which does not support receiving per-CPU SADB_ACQUIRE messages 339 MAY initiate all its Child SAs immediately upon receiving the (only) 340 SADB_ACQUIRE it will receive from the IPsec stack. Such 341 implementations also need to be careful when receiving a Delete 342 Notify request for a per-CPU Child SA, as it has no method to detect 343 when it should bring up such a per-CPU Child SA again later. And 344 bringing the deleted per-CPU Child SA up again immediately after 345 receiving the Delete Notify might cause an infinite loop between the 346 peers. Another issue of not bringing up all its per-CPU Child SAs is 347 that if the peer acts similarly, the two peers might end up with only 348 the Fallback SA without ever activating any per-CPU Child SAs. It is 349 there for RECOMMENDED to implement per-CPU SADB_ACQUIRE messages. 351 The minimum number of Child SAs negotiated should not be treated as 352 the maximum number of allowed Child SAs. Peers SHOULD be lenient 353 with this number to account for corner cases. For example, during 354 Child SA rekeying, there might be a large number of additional Child 355 SAs created before the old Child SAs are torn down. Similarly, when 356 using on-demand Child SAs, both ends could trigger multiple Child SA 357 requests as the initial packet causing the Child SA negotiation might 358 have been transported to the peer via the Fallback SA where its reply 359 packet might also trigger an on-demand Child SA negotiation to start. 360 A peer may want to allow up to double the negotiated minimum number 361 of Child SAs, and rely on idleness of Child SAs to tear down any 362 unused Child SAs gradually to to reach an optimal number of Child 363 SAs. Adding too many SAs may slow down per-packet SAD lookup. 365 Implementations might support dynamically moving a per-CPU Child SAs 366 from one CPU to another CPU. If this method is supported, 367 implementations must be careful to move both the inbound and outbound 368 SAs. If the IPsec endpoint is a gateway, it can move the inbound SA 369 and outbound SA independently from each other. It is likely that for 370 a gateway, IPsec traffic would be asymmetric. If the IPsec endpoint 371 is the same host responsible for generating the traffic, the inbound 372 and outbound SAs SHOULD remain as a pair on the same CPU. If a host 373 previously skipped installing an outbound SA because it would be an 374 unused duplicate outbound SA, it will have to create and add the 375 previously skipped outbound SA to the SAD with the new CPU ID. The 376 inbound SA may not have CPU ID in the SAD. Adding the outbound SA to 377 the SAD requires access to the key material, whereas for updating the 378 CPU selector on an existing outbound SAs. access to key material 379 might not be needed. To support this, the IKE software might have to 380 hold on to the key material longer than it normally would, as it 381 might actively attempt to destroy key material from memory that it no 382 longer needs access to. 384 7. Security Considerations 386 [TO DO] 388 8. Implementation Status 390 [Note to RFC Editor: Please remove this section and the reference to 391 [RFC6982] before publication.] 393 This section records the status of known implementations of the 394 protocol defined by this specification at the time of posting of this 395 Internet-Draft, and is based on a proposal described in [RFC7942]. 396 The description of implementations in this section is intended to 397 assist the IETF in its decision processes in progressing drafts to 398 RFCs. Please note that the listing of any individual implementation 399 here does not imply endorsement by the IETF. Furthermore, no effort 400 has been spent to verify the information presented here that was 401 supplied by IETF contributors. This is not intended as, and must not 402 be construed to be, a catalog of available implementations or their 403 features. Readers are advised to note that other implementations may 404 exist. 406 According to [RFC7942], "this will allow reviewers and working groups 407 to assign due consideration to documents that have the benefit of 408 running code, which may serve as evidence of valuable experimentation 409 and feedback that have made the implemented protocols more mature. 410 It is up to the individual working groups to use this information as 411 they see fit". 413 Authors are requested to add a note to the RFC Editor at the top of 414 this section, advising the Editor to remove the entire section before 415 publication, as well as the reference to [RFC7942]. 417 8.1. Linux XFRM 419 Organization: Linux kernel XFRM 421 Name: XFRM-PCPU-v1 422 https://git.kernel.org/pub/scm/linux/kernel/git/klassert/linux- 423 stk.git/log/?h=xfrm-pcpu-v1 425 Description: An initial Kernel IPsec implementation of the per-CPU 426 method. 428 Level of maturity: Alpha 430 Coverage: Implements Fallback Child SA and per-CPU Child SAs. It 431 only supports the NETLINK API. The PFKEYv2 API is not supported. 433 Licensing: GPLv2 435 Implementation experience: The Linux XFRM implementation added two 436 additional attributes to support per-CPU SAs. There is a new 437 attribute XFRMA_SA_PCPU, u32, for the SAD entry. This attribute 438 should present on the outgoing SA, per-CPU Child SAs, starting 439 from 0. This attribute MUST NOT be present on the Fallback XFRM 440 SA. It is used by the kernel only for the outgoing traffic, 441 (clear to encrypted). The incoming SAs, both the Fallback and the 442 per-CPU SA, do not need XFRMA_SA_PCPU attribute. XFRM stack can 443 not use CPU id on the incoming SA. The kernel internally sets the 444 value to 0xFFFFFF for the incoming SA and the Fallback SA. 445 However, one may add XFRMA_SA_PCPU to the incoming per-CPU SA to 446 steer the ESP flow, to a specific Q or CPU e.g ethtool ntuple 447 configuration. The SPD entry has new flag 448 XFRM_POLICY_CPU_ACQUIRE. It should be set only on the "out" 449 policy. The flag should be disabled when the policy is a trap 450 policy, without SPD entries. After a successful negotiation of 451 CPU_QUEUES, while adding the Fallback Child SA, the SPD entry can 452 be updated with the XFRM_POLICY_CPU_ACQUIRE flag. When 453 XFRM_POLICY_CPU_ACQUIRE is set, the XFRM_MSG_ACQUIRE generated 454 will include the XFRMA_SA_PCPU attribute. 456 Contact: Steffen Klassert steffen.klassert@secunet.com 458 8.2. Libreswan 460 Organization: The Libreswan Project 462 Name: pcpu-3 https://libreswan.org/wiki/XFRM_pCPU 464 Description: An initial IKE implementation of the per-CPU method. 466 Level of maturity: Alpha 468 Coverage: implements Fallback Child SA and per-CPU additional Child 469 SAs 471 Licensing: GPLv2 473 Implementation experience: TBD 475 Contact: Libreswan Development: swan-dev@libreswan.org 477 8.3. strongSwan 479 Organization: The StrongSwan Project 481 Name: StrongSwan https://github.com/strongswan/strongswan/tree/per- 482 cpu-sas-poc/ 484 Description: An initial IKE implementation of the per-CPU method. 486 Level of maturity: Alpha 488 Coverage: implements Fallback Child SA and per-CPU additional Child 489 SAs 491 Licensing: GPLv2 493 Implementation experience: StrongSwan use private space values for 494 notifications CPU_QUEUES (40970) and QUEUE_INFO (40971). 496 Contact: Tobias Brunner tobias@strongswan.org 498 8.4. iproute2 500 Organization: The iproute2 Project 502 Name: iproute2 https://github.com/antonyantony/iproute2/tree/pcpu-v1 504 Description: Implemented the per-CPU attributes for the "ip xfrm" 505 command. 507 Level of maturity: Alpha 509 Licensing: GPLv2 511 Implementation experience: TBD 513 Contact: Antony Antony antony.antony@secunet.com 515 9. IANA Considerations 517 This document defines two new IKEv2 Notify Message Type payloads for 518 the IANA "IKEv2 Notify Message Types - Status Types" registry. 520 Value Notify Type Messages - Status Types Reference 521 ----- ------------------------------ --------------- 522 [TBD1] CPU_QUEUES [this document] 523 [TBD2] CPU_QUEUE_INFO [this document] 524 Figure 1 526 This document defines one new IKEv2 Notify Message Type payloads for 527 the IANA "IKEv2 Notify Message Types - Error Types" registry. 529 Value Notify Type Messages - Status Types Reference 530 ----- ------------------------------ --------------- 531 [TBD3] TS_MAX_QUEUE [this document] 533 Figure 2 535 10. References 537 10.1. Normative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 545 Management API, Version 2", RFC 2367, 546 DOI 10.17487/RFC2367, July 1998, 547 . 549 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 550 Kivinen, "Internet Key Exchange Protocol Version 2 551 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 552 2014, . 554 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 555 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 556 May 2017, . 558 10.2. Informative References 560 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 561 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 562 December 2005, . 564 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 565 Code: The Implementation Status Section", RFC 6982, 566 DOI 10.17487/RFC6982, July 2013, 567 . 569 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 570 Code: The Implementation Status Section", BCP 205, 571 RFC 7942, DOI 10.17487/RFC7942, July 2016, 572 . 574 Authors' Addresses 576 Antony Antony 577 secunet Security Networks AG 579 Email: antony.antony@secunet.com 581 Tobias Brunner 582 codelabs GmbH 584 Email: tobias@codelabs.ch 586 Steffen Klassert 587 secunet Security Networks AG 589 Email: steffen.klassert@secunet.com 591 Paul Wouters 592 Aiven 594 Email: paul.wouters@aiven.io