Hi Michael, On Mon, Jul 08, 2024 at 12:31:57PM -0400, Michael Richardson wrote: > > Antony Antony <ant...@phenome.org> wrote: > >> Antony Antony <antony.ant...@secunet.com> wrote: > >> > We are proposing Encrypted ESP Ping, which will compliment/co-exist > >> > with draft-colitti-ipsecme-esp-ping. We welcome feedback on this > >> > proposal. Both authors will be present at the upcoming Vancouver > IETF and > >> > would love to chat about this ID and our implementation plans. Also, > we are > >> > planning a short presentation at IPsecME session there. > >> > >> This proposal allows the initiator to specify the SPI# in which the > response > >> will appear. I see the utility of this, particularily for multi-SA > >> configurations. I'm not yet convinced this is safe, but I'm thinking > about > >> it. > > > Thanks for your feedback. > > > I am curious about your concerns. Could you share more details? > > > One concern I imagine is responding to a different peer would cause a > DoS? > > We specified more validations on the responder to address this problem. > > Assume a bunch of remote access (laptops) connected to a gateway machine.
I have been thinking about this and we had a few discussions in the hallway here @IETF 120. I notice three cases 1. Single SA Pair: There is only one pair of Security Associations (SAs). Think of simple Laptop use case. 2. Multiple SA pair Between Same Peer Endpoints: for DSCP, for per-CPU distribution. 3. Multiple SAs between different Peer Endpoints: SAs over both WiFi and LTE. A simple case would same identies, however, a more generic one would be multiple identies, aka, IDi and IDr in IKEv2. > a) can peer A send traffic to another peer? In the first case, it is easy to detect and avoid responding to another peer. The inbound and outbound SAs would simply be reverse and would even match the policy on the SA. Also upcoming, IP-TFS implementation experience of paired SA in Linux XFRM would give us more ideas. In the second case, it would be more challenging but not impossible to avoid responding to another peer, all SA are between same peers. I am hopeful that we can support it in ESP stack, say Linux XFRM. I will report back on the progress. The third case is need more care, and I am still researching how to implement it. In the worst case, speaking in Linux terms, the xfrm subsystem would pass the request to IKE daemon to decide and respond to another peer endpoint. Especially when a request arrive over LTE with return path SA, SPI, is over WiFi. Any other ideas how to implement this in IPsec kernel stack? > b) can peer A use this to find out what SPI# are in use? I don't see how. Responder does not add any SPI in the response, only Encrypted ESP Ping initiator request return path SPI. > c) can peer A find out where peer B is? I don't see how. Would you like to share more about b and c? > I think that we want to prevent all of these things, and I don't think it's > impossible to code. I think that we have to think about the error conditions > carefully though. Let's figure out how to implement it, prefferably in in stack withoug ESP Ping Daemon. -antony _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
