Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

Thanks for your and Michael’s clarifications. I’m much clearer now and I’m convinced this is an useful draft.
I think it would be useful to add one or two sentences in the introduction. An example is given below.

   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.
  For example, the on-path firewall may allow UDP packets but discard ESP packets, and IKE negotiation isn’t able to detect this. When NAT function is not used as well, which is common in IPv6 networks, the IPsec session will by default use unencapsulated IPv6 ESP.
   This leads to the IPsec session not being able to exchange any
   packets even though IKE negotiation succeeded.

Regards & Thanks！
Wei PAN (潘伟)

From: Lorenzo Colitti <lorenzo@google.com>
Sent: Wednesday, March 27, 2024 12:07 PM
To: Panwei (William) <william.panwei@huawei.com>
Cc: Jen Linkova <furry13@gmail.com>; ipsec@ietf.org WG <ipsec@ietf.org>; Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

Yes, the idea is to make it possible to leverage native ESP. Pretty much all IPv6 networks (at least commercial networks) don't do NAT. But some of them drop ESP packets. On these networks, NAT detection will say there is no NAT, and the ESP session will be established, but no traffic will flow.

On Tue, Mar 26, 2024 at 6:24 PM Panwei (William) <william.panwei@huawei.com<mailto:william.panwei@huawei.com>> wrote:
Hi,

I've read the draft and I think I can understand the solution part. But please allow me to ask a stupid question about the motivation or use case, because I'm a little confused about that.

I feel that the problem of IPv6 ESP traverse failure, as described in the draft and presentation slides, is because of NAT. IKEv2 already supports the detection of NAT. After the detection of NAT, the peers can use IP + UDP (4500) + ESP to traverse the NAT. Are there some use cases that this existing solution doesn't work and this draft tries to solve? Or, are there some use cases that IKEv2 fails in detecting the existence of NAT?
I can understand the advantages of native ESP described in the draft: 1) no keepalives or fewer keepalives, 2) no overhead of UDP header. Does this draft target the use cases where IP + UDP + ESP and IP + ESP can both work in the existence of NAT, and try to benefit from the native ESP?

Regards & Thanks！
Wei PAN (潘伟)

    > -----Original Message-----
    > From: IPsec <ipsec-bounces@ietf.org<mailto:ipsec-bounces@ietf.org>> On Behalf Of Jen Linkova
    > Sent: Thursday, February 29, 2024 11:28 PM
    > To: ipsec@ietf.org<mailto:ipsec@ietf.org>
    > Cc: Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>; Michael Richardson
    > <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>>
    > Subject: [IPsec] Fwd: New Version Notification for
    > draft-colitti-ipsecme-esp-ping-01.txt
    >
    > -01 version shall address comments received since -00.
    > The main change is that payload format is defined similarly to ICMPv6
    > echo, and the draft now updates RFC4303, so ESP packets with SPI == 7
    > or 8 and next header==59 are not considered to be dummy packets.
    >
    > Comments are appreciated!
    >
    >
    > ---------- Forwarded message ---------
    > From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
    > Date: Fri, Mar 1, 2024 at 2:24 AM
    > Subject: New Version Notification for
    > draft-colitti-ipsecme-esp-ping-01.txt
    > To: Jen Linkova <furry13@gmail.com<mailto:furry13@gmail.com>>, Lorenzo Colitti
    > <lorenzo@google.com<mailto:lorenzo@google.com>>, Michael Richardson
    > <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>>
    >
    >
    > A new version of Internet-Draft draft-colitti-ipsecme-esp-ping-01.txt
    > has been successfully submitted by Jen Linkova and posted to the IETF
    > repository.
    >
    > Name:     draft-colitti-ipsecme-esp-ping
    > Revision: 01
    > Title:    ESP Echo Protocol
    > Date:     2024-02-29
    > Group:    Individual Submission
    > Pages:    7
    > URL:
    > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.txt
    > Status:
    > https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/
    > HTML:
    > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.html
    > HTMLized:
    > https://datatracker.ietf.org/doc/html/draft-colitti-ipsecme-esp-ping
    > Diff:
    > https://author-tools.ietf.org/iddiff?url2=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.
    >
    >
    >
    > The IETF Secretariat
    >
    >
    >
    >
    > --
    > Cheers, Jen Linkova
    >
    > _______________________________________________
    > IPsec mailing list
    > IPsec@ietf.org<mailto:IPsec@ietf.org>
    > https://www.ietf.org/mailman/listinfo/ipsec