]> Google

Shibuya 3-21-3 Japan lorenzo@google.com

Internet IP Security Maintenance and Extensions ipsec esp ipv6 This document defines an ESP echo function which can be used to detect whether a given network path supports IPv6 ESP packets.

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 when, and only when, they appear in all capitals, as shown here.

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 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 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 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.

Protocol Specification An IPsec peer, prior to an IKE negotiation, intending to ascertain the path's capability to support ESP packets to a specific destination, MAY send an ESP Echo Request packet to such destination. The ESP Echo Request packets are distinguished as ESP packets with an SPI value set to [ESP-ECHO-REQUEST], a Next Header value of 59 (No Next Header), and devoid of any payload. Should the destination support ESP and intend to communicate this capability to the potential IPsec peer, it SHOULD respond with an ESP Echo Reply packet. These ESP Echo Reply packets are characterized as ESP packets with an SPI value set to [ESP-ECHO-REPLY], a Next Header value of 59, and are devoid of any payload. Upon completing an IKE negotiation, an IPsec peer wishing to ascertain the viability of the path for ESP packets MAY initiate an ESP Echo Request packet to the other peer. The ESP Echo Request packet MAY be encrypted. If encrypted, it SHOULD utilize an SPI value previously negotiated through IKE and set the Next Header value to 59 (No Next Header). The receiving IPsec peer, having established ESP through IKE, MAY issue an ESP Echo Response. When replying to an encrypted ESP Echo Request, the ESP Echo Response MUST be encrypted and utilize the corresponding negotiated SPI.

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 .
• 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.

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

Number	Description	Reference
7	ESP Echo Request	[THIS DOCUMENT]
8	ESP Echo Reply	[THIS DOCUMENT]

References Normative References Informative References

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