Hi Antony, On Fri, Jan 12, 2024 at 3:57 PM Antony Antony <[email protected]> wrote: > I'm glad to seee this ID will be updatead soon, before it > expire this month!
Let's see if I can make the deadline.. > > >"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. But the problems are: - the sender doesn't know if the received packet is the response or a request which its peer sent independently. For example, A sends an ESP ping packet to B using existing SPI. It gets back a packet with next header = 59 and assumes it's a response, and drops it. But actually it's not a response, it's peer B trying to initiate ESP ping - and packets from A might never reach B even. If A responds, it might cause an endless loop of pings. - what's inside the payload - or, more importantly, how to parse it after it's decrypted, is defined by the next header. In this case, even if we update RFC4303 with "it might be either a dummy packet, so drop it, or it might be a ping, then it shall be processed" - how would the receiver tell the difference? Whatever format we define, it can't be differentiated from garbage inside a dummy packet. > 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. Then it probably should be an ICMPv6 packet encapsulated into ESP. Is there any reason we can't just use an existing SPI to send ICMPv6 packets? Off-top of my head: - what source/dst addresses to use, - it could be a problem if the peer's configuration doesn't allow pings. > > 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. I've been thinking about it for a while and so far I see the following options: 1. We limit the scope of the draft to SPI 7/7 only. define the specific format (similar to ICMPv6) for SPIs 7 and 8 * (actually we might not need 8 tnen). For those SPIs next header = 59 doesn't mean "a dummy packet with garbage payload". Instead the payload shall be processed as described in the draft. Ignore the existing SPI use case (or we might try do smth based on ICMPv6). The main drawback is that, as it's been pointed out, allows a 3rd party to respond to ESP ping. 2. We try to make it work with real SPIs. Then the next header can not be 59. Options are: 2.1 Explore that ICMP trick 2.2 Define a new destination option - similar to ICMPv6 echo response/echo reply. Pros: -- solves all problems caused by "next header = 59" -- simpler that using ICMPv6 Cons: well, 6man would need to be involved (and this draft adopted first, before we go there). Strictly speaking options 1 and 2 are not mutually exclusive. We can start with 1 (and maybe 2.2). Does it make sense? -- Cheers, Jen Linkova _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
