Hi William, > Hi Valery, > > It seems like a rare scene but I think it needs to be considered. > Compared with ignoring cookie payload, how about adding N(COOKIE2) in the 9th > message? Then when > Initiator received the 12th message, it'll know which cookie this message > matches with.
The problem with this approach is that the responder doesn't know whether initiator is a legacy implementation or an updated one. The legacy implementation may treat any IKE_SA_INIT response containing COOKIE as a request to re-send a request with this COOKIE, even it contains other payloads. So, if the responder includes N(COOKIE) in every IKE_SA_INIT response it will cause infinite loop of resending request if initiator is legacy implementation. Regards, Valery. > Regards & Thanks! > Wei Pan > > > -----Original Message----- > > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov > > Sent: Tuesday, September 22, 2020 10:47 PM > > To: IPsecME WG <ipsec@ietf.org> > > Subject: [IPsec] Cookie logic results in failed authentication > > > > Hi, > > > > while performing stress tests, we ran into the problem, that is concerned > > with the way cookies are handled in RFC7296. > > The problem is that if network conditions are bad (high probability for > > packets to be delayed, reordered or lost), then some SAs are not established > > with AUTHENTICATION_FAILED error. Consider the following scenario: > > > > Initiator > > Responder > > 1. HDR, SAi, KEi, Ni --> > > 2. --> HDR, > > SAi, KEi, Ni > > (server > > has a large number of > > half-open SAs, so it responds with cookie, > > that is > > generated using cookie > > secret K1) > > 2. (message is delayed in the network) ... <-- HDR, N(COOKIE1) > > 3. (client retransmits its original message) > > HDR, SAi, KEi, Ni --> > > 4. --> HDR, > > SAi, KEi, Ni > > (server > > has a large number > > half-open SAs, so it responds with cookie, > > but the > > cookie generation secret > > has been already changed, and becomes K2, > > that > > results in generating a new > > cookie for the same request, COOKIE2) > > 5. <-- HDR, > > N(COOKIE2) > > 6. HDR, N(COOKIE2) <-- > > 7. (client receives message and retransmits its request with COOKIE2) > > HDR, N(COOKIE2), SAi, KEi, Ni --> > > 8. --> HDR, > > N(COOKIE2), SAi, KEi, Ni > > (server > > verifies COOKIE2, it's OK, > > since K2 is still the current secret) > > 9. (message is delayed in the network) ... <-- HDR, SAr, KEr, > > Nr > > 10. HDR, N(COOKIE1) <-- > > 11. (eventually the delayed first message from the server with COOKIE1 > > reaches the client. Since the client doesn't know that COOKIE1 is stall, it > > decides that it's fresher than COOKIE2, because it receives this message > > later, > > so the client replaces cookie and resends its initial request with COOKIE1) > > HDR, N(COOKIE1), SAi, KEi, Ni --> (this message get lost) > > 12. HDR, SAr, KEr, Nr <-- > > (eventually delayed server's response reaches the client. At this point the > > client thinks that IKE_SA_INIT is completed and starts > > IKE_AUTH) > > > > What is interesting in the above diagram: both the client and the server > > have > > eventually completed IKE_SA_INIT, but they have different opinions on what > > IKE_SA_INIT message from initiator to responder contains. > > The client thinks that the server has responded to its most recently sent > > message HDR, N(COOKIE1), SAi, KEi, Ni, while the server has never received > > it and in fact has responded to HDR, N(COOKIE2), SAi, KEi, Ni. > > As a result - while calculating AUTH payload they will have different > > inputs to > > it and authentication will fail. > > > > Despite this diagram looking artificial, we did observe a noticeable number > > of these errors during real stress tests (up to 5% of SAs failed with this > > error > > in bad network conditions). > > > > What's particularly unfortunate with this: > > 1. The bad network conditions may happen as a result of DDoS attack, which > > also may cause cookie logic to be triggered on the server. > > So, the two pre-conditions - bad network and server under attack are > > coupled. > > 2. The most disappointing thing for me is that despite bad network > > conditions, peers did manage to complete initial IKE exchanges, > > only to get "authentication failed" result. > > 3. For customers this looks surprising - they have valid credentials, but > > from > > time to time they receive "authentication failed" > > diagnostics without any clue why this happens. > > > > The root of the problem is that IKE_SA_INIT request may be retransmitted > > with different content (different cookies) and the peers have no means to be > > sure that they have send/receive identical messages. And later these > > possibly > > different messages are used in AUTH payload calculation. > > > > I believe that the proper solution would be to exclude cookie from the AUTH > > payload calculation. > > It is verified by the responder using cookie generation secret and it is not > > concerned with a client (the client did not generate it, just echoes it > > back). > > However, this solution is obviously incompatible with RFC7296, so this is > > not > > an option. > > > > Any opinions? Should this problem be addressed by the WG or ignored? > > > > Regards, > > Valery. > > > > > > _______________________________________________ > > 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
