Well, I just glanced through the original draft, and I'm a bit confused about the objectives.
Essentially, it's a way to ask "is there someone at IP address x.x.x.x that supports IPsec and is reachable" Normally, we want to know more than that - if we think we have an IPsec SA with x.x.x.x, we would like to know if they also have that same SA (for example, they didn't just reboot and lost all their state). As such, having the echo request/response go through the SA makes more sense, which appears to be the reason beyond Jen's comments. On the other hand, IPsec (4303) already gives semantics to next header = 59, that is, that the receiver MUST discard it silently. It might be usable as a 'ECHO RESPONSE' packet, but certainly not as an 'ECHO REQUEST' > -----Original Message----- > From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Jen Linkova > Sent: Wednesday, January 10, 2024 11:08 AM > To: ipsec@ietf.org; ant...@phenome.org > Cc: Lorenzo Colitti <lore...@google.com>; Michael Richardson > <mcr+i...@sandelman.ca> > Subject: Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme- > esp-ping-00.txt > > Hello, > > Jen here, a new co-author of this undoubtedly useful draft. > I'm working on addressing comments received after -00 was submitted, and I > have a question.. > > Antony Antony wrote: > > >> 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." > > As I'm not really an IPSec expert, I'm not sure I understand how it would > work. > Let's say a device A sends an ESP echo request packet using an existing > negotiated SPI. > Then it receives an ESP packet back, and that packet uses the negotiated SPI > and has the next header set to no next header. > How would that device A differentiate between: > - an Echo Reply sent in response to its Echo request; > - an Echo Request sent by the peer independently; > - just some garbage (or shall the device assume that any packet with next > header = 59 is a valid ESP ping packet? > > In the original proposal it was clear, as the reserved SPI values were used. > Am I missing anything? > -- > Cheers, Jen Linkova > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
