Markdown Version | Session Recording | Session Materials

Session Date/Time: 09 Nov 2022 15:00

ipsecme

Summary

The ipsecme working group session discussed the status of various drafts, several new proposals, and challenges in scaling IPSec deployments. Key topics included the adoption of optimized multi-child SA rekeying, issues with IKEv2 payload size limits and cookie processing, source address validation using RPKI and IPSec, and a proposal for anti-replay subspaces to improve performance in multi-core and multi-path environments. The session highlighted a clear interest in addressing scalability and performance for large-scale IPSec deployments, particularly in the context of emerging post-quantum cryptography and 5G use cases.

Key Discussion Points

• Draft Status Update:

  • Four drafts are in the RFC Editor queue.
  • Two documents are in IETF/WG Last Call, with reminders for shepherd review (IKEv2) and additional reviews (P2).
  • IKEv2-no-ids was noted as ready for Working Group Last Call.

• Multiple Child SAs (draft-wouters-ipsecme-multiple-sas):

  • The latest version removes the "special fallback SA," making it an implementation-specific functionality.
  • Discussion on scalability concerns for large IPSec hubs with many SAs; the expected use case focuses on filling CPU capacity rather than excessive SA multiplication per tunnel.
  • Support for adoption as a starting point, with calls to potentially limit SA creation.

• IPSec Workshop Report:

  • FIPS requirements for AES-GCM: Clarified that the same key can be used for more than 2^32 packets in FIPS mode if IV/ICV is greater than 8 octets.
  • Decoupled Policies: Flat SPD data structures improve lookup efficiency.
  • Full Hardware Offload for IPSec: APIs exist for Linux, supported by Melanox Nvidia CX-7 cards, enabling full IPSec data path in hardware.
  • Forwarding Fast Path (Linux): Packet parking, using netfilter flow tables and small code loops, showed a 5x performance boost.
  • ANEMA and IPSec: Problem with VTI interfaces for network name status; XFRM interfaces were proposed as a solution.
  • IPTFS: Aggregation and fragmentation are supported, but constant rate sending is still missing.
  • Re-thinking ESP: Extensive discussion around multi-CPU, QoS, hardware flows, and anti-replay windows, potentially leading to an "ESPv4" due to limitations and new protocols like PLP Crypto.
  • Beat Mode: Despite being an old, unfinished draft (2008), it's implemented in Linux and widely used; a consensus to continue its work towards a Proposed Standard.

• IPComp Extension (draft-hu-ipsecme-ipcomp-extension):

  • Proposed extensions to address IPComp issues:
    1. Incompatibility with network functions: Transport layer (L4) information (ports) is compressed, hindering firewalls/NAT. Solutions proposed: new flag or duplicate CPI code points.
    2. Out-of-order processing: Uncompressed packets sent without an IPComp header are processed differently. Proposed solution: always send IPComp header with a new CPI for uncompressed packets.
  • Discussion also touched on decoupling IPComp from IPSec, as its issues are not security-related.
  • The working group suggested exploring existing alternatives like IPTFS, CHIC over IP, or DIET-ESP for compression and MTU issues, indicating low interest in extending IPComp within ipsecme.

• New IKEv2 Payload Formats (draft-valerie-ipsecme-compact-ikev2-payloads-format, draft-wouters-ikev2-large-payloads):

  • Current IKEv2 payload length (2 bytes) limits payloads to 64KB, problematic for Post-Quantum (PQ) algorithms with large public keys and signatures (e.g., Classic McEliece).
  • Existing formats also exhibit redundancy (reserved fields, fixed-size parameters).
  • Proposals address either the 64KB limit or redundancy, with different negotiation and implementation complexities.
  • Working group expressed interest in a single, generic solution for the >64KB limit, with redundancy reduction being a separate, though related, concern.

• IKEv2 Cookie Rework (draft-valerie-ikev2-revised-cookie-processing):

  • Identified a protocol flaw where packet loss/reordering or a responder changing its secret key can cause IKE_SA_INIT authentication failures due to differing views of the most recent request used in calculation.
  • Proposed a "revised cookie processing" that excludes the cookie notify payload from authentication calculation, negotiated via a new notify message.
  • Concerns were raised about modifying the authentication system for a non-security-critical error, with suggestions for less intrusive solutions like the initiator echoing the cookie in IKE_AUTH for verification by the responder, leading to an error message if there's a mismatch.

