Internet DRAFT - draft-colitti-ipsecme-esp-ping
draft-colitti-ipsecme-esp-ping
IPSECME Working Group L. Colitti
Internet-Draft J. Linkova
Updates: 4303 (if approved) Google
Intended status: Standards Track M. Richardson
Expires: 1 September 2024 Sandelman Software Works
29 February 2024
ESP Echo Protocol
draft-colitti-ipsecme-esp-ping-01
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 1 September 2024.
Copyright Notice
Copyright (c) 2024 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, et al. Expires 1 September 2024 [Page 1]
Internet-Draft ESP-PING February 2024
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
4. Discovering ESP Echo Support . . . . . . . . . . . . . . . . 4
5. Updates to RFC4303 . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Problem Statement
IPsec sessions between nodes 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.
Colitti, et al. Expires 1 September 2024 [Page 2]
Internet-Draft ESP-PING February 2024
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 [RFC4555] to a
network that does not 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.
2. Terminology
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.
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 (7-TBD), 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 (8-TBD), a
Next Header value of 59, and no payload.
The ESP Echo Request and Reply packets utilize the standard ESP
packet format as described in Section 2 of [RFC4303] with the
following changes:
* SPI set to
- [ESP-ECHO-REQUEST] for ESP Echo Request
- [ESP-ECHO-REPLY] for ESP Echo Reply
* The Next Header field of the ESP header SHOULD be set to 59 (No
Next Header).
* No Integrity Check Value-ICV.
The payload has the following format:
Colitti, et al. Expires 1 September 2024 [Page 3]
Internet-Draft ESP-PING February 2024
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECHO Identifier | ECHO Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... |
+-+-+-+-+-
* ECHO Identifier: An identifier to aid in matching Echo Replies to Echo Requests. MAY be zero.
Implementations that support multiple simultaneous Echo Request sessions MUST ensure that
different sessions have different identifiers. Implementations that are not aware of other
implementations that might be running on the same node at the same time SHOULD randomize the
identifier to prevent collisions, and MUST be prepared to receive responses to packets that
were sent by another implementation.
* ECHO Sequence Number: An identifier to aid in matching Echo Replies to Echo Requests. MAY be zero.
* Data: Zero or more octets of arbitrary data.
Figure 1: ESP Echo Request and Reply Payload Overview
An IPsec peer, prior to an IKE negotiation or after completing an
IPsec negotiation, intending to ascertain the path's capability to
support ESP packets to a specific destination, MAY send one or more
ESP Echo Request packet(s) to the destination. 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.
The sender MAY send ESP Echo packets with zero data. When responding
to an ESP Echo packet, the node MUST copy the data from the ESP Echo
packet to the ESP Echo Reply packet, up to the limit of the MTU of
the path back to the sender.
4. Discovering ESP Echo Support
If no response is received to an ESP Echo Request packet, it can be
caused by one of the following:
* the peer doesn't support ESP Echo protocol.
* there is no end-to-end ESP connectivity.
Without some prior knowledge about ESP Echo support by the remote
side, the sender can not distibguish those two scenarios. Therefore
the sender SHOULD NOT treat lack of response as an indicator of end-
to-end connectivity issues until an explicit confirmation of ESP Echo
Colitti, et al. Expires 1 September 2024 [Page 4]
Internet-Draft ESP-PING February 2024
support by the peer is received. The sender MAY use any means of
obtaining the information about ESP Echo support, such as an explicit
out-of-band configuration (for example, a VPN client might be
configured to always use ESP Echo when communicating to the given VPN
server).
5. Updates to RFC4303
Section 2.6 of [RFC4303] discusses "dummy" ESP packets, which are
distinguishable by the Next Header value set to 59. As per [RFC4303]
a receiver MUST be prepared to silently discard "dummy" packets.
This document updates Section 2.6 of [RFC4303] to allow packets with
the Next Header value of 59 to be processed, if SPI is set to [ESP-
ECHO-REQUEST] or [ESP-ECHO-REPLY].
OLD TEXT:
A transmitter MUST be capable of generating dummy packets marked with
this value in the next protocol field, and a receiver MUST be
prepared to discard such packets, without indicating an error.
NEW TEXT:
A transmitter MUST be capable of generating dummy packets marked with
this value in the next protocol field, and a receiver MUST be
prepared to discard such packets, without indicating an error. A
transmitter MUST NOT use the reserved SPI values [ESP-ECHO-REQUEST]
or [ESP-ECHO-REPLY] for dummy packets. A receiver SHOULD NOT discard
packets with the Next Header value set of 59, if those packets use
the reserved SPI values. Packets with the reserved SPI values [ESP-
ECHO-REQUEST] or [ESP-ECHO-REPLY] and the Next Header value set of 59
SHOULD be processed by the receiver as described in draft-colitti-
ipsecme-esp-ping.
6. Security Considerations
To prevent a downgrade attack, the IPSec-capable node MUST NOT fall
back to unencrypted mode of communication in case of ESP Echo
failure. The node MAY switch to another path (e.g. via another
interface) or another protocol (e.g. IPv4).
The security considerations are similar to other unconnected request-
reply protocols such as ICMPv6 echo. In particular:
Colitti, et al. Expires 1 September 2024 [Page 5]
Internet-Draft ESP-PING February 2024
* 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.
7. 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 | ESP Echo Request | THIS DOCUMENT |
+--------------------+------------------+---------------+
| 8-ESP-ECHO-REPLY | ESP Echo Reply | THIS DOCUMENT |
+--------------------+------------------+---------------+
Table 1
8. Acknowledgements
Thanks to Tero Kivinen, Steffen Klassert, Andrew McGregor, and Paul
Wouters for helpful discussion and suggestions.
9. Changelog
10. References
10.1. Normative References
[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>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
Colitti, et al. Expires 1 September 2024 [Page 6]
Internet-Draft ESP-PING February 2024
[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>.
10.2. Informative 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>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>.
Authors' Addresses
Lorenzo Colitti
Google
Email: lorenzo@google.com
Jen Linkova
Google
Email: furry13@gmail.com
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
Colitti, et al. Expires 1 September 2024 [Page 7]
