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