• Receive RPKI and IPSec AS2AS Approach for Source Address Validation (rSAV) (draft-li-ipsecme-rsav):

  • Proposal for a cryptographically based inter-AS Source Address Validation (SAV) protocol using RPKI for prefix origin authorization and IPSec (rSAV AH in transport mode) for IP source address authentication.
  • Key features: RPKI integration, AS Contact Servers (ACS) for IKEv2 negotiation, rSAV announcement in RPKI, and IPSec SA indexed by SPI and AS number.
  • Discussion touched on specific IPSec protocol details, such as the use of DELETE notifications for rejection, the role of ICV in ESP, and the negotiation of transport vs. tunnel mode.
  • A warning was raised against using Static Diffie-Hellman due to the lack of Post-Quantum equivalents.
  • The proposal is in early stages, focusing on addressing large-scale IPSec mesh deployments and minimizing state.

• Optimized IKEv2 Rekeying (draft-li-ipsecme-optimized-rekeying):

  • Leverages RFC 7296 (section 2.8) to omit Traffic Selector (TS) and Security Association (SA) payloads during rekeying for child SAs if they are unchanged. This saves bandwidth and CPU cycles.
  • Implementation in 5G base stations reported, demonstrating practical value for large-scale, low-power, and constrained environments.
  • Clarification: This optimization primarily applies to child SAs, not IKE SAs, as IKE SAs can have different algorithms during rekeying.

• IPSec Anti-Replay Subspaces (draft-thompson-ipsecme-anti-replay-subspaces):

  • Addresses performance challenges in multi-core, multi-path IPSec hubs handling thousands of peers. Current approach of using many child SAs (e.g., 4M for 6 paths/6 QoS classes) leads to high IKE negotiation load and memory issues.
  • Proposal: Introduce multiple anti-replay windows within a single child SA, distinguished by a "Subspace ID" in the ESP header.
  • Discussion points include IKE negotiation mechanisms, where to embed the Subspace ID in the ESP header (e.g., explicit extended sequence number field), and FIPS compliance for AES-GCM nonces.
  • The working group acknowledged the problem, with some suggesting that separate SAs are the existing solution, while others highlighted the scalability issues of that approach in large-scale deployments.

Decisions and Action Items

• Multiple Child SAs (draft-wouters-ipsecme-multiple-sas): A working group adoption call will be issued.
• New IKEv2 Payload Formats: Valerie to draft a combined solution addressing both the >64KB payload size limit and message redundancy.
• IKEv2 Cookie Rework (draft-valerie-ikev2-revised-cookie-processing): Valerie to send an email to the mailing list to gather feedback on the problem and the proposed solutions, particularly Tero's suggestion of an explicit cookie copy in IKE_AUTH.
• Optimized IKEv2 Rekeying (draft-li-ipsecme-optimized-rekeying): A working group adoption call will be issued.
• IPSec Anti-Replay Subspaces (draft-thompson-ipsecme-anti-replay-subspaces): Discussions to continue on the mailing list.

Next Steps

• Chairs to issue adoption calls for draft-wouters-ipsecme-multiple-sas and draft-li-ipsecme-optimized-rekeying.
• Valerie to initiate mailing list discussions for IKEv2 payload formats and IKEv2 cookie rework.
• Proponents of IPSec Anti-Replay Subspaces to continue mailing list discussions, with a virtual interim meeting proposed to consolidate ideas.
• Continue work on Beat Mode to bring it to Proposed Standard status.
• Monitor new developments like ESPv4 and IPTFS as potential solutions for existing problems.

Related Documents

draft-hu-ipsecme-ipcomp-extension, draft-li-ipsecme-optimized-rekeying, draft-li-ipsecme-rsav, draft-thompson-ipsecme-anti-replay-subspaces, draft-valerie-ikev2-revised-cookie-processing, draft-valerie-ipsecme-compact-ikev2-payloads-format, draft-wouters-ikev2-large-payloads, draft-wouters-ipsecme-multiple-sas