Jimmy Zhang writes: We have the following policy table: (cited from mipv6haipsec draft #5) " mobile node SPD OUT: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & local phase 1 identity = user_1 home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_address_1 & peer phase 1 identity = user_1 " When mobile node initiates IKE phase 2 negotiation with HA to establish the IPsec SA for return routability test, it only sends information like source, destination and protocol to HA in IKE message phase 2 ID payload. The MN has the HOTI packet to trigger this negotiation, so MN has its own way from HOTI to determine the interface information. However, how should HA know the interface part "IF interface = IPv6 tunnel from home_address_1"? If HA doesn't know this information, it is very likely to pick the wrong policy, and will reject the security association proposals. --------------- Francis Dupont: We (authors) had a long discussion about the "interface" issue but with no conclusion because according to the RFC 2401, SPDs are per interfaces... Fortunately this part of the document is only an example, the mandatory specification is the packet layouts and the behaviors, so it is not critical to get a perfect wording here (but if you have suggestions...). --------------- Jimmy Zhang writes: Yes, according to RFC 2401, SPDs are per interface, however, that is REAL interface. It is very natural to have different SPDs on different interfaces because you are going to send & receive on different interface too. If you send/receive packet on interface 1, you must use SPD of interface 1; if you send/receive packet on interface 2, you must use SPD of interface 2. I don't think RFC 2401 allows us to send/receive packet on interface 1, however apply the SPD of interface 2. 'SPDs are per interface' is true, I think, only when you send/receive per interface. If you send/receive on the same interface, but want to apply different SPDs, the peer has no way to determine which interface you are talking about, given the current IKE message exchanges. Here our situation is that, we are going to send/receive packet on home agent's one same interface (the interface IKE runs on), however, sometimes we need apply the real interface SPD, such as the policy to protect BU and BA, and sometimes we need apply the virtual interface SPD such as the policy to protect HOTI and HOT, IMHO, IKEv1 just doesn't have that luxury to tell which is which. The only information IKE phase 2 responder knows are source address/source port, destination address/destination port, protocol, there is no interface. This question is not perfect wording or not, but doable or not doable. We should at least add one notify payload to IKEv1. The purpose of this notify payload is to let the peer know that 'this SA proposal is not for the interface on which you receive this negotiation, but some interface else, please query your SPD of that interface before you reject me'. We extend the idea of proxy negotiation here to include proxy service for another interface. When the peer receives this notification, it knows that it should query the SPD of that mentioned interface, and then process the SA proposal accordingly. Proxy service for different interfaces is maybe useful for IPsec/IKE itself too, especially for router which may have multiple SPDs for multiple interfaces. --------------- Ed Remmell writes: I've discussed this in some depth with Jin Zhang (his desk is approx. 15 feet from mine , we looked at the detailed discussion logged between Jari, Francis, etc. for issue #306 to understand more of the background. I agree with Jin, the basic problem with using IKE to protect payload packets and return routability tunneled between the MN and the HA is: When the MN initiates IKE, it has the packet that triggered IKE, therefore it knows what interface it is sending that packet on (specifically, the MN-to-HA tunnel interface). However, on the receiving end of this scenario (i.e. the HA), when it recieves the IKE proposal from the MN, the HA does not have the packet that triggered IKE (since that is a packet the MN is sending, and IKE hasn't completed yet for that packet to be sent), therefore it doesn't know that it should be looking up interface-specific SPD entries on the HA-to-MN tunnel interface to prepare the response to the MN's IKE proposal, as Francis said: "=> the only issue with this is the SPD is applied to the wrong interface: on a HA the SPD must be applied to the home link interface, *not* to the HA-MN tunnel interface." This is the crux of the problem. In the case of manual keying, both the MN and the HA have the packet (there is no IKE negotiation required first, to setup to use the SAs), therefore it is possible in the manual keying case for both the HA and the MN to be able to identify the sending interface for the packet as being the HA-to-MN (or MN-to-HA) tunnel and use the interface-specific SPD entries. So, with manual keying, this complex SPD scenario described in draft-ietf-mobileip-mipv6-ha-ipsec-05.txt to protect payload and return routability packets tunneled between the MN and the HA is workable albeit painful for those of us whose IPsec implementations do not currently support interface-specific SPD entries. --------------- Francis Dupont responds to Ed Remmell: When the MN initiates IKE, it has the packet that triggered IKE, therefore it knows what interface it is sending that packet on (specifically, the MN-to-HA tunnel interface). => I agree: the packet is produced by the mobility code and we can assume some kind of ad-hoc processing. However, on the receiving end of this scenario (i.e. the HA), when it recieves the IKE proposal from the MN, the HA does not have the packet that triggered IKE (since that is a packet the MN is sending, and IKE hasn't completed yet for that packet to be sent), therefore it doesn't know that it should be looking up interface-specific SPD entries on the HA-to-MN tunnel interface to prepare the response to the MN's IKE proposal, as Francis said: "=> the only issue with this is the SPD is applied to the wrong interface: on a HA the SPD must be applied to the home link interface, *not* to the HA-MN tunnel interface." => I haven't changed my mind: the real problem is the spurious "per-interface SPD" requirement and its strange (IMHO) interpretation. This is the crux of the problem. In the case of manual keying, both the MN and the HA have the packet (there is no IKE negotiation required first, to setup to use the SAs), therefore it is possible in the manual keying case for both the HA and the MN to be able to identify the sending interface for the packet as being the HA-to-MN (or MN-to-HA) tunnel and use the interface-specific SPD entries. So, with manual keying, this complex SPD scenario described in draft-ietf-mobileip-mipv6-ha-ipsec-05.txt to protect payload and return routability packets tunneled between the MN and the HA is workable albeit painful for those of us whose IPsec implementations do not currently support interface-specific SPD entries. => such implementations are not conformant... But the issue is not a mobility issue, as Jin and me have discussed, IPsec/IKE has the same issue in a dynamic environment, for instance when one can't assume the incoming interface of all traffic. --------------- Ed Remmell responds to Francis Dupont: >=> such implementations are not conformant... But the issue >> is not a mobility issue, as Jin and me have discussed, >> IPsec/IKE has the same issue in a dynamic environment, for >> instance when one can't assume the incoming interface of all traffic. I was thinking about this some more... and I have an idea: When the MN does IKE with the HA for the purpose of securing Return Routability, it uses its home address as the source address for the IKE exchange. This causes the IKE exchange to use the MN-to-HA tunnel. When the HA then receives the IKE proposal from the MN, it will have been tunneled to the HA over the MN-to-HA tunnel. The HA can then detect that the MN's IKE proposal was received on this tunnel interface, and then the HA uses that information when creating the SAs associated with this IKE exchange to create them in the per-interface SPD associated with the MN-to-HA tunnel interface. So, the fact that the IKE is tunneled over the MN-to-HA tunnel indicates to the HA that the SAs created by that IKE exchange should be scoped to that tunnel interface. --------------- Francis Dupont responds to Ed Remmell: When the MN does IKE with the HA for the purpose of securing Return Routability, it uses its home address as the source address for the IKE exchange. This causes the IKE exchange to use the MN-to-HA tunnel. => this doesn't work because IKE will establish the SAs with the home address in the external header when we want the care-of address. And the IKE exchange won't use the MN-to-HA tunnel because the HA is a CN (so packets will get a HAO or a RH2). PS: there is no problem other than the wording: the home registration BU has set the proper SPD entry (it comes from the care-of address so from the right interface). --------------- Ed Remmell responds to Francis Dupont: > this doesn't work because IKE will establish the SAs with > the home address in the external header when we want the > care-of address. And the IKE exchange won't use the MN-to-HA > tunnel because the HA is a CN (so packets will get a HAO or a RH2). Yes, you are correct. --------------- Ed Remmell writes: typos in draft-ietf-mobileip-mipv6-ha-ipsec-05.txt: sections 5.3.2 "Return Routability Signaling" and 5.3.4 "Payload Packets" have come incorrect verbage, from section 5.3.2: " mobile node SPD OUT: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & local phase 1 identity = user_1 mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_agent_1 & local phase 1 identity = user_1 home agent SPD OUT: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_address_1 & peer phase 1 identity = user_1 home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA ESP TUNNEL: outer destination = home_address_1 & peer phase 1 identity = user_1" In the case of mobile node SPD IN, "outer destination = home_agent_1" for the ESP tunnel is incorrect, the source (not destination) address in the outer tunnel header is home_agent_1 and the outer destination is the MN's care-of address. In the case of home agent SPD OUT, "outer destination = home_address_1" is incorrect, this should be the MN's care-of address. In the case of home agent SPD IN, "outer destination = home_address_1" is incorrect, the source address in the outer tunnel header is the MN's care-of address (not home_address_1) and the outer destination is home_agent_1. Section 5.3.4 has the same problems. --------------- Francis Dupont responds to Ed Remmell: typos in draft-ietf-mobileip-mipv6-ha-ipsec-05.txt: => they are not typos, they are side-effects of the "interface = IPv6 tunnel" stuff... In the case of mobile node SPD IN, "outer destination = home_agent_1" for the ESP tunnel is incorrect, the source (not destination) address in the outer tunnel header is home_agent_1 and the outer destination is the MN's care-of address. => the traffic filter is for the inner header. I share your concern but we have no good solution because of the per-interface SPD requirement of RFC 2401. Section 5.3.4 has the same problems. => same cause, same effect. --------------- Jari Arkko writes: (Returning to this old issue.) I realize the decision is problematic for the home agent. But I'd like to note that there appears to be enough information in the IKE proposal packets to make the decision, assuming the implementation can take advantage of this. Section 4.4 states the following: The security associations for protecting Binding Updates and Acknowledgements are requested for the Mobility header protocol in transport mode and for specific IP addresses as endpoints. No other selectors are used. Similarly, the security associations for protecting prefix discovery are requested for the ICMPv6 protocol and the specific IP addresses, again without other selectors. Security associations for payload and return routability protection are requested for a specific tunnel interface and either the payload protocol or the Mobility header protocol, in tunnel mode. In this case one requested endpoint is an IP address and the other one is a wildcard, and there are no other selectors. That is, the proposals will be different in other respects as well as the interface. But it does require some support from the implementation. My proposal is that we should let this suffice for the moment. There's going to be opportunities for creating a tighter, better integration to IKE in the future, such as when we define how Mobile IPv6 and IKEv2 should work together. --------------- Ed Remmell responds to Jari Arkko: Well, seeing how there doesn't appear to be a good alternative (besides waiting for IKEv2), I guess we don't have much choice. --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------