<not wearing any hats> Section 7.8 currently says that "In any case, a ticket replayed by an adversary only causes partial IKE state to be created on the gateway."
Such partial IKE state is not really a big problem, since the only harm it causes is using a small amount of memory. The memory will be eventually freed, and as described in Section 4.3.2, if the gateway notices it's short on memory, it can do the COOKIE thing. What the draft does not yet describe is that IKE_SESSION_RESUME request replays can have other bad consequences in many circumstances. The VPN gateway often interacts with other components, and they cause problems that would not be solved by having infinite amount of RAM: - If the VPN gateway gets the IP addresses from a DHCP server, replays could consume addresses from the DHCP server pool, and use DHCP server processing resources (in addition to VPN gateway RAM). - If the VPN gateway acts as a Proxy MIP "Local Mobility Anchor", replay would cause a PBU message to be sent, which would consume resources at the MAG, and worse, break connectivity for the real client. - If a client can use the same IP address with different cluster members, replay would impact whatever mechanism the gateways use to keep track of which IP is where (e.g. injecting a host route via IGP, or claiming it via ARP/ND), causing load for the infrastructure and possibly breaking connectivity for the real client. - Many VPN gateways interact with AAA (RADIUS/Diameter) in some way. Replay could cause e.g. Accounting-Start message, authorization-only exchange, QoS related AAA stuff (e.g. draft-ietf-dime-diameter-qos), and so on. These would consume resources at the AAA infrastructure, and lead to incorrect data at AAA servers. - If the VPN gateway updates DNS records dynamically on behalf of the client, replay would consume DNS server resources, and possibly lead to incorrect data in the DNS. In some cases, like the DHCP server, it's relatively easy to "roll back" the incorrect state: when the VPN gateway deletes the partial IKE_SA state, it would also release DHCP lease. And in some cases, it might be possible to modify how the boxes interact so that attack becomes ineffective (e.g. don't send Accounting-Start immediately when the IKE_SA/IPsec SAs are created, but only when we've received some traffic proving that they're live). At any rate, the draft needs to describe this: it's not just a local optimization between the VPN client and gateway (saving network traffic and time), but can change how the VPN gateway fits in a larger architecture -- and the 2-roundtrip-version (Cookie exchange in Section 4.2.3) might be needed for many other reasons than VPN gateway having limited RAM. Best regards, Pasi _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
