On Fri, Jul 28, 2023 at 01:01:39PM -0700, Lorenzo Colitti wrote: > On Fri, Jul 28, 2023 at 11:36 AM Tero Kivinen <kivi...@iki.fi> wrote: > > > Sequence number is just 32-bit sequence number (always present, can > > be used when correlating request to response). > > > > Antony yesterday suggested to me that some stateful firewalls/middleboxes > might be happier if these numbers started from 1 and counted upwards. I'm > not sure if this is possible though - the first time you run the esping (or > espping?) binary it can send packets 1, 2, 3, ...42, but the second time > you run it, how will it know that it needs to start with 42? > > By comparison, ping uses both an ID and a sequence number, and the sequence > number is scoped to a particular ID. We could do something like this by > deciding that the first 16 bits of the ESP sequence number are the ID and > the bottom 16 bits are the sequence number. > > Payload data/padding is can be any length in reqeust and is always > > copied in response, i.e., it can be used as nonce/cookie to make sure > > nobody out side the path can fake responses. > > > > There would not be padding or next header fields, and the ICV field > > would be zero length. > > > > SGTM. Hopefully middleboxes won't be too unfriendly to this. Generally I > would assume that when a middlebox looks at ESP packets, other than the > sequence number, it's not going to look into the payload because it will > assume it's encrypted. > > If we want to implement Antony's suggestion of doing this ping on real ESP > sessions as well, then that would require the ping packet to be valid ESP, > i.e., properly encrypted, with valid padding and next header fields. In > that case, maybe we can use Next Header 59 per RFC 4303 section 2.6?
Here is a proposed text for the I-D. "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." Feel free to adopt the text as you see fit. I have also attached it as xml for your convenience. -antony
draft-colitti-ipsecme-esp-ping-00.xml
Description: XML document
IP Security Maintenance and Extensions L. Colitti
Internet-Draft Google
Intended status: Standards Track 6 September 2023
Expires: 9 March 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 9 March 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 9 March 2024 [Page 1]
Internet-Draft esp-ping September 2023
Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2
3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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 9 March 2024 [Page 2]
Internet-Draft esp-ping September 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 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.
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].
Colitti Expires 9 March 2024 [Page 3]
Internet-Draft esp-ping September 2023
* 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:
+========+==================+=================+
| 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>.
Colitti Expires 9 March 2024 [Page 4]
Internet-Draft esp-ping September 2023
6.2. Informative References
Acknowledgements
Thanks to Tero Kivinen, Steffen Klassert, Andrew McGregor, and Paul
Wouters for helpful discussion and suggestions.
Author's Address
Lorenzo Colitti
Google
Shibuya 3-21-3,
Japan
Email: lore...@google.com
Colitti Expires 9 March 2024 [Page 5]
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
