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