**Session Date/Time:** 08 Nov 2021 12:00

# ipsecme

## Summary

The ipsecme working group session at IETF 112 covered the status of various documents, with significant discussion on the `iptfs` aggregation/fragmentation protocol. Key technical points were debated regarding packet reordering and delay, leading to specific document modifications. Discussions also included the current efforts in quantum-resistant key exchanges, particularly concerning the `ikev2-beyond-64k` draft and the trade-offs between security, complexity, and performance. Updates were provided on Group Key Management for IKEv2 (`g-ikev2`) and a proposal for announcing supported authentication methods in IKEv2. Several drafts were identified for upcoming Working Group Last Call or Adoption Calls.

## Key Discussion Points

*   **Document Status Update:**
    *   `draft-ietf-ipsecme-ikev2-intermediate`: Currently in "Publication Requested" state.
    *   `iptfs` document set (`main`, `yang`, `bignum`): `main` is expected to be ready for "Publication Requested" soon after this IETF. `yang` and `bignum` need further write-ups.
    *   `rfc8229bis` (YANG for IKEv2): Ready for Working Group Last Call (WGLC).
    *   `draft-ietf-ipsecme-g-ikev2`: Needs more reviews.
    *   `draft-ietf-ipsecme-ikev2-auth-announce`: Ready for Working Group (WG) adoption call.
    *   `draft-btw-ipsecme-additional-ikev2-auth-methods`: Also ready for WG adoption call.
    *   Other non-WG drafts (e.g., compression) received no updates; authors encouraged to engage the mailing list.

*   **IPTFS Discussion (`draft-ietf-ipsecme-iptfs-main`)**:
    *   **2021 Recap:** Post-WGLC comments led to language changes (e.g., "ag-frag" instead of "IPTFS") and clarifications on replay/reorder windows. A key change was the *recommendation for using a drop timer* for detecting lost packets, rather than relying solely on the reorder window.
    *   **Core Debate: "Should" vs. "May" for Immediate Inner Packet Transmission:**
        *   **Christian's Position:** The document currently uses "may" (optimization for receiver to transmit fully formed inner packets prior to reordering outer packets). With a drop timer, the reorder window is for minor reordering, not packet loss detection. This approach is flexible and allows operational experience to dictate optimal settings.
        *   **Tero's Position:** Concerned about the implications of sending inner packets out of order, particularly the *amplification of out-of-order delivery* to transport protocols (e.g., TCP), increased memory usage, and difficulty in defining a suitable "drop timer" for non-constant bit rate scenarios. Argues that IPsec should not try to fix general network reordering. Proposed "should" for in-order processing of outer packets to prevent amplification.
        *   **Lou's Concern:** Amplifying reordering is risky for transport protocols; TCP connections can reset if packets are too far out of order. Prioritizes safety and existing protocol behavior. Advocates for "may" and letting operational experience guide deployment.
        *   **Valerie's Comment:** Sending aggregated packets in a "bunch" due to immediate processing can cause congestion and burstiness.
    *   **Lost Packet Timer:** Agreement to rename "drop timer" to "lost packet timer" to better reflect its function (assuming a packet is lost after a timeout, but not necessarily discarding it from buffers).

*   **Quantum Resistant Dust Protection / Big Keys (`draft-ietf-ipsecme-ikev2-beyond-64k`)**:
    *   **Proposal:** Introduce a "cost-efficient" quantum-resistant (QR) first barrier in `IKE_SA_INIT` using a single, efficient QR KEM. This is seen as an interim solution for high-security environments (e.g., governmental/military) to gain immediate QR protection without the full complexity of hybrid or multiple key exchanges initially.
    *   **Performance:** Measurements with UDP transport showed handshake durations of ~10 seconds for 100 Mbps/100ms latency networks with up to 10% packet loss, deemed acceptable for specific site-to-site use cases. Performance was significantly worse (50+ seconds) at 1 Mbps, suggesting it's not suitable for unreliable/low-throughput environments.
    *   **DoS Concern:** Sending large QR public keys from unauthenticated peers can lead to denial-of-service (DoS) or memory exhaustion attacks on gateways.
        *   **Recommendation:** Larger key exchanges (like those requiring `beyond-64k`) should be performed *after authentication* (e.g., via rekeying or follow-up exchanges) to mitigate DoS risks.
    *   **Valerie's Feedback:**
        *   Advocated for mixed transport (TCP for handshake, UDP for payload) for `beyond-64k` to improve reliability.
        *   The `multiple-key-exchanges` draft offers greater flexibility than fixed combined schemes. Similar results can be achieved using classical `IKE_SA_INIT` followed by an intermediate exchange with a small QR key.
        *   `RFC 8764` (using Preshared Keys for QR) is an existing short-term solution.
        *   Suggested that defining combined key exchange methods could be a separate draft, and cautioned against fixed hash functions for key combination, recommending concatenation for better agility.
    *   **Scalability Concern:** 10-20 second delays are generally unacceptable for gateways handling hundreds or thousands of concurrent client connections. This solution is targeted at specific, secure, low-client-count scenarios.

