ESP Echo Protocol
draft-colitti-ipsecme-esp-ping-00

IP Security Maintenance and Extensions                        L. Colitti
Internet-Draft                                                    Google
Intended status: Standards Track                            25 July 2023
Expires: 26 January 2024

                           ESP Echo Protocol
                   draft-colitti-ipsecme-esp-ping-00

Abstract

   This document defines an ESP echo function which can be used to
   detect whether a given network path supports IPv6 ESP packets.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 January 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Colitti                  Expires 26 January 2024                [Page 1]
Internet-Draft                  esp-ping                       July 2023

Table of Contents

   1.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Protocol Specification  . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Problem statement

   IPsec sessions between hosts that have global connectivity will by
   default use unencapsulated IPv6 ESP, i.e., IPv6 packets with a Next
   Header value of 50.  ESP packets may have advantages over ESP-in-UDP
   encapsulation, such as:

   *  They require fewer keepalive packets to keep sessions open.

      -  On some networks, ESP is be statelessly allowed in both
         directions, and thus not require any keepalive packets at all.
         For example, the IPv6 Simple Security recommendations [RFC6092]
         specify that ESP by default must always be allowed and not be
         subject to any timeouts.

      -  Even if ESP is not statelessly allowed, experience from real
         world networks is that timeouts for ESP are higher than for UDP
         sessions, thus requiring IPsec endpoints to send fewer
         keepalives.

   *  They provide slightly lower overhead, due to the absence of the
      UDP header.

   However, because ESP packets do not share fate with IKE packets, it
   is possible for the network to allow IKE packets but not ESP packets.
   This leads to the IPsec session not being able to exchange any
   packets even though IKE negotiation succeeded.  Because ESP is only

Colitti                  Expires 26 January 2024                [Page 2]
Internet-Draft                  esp-ping                       July 2023

   used after IKE negotiation, this failure mode is difficult to
   predict, difficult to detect, and difficult to recover from.  In
   particular, migrating a session using MOBIKE [RFC4555] to a network
   that doe snot allow ESP could result in the session blackholing all
   future packets until the problem is detected and a new migration is
   performed to enable encapsulation.

   Operational experience suggests that networks and some home routers
   that drop ESP packets are common enough to be a problem for general
   purpose VPN applications desiring to work reliably on the Internet.

3.  Protocol Specification

   An IPv6 node that desires to determine whether the path to a
   particular destination can support ESP packets can send an ESP Echo
   Request packet to that destination.  ESP Echo Request packets are ESP
   packets with an SPI value of [ESP-ECHO-REQUEST], a Next Header value
   of 59 (No Next Header), and no payload.

   If the destination supports ESP, and wishes to reveal to the sender
   that it does so, it SHOULD reply with an ESP Echo Reply packet.  ESP
   Echo Reply packets are ESP packets with an SPI value of [ESP-ECHO-
   REPLY], a Next Header value of 59, and no payload.

4.  Security Considerations

   The security considerations are similar to other unconnected request-
   reply protocols such as ICMPv6 echo.  In particular:

   *  By sending an ESP Echo Request from a spoofed source address, an
      attacker could cause a server to send an ESP Echo Reply to that
      address.  This does not constitute an amplification attack because
      the ESP Echo Reply is the same size as the ESP Echo Request.  This
      can be prevented by implementing ingress filtering per BCP 38
      [RFC2827].

   *  An attacker can use ESP Echo Request packets to determine whether
      a particular destination address is an ESP endpoint.  This is not
      a new attack because any endpoint that supports ESP must also
      reply to IKE INIT packets.

5.  IANA Considerations

   This memo requests that IANA allocate two new values from the
   "Security Parameters Index (SPI)" registry.  The following entry
   should be appended:

Colitti                  Expires 26 January 2024                [Page 3]
Internet-Draft                  esp-ping                       July 2023

              +========+==================+=================+
              | Number | Description      | Reference       |
              +========+==================+=================+
              | 7      | ESP Echo Request | [THIS DOCUMENT] |
              +--------+------------------+-----------------+
              | 8      | ESP Echo Reply   | [THIS DOCUMENT] |
              +--------+------------------+-----------------+

                                  Table 1

6.  References

6.1.  Normative References

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
              <https://www.rfc-editor.org/info/rfc4555>.

   [RFC6092]  Woodyatt, J., Ed., "Recommended Simple Security
              Capabilities in Customer Premises Equipment (CPE) for
              Providing Residential IPv6 Internet Service", RFC 6092,
              DOI 10.17487/RFC6092, January 2011,
              <https://www.rfc-editor.org/info/rfc6092>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2.  Informative References

Acknowledgements

   Thanks to Tero Kivinen, Steffen Klassert, Andrew McGregor, and Paul
   Wouters for helpful discussion and suggestions.

Author's Address

Colitti                  Expires 26 January 2024                [Page 4]
Internet-Draft                  esp-ping                       July 2023

   Lorenzo Colitti
   Google
   Shibuya 3-21-3,
   Japan
   Email: lorenzo@google.com

Colitti                  Expires 26 January 2024                [Page 5]