On Wed, Jan 10, 2024 at 05:07:55PM +0100, Jen Linkova wrote: > 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..
Thanks, Jen. I'm glad to seee this ID will be updatead soon, before it expire this month! > 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? For a basic use case, any response would suffice. The essential requirement is the ability to send a request and receive a response from the IPsec peer, which is why I proposed the minimal solution to begin with. However, following several discussions and [1] , there's interest in developing a more generic approach. I am hopping the Internet Draft would define a more detailed payload, similar to how ICMP defines packet payload in RFC 792. > In the original proposal it was clear, as the reserved SPI values were > used. > Am I missing anything? For a minimal use case it may work; however, for more generic use cases, such as sending multiple requests simultaneously from multiple applications, would it work? How would ESP Ping responses correlate to multiple instances sending ESP Ping from a sender? I feel the document might need to define a specific payload format. This format would help us correlate responses with their respective requests, the ESP ping ID and sequnce number proposed in [1] Proposal to add ID , seq. https://mailarchive.ietf.org/arch/search/?q=%22draft-colitti-ipsecme-esp-ping%22 Also the SAs are unidiectional and posisbly there would be multiple SAs same direction too. I just saw a response from Michael brinigin up similar point . Let's start with defining a simple message format to gain hands-on experience of ESP Ping. Based on our learnings, we can then detail out the ESP echo message. This approach aligns with our discussions at the last IPsec workshop on generic ESP socket, and ping message implementation for Linux. I noticed the initial draft created a lot of interest and I feel There is clear interest in pinging specific SAs usin encrypted ESP ping. However, I/we currently lack the practical experience to fully define IPsec ping message format. I am hopping we can comeup with minimal spec. regards, -antony _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
