Subject: [IPsec] Issue (resumption): Replays in 1-rtt protocol

From: <[email-masked]>
Date: Tue, 17 Mar 2009 11:12:12 +0100

<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