*   **Group Key Management Using IKEv2 (`draft-ietf-ipsecme-g-ikev2`)**:
    *   **Status:** The draft for securing IP multicast, used in IEEE 802.15.9, is considered mature by authors but *urgently needs reviews* from the WG.
    *   **Key Features:** Redesigned policy representation (IKEv2-style transforms), encrypted group key distribution (supporting logical key hierarchy), and new IKEv2 payloads (GSA, KDP, IDG) and notifications.
    *   **PPK Challenges:** Using Preshared Key (PPK) with G-IKEv2 is complex due to the need for `IKE_SA_INIT` to be secure from the beginning. An alternative draft (`draft-vallee-ipsecme-alternate-pqc-with-psk-for-ikev2`) was mentioned as a potential solution to simplify this.

*   **Announcing Supported Authentication Methods in IKEv2 (`draft-ietf-ipsecme-ikev2-auth-announce`)**:
    *   **Problem:** IKEv2 lacks negotiation of authentication methods. Initiators might choose a method (e.g., RSA PSS) not supported by the responder, leading to authentication failure without clear diagnostic information.
    *   **Proposed Solution:** A new optional `Supported Auth Method` status notification allowing peers to announce the authentication methods they *support* (implemented/allowed). This is an *announcement*, not a negotiation.
    *   **Details:** Supports linking to `CertReq` payloads for certificate-based authentication. Can be sent in `IKE_SA_INIT` or `IKE_INTERMEDIATE` (to avoid fragmentation for large announcements).
    *   **Clarification:** Discussion about the distinction between *supported* (implemented capabilities) and *configured* (allowed for a specific connection/peer). The responder's announcement would ideally reflect what's allowed for the `IDi` it expects, which is only known after receiving the `IDi` payload.

*   **Other Drafts for Adoption:**
    *   `draft-vallee-ipsecme-ikev2-cookie-processing`
    *   `draft-vallee-ipsecme-alternate-pqc-with-psk-for-ikev2`
    *   `draft-ietf-ipsecme-ikev2-beyond-64k`
    *   `draft-ietf-ipsecme-multiple-key-exchanges`: Author (Paul Wouters) reported updates (removal of QoS, simplification), encouraging reviews.

## Decisions and Action Items

*   **IPTFS (`draft-ietf-ipsecme-iptfs-main`)**:
    *   **Decision:** The document text will be modified to change "should" to "may" regarding the immediate transmission of fully formed inner packets by the receiver. This allows for both in-order processing of outer packets and immediate transmission of inner packets.
    *   **Action Item:** Christian to rename "drop timer" to "lost packet timer" in the text.
    *   **Action Item:** Christian to add clarifying text discussing the potential for amplification of out-of-order inner packet delivery, burstiness, and extra delay associated with each approach.
    *   **Action Item:** An informative statement will be added recommending that the lost packet timer should correspond proportionately to the expected tunnel rate.
    *   **Action Item:** Christian to publish a new version of the draft incorporating these changes for immediate review by the working group.

*   **G-IKEv2 (`draft-ietf-ipsecme-g-ikev2`)**:
    *   **Decision:** The Chairs will initiate a Working Group Last Call to solicit comprehensive reviews, which are critically needed for this draft.

*   **Announcing Supported Authentication Methods in IKEv2 (`draft-ietf-ipsecme-ikev2-auth-announce`)**:
    *   **Decision:** The Chairs will initiate a Working Group Adoption Call for this document.

*   **Other Drafts for Adoption**:
    *   **Action Item:** Authors of `draft-vallee-ipsecme-ikev2-cookie-processing`, `draft-vallee-ipsecme-alternate-pqc-with-psk-for-ikev2`, and `draft-ietf-ipsecme-ikev2-beyond-64k` are encouraged to send emails to the mailing list to gauge interest for WG adoption calls.

## Next Steps

1.  Publish the updated `iptfs` draft (`draft-ietf-ipsecme-iptfs-main`) with agreed-upon changes.
2.  Initiate a Working Group Last Call for `draft-ietf-ipsecme-g-ikev2`.
3.  Initiate a Working Group Adoption Call for `draft-ietf-ipsecme-ikev2-auth-announce` and `draft-btw-ipsecme-additional-ikev2-auth-methods`.
4.  Engage on the mailing list for other drafts seeking adoption.