Jari Arkko writes: I have good news and bad news. The good news is that today I saw what was probably the world's first IKE-based Mobile IPv6 implementation demo. It worked very nicely. The bad news is that the folks behind the demo (SSH, Santeri Paavolainen and Tero Kivinen) had a number of serious concerns about ha-ipsec and had implemented a different scheme than described in the draft. Specifically, they had the following concerns: 1. HAO/RH2 pre/postprocessing is hard to implement on a BITS, impossible on a BITW. (This is the previously held discussion.) 2. On a security gateway running on a box that supports mobile ipv6, the SPDs being based on HAO and RH2 contents will lead to surprising problems or possibly even attacks. For instance, a policy to tunnel everything from network prefix x/n to a gateway y will no longer automatically apply to all packets within the network x, because MIPv6-based packets will look different, i.e. use home addresses. (Santeri promised to write a better description of this problem today.) 3. Tero thinks that IKE "proxy" mode authorization for establishing SAs for addresses other than those transporting IKE will not work on most implementations. 4. In IKEv2, the proxy mode authorization has been explicitly forbidden. Their suggested approach is the use of plain src/dst addresses in the policy checks, running IKE on those addresses as well, and adding a new local policy scheme to IPsec implementations on both ends to check for the right HAO in order to avoid MN1 from sending a BU on behalf of MN2. Overall, they felt that the manual keying process and specs are OK, but that the IKE parts are not done in the most suitable way for IKE, and contain a lot of handwaving. They think the problems are serious enough for them to take a stand in IPsec WG and/or talk to Steven Bellovin. They do understand that we'd like to finish the spec, though. They would be happy to accept a something-now- something-more-later solution, if we could come up with one. For instance, if the spec only handled the manual keying case and another one was written later for the dynamic keying case, or if it would somehow be possible to see which variant of IKE is being run etc. ---------------- Basavaraj Patil writes: One step forward and two steps back :) Is it possible that we could possibly use the experience gained from the implementation to change the IKE sections in the base and MN-HA IPsec documents? I mean will that be enough to take care of the issues that Santeri et al. are raising. If IKE is the primary concern here, would it not be better to remove all IKE interactions from the base spec and only allow manual keyed SAs. This would get the spec done and we could then take up the IKE based SA mechanism and work on it with more time. But is this an acceptable approach? I think we have discussed this before and concluded that IKE is required for replay protection (re-keying). Would it not be a better approach for IKEv2 to be completed before the Mobile IP WG decides how to incorporate this into the base spec? Whats the point with working on all the IKE details when it is in the process of being deprecated. I am hoping that the new discovery will not derail the current status of the MIPv6 work. If possible we should try to get Santeri's help in working on the IKE parts of the spec. Even that will set us back by a few weeks and our target is to get IESG approval by IETF57. Maybe we should have a teleconf this week. How about tomorrow or Wednesday? And it would be good to have Santeri also parrticipate. ---------------- Jari Arkko writes: > If IKE is the primary concern here, would it not be better to > remove all IKE interactions from the base spec and only allow > manual keyed SAs. This would get the spec done and we could > then take up the IKE based SA mechanism and work on it with > more time. But is this an acceptable approach? I think we have > discussed this before and concluded that IKE is required for > replay protection (re-keying). Thats the problem. Tero and Santtu suggested this, but I fear it would not pass IESG. One might try though, if one had a very believable approach coming up later. > Would it not be a better approach for IKEv2 to be completed before > the Mobile IP WG decides how to incorporate this into the base spec? Sure. And even Tero and Santtu would agree about that. But Tero's point was that the current approach does not seem compatible with IKEv2, so a change of direction will be needed at some point. > Whats the point with working on all the IKE details when it is in > the process of being deprecated. > > I am hoping that the new discovery will not derail the current status > of the MIPv6 work. If possible we should try to get Santeri's help in > working on the IKE parts of the spec. Even that will set us back by a > few weeks and our target is to get IESG approval by IETF57. > Maybe we should have a teleconf this week. How about tomorrow or > Wednesday? And it would be good to have Santeri also parrticipate. Wednesday would be better. Any time suits me. Before that, today and tomorrow, I'll try to work on this more with them. I wish I could come up with something that refutes the claim that HAO/RH2-based IPsec SPD lookups are bad. That's because manual keying doesn't work without it, and letting it be either way per config looks very ugly. The remaing problems would be easier to deal with, if we got rid of this... ---------------- Santeri Paavolainen writes: There is a policy decision problem in the way IPSec Policies, dynamic IKE keying and general gatewaying (either VPN or regular) interact. This manifests on a situation where a gateway operates as a MIPv6 node (either MN, HA or a MIPv6-enabled CN) and a gateway (either security gateway using IPSec tunnels for VPN, or "regular" router) as the IPSec processing is currently specified for BITS implementations in the MIPv6 draft. Currently the steps a BITS implementation must do for each incoming or outgoing packet are: 1. Decide whether the packet is a MIPv6 packet (look for HAO/RT2 header from packet). 2. If the packet is a MIPv6 packet, perform a "normalization" step on the packet, and make a note that the reverse operation is needed later. 3. Perform IPSec processing. 4. If the packet required "un-normalization" (step 2), perform it. The picture below should describe the flow of packets. The IPSec Processing step is identical for both non-MIPv6 and MIPv6 packets, but I have drawn them separately since we'll see later that they in the end require different logical handling within the IPSec processing. Packet flow Why are these two paths logically different even if physically the same. Because policy decisions in the first, non-MIPv6 path are done based on the original packet's source / destination address where in the second path these decisions are based on the packet's RT2/HAO header value. Define the following setup: * Host A is a security gateway for network A. Host A is also a Mobile Node. Host A is thus also MN A (with home address A) and SGW A. * Host B is the other-end of the secured network, e.g. SGW B. Host B is not a mobile node nor a home agent. * Host C is a home agent for MN A. What happens when a host D in the network A sends a MH packet to HA B? The packet is: IPv6: src=host d dst=home agent DSTOPTS: HAO=home address a MH: Binding Update Since the packet is a MIPv6 packet, it will be normalized into: IPv6: src=home address dst=home agent DSTOPTS: HAO=host d MH: Binding Update This packet can match the MN A <-> HA B binding protection SA. A host in the Network A can subvert the MN traffic at will. This situation gets even more hairy if HA is also SGW with both the VPN tunnel and the binding protection SA having endpoint in the host (a tunneled MH packet is received by SGW, and it proceeds to MIPv6, which assumes that since the packet came through IPSec it is from the binding protection SA -- without a per-packet API MIPv6 can only assume that the security policy protects binding traffic, which is in this case correct!) In general terms, using normalization during IPSec processing causes a situation where packets without HAO/RT2 will have the "true" IPv6 src/dst addresses used for policy, whereas for HAO/RT2 packets the policy is based on the HAO/RT2 contents. All security policies that are in effect in the system must take the third possible address into account. (Note that the same problem applies to firewalls too: should they filter packets before or after normalization steps? It would be prudent to do that before IPSec since otherwise you are not seeing on-the-wire IP addresses - however that makes it impossible to integrate firewalling into IPSec processing as MIPv6 packets must be normalized before IPSec, and at that step you lose the on-the-wire IP addresses.) ---------------- Jari Arkko writes: > This packet can match the MN A <-> HA B binding protection SA. A > host in the Network A can subvert the MN traffic at will. Let me play the devil's advocate here for a while to make sure we have a problem. So what essentially happens in your example is that a packet comes in to node A with real source D but a forged home address option, pointing to A. IPsec policies will mistakenly think the packet is from node A itself and protect it. Fine so far. But how is this different from the case where the spoof happens not at HAO level but at a source address level directly? Presumably, security gateways would have an ingress filtering mechanism? Wouldn't that be needed for HAO/RH2 as well? ---------------- Vijay Devarapalli writes: simple question. how does SSH's BITS implementation handle RFC 2402. Routing (Type 0) -- The IPv6 Routing Header "Type 0" will rearrange the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. Hence, the IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation. this also requires "normalization" and "un-normalization", right? ---------------- Vijay Devarapalli writes: > What happens when a host D in the network A sends a MH packet to HA B? The packet is: this is a Mobile Network scenario. Host A is a mobile router. we are _NOT_ dealing with a mobile network with a bunch of nodes in the mobile network and the mobile node being a mobile router/security gateway. I just finished editing a Mobile Network draft for NEMO http://people.nokia.net/vijayd/nemo_protocol.txt. am I missing something? ---------------- Jari Arkko responds to Vijay Devarapalli: I haven't read Santeri's description yet. The way that we talked about it in their office was that we don't have to involve NEMO at all. Basically, you get a security gateway box that happens to support MIPv6 -- what happens then, does it do the norm & de-norm process for forwarded traffic as well, or just the originating/terminating traffic? ---------------- Vijay Devarapalli responds to Jari Arkko: I am not saying using NEMO. As MIPv6 currently stands, a MIPv6 node is explicitly restricted to a mobile host. it cannot be a security gateway. infact the MIPv6 spec also explicity prohibits forwarding packets received with routing headers out of the host. it cannot forward packets!!!. how can it serve bunch of nodes behind it? > does it do the norm & de-norm process for forwarded > traffic as well, or just the originating/terminating > traffic? I see the problem (something which we have to take care of in NEMO). MIPv6 node DOES NOT forward traffic!!! we can make it more explicit if needed. one more thing. NEMO prohibits this. packets from hosts inside the network have to use reverse tunneling. if there is a packet from the the host D behind the mobile security gateway, it has to send it like IPv6: src=host d, dst=any node in home link IPv6: src=SGW_CoA, dst=Home agent payload. ---------------- Vijay Devarapalli writes: There is another flaw in the above example. the source address in the IPv6 hdr and the address in the Home Address option MUST belong to the same node. the destination address in the IPv6 hdr and the address in the Routing Header Type 2 MUST belong to the same node. ---------------- Jari Arkko responds to Vijay Devarapalli: That's right, but a node that supports MIPv6 (but not use it currently for mobility) might be configured as a router. Say, a BSD box with MIPv6 support in the kernel -- would it look at the HAO or the source field when deciding policies? Anyway, Santeri and Tero said also that this issue can be fixed (they are more concerned about the overall complexity). ---------------- Vijay Devarapalli responds to Jari Arkko: > That's right, but a node that supports MIPv6 (but > not use it currently for mobility) might be configured > as a router. sure. > Say, a BSD box with MIPv6 support in the > kernel -- would it look at the HAO or the source field > when deciding policies? nobody denied there are issues. we hope to solve these issues in NEMO. > Anyway, Santeri and Tero said also that this issue > can be fixed (they are more concerned about the > overall complexity). can they make a simplifying assumption in their implementation? tell them to assume it is a Mobile Host. not a Mobile Router (and therefore not a Security Gateway with a network behind it). ---------------- Tero Kivinen responds to Vijay Devarapalli: > how does SSH's BITS implementation handle > > RFC 2402. > Routing (Type 0) -- The IPv6 Routing Header "Type 0" will > rearrange the address fields within the packet during > transit from source to destination. However, the contents > of the packet as it will appear at the receiver are known > to the sender and to all intermediate hops. Hence, the > IPv6 Routing Header "Type 0" is included in the > Authentication Data calculation as mutable but predictable. > The sender must order the field so that it appears as it > will at the receiver, prior to performing the ICV > computation. > > this also requires "normalization" and "un-normalization", right? When the packet contents is added to the MAC, it is added piece by piece, and if the piece happens to be routing header, the header is copied and modified to match the routing header in the end. This is only done during the MAC calculation, the actual packet is not modified at all. ---------------- Jari Arkko responds to Tero Kivinen: So, in this case is that there is some RH0/RH2 specific processing that the hardware IPv6 IPsec engine needs to do. The difference with RH2 (and HAO) is that there is in addition some policy lookup processing that needs to be done? ---------------- Vijay Devarapalli responds to Jari Arkko: no Jari, even with RH0, one needs to provide specific support for policy lookup. MIPv6 implementors have known this for about 4 years now. ---------------- Vijay Devarapalli responds to Tero Kivinen: the rearranging is not limited to te routing header alone. the rearraning is between the IPv6 header and the routing header. an example. lets assume there are three hosts. A------------>B------------>C A wants to protect all traffic between A and C. it also wants the traffic go through B. lets assume the IPsec implementation on A is a BITS implementation. the IP stack on A creates the following packet IPv6 hdr (src=A, dst=B) Routing hdr segleft=1, addr=C payload. how does the BITS implementation pick the right SPD entry? the SPD entry was between A and C. it has to first rearrange the addresses so that it can use A and C to do the SPD lookup, right? ---------------- Santeri Paavolainen writes: Kivinen's response is correct. For ICV calculation there is no need to "normalize" the packet. Note that for MIPv6 the "normalization" step is required, since for example ICMP errors need to be (this is my out of memory guess) sent with the "normalized" packet being the packet that is included. Also, policy decisions need to be made on the packet. ---------------- Santeri Paavolainen responds to Vijay Devarapalli: > the rearranging is not limited to te routing header alone. the > rearraning is between the IPv6 header and the routing header. > > an example. > > lets assume there are three hosts. > > A------------>B------------>C > > A wants to protect all traffic between A and C. it also wants > the traffic go through B. lets assume the IPsec implementation > on A is a BITS implementation. the IP stack on A creates the > following packet > > IPv6 hdr (src=A, dst=B) > Routing hdr > segleft=1, addr=C > payload. > > how does the BITS implementation pick the right SPD entry? the > SPD entry was between A and C. > > it has to first rearrange the addresses so that it can use > A and C to do the SPD lookup, right? The final destination address is always used for policy lookups. Note that the final destination can be looked from the original packet.There are no modifications to the packet (unless IPSec transforms are used, but these as said before do not require any "normalization" for ICV calculation). ---------------- Vijay Devarapalli responds to Santeri Paavolainen: wait a minute. I am not sure I understood. my question is, if you support routing header type 0, where you have to do the re-arranging for both policy lookup and ICV calculation, why cant you support routing header type 2? I dont care if you do the re-arranging on the original packet or not. your BITS IPsec implementation has to be aware of the routing header and know how to deal with it. ---------------- Santeri Paavolainen responds to Vijay Devarapalli: Because RT0 tells where the packet is going, RT2 tells where the packet is going virtually, not physically. In a situation where there is complete routability (e.g. all addresses are globally reachable), RT0 is redunant. Even if there is complete routability, RT2/HAO is not redunant - you cannot take the RT2/HAO address and replace src/dst with it. This is the difference. If you take RT2/HAO address, re-write src/dst (normalize packet) as them, and send the packet, it will not route correctly (even in case of the complete routability). "Normalized" RT0 packets would route correctly. I am not interested in what is theoretically possible: if you have (x + 1)^500, you could always expand it to x^500 + 500x^499 + 124750x^498 + ..., but the first is feasible to calculate by hand, whereas the expansion is not. The normalization step is feasible (although as I've argumented before, not very effective) to perform as the first step. You can do it later ("just-in-time"), but it incurs code complexity (bugs), more time in implementation : less desirable ---------------- Santeri Paavolainen responds to Vijay Devarapalli: > the source address in the IPv6 hdr and the address in the Home Address > option MUST belong to the same node. > > the destination address in the IPv6 hdr and the address in the Routing > Header Type 2 MUST belong to the same node. Yes of course they must - for valid MIPv6 use. This is a case of an attack. The mobile node receives the packet: ipv6: src=host d dst=home agent DSTOPTS: HAO=home address MH: BU Since this is not destined to us, but MN is also a GW, so it needs to be forwarded. The packet needs to be normalized, since it is (according to rules) an MIPv6 packet. The result is the: ipv6: src=home address dst=home agent DSTOPTS: HAO=host d MH: BU and WHOA! This now matches the IPSec selectors for binding update protection (src=home address, dst=ha, proto=mh)! So it gets stuffed into the binding update SA. HA receives it, sees that it came securely from the SA, and accepts it. Now all traffic is directed to "host d" address. It is very nice that "dst addr and addr in the rh2 MUST belong to the same node", but from GWs point of view it is just forwarding packets. Since they were not generated by it, it has no say what the "host d" put into inside these packets. The problem here is that because of the "normalization" step allows a malicious host to generate packets that will after a normalization step look for the IPSec policy engine just like packets generated by the local host. Of course one can arguet that the HA IPSec implementation must check that the src in the packet is the peer src that was negotiated. Oops, which peer address, the IKE endpoint peer or the misused "proxy id" address? It needs to verify both, src and HAO values. However at this point I already think the setup has failed. There should not have been in the first place a packet that an attacking party could inject into a transport mode connection. The rest is just like plugging a finger into a leaking dam. I think that at this point security of the setup starts to become very sensitive to a correct configuration. (E.g. you need to add more policy entries to "firewall" or filter out potentially bad packets, and add more processing steps to HA to guard against misconfiguration of MN etc. etc. just to use MIPv6 securely. It is no longer "use IKE and everything's fine.") ---------------- Vijay Devarapalli responds to Santeri Paavolainen: > Since this is not destined to us, but MN is also a GW, so it needs to be > forwarded. this _is_ is the problem. according to MIPv6, the mobile node is a mobile host. it does not forward packets!! period. all packets are originated from the mobile node. it has no ingress and egress interface. if you want to talk about a mobile node which does both forwarding and runs MIPv6, send a mail on the NEMO WG mailing list. ---------------- Francis Dupont writes: => point per point: 1 (hard on BITW): previously discussed. 2 (multiple addresses): this is an inherent issue with mobility, IMHO the traffic selectors should be applied to the inner addresses because they are the addresses the upper layers can see. The outer addresses are only used to carry packets. 3 I agree the "proxy" mode is not very common. I tried to know what commercial implementations support it but I got no answer... BTW I have an implementation for racoon (KAME IKE) and it is simple to support in the static case (i.e., with explicit authorization in the config file). 4 The "proxy" mode is not explicitely forbidden in IKEv2: the IKEv2 specs says nothing at all about it. => about solutions: - there are no such plain src/dst addresses. - multiple address selectors as for SCTP is a way to a solution but I am afraid this will become quickly very complex. In fact the whole -2- is an attack against the HAO/RH2 stuff. - the IKEv2 document has no provision for mobility stuff, for instance it doesn't protect the peer/tunnel endpoint addresses during IPsec SA establishment. I propose a counter-attack against the IKEv2 document: the IPsec/mobile-ip WG exchange must work in both directions. => about Basavaraj's comments: - we need more experiences, for instance I believe we should get feedback from MIPL before dropping the current document. - IKE is needed in the real world. - IKEv2 is not ready and should even not go through its current WG last call. => about Jari's comments: - Tero's point is wrong: IKEv2 specs has no explicit text about or against the proxy mode. IMHO the reason is very simple: nobody understood the IKEv1 text about the proxy mode (it is one of the poorest wording one can find in RFCs) and as it is not useful for VPNs it was dropped in IKEv2. - about SPD lookup: ask why SPD lookup should not be like PCB lookup (PCB: Protocol Control Block)? => about Santeri's comments: - the spurious steps in the processing are from the bad text in the ha-ipsec draft. I already said it should be changed, now we've got a normalization stuff just because MIPv6 and IPsec is not in a sound order. - Santeri's example has nothing to do with ha-ipsec, in fact it is based on MH packets which have two source or destination addresses. Of course a SG which has to forward a MH packet doesn't know what is the right one, same for a firewall BTW. IMHO a forwarding node should not interpret MH packets, but an end node (i.e., a node which is the source or the destination) must interpret it, i.e., use the inner addresses and not the outer addresses. IMHO, it is time to republish the Steve Deering's draft showing that HAO/RH2 are degenerated tunnels, and to ask to Santeri what to do with an encapsulated packet. => about Vijay's simple question: - very nice: it shows both that normalization is a standard stuff in IPsec and that normalization occurs only at the source or at the destination of packets. It even gives an hint: normalization is to simulate the destination case. ---------------- Vijay Devarapalli responds to Santeri Paavolainen: I asked > my question is, if you support routing header type 0, where > you have to do the re-arranging for both policy lookup and > ICV calculation, why cant you support routing header type 2? you replied > Because RT0 tells where the packet is going, RT2 tells where the > packet is going virtually, not physically. In a situation where there > is complete routability (e.g. all addresses are globally reachable), > RT0 is redunant. Even if there is complete routability, RT2/HAO is not > redunant - you cannot take the RT2/HAO address and replace src/dst > with it. This is the difference. If you take RT2/HAO address, re-write > src/dst (normalize packet) as them, and send the packet, it will not > route correctly (even in case of the complete routability). > "Normalized" RT0 packets would route correctly. true. but how does this relate to the complexity in your BITS implementation? are you saying normalization on RT2 is less secure than doing normalization on RT0? you must realise that it is not just the IPsec stack on the Mobile Node which tries to prevent all attacks. the IP stack also takes part in it by explicity not forwarding packets when it is a mobile node. and when the node is a mobile router/security gateway, the IP stack also makes sure that the address in the IPv6 source addressa and the address in the Home Address Option belongs to the mobile router/security gateway before forwarding any packets. you cannot have a situation where the above two addresses belong to different nodes. > I am not interested in what is theoretically possible: if you have (x > + 1)500, you could always expand it to x500 + 500x499 + 124750x498 > + ..., but the first is feasible to calculate by hand, whereas the > expansion is not. The normalization step is feasible (although as I've > argumented before, not very effective) to perform as the first step. > You can do it later ("just-in-time"), but it incurs code complexity > (bugs), more time in implementation : less desirable. I just want to remind you that we are still talking about a BITS implementation here. for a regular IPsec implementation in the kernel, there are no issues with respect to "normalization" and "un-normalization" because this done by the IP stack in the kernel. ---------------- Gabriel Montenegro writes: > That's right, but a node that supports MIPv6 (but > not use it currently for mobility) might be configured > as a router. Say, a BSD box with MIPv6 support in the > kernel -- would it look at the HAO or the source field > when deciding policies? But you just said it is not used for MIPv6, so why would it have an SPD entry with HA0? If it weren't for the amount of traffic this has already generated, I'd side with Vijay and quickly dismiss this as obviously not applying to MIPv6 (as opposed to NEMO). I'll go read the issue on the web, but I confess I'm really confused as to why this represents an issue for MIPv6. ---------------- Gabriel Montenegro writes: I'll try to read up on the issues list. From the email I've seen flying past, without much attention, here's two questions: - is this a BITS issue (as I believe Vijay claimed?). If so, why not just recognize it as such and refer to the existing issue number (and defer further work for later, as we know the tradeoffs with respect to BITS implementations). - is this a NEMO issue? this may be a bit more thorny, cuz if the user inadverdetly configures his machine to be a security gateway, and then decides to also configure it for MIPv6, then he may not even be aware of what NEMO is, but may be falling in some trap that exists nonetheles. Still, this is not the first time configuration can lead to unexpected results, and I believe there's already text in MIPv6 to warn against NEMO (even if it doesn't call it NEMO). perhaps the existing warning is enough to declare this a non-supported configuration and leave further work for later. ---------------- Santeri Paavolainen writes: IPSec and Mobile IPv6 using SSH QuickSec Toolkit written Santeri Paavolainen Copyright SSH Communications Security Corp, 2003 This report summarizes how MIPv6 traffic is protected through IPSec using the SSH QuickSec Toolkit IPSec implementation. * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * ----------- Method Overview The implementation *does not* follow draft-ietf-mobileip-mipv6-ha-ipsec-05. Instead it follows a model where: 1) All traffic between HA and MN are protected (this can be restricted to just MH and IPv6 protocols if required) with IPSec. 2) Only the IPv6 "true" packet source / destination addresses are used as IPSec selectors. Routing Header Type 2 and Home Address Options do not effect IPSec selectors. 3) Whenever MN changes its care-of address, new IKE and IPSec SAs are negotiated. The policy at the Mobile Node is very simple: "Whenever a packet is destined to HA, use IPSec [in transport mode ESP]." A simple scenario perhaps illustrates best how this works from the MN's side: 1) MN is in home network, it uses its home address to send BU etc. packets to HA. Per policy, these interchanges are protected by an SA. Let's call the outbound part of this SA pair SA1 with address parameters of src=home address, dst=home agent, proto=any. (The inbound is just a match for SPI.) Now, as longs as MN is in the home network it will use SA1 to protect all packets it sends to home agent. 2) MN moves to a remote network R1, and acquires a care-of address COA1. MN sends BU to HA, and the sent packet is like: IPv6: src=COA1, dst=HA DSTOPTS: HAO=home address MH: BU This will trigger IKE to negotiate a new IPSec SA. Per policy, the outbound SA (SA2) is defined as: src=COA1, dst=HA, proto=any. Now, as long as MN is in R1, it will use SA2 for all packets it sends to HA. 3) Now MN could move either back to home network, or to another remote network R2. Similarly MN will send BU message to HA, which will trigger a new IPSec SA negotiation to protect the HA<->MN traffic. ----------- Mobile Node & IPSec The base code used for MIPv6 IPSec development was the development version SSH QuickSec Toolkit 2.1 (not yet released). To this base the following changes were required to support MIPv6 at the mobile node's side: - Recognize RH2 and HAO headers during internal sanity-checking procedures. (E.g. do not label them "invalid".) No other changes were necessary to the codebase to support Mobile Node's IPv6 mobility. All other set-up is possible through the IPSec configuration interface. The IPSec policy use in the mobile node is: - Use certificates for authentication (this could be PSK if aggressive mode was used for Phase-1). - Protect all traffic to/from HA address using ESP in transport mode. ----------- Home Agent & IPSec The IPSec at Home Agent requires more changes, as the HA can have multiple Mobile Nodes attached to it, and it must prevent third parties from hijacking MN node connections. To prevent these attacks a new step is added to the HA's packet processing, where MH packets are verified against a known address configuration. As an additional "ingress" filter the HA IPSec will verify that any MH packets with an HAO header validate against the address that it should contain. Packets with non-matching HAO address will be rejected. In summary, the following changes are required to HA (in addition to the MN changes): - Add an IPSec policy rule option specifying the MN home address associated with that rule. - Verify in the IPSec post-processing step that the home address associated with an inbound SA matches that in the HAO field of any MH packets. - Disable internal forwarding (since forwarded packets must go through MIP code, which is integrated in the IP stack, and not IPSec stack). The IPSec policy used in the Home Agent is: - Never initiate an IPSec connection. (Since HA doesn't know MN's care-of addresses, it cannot be the initiating party.) - Accept transport mode ESP as responder, and associate identities of the initiator to given home addresses, for example: email=bill@example.com -> Home Address=800:2243:fefe::5 email=jill@example.com -> Home Address=800:2243:fefe::1000 ----------- Summary A working implementation was accomplished in about two calendar months by one software engineer. Majority of this time was taken by analysis, e.g. studying MIPv6 requirements, determining what was feasible and choosing appropriate implementation choice. Major differences between the model described above and draft-ietf-mobileip-mipv6-ha-ipsec-05 are: - No "normalization" step required. - No changes to IKE (implementation or interpretation of standards) required. - No changes to how the core IPSec operates (HA's HAO check is a post-processing step, which does not require any modification of the packet). Some open questions still remain: - What is the best method to bind Phase-1 identities into home addresses? It could be a field in the certificate, or done through "external" lookup (LDAP?), or bound to specific statically configured identities (as done here). - The HA needs to keep an "last seen coa" for each mobile node, and prevent all traffic to that address even when IPSec SA expires without the MN re-keying it (HA never initiates IKE). This is a general problem with MIPv6 and not specific to the model used here. (Question is: if HA uses IPSec to MN1 in COA1, and the IPSec SA expires, and later someone tries to talk from COA1 address using plaintext, what should HA do? COA1 might have been assigned to non-MN node.) ---------------- Jari Arkko responds to Gabriel Montenegro: > But you just said it is not used for MIPv6, so why would > it have an SPD entry with HA0? [I'm not necessarily agreeing that this is an issue, but just trying to represent the view from SSH as well as I can.] It would not have an SPD entry with HAO. Say, the SUN office in Grenoble has a security gateway that tunnels all traffic to the California office. The policies on this box are set up so that everything within the prefix allocated for the Grenoble office is tunneled. Assume your VP visits you and brings his MIPv6 laptop that has a home address from the California network. Now, if the SPDs look at care-of addresses (IP source and destination), then the VP's traffic is put to this tunnel. If the SPDs look at the home addresses (HAO and RH2), then the VP's traffic is not put to this tunnel. Which one is correct? This is the hard question. You could claim that the box should have been configured with a rule that says everything coming from the internal Grenoble interface should have been tunneled to the California office. Also, Francis argued that since upper layers will use the home addresses, it would be more logical to base the policy lookups on those addresses. (Of course, there may be situations particularly for firewalls, where we'd have to look at both addresses.) ---------------- Gabriel Montenegro responds to Jari Arkko: > [I'm not necessarily agreeing that this is an issue, > but just trying to represent the view from SSH as well > as I can.] The best I can is recognize there are problems, but the issue at hand is another one. Here we're trying to recognize if there are any MIPv6 issues. I don't think whatever issues there may be are actually relevant to MIPv6 base specifications. More below... > It would not have an SPD entry with HAO. Say, the SUN > office in Grenoble has a security gateway that tunnels > all traffic to the California office. The policies > on this box are set up so that everything within the > prefix allocated for the Grenoble office is tunneled. > Assume your VP visits you and brings his MIPv6 laptop > that has a home address from the California network. > Now, if the SPDs look at care-of addresses (IP source > and destination), then the VP's traffic is put > to this tunnel. If the SPDs look at the home addresses > (HAO and RH2), then the VP's traffic is not put to this > tunnel. This is no longer the domain of the base specification. This is figuring out interactions with VPN's and security gateways. Notice that even if we had some previous work in this direction (rfc2556), the real standards tracks efforts to clarify this with respect to VPN and MIPv4 interaction are only happening now. We didn't wait to release rfc2002 up to rfc3344 because some vpn/secGW interactions were unknown. There may have also been much less security scrutiny with respect to MIPv4, but in general, I think the separation of issues is what made it ok to wait this long to spec VPN interactions instead of forcing the base MIPv4 spec to wait. I'm trying to understand why the situation outlined above is not similar. > Which one is correct? This is the hard question. You > could claim that the box should have been configured > with a rule that says everything coming from the > internal Grenoble interface should have been tunneled > to the California office. No, I think the whole point of specifying HAO and RH2 so tightly was precisely so that you could (as an intermediate security gateway) do the simple thing and look at the topologically significant addresses (outer tunnel addresses) and be assured that these new MIPv6 mechanisms would not be used to open up new holes. In other words, if as a security gw you're ok with the topological addresses exchanging packets, then you're also ok with them exchanging packets which also include RH2/HAO cuz you are guaranteed by the MIPv6 spec that these will not end up in another node. It is much simpler for you as a sec GW to have that assurance than to have to second guess and start looking into internal headers. You may still have this problem with RH0. This is precisely why we did not want to overload that header type. We defined RH2 precisely to avoid being put in the same bucket (with all its potential problems) as RH0. It is that forethought that should now prove beneficial to us by dismissing this issue at hand as being out of MIPv6 domain. Why can't we reap the benefits of the previous careful work? Once you start down the slippery slope of second guessing your traffic and looking into internal headers, where do you stop? There's plenty of UDP and TCP encapsulation schemes, what do you do then? What about http encapsulation schemes, do you examine those as well? We crafted this thing carefully so sec GW's could continue doing the sane thing. Perhaps I'm misunderstanding something here... > Also, Francis argued that since upper layers will > use the home addresses, it would be more logical to > base the policy lookups on those addresses. > (Of course, there may be situations particularly for > firewalls, where we'd have to look at both addresses.) Firewalls can do whatever they want (including looking into http addresses), but I don't believe this is the cleanest approach as I mentioned above. ---------------- Jari Arkko responds to Gabriel Montenegro: > Notice that even if we had some previous work in this > direction (rfc2556), the real standards tracks efforts > to clarify this with respect to VPN and MIPv4 interaction > are only happening now. We didn't wait to release rfc2002 > up to rfc3344 because some vpn/secGW interactions were > unknown. There may have also been much less security > scrutiny with respect to MIPv4, but in general, I think > the separation of issues is what made it ok to wait this > long to spec VPN interactions instead of forcing the base > MIPv4 spec to wait. Makes sense. > No, I think the whole point of specifying HAO and RH2 so > tightly was precisely so that you could (as an intermediate > security gateway) do the simple thing and look at the > topologically significant addresses (outer tunnel addresses) > and be assured that these new MIPv6 mechanisms would not be > used to open up new holes. In other words, if as a security > gw you're ok with the topological addresses exchanging > packets, then you're also ok with them exchanging packets > which also include RH2/HAO cuz you are guaranteed by the > MIPv6 spec that these will not end up in another node. > It is much simpler for you as a sec GW to have that assurance > than to have to second guess and start looking into internal > headers. You may still have this problem with RH0. This is precisely > why we did not want to overload that header type. We defined RH2 > precisely to avoid being put in the same bucket (with all its > potential problems) as RH0. It is that forethought that should > now prove beneficial to us by dismissing this issue at hand > as being out of MIPv6 domain. Why can't we reap the benefits > of the previous careful work? Hmm... yes. But there are rules in base/ha-ipsec that say IPsec policies should be applied according to the home address option/rh2 contents. This has been necessary in order to support manually keyed SAs for BUs (or anything else). Is this in conflict with what you say above? Or is there confusion regarding the application of these rules for originating/terminating traffic vs. forwarded traffic? The SSH guys were at least confused with regards to this point, and so was I for a moment... base is actually clear on this point, ha-ipsec may not be so clear. Telling them that HAO/RH2 lookups don't occur for security gateways may help solving the problem? ---------------- Gabriel Montenegro responds to Jari Arkko: > But there are rules in base/ha-ipsec that say IPsec policies > should be applied according to the home address option/rh2 > contents. This has been necessary in order to support manually > keyed SAs for BUs (or anything else). Is this in conflict > with what you say above? No, cuz we do it for the end nodes, what I was talking about was referring to inspecting nodes, those that do not source or sink the traffic. These are the ones that I think should have the *option* not to second guess traffic and look inside beyond the external header. This option is what our careful wording of RH2/HAO provides. Of course, they may wish to go in and inspect these, but I don't think that is up to us. > Or is there confusion regarding the > application of these rules for originating/terminating traffic vs. > forwarded traffic? Yes, I think so. > The SSH guys were at least confused with > regards to this point, and so was I for a moment... base is > actually clear on this point, ha-ipsec may not be so clear. Perhaps we need to make it clearer. It may be clear to some folks, but I take the SSH confusion as feedback that we need to be more explicit in the ha-ipsec draft as well. > Telling them that HAO/RH2 lookups don't occur for security > gateways may help solving the problem? That would be my take. ---------------- Jari Arkko writes: After a discussion with the other authors and chairs, here's a summary of what I currently think of the normalization issue. First of all, Mobile IPv6 base specification is in fact clear that the home address (ours or the peer's) based SPD checks are only done for originating or terminating traffic, i.e., not in forwarded traffic. This appears to make it clear that current security gateways should operate as they are. The ha-ipsec document wording is less clear on this issue, but the whole document treats the issue of home agent - mobile node communications so... in any case a clarification is required. In fact, I might just remove the words about this since they are described more in depth in the base document. Secondly, the case of an attack where the care-of and home addresses do not belong to the same node. The HAO and RH2 have been specifically designed to be used only in end-to-end fashion. That is, unlike RH0 we are guaranteed that RH2 is not used to bypass firewall rules etc. A packet sent to a node with RH2 is either dropped or received per the rules in MIPv6, but it is never forwarded again. As discussed above, HAO and RH2 are processed only by the end points of a connection, and thus intermediate nodes such as security gateways do not either touch or attempt to verify them. I think the above two points help to alleviate your concerns Santeri on the attacks. Thirdly, we'd very much like to follow the MIPv4 process in worrying about the VPN gateway - mobility interactions. That is, such interaction work has happened after the base specifications were published (the work is now ongoing in the Mobile IP working group). Fourth, the implementation aspects. One question is if your BITS implementation easily knows whether its processing an originating or forwaded packet. Does it? I think this should be clear from the source address of the packet, but maybe not. Another question is whether the normalization is too troublesome or not. But here, don't we have two implementation alternatives? Either a normalization process, or a piece-by-piece process as is already implemented for the construction of the MAC for RH2? Comments? Still thinking about the IKE phase 2 authorization aspects... any ideas? I'm trying to figure out if there was any way to avoid the chicken-and-egg problem in running IKE to send the first BU. If there was, we could run IKE using home addresses, and there'd be no specific problems with regards to the proxy authorization. I'm not too hopeful, though, the problem seems impossible. Francis reports that KAME can do the phase 2 policy check, but that he doesn't know what commercial implementations do. ---------------- Tero Kivinen responds to Francis Dupont: > 4 The "proxy" mode is not explicitely forbidden in IKEv2: the IKEv2 > specs says nothing at all about it. It is not explicitely forbidden, but the IKEv2 draft says that the IPsec SAs are implicitely created between the IP numbers of the IKE SA. I.e there is NO WAY to create IPsec SA between any other ip numbers than those used in the IKE SA. This means that the IPsec tunnel mode endpoints will always be those ip-addresses which is used in the IKE SA, and for transport mode the SA is between those same IP numbers. From draft-ietf-ipsec-ikev2-08.txt: 2.11 Address and Port Agility IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. The IP ... > - the IKEv2 document has no provision for mobility stuff, for > instance it doesn't protect the peer/tunnel endpoint addresses > during IPsec SA establishment. I propose a counter-attack against > the IKEv2 document: the IPsec/mobile-ip WG exchange must work > in both directions. I have proposed one change to fix that (i.e the IP-ADDRESS-CHANGE notifications) and I would assume there will be separate draft that will add that to the IKEv2 after the IKEv2 is finished (we decided in IPsec WG that we do not want to concentrate to the mobility now, but take care of it later). > - IKE is needed in the real world. This is true, and I think the current draft makes assumptions that do not work with IKEv1. I.e you cannot use the proxy id stuff to create IPsec SAs between other hosts than where the IKE SA is. The proxy IDs are used in tunnel mode, and only use for them in the transport mode is to limit the SA for specific protocol and port. > - Tero's point is wrong: IKEv2 specs has no explicit text about or > against the proxy mode. IMHO the reason is very simple: nobody > understood the IKEv1 text about the proxy mode (it is one of > the poorest wording one can find in RFCs) and as it is not useful > for VPNs it was dropped in IKEv2. I agree that there is no explict text against it, but there is explicit text saying that the SAs are created between the IP numbers used for the IKE SA. I think this will effectively implicitly forbids the proxy mode. ---------------- Jari Arkko writes: A couple of additional thoughts. Regarding the normalize vs. post-check HAO solutions: as far IPsec is concerned, these appear to be equivalent on the wire. The format of the packets is IP: src=care-of dst=home agent DO: hao=home address MH: BU Whichever solution is used, the values in the packets are the same. Just that the processing of the packets is different. In the normalization case the SPD and selector comparisons are made to the home address, and care-of address is ignored. In the post-check HAO solution the SPD and selector comparisons are made to the care-of address, but the home address is equivalently checked against some authorization table. The real on-the-wire differences appear to be only in IKE. Here, the current solution is a request for phase 2 SAs that are for a home address. In Santeri's solution the SAs are requested for the care-of addresses, and an additional HAO post-check is enabled. In Santeri's solution, would there be a new IKE payload to enable this post-check? If yes, that might offer a way to upgrade the current scheme to a better one in the future? By the way, the post-check HAO solution resembles an earlier proposal by Mike Thomas, where IPsec provided "SA" or "IKE phase 1 identity" information to the MIPv6 module per packet, and let the MIPv6 module make the authorization decision. The differences are mainly implementation details; either you need some additional support in IPsec for the post check or you need an API. At the time we dicussed this solution, we decided against it based on the additional IPsec requirements that it was felt to cause, and the lack of a fully described proposal and all details. But we *did* decide to return to the issue and provide a new, more "scalable" ha-ipsec variant in the future. ---------------- Jari Arkko writes: A set of possible alternative solutions: #0: As is, just require the implementations to do what is necessary #1: Current approach for manual keying, new approach for dynamic keying #2: New approach for for both manual & dynamic keying, needs many manual SAs #3: Application layer replacement for ha-ipsec #4: Only home addresses are used, even for IKE #5: Only home addresses are used, leave it open whether to normalize or post-check HAO Solution sketch #0: In this solution, we simply require the normalization processes to be applied on packets, and we require the IKE authorization steps to be applied for the proxy addresses. That is, this is the currently defined approach. Pros: - Already defined - Allows manual keying, not just for ha-ipsec but also for regular payload traffic Cons: - Needs a new processing step for (IPv6) BITS implementations - Requires the authorization capability from IKE implementations in phase 2 Solution sketch #1: In this solution, the current approach is kept for manual keying, but another approach is used for dynamic keying. Specifically, manual keying behaves as follows: - normalization is used - SPD entries bound to home addresses Dynamic keying behaves as follows: - normalization is not used - extra local policy checks (either at IPsec layer or in MIPv6 through an API) are used to verify the right node uses the given HAO The decision between the used mode has to be done per node, since the normalization process is run before we know which kind of an SA is used. This decision is configured thus per node (even in the home agent). Variant #1a: modified to the current document Variant #1b: dynamic keying removed from ha-ipsec, new draft later Variant #1c: current approach kept in the document, new draft later defines the new approach (use recognized through a negotiated IKE parameter) Pros: - Smooth IKE integration - Clear upgrade path to IKEv2 Cons: - Two different modes - Not easy to support both dynamically and manually keyed mobile nodes in the same home agent - Even an integrated IPsec implementation needs modifications to support the extra policy checks Solution sketch #2: In this solution, manual keying is supported only for those care-of addresses which are known beforehand. There is no normalization step. IKE is run as in solution #1. Pros: - Very simple - Just one mode - Clear, smooth IKEv1 and IKEv2 usage Cons: - Manual keying possible only in a pre-determined area, and requires many SAs (note that this affects not just MIPv6 signaling, but also the regular use of IPsec by mobile nodes) Solution sketch #3: In this solution, current ha-ipsec is replaced by an "application" layer solution that decouples MIPv6 completely from IPsec. Pros: - No requirements for IPsec implementations Cons: - Has to develop its own diffie-hellman & public key exchange Solution sketch #4: In this solution, we use only home addresses in the communication. A special case is built to the Mobile IPv6 stack to handle home address options during the initial IKE negotiation (before a Binding Update has been approved). Thus, both IKE and IPsec runs on home addresses, and normalization process is used. Authorization problem for phase 2 requests is therefore solved. Pros: - Simple for IKE Cons: - Special case processing needed for HAO - Normalization step still required Solution sketch #5: This solution is like solution #4, but in addition IKE implementations would be allowed to declare that they can only support the HAO post-check model. This has only the impact that all negotiated SAs can only be used on the given care-of address, i.e. you need to rerun IKEv1 or run an IKEv2 "move" operation. Pros: - Allows many implementation methods Cons: - Special case processing needed for HAO ---------------- In a phone conference June 27th, 2003, we came to the following conclusions: 1) Keep the current document as is. 2) Attach a warning that says IKEv2 may do things in a (very) different manner. 3) We will create a team that intends to define a new specification for ha-ipsec/IKEv2, as well as define a mobility and multihoming feature for IKEv2. ---------------- Tero Kivinen responds to Jari Arkko: >> The real on-the-wire differences appear to be only in IKE. Here, And also for the ICMP error messages the IPsec stack might be generating. In the other case the packet inside the ICMP error message will have src=care-of, dst=home-agent, and in the other case src=home-address, dst=home-agent. >> the current solution is a request for phase 2 SAs that are for >> a home address. In Santeri's solution the SAs are requested for >> the care-of addresses, and an additional HAO post-check is >> enabled. This HAO post-check is needed always. I.e we need to check that none of the packets goming out from the IPsec have HAO that does not match the one associated with the SA. >> In Santeri's solution, would there be a new IKE payload >> to enable this post-check? If yes, that might offer a way to >> upgrade the current scheme to a better one in the future? No, The post check is needed always, so there is no need to negotiate it. >> P.S. By the way, the post-check HAO solution resembles an earlier >> proposal by Mike Thomas, where IPsec provided "SA" or "IKE phase 1 >> identity" information to the MIPv6 module per packet, and let >> the MIPv6 module make the authorization decision. The differences >> are mainly implementation details; either you need some additional >> support in IPsec for the post check or you need an API. At the >> time we dicussed this solution, we decided against it based on >> the additional IPsec requirements that it was felt to cause, and >> the lack of a fully described proposal and all details. But we >> *did* decide to return to the issue and provide a new, more >> "scalable" ha-ipsec variant in the future. It does not matter where you do the check (i.e in the home agent or in the IPsec engine), but you always need to do the check. It is not enough to check that the packet was protected by the IPsec, you also need to check that the SA protection applied to it actually matches the host. How is this done in the current spec? I.e lets take example we have one mobile nodes A and it also acts as SGW for host B (tunnel mode). Both have SA with HA. The host B tries to attack A, and sends tunnel mode ESP packet: IP: src=care-of dst=home-agent ESP: SPI=spi-b IP: src=host-b-address dst=home-agent DO: hao=home-address-of-A MH: BU This packet does not have DO header or anything like, that so from the IPsec processing point of view it is normal IP packet. The IPsec process will then decapsulate this and make it to: IP: src=host-b-address dst=home-agent DO: hao=home-address-of-A MH: BU The IPsec engine then checks that tunnel selectors do match (src=host-b-address, dst=home-agent), and passes the packet forward to the mobile ip code. Now, this packet is identical to the real BU packet from the host A. I.e the real BU from the host A: IP: src=care-of-a dst=home-agent DO: hao=home-address-of-A ESP: SPI=spi-a MH: BU which will be normalized before IPSec to (I assume the DO, must be before ESP, otherwise the normalization cannot be done, and I assume the original care-of-a is stored somewhere during the IPsec processing?): IP: src=home-address-of-A dst=home-agent DO: hao=home-address-of-A ESP: SPI=spi-a MH: BU Then the IPsec will decrypt that and get packet: IP: src=home-address-of-A dst=home-agent DO: hao=home-address-of-A MH: BU which will then be de-normalized back to: IP: src=care-of-a dst=home-agent DO: hao=home-address-of-A MH: BU and forwarded to the mobile ip code. The mobile IP code will see that both of those packets were protected by IPsec, they are destioned to it, and both have proper hoa, but the other packet was actually sent by B! I.e the IPsec processing needs to have post-checks for ALL SAs (not only those associated with mobile nodes) that they do not contain invalid HAO after the decapsulation/decryption. Is the above example correct, or is there something that I do not undestand? ---------------- Tero, I think your description is correct. For BITS (also BITW) implementation, there is one choice: * To perform HAO post-check for all packets The other "option" of * Have a per-packet API to tell MIP "which SA/identity" the packet came from is actually a non-option, since this wouldn't be a BITS anymore, but an integrated stack. Anyway, I don't see there's much of a point to rehash whether the HAO post-check is needed in BITS or not. It is required. Tero is right. However, I'd like to describe shortly some ideas that followed the question of "how to make ikev1 and ikev2 -based MIPv6 SAs live (efficiently) in the same ipsec implementation?" 1. The problem is not handling IPSec packets. IPSec packets are identified by SPI, and SPI uniquely and efficiently identifies the SA, and SA can have a flag for "normalization required (or not)". SPI -> SA is easy. 2. Performing "IPv6[DO:HAO]MH[...]" -> SA mapping is inefficient if IKEv1/IKEv2 MIP SAs exist simultaneously. If either-or, then there is not such a big problem (of course, as you might expect, I'll point yet again at this point that the normalization step is still required for IKEv1 MIP SAs, and does still pose a single potential bottleneck for all packet processing). Unless there is something in the packet that allows IPSec implementation to determine whether the packet should be subject normalization or not. This could be a bit in RH2/HAO (MH is not present for all packets, so it is out). This is now just an idea I throw up in the air. I already myself have several objections for the scheme: * It is ugly. Only the SA should have information that affects IPSec processing step. (Maybe this could be written as an selector and negotiated as part of IKE?) * Since this requires MIPv6 to encode the bit before giving the packet to IPSec, it leaves an open question of how does MIPv6 know a priori whether the bit must be set or not? * It probably (this is a gut feeling) has security implications, e.g. can attacker somehow fool the IPSec by setting this "normalization" bit to an unexpected value? (e.g. IKEv2 SA with "do not normalize" setting, attacker sets the "do normalize" bit on) * This can be also accomplished by having different HAO/RH2 types (e.g. HAO2/RH3 etc.) for these, as I pointed out as one possibility in the phone conference. This still doesn't help the problem of how MIPv6 knows which one to use... BTW, I have handwaved the "IKEv1 vs IKEv2 MIP SA." I have assumed that the "IKEv1 MIP SAs" have SA endpoints as home agent and home address, whereas "IKEv2 MIP SAs" endpoints are home agent and care-of-address instead, so the first requires normalization (or equivalent in-place processing) and the latter does not. P.S. I am leaving for holidays. If you have questions wrt/ SSH's IPSec, please direct these questions for Tero Kivinen instead. I will be back in office on August. ---------------- Gabriel Montenegro responds to Tero Kivinen: > I.e lets take example we have one mobile nodes A and it also acts as > SGW for host B (tunnel mode). Not allowed by current spec. But you had a similar scenario for the HA side, could you reformulate your example with a HA which is a SGW? This is also outside the current scope, but you argued that there is at least more business justification for considering it... ---------------- Santeri Paavolainen responds to Gabriel Montenegro: Just substitute "HA" for "MN" in Tero's example. The HA could be a VPN gateway. ---------------- Gabriel Montenegro responds to Santeri Paavolainen: >2. Performing "IPv6[DO:HAO]MH[...]" -> SA mapping is *inefficient* if > IKEv1/IKEv2 MIP SAs exist simultaneously. If either-or, then there is > not such a big problem (of course, as you might expect, I'll point yet > again at this point that the normalization step is still required for > IKEv1 MIP SAs, and does still pose a single potential bottleneck for all > packet processing). Would this same problem exist for the simultaneous existence of manual keyed and IKEv2 MIP SA's? ---------------- Santeri Paavolainen responds to Gabriel Montenegro: > Would this same problem exist for the simultaneous existence of > manual keyed and IKEv2 MIP SA's? Yes, actually the category is "manual/IKEv1" (good observation) since they both have the same normalization requirements, for manually keyed and IKEv2 keyed MIP SAs couldn't either live together either. ---------------- Gabriel Montenegro responds to Santeri Paavolainen: > Just substitute "HA" for "MN" in Tero's example. The HA could be a VPN gateway. Hmmm... In that case, why would an HA be sending an HAO to its MN? Seems like to have a reformulated complete nice example s/MN/HA/ won't do. ---------------- Santeri Paavolainen responds to Gabriel Montenegro: +------------+ | | +----------+ | Home Agent | ===Tunnel SA== | host b | | | +----------+ +------------+ | MIP SA | +--------+ | Mobile | | Node | +--------+ MIP SA is transport mode. SA between HA and 3rd party host "host b" is in tunnel mode. Now, the host b sends a tunnel mode packet as described in Tero's mail to the home agent: IP: src=host-b-address dst=home-agent ESP: SPI=spi-b IP: src=host-b-address dst=home-agent DO: hao=home-address-of-A MH: BU This is processed by HA's IPSec and the result is forwarded to its IP/MIP stack as: IP: src=host-b-address dst=home-agent DO: hao=home-address-of-A MH: BU And so, a 3rd party can impersonate MN through the its own tunnel mode SA. This is why HA needs to do post-check on all SAs for correct HAO values. ---------------- Vijay Devarapalli writes: probably a naive question. I am wondering if it would still be possible to set up SAs between home agent and home address even for IKEv2. setting up SAs everytime the mobile node is very bad for performance. the mobile node cant send a binding update till the IPsec SA is re-negotiated. is it already decided it is not possible? ---------------- That would require something like Arkko was saying, i.e running the mobile IP on the IKE packets also. This would mean that there are all kind of problems, like if the IKE SA dies, and the mobile node moves to new place, it cannot recreate the SA, as it cannot use the mobile ip to send IKE packets before it can do the binding update on the home agent, but it cannot do that before it can get the IKE SA up and running... > setting up SAs everytime the mobile node is very bad for > performance. The IKEv2 IPsec SA creation (create child sa) is 2 packets, and there is no requirement to do any public key crypto there, only hashes and symmetric crypto is required (== fast). I.e the performance hit would be one RTT (round trip time). > the mobile node cant send a binding update till the IPsec SA is > re-negotiated. Yep, so it must wait one round trip. > is it already decided it is not possible? The current IKEv2 draft says that IPsec SAs are created between the IP addresses of the IKE SA that creates them. I.e to be able to create transport mode IPsec SA between home address and home agent IP address you need to run the IKE SA also between those two IP addresses. ---------------- Tero Kivinen writes: > What if the HA is also a web server over IPv6? Must all web traffic > be equally > IPsec protected (even if there's, say https on top, or even if it's > public information)? It depends on your policy. If you want to protect some of the information but not all, then you need to have more complicated policy... >>> > 3) Whenever MN changes its care-of address, new IKE and IPSec SAs are >>> > negotiated. > >> Wasn't one of the working requirements for ha-ipsec not to have to do this? I do not know about that requirement, but the current approach does not fill the requirement "does not modify IKE" :-) >> How fast can this be done? For IKEv2, 2 packets, some hash & crypto work, no public key crypto unless configured to do so. This requires the ADDRESS-CHANGE notify payload support I drafted earlier to IKEv2. For current IKEv1 it takes sometime, as you need to do the Diffie-Hellman. It is however about 100 times faster than for our test network to notice that the mobile node have moved to another networks, and before it lets the packets get through. The mobile node seems to wait for the RA before allowing sending anything out, thus it takes tens of seconds to get it, and the IKEv1 SA creation can start after that. The host should have the rtsold running, but maybe it wasn't working... The IKEv1 SA creation takes less than a tenth of a second or similar if there is no latencies in the network. If I remember correctly one of my old tests (500 MHz Alpha, year 2000) created something like 10-20 IKE + IPsec SA per second (this was without network latencies). I.e it took something like 50-100 ms / exchange. This was with RSA and Diffie-Hellman group 2 (1024 bits). The PSK would have been 2 times faster, but it is not scalable and usable in the mobile IP case. The problem with IKEv1 is that it requires 4 RTT, so if the RTT is 200 ms, then the whole exchange takes little less than second. BTW, I will be also on vacation for the next week, so I might not respond to emails very quickly (I propably do read my emails during my vacation too, but not every day). ---------------- Tero Kivinen writes: > Not allowed by current spec. But you had a similar scenario for the > HA side, could you reformulate your example with a HA which is > a SGW? This is also outside the current scope, but you argued This was the SGW. My text on that sentence was incorrect. I was trying to say that: I.e lets take example, that we have a machine, which acts as a HA for one mobile node A and the same machine also acts as a SGW for the host B (tunnel mode). The rest of the text should be fine after that modification. I simply forgot to fix that one sentence after I decided that it is enough to have one mobile node A, not two (I first had two mobile nodes A and B...). ---------------- Jari Arkko writes: PART 1: Current document ======================== A few observations first based on the last days discussions. First, I agree that we need a post check. The treatment of HAO/RH2 is symmetric in the sense that the same rules apply on sending/receiving direction. This is the same thing as having the outbound IPsec policy for a packet be the same as the post-decryption check at the inbound side. So, if HA is the final recipient of the packet from host b (the attacker trying to spoof a BU from host a), it shall run its post-decryption IPsec policy check according to the contained HAOs and RH2s. Secondly, as far as the run-IKEv2-on-home-address solution goes, I think the problems with expired SAs are similar in any solution. If the mobile node does not report its new location, we are dead, and a new connection has to be built later on the mobile node's initiative. Thirdly, I have modified the ha-ipsec draft slightly to (a) add the same warning as was in the base that this work does not make any claims about how IKEv2 would work for this, and (b) clarify that the HAO/RH2 to be taken in account only terminating/originating traffic. The URL is http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsecdiff.html PART 2: IKEv2 ============= Finally, lets talk about what I think is the most interesting piece. How can we make all this work nicely in the IKEv2 environment? And how can we make the IKEv2 capable of roaming, mobility, privacy addressing, and possibly multi-homing? I do not have a specific proposal on how the new feature should look like. However, there are a number of aspects we should cover in our dicussion: 1. Scope of the IKEv2 feature. Does this accomplish only "simple" movement (kind of like Mobile IPv6) or does it also do multi-homing? For a drafty draft of a multi-homing capable IKE-like scheme, see draft-nikander-hip-mm-00.txt. Tentative answer: include multihoming too. 2. In Mobile IPv6, we have left out several functions that we would have desired the HA-MN security to have, but did not want to include them in the first protocol RFC. For instance, we'd really like to have RFC 3041 address support for home addresses? How can this be accomplished, and is this a part of the IKEv2-MIPv6 effort or a separate effort? Tentative answer: do it as a separate effort. Just that there may be implications on the way 3041 support is done. Need to feed that back to the IKEv2 work. 3. How do we make the MIPv6 location updates and IKEv2 location updates live peacefully with each other? Tentative answer: make the IKEv2 location updates worry about IKEv2 SAs and IPsec SAs, let MIPv6 location updates worry about MIPv6 BCEs and tunnels. Also, IKEv2 location updates are useful not just when doing Mobile IPv6, but also in other contexts. The hard part is the authorization step to assure the right node sends the messages with the given home address, but solutions to this have been outlined by Santeri. 4. How is IKEv2 movement feature going to tackle simultaneous movements? Tentative answer: we may not be able to do this if the assumption is just two moving nodes talking to each other. With stable home agents (MIPv6) or forwarding agents (HIP) this would be doable. 5. Backwards compatibility with MIPv6 ha-ipsec RFC. Discussed separately. 6. Backwards compatibility with IKEv2 RFC. I assume this is doable. 7. If multihoming is supported, what is the interaction to SCTP and IPsec/IKE SCTP extensions? 8. The return routability test scheme. I assume what Tero defined earlier is going to be sufficient for IKEv2. Adding multihoming support would complicate it somewhat, however. ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ----------------