-------------------- Francis Dupont (2005-11-02): https://www.machshav.com/pipermail/mobike/2005-November/001250.html => I am afraid it is not enough: the link issue is not the only issue: if the SPD has no indication of what are the new endpoint addresses to use after an update, one cannot guarantee a new SA pair will be create using the right addresses. So an update should impact something somewhere in the SPD. -------------------- Pasi Eronen (2005-11-02): https://www.machshav.com/pipermail/mobike/2005-November/001253.html Currently, it's beyond the scope of MOBIKE how the initial contact is handled. Section 1.2 says: The mobility support in MOBIKE allows both parties to move, but does not provide a "rendezvous" mechanism that would allow [...] discovering the addresses when the IKE_SA is first established. In fact, if your manually configured SPD entry says that a certain IP address must be used when the SA is established, then that's the policy that must be followed, MOBIKE or not. If the IP address of the remote tunnel endpoint is not static, you need some kind of "rendezvous" mechanism for discovering it, like DNS (but then the SPD entry that triggers the creation of the IKE_SA would contain the FQDN of the remote tunnel endpoint, not the IP address -- and this is what "remote access" VPN clients usually do, I guess). -------------------- Francis Dupont (2005-11-02): https://www.machshav.com/pipermail/mobike/2005-November/001254.html Currently, it's beyond the scope of MOBIKE how the initial contact is handled. Section 1.2 says: => I don't speak about the initial contact but the case where there are many SPD entries requiring IPsec protection between the two peers and only some of them have active IPsec SA pairs. The peer addresses are somewhere in the SPD (this is highly implementation dependent) and this information must be updated. In fact, if your manually configured SPD entry says that a certain IP address must be used when the SA is established, then that's the policy that must be followed, MOBIKE or not. => this is not the issue, next paragraph seems better. If the IP address of the remote tunnel endpoint is not static, => they are not in MOBIKE. you need some kind of "rendezvous" mechanism for discovering it, => no, we need this only if they are dynamic at *both* sides. like DNS (but then the SPD entry that triggers the creation of the IKE_SA would contain the FQDN of the remote tunnel endpoint, not the IP address -- and this is what "remote access" VPN clients usually do, I guess). => the VPN client I use has the addresses of the VPN server. It doesn't try DNS resolution because it tries to send no packets before IKE/IPsec setup. To come back to the main point, the peer addresses are dynamic and included somewhere in the SPD or the PAD. The way this is supported is very implementation dependent but the fact the information must be updatable by MOBIKE is not at choice. -------------------- Pasi Eronen (2005-11-06): https://www.machshav.com/pipermail/mobike/2005-November/001266.html > => I don't speak about the initial contact but the case where > there are many SPD entries requiring IPsec protection between > the two peers and only some of them have active IPsec SA pairs. > The peer addresses are somewhere in the SPD (this is highly > implementation dependent) and this information must be updated. (I created a new issue for this -- this is clearly different from issue 51 where the IPsec SAs already exist) In fact, 2401bis does not specify how the peer is determined when an outgoing packet triggers the creation of an SA. Section 4.4.3.4 writes: For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 and 2401bis do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X. In particular, there can be several peers that are allowed to represent X (several different security gateways we could contact to establish an SA for the triggering packet). Presumably, the process is something like this: 1. Determine the right peer for the IPsec SA 2. Determine whether we have an active IKE_SA with this peer 3. If not, create an IKE_SA 4. Create the IPsec SA using CREATE_CHILD_SA exchange (possibly piggybacked in IKE_AUTH if we needed a new IKE_SA) The text I quoted above basically says steps 1 and 2 are beyond the scope of 2401bis (and IMHO also MOBIKE). Step 3 is discussed in Section 3.1 of MOBIKE draft (basically, finding out the peer addresses is beyond the scope), and step 4 should be very simple. > To come back to the main point, the peer addresses are dynamic and > included somewhere in the SPD or the PAD. The way this is supported > is very implementation dependent but the fact the information must be > updatable by MOBIKE is not at choice. Hmm.. as long as we agree that the inital contact (how to determine addresses when establishing the IKE_SA) is beyond the scope of MOBIKE (as Section 3.1 currently says), the question seems to be just about steps 1 and 2 above, right? But since 2401bis is not very light reading in this area, perhaps it would be a good idea to mention that depending on exactly how those unspecified steps are implemented, the implementation may be affected by MOBIKE. How about adding something like this to the "implementation considerations" appendix? A.2 Creating Outbound SAs When an outbound packet requires IPsec processing but no suitable SA exists, a new SA will be created. In this case, the host has to determine (1) who is the right peer for this SA, (2) whether the host already has an IKE_SA with this peer, and (3) if no IKE_SA exists, the IP address(es) of the peer for contacting it. Neither [IPsecArch] nor MOBIKE specifies how exactly these three steps are carried out. [IPsecArch] Section 4.4.3.4 says: For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 and 2401bis do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X. In step 1, there may be more than one possible peer (e.g., several security gateways that are allowed to represent X). In step 3, the host may need to consult a directory such as DNS to determine the peer IP address(es). Some implementations are known to use a single IP address as an identifier for the right peer in steps 1 and 2 (in which case step 3 becomes trivial). This approach may complicate the implementation of MOBIKE; however, these implementation details are beyond the scope of this specification. -------------------- Francis Dupont (2005-11-06): https://www.machshav.com/pipermail/mobike/2005-November/001269.html (I created a new issue for this -- this is clearly different from issue 51 where the IPsec SAs already exist) => I agree but the intersection between 41 and 70 is not void. In fact, 2401bis does not specify how the peer is determined when an outgoing packet triggers the creation of an SA. => yes, this is very implementation dependent so the specs should provide no details, but should say something as it is in fact needed... Presumably, the process is something like this: 1. Determine the right peer for the IPsec SA 2. Determine whether we have an active IKE_SA with this peer 3. If not, create an IKE_SA 4. Create the IPsec SA using CREATE_CHILD_SA exchange (possibly piggybacked in IKE_AUTH if we needed a new IKE_SA) => I agree. 1 is only for outgoing traffic in all implementations I know but it doesn't matter (if the policies are symmetrical the other peer will establish the SAs, if they are not this is an error). The text I quoted above basically says steps 1 and 2 are beyond the scope of 2401bis (and IMHO also MOBIKE). => I disagree about step 1 which is in the scope of 2401bis (only). Step 3 is discussed in Section 3.1 of MOBIKE draft (basically, finding out the peer addresses is beyond the scope), and step 4 should be very simple. => to find the peer addresses is IMHO a part of step 1. > To come back to the main point, the peer addresses are dynamic and > included somewhere in the SPD or the PAD. The way this is supported > is very implementation dependent but the fact the information must be > updatable by MOBIKE is not at choice. Hmm.. as long as we agree that the inital contact (how to determine addresses when establishing the IKE_SA) is beyond the scope of => oops. The term "initial contact" meant something else for me. MOBIKE (as Section 3.1 currently says), the question seems to be just about steps 1 and 2 above, right? But since 2401bis is not very light reading in this area, perhaps it would be a good idea to mention that depending on exactly how those unspecified steps are implemented, the implementation may be affected by MOBIKE. => yes, my concern is the step 1 has to be done so there are some infos somewhere which must be updated by MOBIKE. How about adding something like this to the "implementation considerations" appendix? => this is a way to solve the issue A.2 Creating Outbound SAs When an outbound packet requires IPsec processing but no suitable SA exists, a new SA will be created. In this case, the host has => s/will/shall/ ? BTW it is more a SA pair but I agree the text is more readable as it is. to determine (1) who is the right peer for this SA, (2) whether the host already has an IKE_SA with this peer, and (3) if no IKE_SA exists, the IP address(es) of the peer for contacting it. Neither [IPsecArch] nor MOBIKE specifies how exactly these three steps are carried out. [IPsecArch] Section 4.4.3.4 says: For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 and 2401bis do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X. In step 1, there may be more than one possible peer (e.g., several security gateways that are allowed to represent X). In step 3, the host may need to consult a directory such as DNS to determine the peer IP address(es). => the last sentence is loose enough to make MIPv6 to work (:-)! Some implementations are known to use a single IP address as an identifier for the right peer in steps 1 and 2 (in which case step 3 becomes trivial). This approach may complicate the implementation of MOBIKE; however, these implementation details => IMHO here we have to explain why, i.e., this IP address has to be updated when it changes. -------------------- Pasi Eronen (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001274.html IMHO at least some parts of step 1 are beyond the scope of 2401bis (e.g. Section 4.4.3.4 says "RFC 2401 and 2401bis do not specify how A determines the address of the IKE peer serving X.") On the other hand, 2401bis does not specify that exactly these four steps must be done in this order, so it's a matter of taste how you want to describe it... Hmm... actually the text I proposed was not quite right. Using a single IP address as the sole identifier for the right peer simply doesn't work correctly, since an IP address does not uniquely identify a peer (for similar reasons as in issue 51). More likely, it has to also take into account information in the PAD etc.. How about rephrasing the last paragraph to something like this? When performing these steps, implementations may use information contained in the SPD, the PAD, and possibly some other implementation-specific databases. Regardless of how exactly the steps are implemented, it is important to remember that IP addresses can change, and that an IP address alone does not always uniquely identify a single IKE peer (for the same reasons as why the combination of the remote IP address and SPI does not uniquely identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 and 2 it may be easier to identify the "right peer" using its authenticated identity instead of its current IP address. However, these implementation details are beyond the scope of this specification. -------------------- Francis Dupont (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001275.html => yes, this is a known issue for ipsec-tools... => the sentence about the authenticated identity is IMHO only for positive step 2 but I think the text is enough detailed. -------------------- Jari Arkko (2005-11-15): https://www.machshav.com/pipermail/mobike/2005-November/001308.html I'm OK with Pasi's initial suggestion as updated below in his e-mail. --------------------