Panwei (William) writes:
> 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.
Actually I think the best option is to include the N(COOKIE) in the
Initiators IKE_AUTH too. I.e.:
Initiator Responder
-------------------------------------------------------------------
1. HDR(A,0), SAi1, KEi, Ni -->
2. delayed<-- HDR(A,0), N(COOKIE1)
3. HDR(A,0), SAi1, KEi, Ni -->
4. <-- HDR(A,0), N(COOKIE2)
5. HDR(A,0), N(COOKIE2), SAi1,
KEi, Ni -->
6. delayed received here
7. HDR(A,0), N(COOKIE1), SAi1,
KEi, Ni --> lost
8. <-- HDR(A,B), SAr1, KEr,
Nr, [CERTREQ]
9. HDR(A,B), SK {IDi, [CERT,]
[CERTREQ,] [IDr,] AUTH,
SAi2, TSi, TSr,
N(COOKIE1)} -->
^^^^^^^^^^ Added here.
10. <-- HDR(A,B), SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr}
Now when Responder receives IKE_AUTH at step 9, it will decrypt that
and it can see that Initiator thinks the cookie is COOKIE1, and it can
then reconstruct the packets initiator is using for his calculations.
Of course it needs to assume that initiator did not change order of
payloads or anything else when it swiched from COOKIE2 to COOKIE1,
i.e., that only difference in step 5 and step 7 packets is the cookie
payload contents.
This kind of change would most likely be backward compatible, i.e.,
old responders would simply ignore the extra notify payload in
IKE_AUTH and old initiators would not simply even send it.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
