I am afraid that only multi-paths cannot enhance the security. As Tero commented, if one can decrypt one path, then it is a successful security breach already. I think the point is that what is the definition of "insecure network", and the definition of the "security" here.
From a cryptographic point of view, it may be helpful to enhance the protocol in this way. Such as, encode the original flow into pieces, with an All-or-Nothing-Transform (AONT), which does NOT require a secret key and has a property that it is hard to invert unless all of the output is known. (OAEP is an example, in the random oracle model) Then, encapsulate the encoded flow into multi-path IPsec tunnels as proposed. This time, the security will be definitely enhanced since the attacker will not get anything unless it breaks confidentiality of all sub-tunnels. ________________________________________ 发件人: [email protected] [[email protected]] 代表 Tero Kivinen [[email protected]] 发送时间: 2012年11月4日 10:57 到: [email protected]; Tina TSOU; Will Liu (Shucheng); [email protected] 主题: [IPsec] Comments to the draft-zhang-ipsecme-multi-path-ipsec-02 In section 4 this draft claims: ---------------------------------------------------------------------- The method enhances the security service by spreading the traffic onto multiple paths. ---------------------------------------------------------------------- I do not think the multiple paths really enhances the security. Also as the sequence number in sending and receive window handling is different (it is shared with all sub-SAs) this feature must be negotiated between the peers. The claim: ---------------------------------------------------------------------- For example, it makes it harder for the attacker to intercept all the packets if different routes are used. ---------------------------------------------------------------------- If attacker can intercept and decrypt one path, that is quite often already big enough problem that security is completely lost. Also ---------------------------------------------------------------------- Even with the same route used, it is harder for the attacker to know which set of SAs are clustered SA, thus harder to decrypt the intercepted packets. ---------------------------------------------------------------------- This kind of things are usually very easy to see from traffic analysis. Especially if the packets are round robined over the all sub-SAs. Also as the SPI and sequence numbers are in clear, and as sequence number counter is shared between all sub-SAs it is trivial to see which packets belong to the same clustered SA set. Also using different keys to encrypt the different sub-SAs will not add that much to the security. If the underlaying crypto algorithm has 2^128 bits of security, splitting the data over for example 4 sub-SAs will simply add 2 more bits of security. On the other hand it is usually much better for attacker to attack the IKEv2 negotiation itself (the Diffie-Hellman etc), as those most likely have less security than the symmetric crypto used to protect the data, and if that can be broken then that will also reveal all sub-SA keys. In section 6 there is text saying: ---------------------------------------------------------------------- SA cluster provides the option to perform the different cryptographic transformation on the different packet. ---------------------------------------------------------------------- which actually lowers the security. If one sub-SA uses DES and another uses 3DES, the overall security is lowered to the level of DES... Even if both algorithms are supposed to have same strength (AES, CAMELLIA etc) that does not mean that they in practice have exactly same security. In this case attacker will attack the weaker algorithm and again gains benefits over than if same stronger algorithm was used on all of the data. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
