-------------------- Tuomas Aura (2005-10-07): https://www.machshav.com/pipermail/mobike/2005-October/001102.html Comment 4: IPsec SAs are identified by the pair. Normally, these identifiers are unique for inbound SAs destination host is responsible for allocating the SPIs and for outbound SAs because the destination address identifies a unique host. In Mobike, the latter is no longer true. That is, identifier collisions may occur for outbound SAs at the responder. Consider the following example of an accidental collision: I1 and I2 are honest initiators that both have an SA with the same honest responder R. The outbound SAs from R happen, by change, to have the same SPI. (This is ok because the destination IP addresses differ.) I1 is first located at the address A1 and I2 is located at the address A2. Thus, tunnel-mode ESP packets from R to I1 have A1 as the outer destination address and I1 as the inner destination address; tunnel-mode ESP packets from R to I2 have A2 as the outer destination address and I2 as the inner destination address. Now, I2 becomes disconnected from the network and I1 moves to its old address A2. I1 sends the UPDATE_IP_ADDRESS notification to R. R updates the outbound SA to point to A2. It now has two outbound SAs with the same identifier . Can Mobike implementations cope with this? (Consider also a situation where both SAs were created from the same SPD entry with the destination addresses populated from packets.) One policy for dealing with accidental collisions of is to evict either the unchanged or the changed SA from SAD. Unfortunately, both policies enable a DoS attacks. If the unchanged SA is evicted, an attacker that sees a packet from R to I1 and learns the SPI can intentionally create another SA with the same SPI and then cause the collision. If the changed SA is evicted, the attacker can squat the pair if it knows the address to which the initiator will next move. In both cases, the result is the loss of the target SA. Both attacks require the attacker to be either at the initiator's local link or on the route between the initiator and the responder. While these attacks do not appear very serious, it is better to manage outbound SAs at the responder in such a way that collisions can be tolerated. Some implementations probably work like this already. -------------------- Tero Kivinen (2005-10-10): https://www.machshav.com/pipermail/mobike/2005-October/001110.html >Comment 4: > >IPsec SAs are identified by the pair. >Normally, these identifiers are unique for inbound SAs destination >host is responsible for allocating the SPIs and for outbound SAs >because the destination address identifies a unique host. In >Mobike, the latter is no longer true. That is, identifier >collisions may occur for outbound SAs at the responder. ESPv3 the IPsec SA is identified by the SPI alone for the unicast SAs. There is no destination IP address threre anymore. Implementations are allowed to use SPI and IPsec protocol type also. (draft-ietf-ipsec-esp-v3-10.txt section 2.1). >Consider the following example of an accidental collision: I1 and >I2 are honest initiators that both have an SA with the same honest >responder R. The outbound SAs from R happen, by change, to have the >same SPI. (This is ok because the destination IP addresses differ.) This is not ok with the mobike, as it requires IKEv2, which requires RFC2401bis, which requires ESPv3... -------------------- Mohan Parthasarathy (2005-10-10): https://www.machshav.com/pipermail/mobike/2005-October/001111.html > ESPv3 the IPsec SA is identified by the SPI alone for the unicast SAs. > There is no destination IP address threre anymore. Implementations are > allowed to use SPI and IPsec protocol type also. > (draft-ietf-ipsec-esp-v3-10.txt section 2.1). > Yes, but that concerns inbound processing. Here we are talking about outbound processing i thought. > This is not ok with the mobike, as it requires IKEv2, which requires > RFC2401bis, which requires ESPv3... Are you saying that this problem cannot happen ? The I1 and I2 are two different hosts and they *can* choose the same SPI. When R is sending packets to I1 or I2, it does not use the SPI for lookup. It uses the selectors from the packet to lookup the SA. The selectors are unique (they are still I1 plus whatever the policy requires) even after I1 moves to A2. But this leads to two SAs with the same SPI. This should not cause any problem (in theory) because you never lookup this SA directly. You always lookup the SPD which points to the SA. But there are implementations (e.g. Linux) where this can cause problems if you update an SA that will result in the same values (dest address, SPI, protocol) as another SA. So, can you clarify ? -------------------- Tero Kivinen (2005-10-10): https://www.machshav.com/pipermail/mobike/2005-October/001112.html > Yes, but that concerns inbound processing. Here we are talking about > outbound processing i thought. Ups, I seem to have read the question too quickly. > Are you saying that this problem cannot happen ? The I1 and I2 are > two different hosts and they *can* choose the same SPI. When R is > sending packets to I1 or I2, it does not use the SPI for lookup. It > uses the selectors from the packet to lookup the SA. The selectors > are unique (they are still I1 plus whatever the policy requires) > even after I1 moves to A2. But this leads to two SAs with the same > SPI. Same outbond SPI, so that is not a problem. > This should not cause any problem (in theory) because you never > lookup this SA directly. You always lookup the SPD which points to > the SA. But there are implementations (e.g. Linux) where this can > cause problems if you update an SA that will result in the same > values (dest address, SPI, protocol) as another SA. So, can you > clarify ? When you are sending packets outbound you do lookup from SPD-S based on the selectors (I1 or I2) and you get SA based on that. Then in the SA there is the SPI and destination IP to be used for the other end. Then you simply make tunnel encapsulation and send the packet along. I do not really see what is the problem there? So we have case where we have I1 and I2 using addresses A1 and A2 talking to the R and both have selected same SPI for the IPsec SA. Now if I2 disappears i.e. does not send IKE SA delete to destroy the IKE SA and the IPsec SA. If the I1 happens to get the same IP-address A2 in the local link, and sends UPDATE_IP_ADDRESSES to the R, we can have that situation. Note, that this I1 must get A2 before DPD notices that I2 is dead to this happen. As R uses selectors I1 and I2 to search from the SPD-S and the SPD-S will then point to the SA, there should be no problem for the R to send packets out. The I1 will discard those packets R sends which have keying material for the I2, and after a while R will start DPD for the I2 IKE SA and delete it as it does not see any traffic for it. When finding the SA based on the selectors we match those selectors against SPD-S, which have the exact selectors based on the SPD and the PFP flags (populate from packet), so there should not be problem even when they are using same PFP SPD rule. The case where we have multiple IKE SAs with the same IP address is already happening without MOBIKE, in case of NAT-T. The 4.4.2 of the RFC2401bis says: ... For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache. ... The section 4.4.1 describes the SPD-S: ... - SPD-S: For traffic that is to be protected using IPsec, the entry consists of the values of the selectors that apply to the traffic to be protected via AH or ESP, controls on how to create SAs based on these selectors, and the parameters needed to effect this protection (e.g., algorithms, modes, etc.). Note that an SPD-S entry also contains information such as "populate from packet" (PFP) flag (see paragraphs below on "How To Derive the Values for an SAD entry") and bits indicating whether the SA lookup makes use of the local and remote IP addresses in addition to the SPI (see AH [Ken05b] or ESP [Ken05a] specifications). ... Does that (correctly) answer the (correct) question? -------------------- Mohan Parthasarathy (2005-10-11): https://www.machshav.com/pipermail/mobike/2005-October/001113.html > So we have case where we have I1 and I2 using addresses A1 and A2 > talking to the R and both have selected same SPI for the IPsec > SA. Now if I2 disappears i.e. does not send IKE SA delete to destroy > the IKE SA and the IPsec SA. If the I1 happens to get the same > IP-address A2 in the local link, and sends UPDATE_IP_ADDRESSES to > the R, we can have that situation. Note, that this I1 must get A2 > before DPD notices that I2 is dead to this happen. As R uses > selectors I1 and I2 to search from the SPD-S and the SPD-S will then > point to the SA, there should be no problem for the R to send > packets out. Yes, this is the case. Now, when R receives the UPDATE_IP_ADDRESSES, it need to update the information in SA about where the packets should be tunneled out. How do you locate the SA to update its peer address ? If you locate the SA based on peer SPI, destination address and protocol (it does not matter how the peer chose the SPI i.e it can be unique for the whole system etc.), some implementation might have wrongly assumed that it will be unique. As you point out below, it does not work for NAT-T. So, you need a different way to lookup the SA. I am merely *guessing* that the original question was based on this. > The I1 will discard those packets R sends which have keying material > for the I2, and after a while R will start DPD for the I2 IKE SA and > delete it as it does not see any traffic for it. Yes, this is not an issue. > When finding the SA based on the selectors we match those selectors > against SPD-S, which have the exact selectors based on the SPD and > the PFP flags (populate from packet), so there should not be problem > even when they are using same PFP SPD rule. > > The case where we have multiple IKE SAs with the same IP address is > already happening without MOBIKE, in case of NAT-T. Agreed. This happens when there are two hosts (I1 and I2) behind the SAME NAT establishing the SA with a responder (R). If I1 and I2 picks the same SPI, then the destination address (public address), SPI and protocol as seen by the responder R will not be unique. > Does that (correctly) answer the (correct) question ? Yes. -------------------- Tero Kivinen (2005-10-12): https://www.machshav.com/pipermail/mobike/2005-October/001115.html > Yes, this is the case. Now, when R receives the > UPDATE_IP_ADDRESSES, it need to update the information > in SA about where the packets should be tunneled out. > How do you locate the SA to update its peer address ? The UPDATE_IP_ADDRESSES is IKE SA operation, that is done on the IKE SA, and each IPsec SA is tied to the IKE SA, thus all IPsec SAs affected can be found by finding the IPsec SAs created by this IKE SA (similarly what you do when the IKE SA is deleted, and you need to find all IPsec SAs created by IKE SA so you can delete them). -------------------- Pasi Eronen (2005-10-19) https://www.machshav.com/pipermail/mobike/2005-October/001132.html > The 4.4.2 of the RFC2401bis says: > ... > For outbound processing, each SAD entry is pointed to by > entries in the SPD-S part of the SPD cache. It seems the issue is about how exactly this "pointing" is implemented. I think Tuomas was saying that storing the (remote tunnel header IP, remote SPI) pair is not a right way to implement this pointing, since it does not always uniquely identify an outbound SA. And as you pointed out, this is not new to MOBIKE: it obviously happens with NAT Traversal, but can happen without NAT-T too (one peer goes away without deleting the SAs; another peer comes in, gets the same address, and creates new SAs with that). I'm not sure what, if anything, the spec should say about this. 2401bis itself is quite clear that it's describing a nominal model, and is not intended to match any real implementations. Clearly there are several ways to implement the pointer, depending on e.g. how exactly the required information is stored (there's no requirement that an implementation has two different data structures, one called SAD and another called SPD), and what programming language is used. But the details of C pointers, Java references, Prolog clauses, or LISP expressions are really beyond the scope of 2401bis (and MOBIKE). So, my gut feeling would be that if something needs to be said about this, the best place would be 2401bis, since the issue is not specific to MOBIKE. Also, it's an implementation detail, so there's no need to specify one single way to do it. However... I think some IPsec implementations have actually got this wrong. Mohan mentioned Linux, and based on a quick look, yes, it seems the 2.6 kernel IPsec uses (remote tunnel header IP, remote SPI, protocol) as the outbound SA lookup key. So maybe it would be worthwhile to mention this, perhaps in a non-normative "implementation considerations" appendix? -------------------- Mohan Parthasarathy (2005-10-19) https://www.machshav.com/pipermail/mobike/2005-October/001136.html I don't think it would hurt to point this out. For folks that are using Linux, they can know immediately that MOBIKE does not work and it might get fixed soon :-) -------------------- Jari Arkko (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001188.html It seems that we now have the same understanding of this issue. I asked Tero to write some text for an implementation note. Here goes: Add to the end of Section 4.4 an indented implementation note as follows: Implementation note: In MOBIKE (and also in IKEv2) it is possible to have cases where the SPI, protocol and destination address may not be uniquely distinguish SA to be used for outgoing traffic. In those cases implementations need to have a direct pointer from the matched traffic selectors of the outgoing traffic to the outbound SA to be used. That is, it is not enough to store SPI, protocol, and destination address to the SPD-S, but some kind of unique identifier is also needed. -------------------- Pasi Eronen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001193.html The basic idea in the text seems to be right, but IMHO we need much longer explanation than that (at least if we want people who didn't read the mailing list discussion to understand what the note says). I can try to write something (but not today)... -------------------- Jari Arkko (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001194.html Would this text + a pointer to design draft be sufficient? -------------------- Tero Kivinen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001199.html As this is only implementation hint and the same problem is already in the IKEv2 (i.e. the issue is not created by MOBIKE, it just might make it more common), I do not think we need too much text about that. -------------------- Mohan Parthasarathy (2005-10-25): https://www.machshav.com/pipermail/mobike/2005-October/001212.html The text is too simple to help the readers understand the issue. At least providing an example (like the one given in Thomas mail) as a background before the suggested text might help read it better. -------------------- Pasi Eronen (2005-11-02): https://www.machshav.com/pipermail/mobike/2005-November/001249.html Here's a proposal for text: Appendix A. Implementation Considerations A.1. Links from SPD Cache to Outbound SAD Entries [IPsecArch] Section 4.4.2 says that "For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache". The document does not specify how exactly this "pointing" is done, since this is an implementation detail that does not have to be standardized. However, it is clear that the links between the SPD cache and the SAD have to be done correctly to ensure that outbound packets are sent over the right SA. Some implementations are known to have problems in this area. In particular, simply storing the (remote tunnel header IP address, remote SPI) pair in the SPD cache is not sufficient, since the pair does not always uniquely identify a single SAD entry. For instance, two hosts behind the same NAT can accidentally happen to choose the same SPI value. The situation can also occur when a host is assigned an IP address previously used by some other host, and the SAs associated with the old host have not yet been deleted by dead peer detection. This may lead to packets being sent over the wrong SA or, if the key management daemon ensures the pair is unique, denying the creation of otherwise valid SAs. Storing the remote tunnel header IP address in the SPD cache may also complicate the implementation of MOBIKE, since the address can change during the lifetime of the SA. Thus, we recommend implementing the links between the SPD cache and the SAD in a way that does not require modification when the tunnel header IP address is updated by MOBIKE. For instance, in the C programming language, an ordinary pointer could be used. Any comments? -------------------- Francis Dupont (2005-11-02): https://www.machshav.com/pipermail/mobike/2005-November/001250.html PS: NAT-T and MIPv6 have the same issue. In NAT-T it is solved by making the initiator always behind the NAT (so the address can "float" as it is never used :-). In MIPv6 a solution is described in draft-sugimoto-mip6-pfkey-migrate-01.txt and in the real world an "unique" tag is used. BTW a C pointer is not a good solution because there is no one-to-one mapping between SPD and SAD. -------------------- Tero Kivinen (2005-11-02): https://www.machshav.com/pipermail/mobike/2005-November/001252.html Fine by me. -------------------- Pasi Eronen (2005-11-02): https://www.machshav.com/pipermail/mobike/2005-November/001253.html Yes, some kind of unique tag could be used instead of a pointer... Well, it's many-to-one, so a pointer could work in the SPD cache-to-SAD direction..? But perhaps it's better not to say anything about C pointers in this document at all. -------------------- Francis Dupont (2005-11-02): https://www.machshav.com/pipermail/mobike/2005-November/001254.html Well, it's many-to-one, so a pointer could work in the SPD cache-to-SAD direction..? => but without a back pointer to patch it when the SAD changes is painful. But perhaps it's better not to say anything about C pointers in this document at all. => I agree. -------------------- Mohan Parthasarathy (2005-11-02): https://www.machshav.com/pipermail/mobike/2005-November/001255.html I would remove the last sentence. Otherwise looks good... --------------------