|Main Archive Page > Month Archives > ipsec archives|
Like I explained earlier, sharing the address-less QCD token is problematic in multiple practical network designs:
- Stateless failover pairs (e.g. VRRP, HSRP, ..)
- Load Balanced clusters
- Anycast server clusters
In general, QCD address-less token generation is dangerous in all the scenarios where the server owning the state can be bypassed by the attacker and any other server in the cluster, not owning state, can be targeted to receive the "invalid" IKE or ESP packet.
In the current proposal, I agree that the issues raised by address-less token should be more explicit and general. This token method should be explicitly forbidden when either
- the accessibility to other servers of the clusters can not be restricted
- or insufficient state is shared across the cluster to avoid sending unwanted INVALID_SPI
This statement is more accurate and less restrictive than having to share the IKE SA DB.
On 21 Oct 2010, at 11:59, Tero Kivinen wrote:
>> An eavesdropper could see an IKE request (e.g. CREATE_CHILD_SA request)
>> and forge an informational message back to the requester containing N
>> (INVALID_IKE_SPI) and N(QCD_TOKEN). If he guesses QCD_TOKEN correctly he
>> can disrupt the IKE_SA and force a negotiation. So in theory this makes
>> IKE more prone to a passive MITM, but that's theory. Given significant
>> randomness in the token the attack is not feasible. If there's a flaw in
>> the RFC that makes tokens easy to guess this would be a valid attack.
>> True, if we do not mandate the algorithm somebody can implement a token
>> generation scheme that is easy to guess.
> There has been talks here in the list about cases where we have loose
> cluster which do not share same IKE SA state, but which do share QCD
> token generation secrets. Such clusters would be vulnerable to this
> kind of attacks regardless whether the token generation contains token
> takers IP number or not.
> The attack simply needs to fake one IKE SA message so that its source
> IP is the real source ip of the host attacker wants to attack, send it
> to the cluster member which do not have the IKE SA state for that IKE
> SA, and then see the QCD reply sent by the cluster member. This reply
> now contains the QCD token which can then be used to attack the host.
> Actually normally when that packet reaches its final destination the
> host will tear down its IKE SA anyways.
> So attacker just need to know the IKE SA SPI pair and the IP addresses
> of the valid IKE SA on one cluster member and then send any faked IKE
> message to another cluster member sharing same QCD token generation
> secret, but separate IKE SA database.
> The section 10.4 seems to assume that attacker cannot force the load
> balancer to send the faked packet to any other cluster member than the
> one mapped by the source IP-address of the packet. As the algorithm
> how the load balancer really selects the peer where it sends the
> packet is not necessarely known by the IPsec implementations, I do not
> think we can trust we can include all same information to the token
> For example it could use source port numbers, or destination
> IP-address, etc so I think it is quite unsafe to assume anything what
> the load balancer might do.
> I think it would be safer to forbid situations where the cluster
> members share the same QCD token unless they also share the IKE SA
> IPsec mailing list
IPsec mailing list