Steven Bellovin writes: Per Steve Kent's comments (see his annotated version of the draft at http://psg.com/~smb/draft-ietf-mobileip-mipv6-ha-ip.htm ), there seems to be a serious mismatch between the semantics of IPsec and what is needed by this spec. In particular, the spec demands special matching and processing rules for input and output packets that are seriously inconsistent with IPsec. In principle, IPsec might be changeable in this regard, since the specs are currently undergoing revision; in practice, I suspect that the changes needed are too great. In any event, the changes will require the approval of the IPsec working group. Beyond that, this spec requires changes to the SPD as the mobile node roams. That implies a deep coupling between the MobileIP layer and the IPsec layer. Implementation might be problematic if outboard (i.e., NIC-resident) IPsec implementations are used. I would note that these have been on the market for a couple of years at the least; they're not hypothetical devices. I suspect that some of these issues might be resolvable by using IKE and negotiating new Phase 2 associations. This would rely on the existing API to IPsec, though admittedly it might require a new interface to IKE. Kent's much more detailed comments must be addressed, too. -------------- Jari Arkko responds to Steven Bellovin: We had a brief discussion with Steve Kent about these already. See http://www.piuha.net/~jarkko/publications/mipv6/issues/issue292.txt Basically, the conclusion of the discussion seemed to be (even Steve Kent appeared to agree) that there actually isn't a processing rule mismatch. The question is about the order in which things happen; if the mobile IPv6 processing leaves the packets in a suitable form, IPsec can do its work in the usual manner. The document was revised to clarify the issue, and I also took in account Steve's other comments. (Haven't received a final ack from Steve though.) One thing that was left to do was that he raised the issue of exactly what kind of replay protection can be provided without IKE, related to the question of whether IKE is mandatory or optional. This is something Vijay and I are working on to produce some explanatory text. You are right about the tight coupling (or at least an API is required). We've debated the issue in the WG while working on the document. There's a tradeoff involved, where in the current solution things get harder for BITS implementations but in the alternative solution packet formats get somewhat bigger. The consensus was on choosing the current solution. -------------- Steven Bellovin continues (after asking for comment regarding whether resolutions of issue #292 satisfy the concerns): We both have concerns about interfaces -- you have special requirements on the implementation of MobileIP. I'm at least as much concerned about the interface to IKE; I'm not even convined that the SPD modifications you call for are possible within the current structure. -------------- Jari Arkko responds to Steven Bellovin: Ok, so let me try to constrain this a bit: - So am I correct in assuming that the mismatch to 2401 is no longer an issue? (The issue that Steve K had about policy checks on HAO/RH2 vs. source. I think this is a matter of ordering MIPv6/IPsec processing and not a change to IPsec.) - When you say "interfaces", do you mean the API requirements, or the fact that we require interface-specific SPD entries? I assume the former, but I just wanted to be sure. Background: we have two sets of API requirements: (1) IKE, to make it possible to move its endpoints. This is optional, and strictly speaking not required. Just that movements will require re-establishing IKE, where IKE is used. This may, or may not, improve with IKEv2. Bottom line: we could take this away if this comes a critical item. (2) Control for the mobile node side gateway address. This is mandatory. However, if this becomes a critical issue we could go back to the alternative encapsulation format which we debated on the mailing list. In this format, there's a few dozen additional bytes, but it does not require the API. (But before I start removing functions I'd like to make sure I understand the concerns. Currently I do not.) - SPD modifications. Are you referring to e.g. the gateway address change, or is your belief that we need to extend IPsec SPDs in some manner? Or is this about the IKE authorization step for phase 2? -------------- Steven Bellovin writes: We both [S. Kent] have concerns about interfaces -- you have special requirements on the implementation of MobileIP. I'm at least as much concerned about the interface to IKE; I'm not even convined that the SPD modifications you call for are possible within the current structure. I have not been able to get to www.piuha.net to follow the references you sent me. -------------- Jari Arkko responds to Steven Bellovin: The links were http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.html (with modifs per steve K, bernard, russ) http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsecdiff-292.html (diff for steve K's modifs) http://www.piuha.net/~jarkko/publications/mipv6/issues/issue292.txt (discussion with steve K) http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#outbound-ipsec (processing order) Anyway here are the main excerpts from Vijay's discussion with Steve K April 9-10th: -------------vijay writes--------- Thanks for the in-depth review. A few quick answers.... The Home Adress Option appears before the IPsec header. At the receiving node, it is processed before the IPsec header is processed. Processing the Home Address Option means the IPv6 source address of the packet is replaced by the contents of the home address option. By the time the selector match is done, the implementation has to ensure that the home address is the source address of the packet. Similarly on the sending node, the SPD lookup should be done as if the source address of the packet is the home address. > o When a packet is matched against IPsec security policy or > selectors of a security association, an address appearing in a > Home Address destination option MUST be considered as the source > address of the packet. The above text does not mean IPsec code must be aware of the home address option. It says MIPv6 code in the kernel has to make sure that IPsec processing is applied as if the source address is the home address. Some of the current implementations handle this by adding the Home Address Option after IPsec processing. The argument is similar for Routing Header Type 2. Current MIPv6 implementations handle this by adding the routing header after IPsec processing is done (on the sending node) and processing the routing header before IPsec processing is done (in the receiving node). -----------steve k writes-------------- > The Home Adress Option appears before the IPsec header. At the > receiving node, it is processed before the IPsec header is > processed. Processing the Home Address Option means the IPv6 > source address of the packet is replaced by the contents of the > home address option. By the time the selector match is done, the implementation has to ensure that the home address is the source > address of the packet. Similarly on the sending node, the SPD > lookup should be done as if the source address of the packet is > the home address. If I understand what you are saying, then this seems OK, i.e., if the IP v6 semantics will cause literal substitution of one address for another, then the processing by IPsec will occur after such substitutions and it is not a change to the existing IPsec processing. Is that right? >> o When a packet is matched against IPsec security policy or >> selectors of a security association, an address appearing in a >> Home Address destination option MUST be considered as the source >> address of the packet. > > The above text does not mean IPsec code must be aware of the home > address option. It says MIPv6 code in the kernel has to make sure > that IPsec processing is applied as if the source address is the > home address. Some of the current implementations handle this by > adding the Home Address Option after IPsec processing. OK. > The argument is similar for Routing Header Type 2. Current MIPv6 implementations handle this by adding the routing header after > IPsec processing is done (on the sending node) and processing the > routing header before IPsec processing is done (in the receiving node). OK. -------------vijay writes--------- > If I understand what you are saying, then this seems OK, i.e., if > the IP v6 semantics will cause literal substitution of one address > for another, then the processing by IPsec will occur after such > substitutions and it is not a change to the existing IPsec > processing. Is that right? Right. -------------- Steven Bellovin responds to Jari Arkko: Thanks. Due to Passover, I'm not going to get to until next week, I fear. I do need to reread the document with this new understanding in mind. -------------- -------------- --------------