Francis Dupont writes: - 1. Introduction ... A care-of address is an IP address associated with a mobile node that has the subnet prefix of a particular foreign link. ^^^ s/the/a/ - 3.1 Binding Updates and Acknowledgements Note that the home address is not cryptographically protected but a bad home address can't be used because of the check on addresses of IPsec incoming processing (i.e., it is an ACL-like protection done by the traffic selectors). IMHO this is not an issue but this point should be made clearer. - 3.2 Return Routability Signaling s/gateway address[es]/outer header address[es]/g (for IKE the proper term is "peer address[es]" but RFC 2401 just talks about outer header) s/tunnel gateway address/tunnel endpoint address/g (note: "g" because there are many occurrences) - same (3.2) ... When the mobile node adopts a new care-of address, its source address selection rules will automatically adopt a new source address for outgoing tunnel packets. this is 100% wrong because IPsec doesn't use the source address selection rules: the endpoint addresses are SA parameters. We can't rely on the address selection: we have to enforce the same address than given by applying the address selection rules. - same (3.2) (The home agent accepts packets sent like this, as the outer source address in tunnel packets is not checked.) this is a wrong assumption because if the RFC 2401 explains why it should not be checked, many real world implementations check it... In fact, it works only because of the 4.3 HA requirement. - same (3.2) (typo/improvement) ... on top of its then current care-of address ^ ? addresses as IKE was transported on. (from IKEv2 draft: s/was transported on/ran over/ - 4.1 Mandatory Support I don't understand different requirements for "supported" and "used": if the "supported" requirement means we have to implement it then when we decide to not use something we don't need to implement it... For instance, what to do exactly for prefix discovery (which is painful to implement without any real world utility)? - 4.2 Policy Requirements ... for the tunnel interface between ... No, we can't assume the IPsec implementation uses interfaces for IPsec tunnels! Please use a wording which works for every choices of implementation (i.e., both for "interface" and for "policy"). - same (4.2) (typo) prefix discovery SHOULD not be deleted as they do not depend on s/not/NOT/ - 4.3 IPsec Protocol Processing (typo) A non-null encryption transform and authentication Either "Non-null ..." or "... and an authentication"? - same (4.3) MUST be supported and SHOULD be used (same concern than in 4.1) - same (4.3) It seems the current proposal is to update the SPD/SADB from the mobility code: - of course this is more efficient than to rekey via IKE - I am afraid this is not implementable with every IPsec, for instance with BITW or BITS... We should look at this issue before or during the IETF last call. - this restricts the K bit to the peer address update of IKE session only: * not very useful for pure IKEv1 with the use of very short IKE sessions * not compatible with your (:-) peer address update proposal for IKEv2 (only the IKE SA needs to be updated: IPsec SAs it manages are updated directly by the mobility code)! - 4.4 Dynamic Keying o Conversely, the IPsec security associations with the mobile node's home agent MUST be requested from the key management protocol with the home address as the mobile node's address. This has no sense because there are many (zero to four) addresses in an IPsec SA. We have to specify in each case the MN address in the traffic selector and for tunnel mode SA the endpoint address. So this alinea must be completely rewritten... - same (4.4) (improvements) s/IKE endpoints/IKE peer addresses/g - same (4.4) if rekeying is needed. (twice) the term is not good because IKEv1 has no ISAKMP SA rekeying. For some implementations the session has to be closed and reopened, for some others nothing is needed because the last seen peer address is used (i.e., IKEv1 implementations are not flexible enough or are insecure . - 5.1 Format SA entries should get an outer source parameter too, not only an outer destination parameter. Note this is important for manual keying because with automatic keying SAs come by pair. - same (5.1) (note) The name of the SA database is the SADB in many texts (but not the RFC 2401 so we can keep SPD/SAD). - 5.2.2 Return Routability Signaling Same concern about the tunnel interface, but here this can be solved by a simple warning at the beginning ("interface" choice = same text, "policy" choice = any interface (MN) or home link (HA)). Of course, the interpretation of traffic selectors by interface is hairy when IPsec tunnels are interfaces so IMHO the best is to reverse the assumption about the choice (but keep a warning) and to remove the interface stuff in the SPDs. - same (5.2.2) The MN tunnel endpoint address is the primary care-of, not the home address, so : mobile node SAD: - SA4(IN, spi_d, home_address_1, ESP, TUNNEL): and home agent SAD: - SA4(OUT, spi_d, home_address_1, ESP, TUNNEL): are WRONG! - 5.2.3 Prefix Discovery we should add a warning explaining we don't assume a fine selection on the type and code of ICMPv6, so all ICMPv6 are selected in place of only the prefix discovery messages. Note that the SPDs described above protect all ICMPv6 traffic between the mobile node and the home agent. => move this at the beginning (because it is a consequence of the assumption). - 5.2.4 Payload Packets Same tunnel interface concern (and again packets go through the tunnel if they use the interface . - same (5.2.4) If the protocol is Any (in place of X) the 5.2.2 (RR protection) is no more needed. Please be a bit more clearer about this. - same (5.2.4) SA8s must use the primary care-of address, not the home address. - same (5.2.4) In this case the source and destination can be left as a wildcard and the SPD entries will work solely based on the used interface and the protocol, which is ICMPv6 for both MLDv1 and MLDv2. this doesn't work if the IPsec tunnel is not an interface. - same (5.2.4) It is therefore useful to avoid setting the protocol X in the above entries to either AH or ESP. It is not possible to set the protocol X to something which is not an "upper layer" protocol, so this issue doesn't exist. - 5.3.1 Binding Updates and Acknowledgements The HA can't be the initiator, so we should specify it runs in the "passive" mode. Note this is true only for BU/BA. - 5.3.2 Return Routability Signaling Same concern about the tunnel interface... - same (5.3.2) s/gameway/XXX endpoint address/ - same (5.3.2) ... In order to avoid writing dynamically changing information to the SPD entries, the above has been written with the home address as the gateway. Note this assumes the SPD is updated at the reception of the home registration BU before a phase 2 is launched to setup the tunnel. And this assumes too the implementation has a way to recognize the entries without using the MN endpoint address. BTW the wording is poor: we should explain the SPD will be updated by the mobility code and we only put an initial value. - 6.2 Binding Update from the Mobile Node Step 4 must include RFC 2401 5.2.1 steps 3 and 4 (SPD look up and policy check). Same for other "from" 6.x. (note: I propose to call step 4 "IPsec post-processing") - same (6.2) Add a step 6 for updating for the SPD and SAD according to the new care-of address or to the return to home. - 6.5 Home Test Init to the Home Agent I totally disagree about the step 2! And the MIPv6 draft 21 section 11.3.2 too, or 6.13 is wrong! IMHO IPsec policy is checked first for common packets and there is no need at all to make an exception for RR signaling. - same (6.5) Step 5 has no sense: the IPsec policy is look up once, cf RFC 2401 section 5.1.1. - 6.7 Home Test to the Mobile Node Same concern about Steps 2 and 5. - 6.17 Establishing New Security Associations Add a comment about the phase 2 identities, explaining they are traffic selectors. - 6.18 Rekeying Security Associations Note the HA can't be the initiator for BU/BA SAs, it should never be a problem but we should note the point because some implementations can have a passive flag per policy (racoon has one per peer address). - 6.19 Movements and Dynamic Keying We may explain that because the step 5 is after the step 4, the HA can be the iniator. I let you judge: if my reasonning is not obvious, add this clarification. - same (6.19) In step 8, the corresponding SPD entries must be updated too and IKE must be warned of the update (what is not (yet) done by KAME). - same (6.19) and establish a new IKE phase 1 -> and will establish ... (i.e., the re-establishment should be done "on demand") - 7. Implementation Considerations Again "gateway address"... BTW *never* use a term from a particular implementation, I know several implementations and the only frequent choices are terribly bad (like tunnel for SA). Please stay in RFC 2401! - same (7) "modification of the packet after it has gone through IPsec processing" So Koh, you are conformant! - same (7) We have chosen to require policy entries that are specific to a tunnel interface. This means that implementations have to regard the Home Agent - Mobile Node tunnel as a separate interface on which IPsec SPDs can be based. I deeply disagree about this requirement. Note that a transport mode over an IPv6-IPv6 tunnel is not equivalent, for instance it supports only the case where X = any in payload (i.e., routing has less selection/filtering capabilities than IPsec). ---------------- Jari Arkko responds to Francis Dupont: Thank you Francis for your comments, I was able to make a lot of fixes in the draft due to these. However, as far as the per-tunnel-interface policies go, I'm not sure what else we can do? Do you have an alternative -- you are not the only one complaining about BITS. But without an alternative the complaints are not very useful. Secondly, unless you have noticed we are past all last calls, and this discussion is a very late one!!! > In your previous mail you wrote: > > Hmm... actually I think what you had in terms of everything else than > the address for IKE was ok. According to ha-ipsec Section 4.3 home > agents are required to update the outer destination of the packets > that eventually go out on the wire to the current care-of address. > This is independent of the K bit. > => BTW the term used by the draft is incorrect (i.e., there is no > "gateway" address in IPsec). Done. > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I've just reread draft-ietf-mobileip-mipv6-ha-ipsec-04.txt: > > - 1. Introduction > ... A care-of address is > an IP address associated with a mobile node that has the subnet > prefix of a particular foreign link. ^^^ > > s/the/a/ hmm... I think not. > - 3.1 Binding Updates and Acknowledgements > Note that the home address is not cryptographically protected but > a bad home address can't be used because of the check on addresses > of IPsec incoming processing (i.e., it is an ACL-like protection > done by the traffic selectors). IMHO this is not an issue but > this point should be made clearer. Added a sentence about this. > - 3.2 Return Routability Signaling > s/gateway address[es]/outer header address[es]/g > (for IKE the proper term is "peer address[es]" but RFC 2401 just talks > about outer header) > s/tunnel gateway address/tunnel endpoint address/g > > (note: "g" because there are many occurrences) Ok. > - same (3.2) > ... When the mobile > node adopts a new care-of address, its source address selection rules > will automatically adopt a new source address for outgoing tunnel > packets. > > this is 100% wrong because IPsec doesn't use the source address > selection rules: the endpoint addresses are SA parameters. We can't > rely on the address selection: we have to enforce the same address > than given by applying the address selection rules. This is not the way at least all implementations work. Perhaps those implementations are bad, but I also can't find the source address from 4.4.3 of RFC 2401. > - same (3.2) > (The home agent accepts packets sent like this, as the > outer source address in tunnel packets is not checked.) > > this is a wrong assumption because if the RFC 2401 explains why > it should not be checked, many real world implementations check it... > In fact, it works only because of the 4.3 HA requirement. I don't think I'm going to change anything if RFC 2401 is in line with what we write. > - same (3.2) (typo/improvement) > ... on top of its then current care-of address > ^ ? Fixed. > addresses as IKE was transported on. > (from IKEv2 draft: s/was transported on/ran over/ Ok. > - 4.1 Mandatory Support > I don't understand different requirements for "supported" and "used": > if the "supported" requirement means we have to implement it then > when we decide to not use something we don't need to implement it... > For instance, what to do exactly for prefix discovery (which is > painful to implement without any real world utility)? Agree about prefix discovery. But no use in arguing about it now. I think the supported/used requirements are quite clear: "supported" means that you must (or should or may) implement them, while "used" means that you must (or should or may) actually use them for the given task i.e. configure them on. > - 4.2 Policy Requirements > ... for the tunnel interface between ... > > No, we can't assume the IPsec implementation uses interfaces for > IPsec tunnels! Please use a wording which works for every choices > of implementation (i.e., both for "interface" and for "policy"). Do you have a suggestion? > - same (4.2) (typo) > > prefix discovery SHOULD not be deleted as they do not depend on > > s/not/NOT/ Ok. > - 4.3 IPsec Protocol Processing (typo) > A non-null encryption transform and authentication > > Either "Non-null ..." or "... and an authentication"? Fixed. > - same (4.3) > MUST be supported and SHOULD be used (same concern than in 4.1) > > - same (4.3) > It seems the current proposal is to update the SPD/SADB from the > mobility code: > - of course this is more efficient than to rekey via IKE > - I am afraid this is not implementable with every IPsec, for > instance with BITW or BITS... We should look at this issue > before or during the IETF last call. We are past any last calls now! In fact, I have precisely *today* for making modifications before we try to get it approved as an RFC in IESG. > - this restricts the K bit to the peer address update of IKE > session only: > * not very useful for pure IKEv1 with the use of very short > IKE sessions I don't believe this is a very useful IKE usage, and does not appear to be at least very wide spread in implementations. > * not compatible with your (:-) peer address update proposal > for IKEv2 (only the IKE SA needs to be updated: IPsec SAs > it manages are updated directly by the mobility code)! This may be a better reason But hmmm... I'm not really sure it is incompatible. First of all, as you know it didn't get approved for IKEv2 so we don't know what the final solution will be. But lets assume it will update both IKE and IPsec endpoints. At this time, we can't make an IKEv2 spec for MIPv6. When IKEv2 comes out, and if there's interest, we can publish an IKEv2-for-MIPv6 document, and this can take care of who updates what. > - 4.4 Dynamic Keying > o Conversely, the IPsec security associations with the mobile node's > home agent MUST be requested from the key management protocol with > the home address as the mobile node's address. > > This has no sense because there are many (zero to four) addresses > in an IPsec SA. We have to specify in each case the MN address in > the traffic selector and for tunnel mode SA the endpoint address. > So this alinea must be completely rewritten... -05 has already done this change. you may want to take a look to make sure its right. > - same (4.4) (improvements) > s/IKE endpoints/IKE peer addresses/g I think we have chosen the endpoint terminology, and I would not like to change that. > - same (4.4) > if rekeying is needed. (twice) > > the term is not good because IKEv1 has no ISAKMP SA rekeying. > For some implementations the session has to be closed and reopened, > for some others nothing is needed because the last seen peer address > is used (i.e., IKEv1 implementations are not flexible enough or are > insecure . Fixed. "... if IKE phase 1 has to be re-established". > - 5.1 Format > SA entries should get an outer source parameter too, not only an > outer destination parameter. Note this is important for manual > keying because with automatic keying SAs come by pair. I'd rather not put the full contents of the SADB in the document, IMHO its sufficient with the "important" parameters. > - same (5.1) (note) > The name of the SA database is the SADB in many texts (but not > the RFC 2401 so we can keep SPD/SAD). Ok no change then. > - 5.2.2 Return Routability Signaling > Same concern about the tunnel interface, but here this can be solved > by a simple warning at the beginning ("interface" choice = same text, > "policy" choice = any interface (MN) or home link (HA)). > Of course, the interpretation of traffic selectors by interface is > hairy when IPsec tunnels are interfaces so IMHO the best is to reverse > the assumption about the choice (but keep a warning) and to remove > the interface stuff in the SPDs. I seem to recall that the reason we have the interface stuff is that you wanted to have optimized packet formats (no extra HAO)? Perhaps I don't remember this right. Anyway, if that hadn't been required, we could have made the policy entries match on tunnel packets MN->HA. As it stands now, the interface is absolutely needed, because otherwise the policy rule would match all MH packets, even those sent to CNs... > - same (5.2.2) > The MN tunnel endpoint address is the primary care-of, not the > home address, so : > > mobile node SAD: > - SA4(IN, spi_d, home_address_1, ESP, TUNNEL): > > and > > home agent SAD: > - SA4(OUT, spi_d, home_address_1, ESP, TUNNEL): > > are WRONG! I fixed this, and added an explanation that when the SAD/SPD is controlled by the mobility code, the care-of addresses change. (They can be initialized to home addresses.) > - 5.2.3 Prefix Discovery > we should add a warning explaining we don't assume a fine selection > on the type and code of ICMPv6, so all ICMPv6 are selected in place > of only the prefix discovery messages. > > Note that the SPDs described above protect all ICMPv6 traffic between > the mobile node and the home agent. > > => move this at the beginning (because it is a consequence of the > assumption). Ok, thanks. > - 5.2.4 Payload Packets > Same tunnel interface concern (and again packets go through the tunnel > if they use the interface . > > - same (5.2.4) > If the protocol is Any (in place of X) the 5.2.2 (RR protection) > is no more needed. Please be a bit more clearer about this. Hmm... I think it is obvious from the precendence discussion. > - same (5.2.4) > SA8s must use the primary care-of address, not the home address. Fixed. > - same (5.2.4) > In this > case the source and destination can be left as a wildcard and the SPD > entries will work solely based on the used interface and the > protocol, which is ICMPv6 for both MLDv1 and MLDv2. > > this doesn't work if the IPsec tunnel is not an interface. > > - same (5.2.4) > It is therefore useful to avoid setting > the protocol X in the above entries to either AH or ESP. > > It is not possible to set the protocol X to something which is not > an "upper layer" protocol, so this issue doesn't exist. I think this still clarifies the situation. Actually, we got a request to make this clear. > - 5.3.1 Binding Updates and Acknowledgements > The HA can't be the initiator, so we should specify it runs in > the "passive" mode. Note this is true only for BU/BA. I don't recall a passive mode term in IKE documentation. > - 5.3.2 Return Routability Signaling > Same concern about the tunnel interface... > > - same (5.3.2) > s/gameway/XXX endpoint address/ > > - same (5.3.2) > > ... In order to avoid writing dynamically changing information > to the SPD entries, the above has been written with the home address > as the gateway. > > Note this assumes the SPD is updated at the reception of the home > registration BU before a phase 2 is launched to setup the tunnel. > And this assumes too the implementation has a way to recognize > the entries without using the MN endpoint address. > BTW the wording is poor: we should explain the SPD will be updated > by the mobility code and we only put an initial value. Fixed. > - 6.2 Binding Update from the Mobile Node > Step 4 must include RFC 2401 5.2.1 steps 3 and 4 (SPD look up > and policy check). Same for other "from" 6.x. > (note: I propose to call step 4 "IPsec post-processing") Reformulated. > - same (6.2) > Add a step 6 for updating for the SPD and SAD according to the > new care-of address or to the return to home. Ok. > - 6.5 Home Test Init to the Home Agent > I totally disagree about the step 2! And the MIPv6 draft 21 > section 11.3.2 too, or 6.13 is wrong! > IMHO IPsec policy is checked first for common packets and > there is no need at all to make an exception for RR signaling. I ack you concern about interfaces, but I don't understand what the other issues here are. > - same (6.5) > Step 5 has no sense: the IPsec policy is look up once, cf RFC 2401 > section 5.1.1. Reformulated. > - 6.7 Home Test to the Mobile Node > Same concern about Steps 2 and 5. Step 5 fixed. > - 6.17 Establishing New Security Associations > Add a comment about the phase 2 identities, explaining they are > traffic selectors. Ok. > - 6.18 Rekeying Security Associations > Note the HA can't be the initiator for BU/BA SAs, it should never > be a problem but we should note the point because some implementations > can have a passive flag per policy (racoon has one per peer address). Again, this is not a standard term so I'd rather avoid it. Ah, now I think I know what you mean: you are talking about responder vs. initiator. I'll add some text about this. > - 6.19 Movements and Dynamic Keying > We may explain that because the step 5 is after the step 4, the HA > can be the iniator. I let you judge: if my reasonning is not obvious, > add this clarification. Ok. > - same (6.19) > In step 8, the corresponding SPD entries must be updated too and > IKE must be warned of the update (what is not (yet) done by KAME). I'm not sure we need an SPD entry update. > - same (6.19) > and establish a new IKE phase 1 -> and will establish ... > > (i.e., the re-establishment should be done "on demand") Ok. > - 7. Implementation Considerations > Again "gateway address"... BTW *never* use a term from a particular > implementation, I know several implementations and the only frequent > choices are terribly bad (like tunnel for SA). Please stay in RFC 2401! Fixed. > - same (7) > "modification of the packet after it has gone through IPsec processing" > > So Koh, you are conformant! > > - same (7) > We have chosen to require policy entries that are specific to a > tunnel interface. This means that implementations have to regard the > Home Agent - Mobile Node tunnel as a separate interface on which > IPsec SPDs can be based. > > I deeply disagree about this requirement. > Note that a transport mode over an IPv6-IPv6 tunnel is not equivalent, > for instance it supports only the case where X = any in payload > (i.e., routing has less selection/filtering capabilities than IPsec). It would be good if you could come up with an alternative. Though this discussion is taking place way way too late! ---------------- Vijay Devarapalli responds to Francis Dupont: > - of course this is more efficient than to rekey via IKE > - I am afraid this is not implementable with every IPsec, for > instance with BITW or BITS... We should look at this issue > before or during the IETF last call. lets not worry about BITS or BITW IPsec implementations for now. with a BITW IPsec implementation, even SPD lookup does not work properly. the lookup is done on the wrong address. lets assume the HA is sending a packet with a routing header type 2. when the BITW implementation traps the packet the destination address on the packet will be the CoA and not the HoA. similarly for incoming packet if the packet is trapped by a BITW IPsec implementation the selector match will be done on the wrong source address. the packet still contains the CoA as the source address because the home address option has not been processed yet. > - 4.2 Policy Requirements > ... for the tunnel interface between ... > > No, we can't assume the IPsec implementation uses interfaces for > IPsec tunnels! Please use a wording which works for every choices > of implementation (i.e., both for "interface" and for "policy"). > > - same (7) > We have chosen to require policy entries that are specific to a > tunnel interface. This means that implementations have to regard the > Home Agent - Mobile Node tunnel as a separate interface on which > IPsec SPDs can be based. > > I deeply disagree about this requirement. > Note that a transport mode over an IPv6-IPv6 tunnel is not equivalent, > for instance it supports only the case where X = any in payload > (i.e., routing has less selection/filtering capabilities than IPsec). I dont really understand your disagreement. you were the strongest proponent for the optimized format, which meant using IPsec tunnels rather than MIPv6 tunnels. we basically replaced MIPv6 tunnels by IPsec tunnels. the requirement you refer to here has existed since the first draft version. it has now gone through WG last call, IETF last call and IESG review. moreover RFC 2401 talks about enabling IPsec per interface and having SPD and SAD per interface. we are just treating the tunnel between the MN and the HA as a tunnel interface, so that we can define the SPD entries per interface. IMO, implementations are free to use whatever mechanism to produce the desired behavior. the most important thing is on-the-wire format. ---------------- Gabriel Montenegro writes; Guys, please fix the nits. As for more substantial comments, I agree, it *is* way tooooo late (IETF LC was over in March!) so let's concentrate on fixing stuff for IESG. These comments are great to keep for the next document after this one ships. ---------------- Francis Dupont responds to Jari Arkko: Thank you Francis for your comments, I was able to make a lot of fixes in the draft due to these. However, as far as the per-tunnel-interface policies go, I'm not sure what else we can do? => one can read the current specified SPD as: if you use the tunnel then use it... IMHO the best is to ask an implementor using interface per tunnel SA in all cases how to express the SPD in a compatible way. A message in the IPsec WG list should be enough? Another idea: ask our "security advisor"! Do you have an alternative -- you are not the only one complaining about BITS. But without an alternative the complaints are not very useful. => at least we can explain there is a choice and for simplicity we assume one. Secondly, unless you have noticed we are past all last calls, and this discussion is a very late one!!! => "I'll believe in it when I'll be able to see it"... As it is not yet published as an RFC we can still get comments from IESG & co. And even a published RFC can be a candidate for improvements. > - 1. Introduction > ... A care-of address is > an IP address associated with a mobile node that has the subnet > prefix of a particular foreign link. ^^^ > > s/the/a/ hmm... I think not. => there can (in fact should) be more than one subnet prefix. IMHO the "the" here is wrong and not compatible with the "A" of the care-of address, nor with the "a" of the foreign link. > - same (3.2) > ... When the mobile > node adopts a new care-of address, its source address selection rules > will automatically adopt a new source address for outgoing tunnel > packets. > > this is 100% wrong because IPsec doesn't use the source address > selection rules: the endpoint addresses are SA parameters. We can't > rely on the address selection: we have to enforce the same address > than given by applying the address selection rules. This is not the way at least all implementations work. Perhaps those implementations are bad, but I also can't find the source address from 4.4.3 of RFC 2401. => it is in 5.1.2 of RFC 2401 and its note 3 which of course is ambiguous: 3. src and dest addresses depend on the SA, which is used to determine the dest address which in turn determines which src address (net interface) is used to forward the packet. As usual when IKE is used there is less freedom and both source and destination endpoint addresses are SA parameters. So one can't say an implementation which uses the standard source address selection for each packets is not conformant, but at least such implementation can't support IKE... > - same (3.2) > (The home agent accepts packets sent like this, as the > outer source address in tunnel packets is not checked.) > > this is a wrong assumption because if the RFC 2401 explains why > it should not be checked, many real world implementations check it... > In fact, it works only because of the 4.3 HA requirement. I don't think I'm going to change anything if RFC 2401 is in line with what we write. => as it is a point where real world implementations don't always follow RFC 2401, at least the word "is" is not right, i.e., we should stress there can be an issue. > - this restricts the K bit to the peer address update of IKE > session only: > * not very useful for pure IKEv1 with the use of very short > IKE sessions I don't believe this is a very useful IKE usage, and does not appear to be at least very wide spread in implementations. => I don't understand your answer... It seems we agree? > * not compatible with your (:-) peer address update proposal > for IKEv2 (only the IKE SA needs to be updated: IPsec SAs > it manages are updated directly by the mobility code)! This may be a better reason But hmmm... I'm not really sure it is incompatible. => I am sure: you need a way to specify which IKE/IPsec SAs to update, my proposal has this, yours not. First of all, as you know it didn't get approved for IKEv2 => none. so we don't know what the final solution will be. => but we should add in requirements of the future peer address update mechanism fine granularity support. At this time, we can't make an IKEv2 spec for MIPv6. When IKEv2 comes out, and if there's interest, we can publish an IKEv2-for-MIPv6 document, and this can take care of who updates what. => I disagree: the mobility code should not behave differently according of what version of IKE (in an user mode process, perhaps dynamically negociated, etc). SPD and IPsec SAs are updated by the kernel mobility code, the IKE SA should be updated by it or by IKE itself following the K bit (which becomes useful . Your only chance to save your proposal is its current form is to make the K bit stuff mandatory, killing the peer address update for mobility! > - 4.4 Dynamic Keying > o Conversely, the IPsec security associations with the mobile node's > home agent MUST be requested from the key management protocol with > the home address as the mobile node's address. > > This has no sense because there are many (zero to four) addresses > in an IPsec SA. We have to specify in each case the MN address in > the traffic selector and for tunnel mode SA the endpoint address. > So this alinea must be completely rewritten... -05 has already done this change. you may want to take a look to make sure its right. => I'll look at it as soon as my mirror will get it. > - 5.2.2 Return Routability Signaling > Same concern about the tunnel interface, but here this can be solved > by a simple warning at the beginning ("interface" choice = same text, > "policy" choice = any interface (MN) or home link (HA)). > Of course, the interpretation of traffic selectors by interface is > hairy when IPsec tunnels are interfaces so IMHO the best is to reverse > the assumption about the choice (but keep a warning) and to remove > the interface stuff in the SPDs. I seem to recall that the reason we have the interface stuff is that you wanted to have optimized packet formats (no extra HAO)? Perhaps I don't remember this right. => optimized packet formats have nothing to do with interface/policy. I asked whether the MN-HA IPsec tunnel is or is not an interface as it is a question without good answer. As an implementor I believe in this case an interface is better but in the current presentation there is a collision between IPsec and mobility which can be avoided using policies... Anyway, if that hadn't been required, we could have made the policy entries match on tunnel packets MN->HA. As it stands now, the interface is absolutely needed, because otherwise the policy rule would match all MH packets, even those sent to CNs... => I don't buy this argument: we are about MN-HA and the fact that MH packets directly sent to CNs need specific SPD entries is out of scope. > - same (5.2.2) > The MN tunnel endpoint address is the primary care-of, not the > home address, so : > > mobile node SAD: > - SA4(IN, spi_d, home_address_1, ESP, TUNNEL): > > and > > home agent SAD: > - SA4(OUT, spi_d, home_address_1, ESP, TUNNEL): > > are WRONG! I fixed this, and added an explanation that when the SAD/SPD is controlled by the mobility code, the care-of addresses change. (They can be initialized to home addresses.) => fine! > - 5.3.1 Binding Updates and Acknowledgements > The HA can't be the initiator, so we should specify it runs in > the "passive" mode. Note this is true only for BU/BA. I don't recall a passive mode term in IKE documentation. => I agree, this is not in IKEv2 too but is a common concept... I don't know whether we should clarify or not. > - 6.5 Home Test Init to the Home Agent > I totally disagree about the step 2! And the MIPv6 draft 21 > section 11.3.2 too, or 6.13 is wrong! > IMHO IPsec policy is checked first for common packets and > there is no need at all to make an exception for RR signaling. I ack you concern about interfaces, but I don't understand what the other issues here are. => 6.13 with X=any and draft 21 11.3.2 are not compatible. > - 6.18 Rekeying Security Associations > Note the HA can't be the initiator for BU/BA SAs, it should never > be a problem but we should note the point because some implementations > can have a passive flag per policy (racoon has one per peer address). Again, this is not a standard term so I'd rather avoid it. Ah, now I think I know what you mean: you are talking about responder vs. initiator. I'll add some text about this. => yes, the initiator needs to know the address to use to reach the other peer. Usually it finds it in the SPD and when it is not in it (common case with road warriors, here with the policy of BU/BA) it can't take the initiator role. > - same (6.19) > In step 8, the corresponding SPD entries must be updated too and > IKE must be warned of the update (what is not (yet) done by KAME). I'm not sure we need an SPD entry update. => the address of the other peer/endpoint is a SPD entry parameter so the SPD must be updated. Note that even your SPD is not a real one, you have this info in it. > - same (7) > "modification of the packet after it has gone through IPsec processing" > > So Koh, you are conformant! > > - same (7) > We have chosen to require policy entries that are specific to a > tunnel interface. This means that implementations have to regard the > Home Agent - Mobile Node tunnel as a separate interface on which > IPsec SPDs can be based. > > I deeply disagree about this requirement. > Note that a transport mode over an IPv6-IPv6 tunnel is not equivalent, > for instance it supports only the case where X = any in payload > (i.e., routing has less selection/filtering capabilities than IPsec). It would be good if you could come up with an alternative. Though this discussion is taking place way way too late! => IMHO the best is to give the issue to IPsec people via our security advisor. I don't believe we can keep the current text because it is not compatible with the mobile IPv6 draft which clearly specifies that IPsec policy lookup is done before the mobility stuff, at least for ordinary packets (including MH packets through HA to MN). Another point is very unclear in the currect draft: the mobility MN-HA tunnel is an interface, is it a different interface? ---------------- Francis Dupont responds to Jari Arkko: I dont really understand your disagreement. you were the strongest proponent for the optimized format, which meant using IPsec tunnels rather than MIPv6 tunnels. we basically replaced MIPv6 tunnels by IPsec tunnels. => this has nothing to do with the interface/policy choice of implementation. the requirement you refer to here has existed since the first draft version. => no, I never got an answer about my question so it was not from the first version. it has now gone through WG last call, IETF last call and IESG review. => and how many implementations are available? I'm afraid we'll get a second round from implementors which are trying to adapt existing IPsec/IKE implementations to the current specs. moreover RFC 2401 talks about enabling IPsec per interface and having SPD and SAD per interface. => to apply a SPD to a tunnel interface doesn't give what you want: the traffic selectors are for the visible part of packets, i.e., outer headers, so the only protocol will be 41... In fact, the only useful policy is to add a transport mode (cf Touch's VPN draft and zillions of messages about this in IPsec lists). we are just treating the tunnel between the MN and the HA as a tunnel interface, so that we can define the SPD entries per interface. => I agree that the mobility tunnel between the MN and the HA is an interface but not about the mandatory choice that the IPsec tunnel between the MN and the HA is an interface. And even it is an interface you can't apply the SPD to it, RFC 2401 is very clear about this. IMO, implementations are free to use whatever mechanism to produce the desired behavior. the most important thing is on-the-wire format. => I agree but as most sections of the draft are an example of how to do, it should be better to have an example which can work... IMHO it will be very dangerous to get only special for Mobile IPv6 IPsec implementations, the first consequence will be a very long delay before IKE support, i.e., deployable and interoperable products. ---------------- Jari Arkko responds to Vijay Devarapalli: > with a BITW IPsec implementation, even SPD lookup does not work > properly. the lookup is done on the wrong address. lets assume the > HA is sending a packet with a routing header type 2. when the BITW > implementation traps the packet the destination address on the > packet will be the CoA and not the HoA. But that issue appears to be easily fixed by the BITW implementation, right? I mean it can recognize RH2 and HAO. > the requirement you refer to here has existed since the first draft version. it has now gone through WG last call, > IETF last call and IESG review. > > moreover RFC 2401 talks about enabling IPsec per interface > and having SPD and SAD per interface. > > we are just treating the tunnel between the MN and the HA > as a tunnel interface, so that we can define the SPD entries > per interface. IMO, implementations are free to use whatever > mechanism to produce the desired behavior. the most important > thing is on-the-wire format. Agree. By the way, I thought about the reasons why we have per-tunnel interface SPD entries. This has to do more with granularity of protection, I think, than with Francis' desire for optimized on the wire format. At least if you interpret IPv6 encapsulation as a transport protocol in RFC 2401 sense. If we don't have per-tunnel interface SPD entries, then MH messages sent directly to CNs look similar to RR messages sent via the home agent, leading to an attempt to use ipsec for all MH messages sent to the CNs. Clearly, this won't work. Alternatively, we could turn on ESP for all MN->HA tunnel packets, but this might cause too much overhead... ---------------- Gabriel Montenegro responds to Francis Dupont: >> => one can read the current specified SPD as: if you use the tunnel >> then use it... IMHO the best is to ask an implementor using interface >> per tunnel SA in all cases how to express the SPD in a compatible way. >> A message in the IPsec WG list should be enough? Another idea: ask >> our "security advisor"! Isn't this from 10.4.6 in the base mipv6 draft enough for now?: The security policy database entries MUST be defined as if they were specifically for the tunnel interface between the mobile node and the home agent. I thought we had enough weasel wording like the above already in place. Not sure if I saw the equivalent in the ha-ipsec draft, perhaps just add something to that effect and be done with it? Or is there anything *broken*? ---------------- Jari Arkko responds to Francis Dupont: > => I agree that the mobility tunnel between the MN and the HA > is an interface but not about the mandatory choice that the > IPsec tunnel between the MN and the HA is an interface. > And even it is an interface you can't apply the SPD to it, > RFC 2401 is very clear about this. There must be some misunderstanding here. I think what we are requiring is that the mobility tunnel to the HA should be an interface, and that it should have specific SPD entries to it. We don't claim that the IPsec tunnel is an interface, and we don't require nested application of IPsec. ---------------- Jari Arkko responds to Gabriel Montenegro: > Isn't this from 10.4.6 in the base mipv6 draft enough for now?: > > The security policy database entries MUST be defined as if they were > specifically for the tunnel interface between the mobile node and the > home agent. > > I thought we had enough weasel wording like the above already in place. > Not sure if I saw the equivalent in the ha-ipsec draft, perhaps just add > something to that effect and be done with it? There is equivalent wording, but I think Francis understands the tunnel interface as the IPsec tunnel interface, which is not the case. So I'll add "... IPv6 encapsulated tunnel interface ...". And clarify this in the example configs section too. > Or is there anything *broken*? According to the specs, we are fine for this issue. Implementation wise... not all implementations might support tunnel -intterface specific SPD entries. Tough, a modif is needed. ---------------- Francis Dupont responds to Jari Arkko: I think what we are requiring is that the mobility tunnel to the HA should be an interface, => I agree with this part and that it should have specific SPD entries to it. => but not with this one because if this SPD can use only the outer header. We don't claim that the IPsec tunnel is an interface, => the tunnel interface is not specified to be a mobility or an IPsec one. and we don't require nested application of IPsec. Did I miss something? => an implementation example from an existing IPv6/IPsec/IKE stack. As it is specified today I claim that it is not implementable. ---------------- Jari Arkko responds to Francis Dupont: > => the tunnel interface is not specified to be a mobility or an IPsec one. Now it is. ---------------- Jari Arkko responds to Francis Dupont: > => one can read the current specified SPD as: if you use the tunnel > then use it... IMHO the best is to ask an implementor using interface > per tunnel SA in all cases how to express the SPD in a compatible way. > A message in the IPsec WG list should be enough? Another idea: ask > our "security advisor"! I don't think we can expect a magic solution to this problem. We already know what expressive power SPD has and does not have. I don't see anyone coming to us and saying that doing it in a specific new way will solve the problem. Actually, the only practical alternatives appear to be: - per-interface SPD entries; according to the RFCs but I agree a stretch for at least some implementations - on/off Ipsec for the tunnel to the home agent. I.e. SPD entries match the tunnel packets. A significant simplification, but may cause performance issues. - scrapping Ipsec and reverting to an apps layer solution (which would at the same time be used to provide a better solution for dynamic home address, prefix, and home agent address generation). My preference is that we publish the RFC with solution 1 now and use the next year (or more) to work on solution 3. ---------------- Jari Arkko responds to Francis Dupont: > => one can read the current specified SPD as: if you use the tunnel > then use it... IMHO the best is to ask an implementor using interface > per tunnel SA in all cases how to express the SPD in a compatible way. > A message in the IPsec WG list should be enough? Another idea: ask > our "security advisor"! Would you be happy with a formulation that leaves this open to implementations? "... must treat MH messages entering the tunnel differently from MH messages sent to others, as if the SPD were specific to the tunnel interface ..."? (Francis, I don't think there is a compatible standard way to represent this. But if you think there is please tell me.) > > - 1. Introduction > > ... A care-of address is > > an IP address associated with a mobile node that has the subnet > > prefix of a particular foreign link. ^^^ > > > s/the/a/ > hmm... I think not. > => there can (in fact should) be more than one subnet prefix. > IMHO the "the" here is wrong and not compatible with the "A" of the > care-of address, nor with the "a" of the foreign link. Ah, now I see what you mean. > > - same (3.2) > > ... When the mobile > > node adopts a new care-of address, its source address selection rules > > will automatically adopt a new source address for outgoing tunnel > > packets. > > > this is 100% wrong because IPsec doesn't use the source address > > selection rules: the endpoint addresses are SA parameters. We can't > > rely on the address selection: we have to enforce the same address > > than given by applying the address selection rules. > This is not the way at least all implementations work. Perhaps > those implementations are bad, but I also can't find the source > address from 4.4.3 of RFC 2401. > => it is in 5.1.2 of RFC 2401 and its note 3 which of course is > ambiguous: > > 3. src and dest addresses depend on the SA, which is used to > determine the dest address which in turn determines which src > address (net interface) is used to forward the packet. > > As usual when IKE is used there is less freedom and both source > and destination endpoint addresses are SA parameters. So one can't > say an implementation which uses the standard source address selection > for each packets is not conformant, but at least such implementation > can't support IKE... Ok. I have formulated the text now so that it changes both addresses. > > - same (3.2) > > (The home agent accepts packets sent like this, as the > > outer source address in tunnel packets is not checked.) > > > this is a wrong assumption because if the RFC 2401 explains why > > it should not be checked, many real world implementations check it... > > In fact, it works only because of the 4.3 HA requirement. > I don't think I'm going to change anything if RFC 2401 is in line > with what we write. > => as it is a point where real world implementations don't always > follow RFC 2401, at least the word "is" is not right, i.e., we > should stress there can be an issue. Ok. I added a note about this. > At this time, we can't make an IKEv2 spec for MIPv6. When IKEv2 > comes out, and if there's interest, we can publish an IKEv2-for-MIPv6 > document, and this can take care of who updates what. > => I disagree: the mobility code should not behave differently according > of what version of IKE (in an user mode process, perhaps dynamically > negociated, etc). SPD and IPsec SAs are updated by the kernel mobility > code, the IKE SA should be updated by it or by IKE itself following > the K bit (which becomes useful . > Your only chance to save your proposal is its current form is to make > the K bit stuff mandatory, killing the peer address update for mobility! I continue to hold the opinion that we won't be able to specify how everything works with IKEv2. In an ideal world, all things are nicely separated. But in reality they are not. Lets defer that at least to a future spec. So, if we can agree on that then it becomes much easier to discuss about the specifics of the future IKEv2 address agility feature. In fact, the main reason that I haven't commented much your proposal and preferred our proposal at the IPSEC WG was that I didn't have time to understand in detail what you wanted to do. Now that the feature is out of ikev2 release 1, we have much more time to agree. I don't want to be held to our old proposal, if other proposals are better. You make a good argument above for your proposal. Lets talk about that. Later. > -05 has already done this change. you may want to take a look > to make sure its right. > => I'll look at it as soon as my mirror will get it. Its submission is pending the end of this discussion. But its available at http://www.piuha.net/~jarkko/publications/mipv6/drafts/drafts.html > => optimized packet formats have nothing to do with interface/policy. I agree, see my earlier e-mail. > => I don't buy this argument: we are about MN-HA and the fact that > MH packets directly sent to CNs need specific SPD entries is out of > scope. It still needs to work and not break other stuff. So a solution which would kill RO towards CN is imho not acceptable. And it would kill RO because the MHs would be expected to be encrypted and there'd be no keys between the CNs and the MNs. > > - same (6.19) > > In step 8, the corresponding SPD entries must be updated too and > > IKE must be warned of the update (what is not (yet) done by KAME). > I'm not sure we need an SPD entry update. > => the address of the other peer/endpoint is a SPD entry parameter so > the SPD must be updated. Note that even your SPD is not a real one, > you have this info in it. The question is whether the information is used. If I understand 2401 correctly the GW address in the SPD is not looked at upon processing packets by an existing SA. ---------------- Gabriel Montenegro writes: Short question: Is anything *broken*? This does not include stuff we knew about which may be offensive to someone's taste or somewhat displeasing. We're beyond that point, all LC's are over. At this point: is there anything *broken*? If not, we're departing from procedure by even considering anything but option 1 above. Am I missing something? To repeat the obvious: any delay in this draft imposes an equivalent delay in the base mipv6 draft, because of the normative reference. ---------------- Basavaraj Patil writes: As Gabriel has also asked in his earlier email, the question to ask or actually the only question to ask at this time is: Is the current solution proposed in the MIPv6 base and MN-HA IPsec drafts broken? If not, there is no point in continuing this discussion. Better solutions or tweaks to IPsec policies etc. can come later. The charters for the new WGs clearly indicates that this is something we will take up in the new WGs. And we also now have the help of Radia Perlman which will go a long way in dealing with the IPsec WGs and the security mafia. Hence at this time, unless the answer is that the solution as it exists now in the current drafts is broken and JUST WONT WORK, I would agree with Gabriel and go forward with the recommendation made by Jari below. ---------------- Jari Arkko responds to Gabriel Montenegro: > To repeat the obvious: any delay in this draft imposes an equivalent delay > in the base mipv6 draft, because of the normative reference. Here's what I'd like to do: - fix the specific text problems that francis reported - stick to earlier agreed upon per-interface SPD requirement - stick to not-perfect-fit for BITS implementations per earlier agreement - avoid any IKEv2 considerations - publish the document on Friday Note that even with the BITS issues, it seems per my note and Vijay's confirmation that even a BITS implementation is possible. And not even extremely complicated, in the order of handling fragmentation or ICMPs that they already are doing. So no real brokeness here. Obviously IKEv2 could mean impacts. And IKEv3, but we are going to deal with those later I *wish* I had another option than the per-interface SPD requirement. But I don't, and its wishful thinking that anyone else is going to tell us how to do it. So we are going to have to stick with that as well. ---------------- Jari Arkko writes: This note describes how to implement MIPv6 specific processing on Bumb-in-the-Stack (BITS) IPsec implementation. The note concentrates only on the manual keying case. Tasks: 1. IPsec processing of regular route optimized packets to CNs Outgoing packets: o recognize hao/rh packets o transform back to plain form o IPsec processing o if original ip adresses remain, reapply hao/rh2 Incoming packets: o recognize hao/rh packets o transform back to plain form o IPsec processing o if original ip addresses remain, reapply hao/rh2 (But this does not make the HAO-BCE check; I don't view this as too dangerous though since its an ipsec protected packet anyway. But its a remaining issue.) 2. Protecting Binding Updates Nothing special needed here beyond what was already done for Task 1 above. Policies are set up manually as described in draft-ietf-mobileip-mipv6-ha-ipsec-nn.txt, i.e., for MH from the home address to the home agent address. 3. Protecting prefix discovery Nothing special is needed here either. Policies are setup manually for ICMPv6 for MH from the home address to the home agent address. 4. RR and payload protection This is the tricky part. There are two main issues: - recognizing which packets are going out to the HA (or MN) - updating the security associations as we move around For the first issue, it appears that the feasible techniques are adding complex APIs between the BITS and the IP stack parts to transfer this information, or recognizing packets tunneled to the HA via configuration. The configuration approach seems easier: configure the address of the home agent to the BITS implementation have it recognize IPv6-encapsulated packets to that address. On the home agent this is harder, however, but perhaps the home agent could be configured to treat any IPv6-encapsulated packet as belonging to this interface. In either direction, the inner packet and the home address appearing there would then be used to decide which SA to use. For the second issue, it appears to require an API. However, even if an implementation works as a BITS implementation, they are usually controllable in some manner. In fact, they must have a control interface as otherwise the security policies and SAs cannot be entered. The only question is whether this interface is just a GUI or also a machine-machine capable API... Personally, I don't think this is a significant requirement... all my implementations have had this type of interfaces. What is required is a capability to delete and add a SA. A non-conformant method to fix both issues is to use a more inefficient encapsulation, where *all* IPv6-encapsulated packets between the home agent and the mobile node are together either passed in the clear or IPsec protected. Conclusion: Unless I'm missing something (am I?), BITS implementations can be easily made to work with basic Mobile IPv6 MN-HA signaling as far as Binding Updates and Prefix Discovery goes. One remaining issue is that in incoming packet processing, the HAO-BCE check cannot be easily implemented, and as thus one requirement of MIPv6 base specification cannot be fullfilled. But in practise the threat is not *that* serious unless the BITS implementation supports opportunistic IPsec. Somewhat more serious problems appear when trying to protect RR signaling. These appear to be solvable, at least to an extent, with some additional BITS configuration information, and a configuration API requirement. ---------------- Santeri Paavolainen responds to Vijay Devarapalli: >this would mean the BITS implementation on the MN needs >to trap every packet with HA as the destination address >and see if it is an encapsulated packet and use the >inner packet for SPD lookup. right? Of course everything can be made to work that is in the computer, it's just a matter of programming. What does not terribly well work is hardware acceleration. Maybe in the future, but not with today's technology. What is affected that a full hardware ipsec chain processing is not possible; you have to trap into software to perform the hao/rt2 lookup (for home address), convert to "plain form", and after ipsec processing back to the old form. For incoming packets the BITS sees the SA of (dst=MN,spi=xxx,esp) as (dst=COA,spi=xxx,esp). If there is a hardware SA lookup step, then this hardware lookup table must be either a) kept up-to-date with the correct COA address (where does this address come from? read BU and keep state?) or b) have a default fall-back method other than to drop all unrecognized incoming esp/ah packets. Either way, for MIP packets the next step cannot be "proceed to transform processing", since the implementation needs to convert the packet into "plain form" before the IPSec processing. So a trap to software level is always necessary. This opens up a very nice DoS if the software step is substantially slower the the wire speed, since an attacker can just send bogus IPSec packets that have a HAO/RT2 header, since they are forced to drop into software side. An assumption here is that you can fudge an "recognize hao/rt2, fudge packet into plain form" step between NIC and IPSec processing for BITS. Oops, that's a software step, not h/w. Anyway, I know none of the issues I've written about are really any road-blocking obstacles, but they are performance-eaters for h/w implementations. (Anyway, this discussion has only touched manual keying. I am not interested in it at all. The whole "fix" here is only required because requirement of supporting manual keying for MIP. If you only use IKE then there is not really any problem, as you can always negotiate a new SA for the current CoA<->HA. In IKEv2 you'd only move the IKE phase-1 address binding without any new SA creation anyway. It would always be possible to add IKE extension for IKEv1 to support this case. IKE is anyway in software, so it is not really a problem from h/w point of view.) ---------------- Francis Dupont responds to Jari Arkko: I don't think we can expect a magic solution to this problem. => but we need a solution or we should not expect to get a HA implementation for a not-dedicated box in a reasonable delay. We already know what expressive power SPD has and does not have. I don't see anyone coming to us and saying that doing it in a specific new way will solve the problem. Actually, the only practical alternatives appear to be: - per-interface SPD entries; according to the RFCs but I agree a stretch for at least some implementations => 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 NA-MN tunnel interface. - on/off Ipsec for the tunnel to the home agent. I.e. SPD entries match the tunnel packets. A significant simplification, but may cause performance issues. => no, we don't need to throw away the mobility tunnel. - scrapping Ipsec and reverting to an apps layer solution (which would at the same time be used to provide a better solution for dynamic home address, prefix, and home agent address generation). => it should take years to get an accepted level of security with this. My preference is that we publish the RFC with solution 1 now and use the next year (or more) to work on solution 3. => I am in favor of a fixed solution 1. ---------------- Santeri Paavolainen responds to Jari Arkko: > What is affected that a full hardware ipsec chain > processing is not possible; you have to trap into software to perform > the hao/rt2 lookup (for home address), convert to "plain form", and > after ipsec processing back to the old form. Ok. Thanks for replying, I think I understand the issue better now. But today's hardware acceleration, does it support IPv6 natively? > For incoming packets the BITS sees the SA of (dst=MN,spi=xxx,esp) as > (dst=COA,spi=xxx,esp). If there is a hardware SA lookup step, then > this hardware lookup table must be either a) kept up-to-date with > the correct COA address (where does this address come from? read BU > and keep state?) or b) have a default fall-back method other than to > drop all unrecognized incoming esp/ah packets. I agree that doing the operations on the packets as they are on the wire is a non-starter. (Fixing the SA lookup does not help, as e.g. AH authenticator calculation would not succeed.) > Either way, for MIP packets the next step cannot be "proceed to > transform processing", since the implementation needs to convert the > packet into "plain form" before the IPSec processing. So a trap to > software level is always necessary. This opens up a very nice DoS if > the software step is substantially slower the the wire speed, since an > attacker can just send bogus IPSec packets that have a HAO/RT2 header, > since they are forced to drop into software side. Bounded queue etc may help here (probably same mechanisms are in use wrt other things, such as reassembly, ICMP, and IKE handling). > An assumption here is that you can fudge an "recognize hao/rt2, > fudge packet into plain form" step between NIC and IPSec processing > for BITS. Oops, that's a software step, not h/w. > > Anyway, I know none of the issues I've written about are really any > road-blocking obstacles, but they are performance-eaters for h/w > implementations. Ok. > (Anyway, this discussion has only touched manual keying. I am not > interested in it at all. The whole "fix" here is only required > because requirement of supporting manual keying for MIP. If you only > use IKE then there is not really any problem, as you can always > negotiate a new SA for the current CoA<->HA. In IKEv2 you'd only > move the IKE phase-1 address binding without any new SA creation > anyway. It would always be possible to add IKE extension for IKEv1 > to support this case. IKE is anyway in software, so it is not really > a problem from h/w point of view.) This is an interesting idea, and would work very nice from IPsec point of view. However, it does not take care of one thing, which makes it hard to adopt for HA-MN security: in this approach, IPsec and its policies would basically ignore the home addresses. However, in HA-MN security it is essential to be able to ensure that a particular user controls only his own home address, not the addresses of others. In the current solution, the SPD entries are used to ensure that the right SA is used for the right home address. In order to provide this in the CoA-based solution, we'd have to have a per-packet API from IPsec to MIPv6, to tell MIPv6 who it was that sent this BU. ---------------- Francis Dupont responds to Jari Arkko: BITS IPsec Implementation for MIPv6 => I assume this is the BITS defined in RFC 2401 3.3b (and I use as an example the Cisco VPN client for MacOS X I know well). This note describes how to implement MIPv6 specific processing on Bumb-in-the-Stack (BITS) IPsec implementation. The note concentrates only on the manual keying case. => I understand why you would not like to deal with automatic keying but only the automatic keying has an interest in the real world, i.e., nobody will use mobile IPv6 with only manual keying outside a lab. Tasks: 1. IPsec processing of regular route optimized packets to CNs Outgoing packets: o recognize hao/rh packets o transform back to plain form o IPsec processing o if original ip adresses remain, reapply hao/rh2 Incoming packets: o recognize hao/rh packets o transform back to plain form o IPsec processing o if original ip addresses remain, reapply hao/rh2 (But this does not make the HAO-BCE check; I don't view this as too dangerous though since its an ipsec protected packet anyway. But its a remaining issue.) => the HAO-BCE check is really a problem: either it is always done by the legacy stack and some legal packets are dropped, or it is never done and some illegal packets are not dropped. The easy solution is to mark packets which were protected by IPsec but usually this facility doesn't exist in BITS (so one must add it). 4. RR and payload protection This is the tricky part. There are two main issues: - recognizing which packets are going out to the HA (or MN) - updating the security associations as we move around For the first issue, it appears that the feasible techniques are adding complex APIs between the BITS and the IP stack parts to transfer this information, or recognizing packets tunneled to the HA via configuration. The configuration approach seems easier: configure the address of the home agent to the BITS implementation have it recognize IPv6-encapsulated packets to that address. => this works well if the BITS implementation looks at the internal of packets (i.e., the inner header). On the home agent this is harder, => the home agent is not supposed to run a BITS because it is a security gateway, so this issue is less important. however, but perhaps the home agent could be configured to treat any IPv6-encapsulated packet as belonging to this interface. In either direction, the inner packet and the home address appearing there would then be used to decide which SA to use. For the second issue, it appears to require an API. => another solution is to do some kind of binding update snooping. However, even if an implementation works as a BITS implementation, they are usually controllable in some manner. => yes, there is a clic-o-drome where the user can select the default config and do connect/disconnect. In fact, they must have a control interface as otherwise the security policies and SAs cannot be entered. The only question is whether this interface is just a GUI => in my example it is a GUI. or also a machine-machine capable API... => there is some kind of IKE implementation too (:-). Personally, I don't think this is a significant requirement... all my implementations have had this type of interfaces. What is required is a capability to delete and add a SA. A non-conformant method to fix both issues is to use a more inefficient encapsulation, where *all* IPv6-encapsulated packets between the home agent and the mobile node are together either passed in the clear or IPsec protected. => I have two remarks: - this method is not optimized but is conformant. In fact I believe it will be commonly used because the BITS will be an IPsec VPN client and what we suggest is just to add mobile IPv6 support to it. - this method is *not* a solution for the second issue. Conclusion: Unless I'm missing something (am I?), BITS implementations can be easily made to work with basic Mobile IPv6 MN-HA signaling as far as Binding Updates and Prefix Discovery goes. One remaining issue is that in incoming packet processing, the HAO-BCE check cannot be easily implemented, and as thus one requirement of MIPv6 base specification cannot be fullfilled. But in practise the threat is not *that* serious unless the BITS implementation supports opportunistic IPsec. => I translate this in there is no problem on MNs which don't support RO as CN. I have no concern as IMHO current RR/RO between MNs is a complete (but easy to fix) disaster. So we have the case of HAs (but HAs are SGs so don't use BITS) and CNs where we kill RR/RO (I won't cry: it is already dead). ---------------- Francis Dupont responds to Vijay Devarapalli: if the IPsec implementation is aware of home address options and routing header type 2, then ofcourse it will work. I was not assuming this. => IMHO nothing won't work if the BITS implementation won't understand mobile IPv6... I dont see it as a big issue. I have always assumed if the home address passes the selector match, then it is verified. you dont have to do a HAO-BCE check. => so any not protected packet with a HAO should be dropped: if the node is a correspondant, it won't support routing optimization. here, are you assuming the encapsulation is already done before the packet hits the BITS IPsec implementation? => if the encapsulation is not done by the BITS, this assumption is included in the BITS definition. ---------------- Jari Arkko responds to Francis Dupont: > => but we need a solution or we should not expect to get a HA > implementation for a not-dedicated box in a reasonable delay. I am sure there will be dedicated boxes in the market. For others the delay seems to exist either way; either in the form of lengthy implementation work or in the form of searching for a new solution. > We already know what expressive power SPD has and does not > have. I don't see anyone coming to us and saying that doing > it in a specific new way will solve the problem. Actually, > the only practical alternatives appear to be: > - per-interface SPD entries; according to the RFCs but > I agree a stretch for at least some implementations > > => 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 NA-MN tunnel interface. > > - on/off Ipsec for the tunnel to the home agent. > I.e. SPD entries match the tunnel packets. A significant > simplification, but may cause performance issues. > > => no, we don't need to throw away the mobility tunnel. ... > => I am in favor of a fixed solution 1. Ok, but do you have the fix? Why is the only issue the HA SPD? Wouldn't the mobile node SPD have the same issue. In either case, the nodes will be sending other MH traffic: in the case HA it could be acting as a CN as well for some other hosts, and in the case of MN it needs to talk to its CNs. If they are sending other MH traffic, how do you separate those MHs from the ones being tunneled? As far as I can see they look the same when the HAO is treated: a BU to a CN IPv6 src = coa dest = cn HAO = hoa MH a HOTI to HA IPv6 src = hoa dest = cn MH And as discussed in another thread, making IPsec operate only on the care-of addresses would require mandatory IKE and a per-packet API so that the HA could check the right user sent the BU. I'm beginning to think we should not have used IPsec on this interface. But the question is what shall we do now? Unless you have the fix (which I don't see), what is the alternative? ---------------- Jari Arkko responds to Francis Dupont: > => I understand why you would not like to deal with automatic keying > but only the automatic keying has an interest in the real world, > i.e., nobody will use mobile IPv6 with only manual keying outside > a lab. Perhaps, but most people that think IKE will solve this particular issue don't realize that they still can't set it up without per-MN configuration. The user <-> home address mapping is still needed. > => I have two remarks: > - this method is not optimized but is conformant. In fact I believe > it will be commonly used because the BITS will be an IPsec VPN client > and what we suggest is just to add mobile IPv6 support to it. > - this method is *not* a solution for the second issue. Actually, it can be. If you get a tunnel packet IPv6 src = ha dst = coa IPv6 src = x dst = hoa ULP you output it as IPv6 src = ha dst = coa HAO = hoa ESP IPv6 src = x dst = hoa ULP No need to know about the current location, because all the information is in the packet. Does require the special case and config for IPv6 encapsulation, though. > => I translate this in there is no problem on MNs which don't support > RO as CN. I have no concern as IMHO current RR/RO between MNs is > a complete (but easy to fix) disaster. A surprising opinion. Why do you think so? ---------------- > > Ok. Thanks for replying, I think I understand the issue better > now. But today's hardware acceleration, does it support IPv6 > natively? That is true. However I don't think it is acceptable to say now "yeah, future hardware will fix it" if the "fix" required is impossible to do. So the h/w side must be considered at this point just to make sure the future h/w side is doable. >> For incoming packets the BITS sees the SA of (dst=MN,spi=xxx,esp) >> as (dst=COA,spi=xxx,esp). If there is a hardware SA lookup step, then >> this hardware lookup table must be either a) kept up-to-date with the >> correct COA address (where does this address come from? read BU and >> keep state?) or b) have a default fall-back method other than to drop >> all unrecognized incoming esp/ah packets. I agree that doing the >> operations on the packets as they are on the wire is a >> non-starter. (Fixing the SA lookup does not help, as e.g. AH >> authenticator calculation would not succeed.) Sorry, I meant to say here that the SA matching would succeed, but the match would still lead to software which would first convert the packet into plain form before either feeding it back to h/w SA lookup or to transform processing (if the SA index is already available from the first match). Keeping the COA in the SA up-to-date helps with dropping unmatched packets early ("drop early, drop often") without resolting to software just to drop the packet. > This is an interesting idea, and would work very nice from IPsec > point of view. However, it does not take care of one thing, which > makes it hard to adopt for HA-MN security: in this approach, > IPsec and its policies would basically ignore the home addresses. > However, in HA-MN security it is essential to be able to ensure > that a particular user controls only his own home address, not the > addresses of others. In the current solution, the SPD entries are > used to ensure that the right SA is used for the right home address. > In order to provide this in the CoA-based solution, we'd have to > have a per-packet API from IPsec to MIPv6, to tell MIPv6 who it was > that sent this BU. Francis said in another mail: >=> I understand why you would not like to deal with automatic keying >but only the automatic keying has an interest in the real world, >i.e., nobody will use mobile IPv6 with only manual keying outside >a lab. > and I agree. Manual keying is anachronism. It might have uses in limited situations (I've never encountered one outside interop testing, however), but from the real-world deployment scenario of MIP I don't see it happening. It is a management nightmare. No-one is going to deploy manually keyed mobile IPSec due to its unmanageability wrt/ key scheduling. I know that the BU matching is a problem, but it is solvable equally well using a configuration API or other intercommunication channel (defined API, flags in packet headers etc., mostly that is integration problem) between IPSec and MIP. There is already requirements for such methods caused by requirement of manual keying, so it's really not a big difference in my mind. (WRT h/w efficiencies: after IPsec processing in HA is done, it already has SA data. The SA data could contain a single field "MN home address" which in post-processing is done to verify that HAO contains the correct address. Post-processing for only a few select packets in software is much cheaper from efficiency point of view. Does this solve a problem? I am probably not understanding the full extent of the HA-BU matching issue.) ---------------- Jari Arkko responds to Francis Dupont: > I dont see it as a big issue. I have always assumed if the > home address passes the selector match, then it is verified. > you dont have to do a HAO-BCE check. > => so any not protected packet with a HAO should be dropped: > if the node is a correspondant, it won't support routing optimization. No, its different. If the HAO-BCE check is hard to do in a BITS implementation, you could skip that. The end result would be that all protected packets would be passed through as is without the check. Unprotected packets would be tested in Mipv6 when the packet hits the main stack. ---------------- Jari Arkko responds to Santeri Paavolainen: > That is true. However I don't think it is acceptable to say now > "yeah, future hardware will fix it" if the "fix" required is > impossible to do. So the h/w side must be considered at this point > just to make sure the future h/w side is doable. Just a quick clarification: do you mean that the current hardware only supports IPv4? If IPv4 only, then the issue at hand is trying to figure out whether future IPv6 hardware would be troublesome to design or not. If current hw is also IPv6 capable, then the issue can also be about trying to use the existing hardware and what the implications are for that. ---------------- Jari Arkko responds to Santeri Paavolainen: > (WRT h/w efficiencies: after IPsec processing in HA is done, it > already has SA data. The SA data could contain a single field "MN > home address" which in post-processing is done to verify that HAO > contains the correct address. Post-processing for only a few select > packets in software is much cheaper from efficiency point of > view. Does this solve a problem? I am probably not understanding the > full extent of the HA-BU matching issue.) No, I think you got it. Yes, a post processing check with an extra field in the SA would work. I suspect an API would be a much more generally useful and cleaner solution that a BU-specific post check, however. ---------------- Santeri Paavolainen responds to Jari Arkko: > Just a quick clarification: do you mean that the current hardware > only supports IPv4? If IPv4 only, then the issue at hand is trying to figure > out whether future IPv6 hardware would be troublesome to design or > not. If current hw is also IPv6 capable, then the issue can also be > about trying to use the existing hardware and what the implications > are for that. Yes, I mean that the current hardware (typically) supports only IPv4 for hardware _SA lookup_ (those that I've seen). H/W lookup for SAs is not that common however yet. The IPSec transformation acceleration is more supported for IPv6 (but that is not an issue here, since the cost here is the added complexity of SA lookup, not its execution). Let me emphasise here once more: SA lookup is the one hit by the "must-look-in-packet-options-for-hao/rt2". The hw SA lookups I have so far seen are mostly just simplistic (SRC,DST,PROTO,SPI) matchers, e.g. just a hardware (parallel) lookup table out of some 500k+, with a result being n-bit number (for example, index to SA table plus some additional bits for other use). The SA lookup and execution steps are done separately, controlled by software. In *current* implementations thus the software extracts the (src,dst,proto,spi) parameters from the packet before passing to hw lookup. So it does a pass over the packet anyway, and can look up hao/rt2 without added cost. Hmmm, let me rephrase the situation in opposite of what would be either impossible or very costly to do in BITS+hw implementation... (Warning: This will digress from Jari's original question into another topic...) Ah yes, the output for tunneled packets: > IPv6 src = ha dst = coa > ESP > IPv6 src = x dst = hoa > ULP This is now out of draft, section 3.4 (payload packets). First of all, a BITS implementation can decode this successfully only by a) keeping SA lookup table/tree/whatever up-to-date for the mobility SA e.g. update the (dst,proto,spi) triplet when it sees a BU to have dst=COA. b) ensure that all SPIs are unique (this means that MIP would narrow the SPI choice mechanism out of the "(dst,proto,spi) must be unique" into "(proto,spi) must be unique") c) or try all matching (proto,spi) until one succeeds - ouch Since b) is treading on the opaqueness (no mechanism for selection of spi values should be specified out of ipsec rfcs?), and c) is infeasible, this means that MN BITS would have to keep track of BUs and have the current CoA as a state. The current use scenarios for mobility do not require a large number of SAs so updating the SA lookup table intermittently is not a problem. But, what do we know about the future? *Could* there be a scenario where BUs are frequent (tiny cell sizes in wireless networks?), SA table is huge (CNs?) and update of the SA table is an expensive operation (shared resource with bias towards preferring readers?)? (No, I don't think this would be a problem, but you might differ in opinion.) Instead of a-c), alternatively as you Jari wrote in another e-mail let's add HAO to tunneled packets at HA: > IPv6 src = ha dst = coa > HAO = hoa > ESP > IPv6 src = x dst = hoa > ULP If HA sends tunneled packets with HAO header, then MN can now perform a pre-SA-selection step, turn the packet into "plain" version and select the correct SA. Again, we get an extra required step. This scheme means that HAO must either be included in all tunneled packets by the HA or that this is a configuration option. The "configuration option" is however not very good idea, as it is configured in the HA. Imagine the following config in HA: mobile mn = xxxx:xxxx:xxxx::xxxx tunnel-hao=no mobile mn = xxxx:xxxx:xxxx::yyyy tunnel-hao=yes mobile mn = xxxx:xxxx:xxxx::zzzz tunnel-hao=yes So what if ::xxxx changes its mobility implementation to a MIP+BITS, and now requires the HAO option to be in tunneled packets. Ouch. So the only real choice is to require HAO to be present for tunneled packets. (Again, this situation occurs because the requirement that the SA is "not really for CoA" but the MN address (hoa). If SAs were ever applied to the true wire addresses (e.g. CoA for MN, not HOA), there would be no problem.) ---------------- Francis Dupont responds to Santeri Paavolainen: => IMHO hardware acceleration is not a good choice for BITS... For incoming packets the BITS sees the SA of (dst=MN,spi=xxx,esp) as (dst=COA,spi=xxx,esp). If there is a hardware SA lookup step, then this hardware lookup table must be either a) kept up-to-date with the correct COA address (where does this address come from? read BU and keep state?) or b) have a default fall-back method other than to drop all unrecognized incoming esp/ah packets. => the lookup should not include the destination address in this case as it will be specified in the revision of RFC 2401. BTW it is easier to do the lookup on the SPI only than on the triple SPI, destination address and protocol (:-)! Either way, for MIP packets the next step cannot be "proceed to transform processing", since the implementation needs to convert the packet into "plain form" before the IPSec processing. So a trap to software level is always necessary. This opens up a very nice DoS if the software step is substantially slower the the wire speed, since an attacker can just send bogus IPSec packets that have a HAO/RT2 header, since they are forced to drop into software side. => I don't buy this argument: - your software step can be done in hardware - IPsec transforms are always the slower part In fact, I consider your argument as an argument against any special processing, including extension header support, because not built in hardware processings should be "slow path". An assumption here is that you can fudge an "recognize hao/rt2, fudge packet into plain form" step between NIC and IPSec processing for BITS. Oops, that's a software step, not h/w. Anyway, I know none of the issues I've written about are really any road-blocking obstacles, but they are performance-eaters for h/w implementations. => h/w BITS (BTW, is there such h/w using good h/w, i.e., not IPsec enhanced NICs ?) (Anyway, this discussion has only touched manual keying. I am not interested in it at all. => 1000% agree! The whole "fix" here is only required because requirement of supporting manual keying for MIP. If you only use IKE then there is not really any problem, as you can always negotiate a new SA for the current CoA<->HA. In IKEv2 you'd only move the IKE phase-1 address binding without any new SA creation anyway. It would always be possible to add IKE extension for IKEv1 to support this case. IKE is anyway in software, so it is not really a problem from h/w point of view.) => two comments: - IKE is in software but can (should when it is available) use hardware acceleration - we need to move only the IKE phase-1 peer addresses when there is a long term phase-1, i.e., when IKE is in a version > 1. In this case IKEv2 should save you as soon as we reach some agreement about the peer address update mechanism (today we only agree about its need and to work on it as soon as IKEv2 base specs are out). ---------------- Jari Arkko writes: Thanks for your input and discussion. I'm trying to summarize the issues in this e-mail. The issues are from two discussion threads, one started by Francis and another started by Santeri. Have I included everything important below? Do you agree with the summaries? The issues are: 1. Terminology and other corrections needed in ha-ipsec 2. Suitability of MIPv6 and HA-IPSEC for BITS implementations 3. Feasibility of the SPD definition for the MN-HA tunnel interface 4. IKE is needed I will talk about each in turn: 1. Terminology and other corrections needed in ha-ipsec This seems largely handled now. Thanks, Francis! 2. Suitability of MIPv6 and HA-IPSEC for BITS implementations We have developed a rough outline for a possible implementation strategy in a BITS implementation. Generally the following is needed: - per packet "normalization" before IPsec treatment, to get rid of HAOs and RH2s. - specific configuration/recognition of MIPv6 tunnels to HA - update of SA endpoints upon movement, via a config API These tasks appear doable, though may not be possible for all BITS implementations. For instance, the BITS could be controlled only through a GUI. Additionally, the normalization process may not match what current hardware does. However, it isn't clear if any IPv6-capable hardware accelators actually exist, so perhaps the question is more about whether future accelerators can take MIPv6 in account with reasonable effort. As discussed under item 4, there are alternative proposals to how ha-ipsec could be rearranged to avoid the normalization process. However, these proposals appear to have other requirements to the BITS implementations. 3. Feasibility of the SPD definition for the MN-HA tunnel interface According to RFC 2401 and 2460 definitions, one can consider even a MIPv6 (IPv6 encapsulation) tunnel as an interface for which SPD entries can be defined. The current approach makes use of this fact, but Francis believes that this is a too hard requirement for implementations, we'd only see special purpose home agents and cause too long delay in getting general support from most platforms. The problem in this case is that it is hard to differentiate other MH packets sent by the MN or the HA from those that need to be protected. Basically, the only difference is that one set of packets is going to the MN-HA tunnel, and the other set is not. This leaves the following alternatives: - accept the requirement for the SPD entries - a yet to be determined solution that avoids this - revert to an on/off IPsec encapsulation for all tunneled packets 4. IKE is needed Francis and Santeri argue that in practise IKE is always required for a real deployment. There are number of questions related to this: - accurate understanding of the implications of IKE and manual keying usage - the current keyword for IKE (only a MAY) - the possibility of an IKE-only approach which would make some of the issues easier for BITS implementations to handle Related to the first two questions, we have recently updated the base draft security consideration section to give an accurate description of what the implications are. I think this is key in what have to do, I see the keywords as of lesser importance. Vendors will provide IKE if its the only practical solution as you say. See http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#seccons:homeupd I haven't heard anything which would indicate that the current solution does not work with IKE. We have, however, an agreement that Santeri's care-of address based approach would work easier in terms of IPsec. This would free the BITS implementations from dealing with HAOs and RH2s. However, a problem remains that in order to provide a home address - mobile node check for home agent binding updates, the care-of address approach is not very useful. This check can be provided by other means, such as through an API. But it isn't clear that the required existence for such an API would be less of a problem than the currently required things. In particular, such an API would probably be quite hard to arrange for a BITS implementation. Summary The first issue has been handled, but for the rest I do not see a clear alternative to the current specification. What ever we do, there is going to be some modifications required for BITS (probably starting from the need to add IPv6 support). I'd very much like to avoid the tunnel interface SPD entries that Francis complained, but are other folks going to accept on/off tunnel encryption without differentiation to the RR packets? I'm not sure I see other alternatives. Finally, as far as I understand we have not heard a specific complaint that in the current approach IKE would not work. I agree that in most cases IKE would be used for real-world cases. But I'm not sure I'm willing to avoid make manually keyed SAs impossible. (I'm also getting more convinced that the use of IPsec for securing home agent communications has lead to a rather complex feature, and as I said on the mipcharter list an apps layer solution would have made it easy to do dynamic home addresses. Perhaps we will work on something like that in the future.) ---------------- Santeri Paavolainen responds to Francis Dupont: >=> IMHO hardware acceleration is not a good choice for BITS... Your opinion cannot affect reality, as H/W acceleration is very much used also for BITS IPSec implementations :-) >=> the lookup should not include the destination address in this case >as it will be specified in the revision of RFC 2401. BTW it is easier >to do the lookup on the SPI only than on the triple SPI, destination >address and protocol (:-)! I agree it is stupid (using (dst,spi,proto) triplet). However that is the reality. Unless you are willing to write into MIP specification that only SPI matching is allowed for IPSec implementation that want to co-exist with MIP, that is. > Either way, for MIP packets the next step cannot be "proceed to > transform processing", since the implementation needs to convert the > packet into "plain form" before the IPSec processing. So a trap to > software level is always necessary. This opens up a very nice DoS if the > software step is substantially slower the the wire speed, since an > attacker can just send bogus IPSec packets that have a HAO/RT2 header, > since they are forced to drop into software side. > >=> I don't buy this argument: > - your software step can be done in hardware Which step? The packet normalization (to non-hao/rt2 format)? Not unless you get the h/w manufacturers to do that (I am not talking about custom ASIC for custom HW people, but Cavium/SafeNet/Hifn who create accelerator chips with specifications that are fixed over the chip model lifetime). And they won't do that until you have a fixed target for them to fix the silicon to. So the interim situation would be that you have accelerators that don't and can't do the "packet normalization" stuff, so you'd have to do that in software before feeding the packet to transform hw. You are correct that "software step can be done in hardware", but you need to take the real world into account before commiting to a solution. Note that the situation currently is and is very likely to be for quite a while that SA lookup and IPSec transform processing are separated from each other. IPSec transformation is a no-brainer *once* you have the SA matched. It's the SA lookup which is affected by hao/rt2. >=> two comments: > - IKE is in software but can (should when it is available) use hardware > acceleration > Yep, but that is mostly just the DH group operation acceleration. There isn't anything other to accelerate in IKE (you can accelerate symmetrics crypto, but given IKE traffic levels that gets pretty much pointless really really fast). Some HW do hide the DH results from user-level (keep SKEY etc. data in hw, and allow them to be referred only by some handle) but that's not really relevant to the fast-path processing e.g. actual IPSec ESP/AH packets. > - we need to move only the IKE phase-1 peer addresses when there is > a long term phase-1, i.e., when IKE is in a version > 1. In this > case IKEv2 should save you as soon as we reach some agreement about > the peer address update mechanism (today we only agree about its need > and to work on it as soon as IKEv2 base specs are out). Yep. However IKEv2 and IKEv1 *and the SAs they negotiate* as well as the manually keyed stuff have to live together. If you create an RFC which specifies MIP6 interoperability with IPSec/IKEv1, in the future another RFC with MIP6 interop with IPSec/IKEv2 has to live together with the previous RFC! You cannot just say "yeah, if you use IKEv2 with MIP for any SA, your host is doomed, it cannot interoperate with IKEv1 MIP." So IKEv2 will not "save" me or anyone else. (This would be so much simpler if manual keying for mobile ip was just dropped, and that transport mode SAs were used between the CoA and HA, always, and that IPSec processing would always be done on the packet with hao/rt2 already, eg. for outbound case after MIP, for inbound before MIP. There would be no special case for MIP in any IPSec implementation, software or hardware (e.g. faster integration), only in IKE.) ---------------- Jari Arkko responds to Santeri Paavolainen: I agree with Santeri about the need for the IKEv1, v2, and manual keying all having to live together. > (This would be so much simpler if manual keying for mobile ip was just > dropped, and that transport mode SAs were used between the CoA and HA, > always, and that IPSec processing would always be done on the packet > with hao/rt2 already, eg. for outbound case after MIP, for inbound > before MIP. There would be no special case for MIP in any IPSec > implementation, software or hardware (e.g. faster integration), only in > IKE.) Yes, it would be simpler except for the authorization step regarding BUs. That appears to require an API from the BITS device to the IP stack. While that would be generally useful, I'm not very optimistic about that being possible. ---------------- Santeri Paavolainen responds to Jari Arkko: Yes. But I do not think that IPSec and MIP can live together (apart if they are really integrated into one stack so MIP can affect IPSec policy) without some configuration. That configuration is required for MN, since it must know the HA address. It is also required for HA, since if you are using IPSec, you want to define the policy anyway (which certs / psk to trust). I am still not sure whether the BU is solved by having a HAO check (+ MH/HAO enforcement for plaintext packets), but that would be just a single configuration entry to HA IPSec configuration (e.g. "mobile node XXX is identified by a certificate with subject name cn=xxxx"). However this is the part where I wasn't sure (referring to my earlier mail) if this solves the BU security problem. (And still am unsure whether I'm still missing a piece here.) If the issue here is that this would require *configuration* for both MIP and IPSec separately, I'm not seeing any problem. If you have integrated MIP/IP/IPSec, there is no double configuration. And for BITS IPSec you have to configure MIP and IPSec separately regardless of the choice[1]. [1] Between hao/rt2 preprocessing in IPSec or CoA SAs. (Can anyone propose names/terms to separate these two methods for future reference?) ---------------- Jari Arkko responds to Santeri Paavolainen: The problem is not about configuration as such. Its about matching information from two places. If IPsec is doing the authentication part but doesn't look at the home address, and mobile ipv6 looks at the home address but doesn't do authentication, then we have a problem. Example: you have a home address feed::f00d and I have an address dead::beef. I shouldn't be able to modify your current location with a BU. Hence someone must check that - The SA nnnn for Santeri has been used for feed::f00d (manual case) or - The identity "santtu@ssh.fi" has been used for the SA created to send a BU for feed::f00d (dynamic case). The current model we have in the document is that IPsec does this check. This is particularly easy with manual keying, we simply set up SPD and SAD entries so that the specific SA and address must go together. For dynamic case, IKE phase 2 needs to make an authz check for the requested addresses. But if you look at the stuff in two places, there needs to be a connection between them, and it can't be done simply by using configuration on both sides. Finally, the third alternative is doing all of this checking in MIPv6 side. ---------------- Francis Dupont responds to Jari Arkko: Would you be happy with a formulation that leaves this open to implementations? "... must treat MH messages entering the tunnel differently from MH messages sent to others, as if the SPD were specific to the tunnel interface ..."? => I am not happy because the SPD must not be specific to the tunnel interface. (Francis, I don't think there is a compatible standard way to represent this. But if you think there is please tell me.) => IMHO the best is to remove the interface from the SPD definition. It is not in the line of RFC 2401 but at least it doesn't give a bad hint. BTW we have three cases: - CNs: not in the scope - HAs: there is an interface: it is the home link interface. And if a MH packet comes from a CN, there is no reason to not give it to IPsec. - MNs: this case is hairy but MH packets are genuine packets and we can assume the mobility code knows how to handle IPsec (in fact, this is why it will be handled by real implementations as there is no PCB but a lot of specific context). This shows how to solve the MH messages to CNs issue, which, I repeat, is not in the scope of this document. > => I don't buy this argument: we are about MN-HA and the fact that > MH packets directly sent to CNs need specific SPD entries is out of > scope. It still needs to work and not break other stuff. So a solution which would kill RO towards CN is imho not acceptable. And it would kill RO because the MHs would be expected to be encrypted and there'd be no keys between the CNs and the MNs. => there are a lot of ways to make these packets (MH messages to CNs) special. In fact IMHO one needs something because there is some kind of SA involved and this stuff should not collide with IPsec. > > - same (6.19) > > In step 8, the corresponding SPD entries must be updated too and > > IKE must be warned of the update (what is not (yet) done by KAME). > > I'm not sure we need an SPD entry update. > > => the address of the other peer/endpoint is a SPD entry parameter so > the SPD must be updated. Note that even your SPD is not a real one, > you have this info in it. The question is whether the information is used. => it is used in the OUT way to create or rekey a SA, either to look for the phase 1, or to create a new one. If I understand 2401 correctly the GW address in the SPD is not looked at upon processing packets by an existing SA. => 100% right but it can be used by a not existing or expiring SA. Thanks Francis.Dupont@enst-bretagne.fr PS: I looked up if the SPD should use or require a SA on the HA for tunneled MHs. The first answer is "require" but in this case a SA is really required so a way to build one is required too. So a valid SPD must exist: - the SPD can't be generated by IKE, it must be configurated before. - the SPD parameters must be updated (in a visible way to IKE). ---------------- Jari Arkko responds to Francis Dupont: > => there are a lot of ways to make these packets (MH messages to CNs) > special. In fact IMHO one needs something because there is some kind > of SA involved and this stuff should not collide with IPsec. Allright, now I think I finally understand what you think we should do. So the idea is that the MH packets that don't go to the HA should be exempt from IPsec processing, by the means of programming and not through SPD? Kind of like the MH packets are exempt from BCE and BUL processing? But how would this work with the BITS implementations? Hmm... maybe I can see that it might work. The tunneled packets are inside IPv6 encapsulation and those should be subject to processing but others not. Or is your intention that we make the language in the draft weaker, and say that one must have *some* way of making this happen, not require the per-tunnel-interface SPD? (But don't we have that already?) ---------------- Francis Dupont responds to Gabriel Montenegro: Short question: Is anything *broken*? => yes, the current draft is not sound. To repeat the obvious: any delay in this draft imposes an equivalent delay in the base mipv6 draft, because of the normative reference. => as a part of the problem is that the draft is not compatible with the base mipv6 draft this is even more obvious. ---------------- Jari Arkko responds to Francis Dupont: ---------------- Santeri Paavolainen responds to Jari Arkko: Me: MN, home address = feed::f00d, CoA = COA1, identity = santtu@ssh.fi You 1: Arbitrary node, address = dead::beef You 2: MN, home address = dead::beef, CoA = COA2, identity = jari.arkko@kolumbus.fi So I am at remote network, I have just acquired CoA = COA1, and am sending BU to HA. IPSec traps BU and starts IKE with HA. Result is SA COA1<->HA. I send the BU, through the SA. HA receives the protected BU, matches SA, decrypts it. Passes it on to MIP. So, the attack scenarios can be two-fold: You 1: Send plaintext BU from arbitrary address (dead::beef) with HAO=feed::f00d. This is prevented through configuration + IPSec/firewalling, either disallow all BUs that are not IPSec protected, or perform selective filtering (e.g. some sort of application-specific firewalling that drops all BUs that have HAO equivalent to one specified for IPSec BU protection). (How do we drop non-IPSec BUs? Two choices: IPSec does filtering based on MH protocol and performs this check, or IPSec sets some packet flag (IPSEC_DONE_ON_PACKET) that the MIP stack can refer to and verify IPSec was done. Latter one *does* require some MIP<->IPSec interaction, true...) You 2: Negotiate an IPSec SA for protecting BU, but instead of sending a BU that has HAO=dead::beef, use HAO=feed:f00d. This is prevented by having SA contain the HAO address that must match the HAO in the packet. In this case You 2 SA would have haomatch=dead::beef, which is not the same HAO you sent, so the packet is dropped. This is a little like egress checking in tunnel mode. Does this cover all cases possible cases? PS. Clarification: In this e-mail I am talking about the scenario where packet is *not* "normalized into plain format" but instead the SA is for care-of-addresses. ---------------- Jari Arkko responds to Santeri Paavolainen: > *You 2: Negotiate an IPSec SA for protecting BU, but instead of sending > a BU that has HAO=dead::beef, use HAO=feed:f00d.* You got it. This is the case that I was talking about. > This is prevented by having SA contain the HAO address that must match > the HAO in the packet. In this case *You 2* SA would have > haomatch=dead::beef, which is not the same HAO you sent, so the packet > is dropped. This is a little like egress checking in tunnel mode. Right. But this is a modification to IPsec, isn't it? Whereas now at least for some implementations we don't need any modifications, assuming the MIP code is inserted to the right place in the packet flow. ---------------- Francis Dupont responds to Basavaraj Patil: As Gabriel has also asked in his earlier email, the question to ask or actually the only question to ask at this time is: Is the current solution proposed in the MIPv6 base and MN-HA IPsec drafts broken? => the SPD description is broken but not the packet format part so the specified behavior is right but the proposed way to get it is not. If not, there is no point in continuing this discussion. => it is more whether we should fix the issue ASAP or publish the draft and be prepared to answer to angry implementors that we know and it will be fixed in the next version. Better solutions or tweaks to IPsec policies etc. can come later. The charters for the new WGs clearly indicates that this is something we will take up in the new WGs. And we also now have the help of Radia Perlman which will go a long way in dealing with the IPsec WGs and the security mafia. Hence at this time, unless the answer is that the solution as it exists now in the current drafts is broken and JUST WONT WORK, I would agree with Gabriel and go forward with the recommendation made by Jari below. => IMHO the best is to remove the annoying text, i.e., everything about per interface stuff. This won't be very conform to RFC 2401 but this removes the "use a tunnel if you use it" unsoundness (note this is in both drafts). And the other detail to fix is to be compatible between the two drafts: ordinary (i.e., not produced by the mobility code) outcoming packets are handled first by IPsec then by mobility. ---------------- Jari Arkko responds to Francis Dupont: > as a part of the problem is that the draft is not compatible with > the base mipv6 draft this is even more obvious. Is the main issue that 11.3.2 order is 1. do ipsec and 2. do mipv6 vs. the per-tunnel-interface-SPD entries would require doing at least part of 2 first? Are there other issues? Let me ask what would satisfy you to fix the above. WHat if we do the following: - reword the per-tunnel-interface-SPD text to say instead that the other MH traffic needs to bypass IPsec. - keep 11.3.2 order - say somewhere that other possibilities than the IPsec bypass are possible, but would require a different order of processing in 11.3.2? Remember that it is only an implementation example. One thing I don't understand in the bypass ipsec solution is whether it would break something else. What if we had a protect-all rule between the MN and the CN? ---------------- Gabriel Montenegro responds to Francis Dupont: > => the SPD description is broken but not the packet format part > so the specified behavior is right but the proposed way to get > it is not. That's exactly what the draft says already. The per-tunnel SPD entries are a SHOULD, not a MUST, and the real specification is for on-the-wire formats, so you're already free to depart from the recommended implementation suggestions as long as the packets look the same on the wire. 4.2 Policy Requirements .... o When IPsec is used to protect return routability signaling or payload packets, the security policy database entries SHOULD be defined as if they were specifically for the tunnel interface between the mobile node and the home agent. That is, the policy entries are not generally applied on all traffic on the physical interface(s) of the nodes, but rather only on traffic that enters this tunnel. Note that this requirement is similar to the approach taken in dynamically routed VPNs [12]. 4.3 IPsec Protocol Processing .... Note that this specification concerns itself only with on-the-wire formats, and does not dictate specific implementations mechanisms. ---------------- Francis Dupont responds to Jari Arkko: There is equivalent wording, but I think Francis understands the => with all possible meanings you have a problem: source, destination and protocol of every packets are the same and you can't select only packets ending by a MH. tunnel interface as the IPsec tunnel interface, which is not the case. So I'll add "... IPv6 encapsulated tunnel interface ...". And clarify this in the example configs section too. > Or is there anything *broken*? According to the specs, we are fine for this issue. Implementation wise... not all implementations might support tunnel -intterface specific SPD entries. Tough, a modif is needed. => the best is to remove this spurious precision. ---------------- Gabriel Montenegro responds to Francis Dupont: > => it is more whether we should fix the issue ASAP or > publish the draft and be prepared to answer to angry implementors > that we know and it will be fixed in the next version. Not a problem. The fact that after many years we are still producing nothing but further delays is the most important issue. > => IMHO the best is to remove the annoying text, i.e., everything > about per interface stuff. This won't be very conform to RFC 2401 > but this removes the "use a tunnel if you use it" unsoundness > (note this is in both drafts). > And the other detail to fix is to be compatible between the two > drafts: ordinary (i.e., not produced by the mobility code) outcoming > packets are handled first by IPsec then by mobility. In order to better understand the scope of the changes suggested, please provide exact and complete suggestions for text modifications to both drafts. ---------------- Vijay Devarapalli responds to Francis Dupont: I think you are missing the basic point. the only mandatory parts in the whole specification are the formats on the wire (and the requirements). check the wording again. > o When IPsec is used to protect return routability signaling or > payload packets, the security policy database entries SHOULD be > defined as if they were specifically for the tunnel interface > between the mobile node and the home agent. That is, the policy > entries are not generally applied on all traffic on the physical > interface(s) of the nodes, but rather only on traffic that enters > this tunnel. The only real requirement, that I see, in the above paragraph is that the SAD entries for protecting return routability signaling should only be applied to the packet entering the MN-HA tunnel. how that is achieved is totally dependent on the implementation. infact many implementations dont even treat the MN-HA tunnel as an IPv6 tunnel interface. ie, there is no tunnel device. they just add an outer IPv6 header when they see they need to add one. > the SPD description is broken but not the packet format part For heaven's sake, it is just a description. let more people implement it. and if they complain we can re-work this draft. I can support this in my implementation. lets get on with it and publish the draft. ---------------- Vijay Devarapalli responds to Jari Arkko: > One thing I don't understand in the bypass ipsec solution > is whether it would break something else. What if we had > a protect-all rule between the MN and the CN? I dont like this bypass ipsec solution, because we dont know what we might be breaking. instead of requiring special handling for our reverse tunneled packets, we are requiring special handling for all other traffic. (here I am talking about not just mobility header traffic, but also payload traffic.) ---------------- Perhaps, but most people that think IKE will solve this particular issue don't realize that they still can't set it up without per-MN configuration. => this is a smaller problem than to have long term per-MN keys. The user <-> home address mapping is still needed. => this is only an implementation problem: how to support scalable and/or dynamic policies. > => I have two remarks: > - this method is not optimized but is conformant. In fact I believe > it will be commonly used because the BITS will be an IPsec VPN client > and what we suggest is just to add mobile IPv6 support to it. > - this method is *not* a solution for the second issue. Actually, it can be. If you get a tunnel packet IPv6 src = ha dst = coa IPv6 src = x dst = hoa ULP you output it as IPv6 src = ha dst = coa HAO = hoa => where does this HAO come from? It seems I didn't understand what was the inefficient encapsulation... ESP IPv6 src = x dst = hoa ULP > => I translate this in there is no problem on MNs which don't support > RO as CN. I have no concern as IMHO current RR/RO between MNs is > a complete (but easy to fix) disaster. A surprising opinion. Why do you think so? => there are four parts (issue/solution x RR/RO): - RR is very unsafe between MNs because it assume the attacker can't be close to the CN, if the CN is itself mobile, the attacker has only to be close to any MN. More, usually MNs are attached to links without a high level of security. - the solution is simple: recognize this case and use an RR procedure where a part of the secret goes through both HAs, using of course protected tunnels between a MN and its HA. The attacker has to be between the two HAs, i.e., on the core. When the two MNs share the same HA, this solution is 100% safe. - current RO between two MNs is inefficient because each side adds an extension header (HAO or RH2), so the overheade is 48 bytes. - the obvious solution is to use a full but single encapsulation between the two MNs (outer header with Co@s, inner with the H@s). I participated to a not-yet-submitted draft about this but I already wrote in the mobile-ip mailing list this case is important and it is a shame we spend time about spurious details in place of just doing something like I describe. ---------------- Francis Dupont responds to Jari Arkko: According to RFC 2401 and 2460 definitions, one can consider even a MIPv6 (IPv6 encapsulation) tunnel as an interface for which SPD entries can be defined. => they can be defined but they don't do what we want. The problem in this case is that it is hard to differentiate other MH packets sent by the MN or the HA from those that need to be protected. Basically, the only difference is that one set of packets is going to the MN-HA tunnel, and the other set is not. => the problem is different on the HA which is supposed to be a general purpose router and on the MN where we can assume some magic interaction between IPsec and mobility codes, for instance the current base MIPv6 draft requirement that IPsec is processed before mobility for outgoing packets is not an issue for MH messages as they are produced by the mobility code... This leaves the following alternatives: - accept the requirement for the SPD entries => I disagree with this solution - a yet to be determined solution that avoids this => easy: ignore the RFC 2401 per-interface SPD stuff. - revert to an on/off IPsec encapsulation for all tunneled packets => note that this works with the SPD for the tunnel interface but it switches to a transport mode... 4. IKE is needed Francis and Santeri argue that in practise IKE is always required for a real deployment. => even I don't like the MAY about IKE (I clearly prefer a SHOULD) I have no concern about keeping the MAY because the market will decide (and an RFC can't change that). The only real argument against the MAY is the replay issue and we already dealt with. There are number of questions related to this: - accurate understanding of the implications of IKE and manual keying usage => easy: 100% of real world deployments use IKE. - the current keyword for IKE (only a MAY) - the possibility of an IKE-only approach which would make some of the issues easier for BITS implementations to handle => I don't believe there are real world cases which can be handled by IKE and not by manual keying. Related to the first two questions, we have recently updated the base draft security consideration section to give an accurate description of what the implications are. I think this is key in what have to do, I see the keywords as of lesser importance. Vendors will provide IKE if its the only practical solution as you say. => I agree with the last statement! I haven't heard anything which would indicate that the current solution does not work with IKE. => it will be fine to have a proof that it works with IKE without too much deep surgeonry in implementations. I have a KAME/racoon stuff but not enough free time (or I have a lot of people looking for me in my office, or my lab is closed... May is the worst month!) to test it. I believe it should work but I prefer a proof. I'm also getting more convinced that the use of IPsec for securing home agent communications has lead to a rather complex feature, and an application layer security solution would have been simpler. => IMHO a security solution written from scratch is only simple at the beginning... No, the good idea was to begin from mobile IPsec VPNs and to add mobile oriented optimization to them because they are already available (I am just using one at this moment). ---------------- Francis Dupont responds to Santeri Paavolainen: Your opinion cannot affect reality, => I know: I am old enough. as H/W acceleration is very much used also for BITS IPSec implementations => My opinion comes from this statement in RFC 2401 "This (BITS) approach, when it is adopted, is usually employed in hosts" and by the fact it seems the SG with H/W acceleration I know (Cisco, Juniper. OpenBSD) are not BITS. >=> two comments: > - IKE is in software but can (should when it is available) use hardware > acceleration Yep, but that is mostly just the DH group operation acceleration. => this and good random number generation are what I should like to see in the hardware. > - we need to move only the IKE phase-1 peer addresses when there is > a long term phase-1, i.e., when IKE is in a version > 1. In this > case IKEv2 should save you as soon as we reach some agreement about > the peer address update mechanism (today we only agree about its need > and to work on it as soon as IKEv2 base specs are out). However IKEv2 and IKEv1 *and the SAs they negotiate* as well as the manually keyed stuff have to live together. => I disagree: only the things outside IKE itself (i.e., SPD and of course the SAs) have to live together. If you create an RFC which specifies MIP6 interoperability with IPSec/IKEv1, in the future another RFC with MIP6 interop with IPSec/IKEv2 has to live together with the previous RFC! You cannot just say "yeah, if you use IKEv2 with MIP for any SA, your host is doomed, it cannot interoperate with IKEv1 MIP." So IKEv2 will not "save" me or anyone else. => the only possible issue today is with the K bit and it seems we shan't be in trouble because both peers will use either manual keying or IKEv1 or IKEv2, i.e., no mixed stuff. (This would be so much simpler if manual keying for mobile ip was just dropped, and that transport mode SAs were used between the CoA and HA, => if I understand well you are in favor of a mobility IP-over-IP tunnel for everything and to put "on the top" of it a transport mode SA pair. I agree this is very easy for a BITS implementation but it is also the less efficient. BTW for another reason in PANA this solution was prefered for the PaC-EP tunnel and we are getting complains... always, and that IPSec processing would always be done on the packet with hao/rt2 already, eg. for outbound case after MIP, for inbound before MIP. There would be no special case for MIP in any IPSec implementation, software or hardware (e.g. faster integration), only in IKE.) ---------------- Francis Dupont responds to Jari Arkko: Yes, it would be simpler except for the authorization step regarding BUs. That appears to require an API from the BITS device to the IP stack. While that would be generally useful, I'm not very optimistic about that being possible. => IMHO Santeri thought about a pure IPsec solution where BUs are used to move the MN tunnel endpoint, not to establish the tunnel... ---------------- Francis Dupont responds to Jari Arkko: Allright, now I think I finally understand what you think we should do. So the idea is that the MH packets that don't go to the HA should be exempt from IPsec processing, => yes, in theory we should have some SPD entries to make them bypass the general rule for ESP tunnel but in practice this should be directly enforced. About the draft only the visible behavior matters so we can say what we'd like, i.e., what is the simplest. Note that the incoming side is interesting because the policy is checked inside the upper layer processing, i.e., for MH messages inside the mobility code itself. by the means of programming and not through SPD? Kind of like the MH packets are exempt from BCE and BUL processing? => what matters is exceptions don't follow the general rule, isn't it? But how would this work with the BITS implementations? Hmm... maybe I can see that it might work. The tunneled packets are inside IPv6 encapsulation and those should be subject to processing but others not. Or is your intention that we make the language in the draft weaker, and say that one must have *some* way of making this happen, not require the per-tunnel-interface SPD? (But don't we have that already?) => IMHO the language in the draft is too strong... ---------------- Francis Dupont responds to Santeri Paavolainen: Me: MN, home address = feed::f00d, CoA = COA1, identity = santtu@ssh.fi You 1: Arbitrary node, address = dead::beef You 2: MN, home address = dead::beef, CoA = COA2, identity = jari.arkko@kolumbus.fi So I am at remote network, I have just acquired CoA = COA1, and am sending BU to HA. IPSec traps BU and starts IKE with HA. Result is SA COA1<->HA. => note that, according to RFC 2409, the authorization is done by the phase 2. (How do we drop non-IPSec BUs? Two choices: IPSec does filtering based on MH protocol and performs this check, or IPSec sets some packet flag (IPSEC_DONE_ON_PACKET) that the MIP stack can refer to and verify IPSec was done. Latter one *does* require some MIP<->IPSec interaction, true...) => the latter is the standard solution for integrated stack (and the flag is more than IPSEC_DONE because it has to specify which kind of protection). *You 2: Negotiate an IPSec SA for protecting BU, but instead of sending a BU that has HAO=dead::beef, use HAO=feed:f00d.* This is prevented by having SA contain the HAO address that must match the HAO in the packet. In this case *You 2* SA would have haomatch=dead::beef, which is not the same HAO you sent, so the packet is dropped. This is a little like egress checking in tunnel mode. => yes, the protection of the home address is an ACL-like one. ---------------- Francis Dupont responds to Jari Arkko: Is the main issue that 11.3.2 order is 1. do ipsec and 2. do => this is the main issue for HAs. mipv6 vs. the per-tunnel-interface-SPD entries would require doing at least part of 2 first? Are there other issues? Let me ask what would satisfy you to fix the above. WHat if we do the following: - reword the per-tunnel-interface-SPD text to say instead that the other MH traffic needs to bypass IPsec. => it is better to say that the other MH traffic needs specific SPD entries (or with other words, is handled by specific SPD entries). This is more general than "bypass". - keep 11.3.2 order => please keep it! - say somewhere that other possibilities than the IPsec bypass are possible, but would require a different order of processing in 11.3.2? Remember that it is only an implementation example. => we can say that on the MN the SPD lookup is done by a specific way for MH traffic. Not only this cancels the issue but also it should be the way it is done by implementations. One thing I don't understand in the bypass ipsec solution is whether it would break something else. What if we had a protect-all rule between the MN and the CN? => so we should be more general than "bypass". ---------------- Francis Dupont responds to Vijay Devarapalli: I think you are missing the basic point. the only mandatory parts in the whole specification are the formats on the wire (and the requirements). check the wording again. => There is no annoying MUSTs in the ha-ipsec draft but a discutable SHOULD... There is no critical requirement, only wording which suggests or requires the spurious per-tunnel-interface SPD. > o When IPsec is used to protect return routability signaling or > payload packets, the security policy database entries SHOULD be > defined as if they were specifically for the tunnel interface > between the mobile node and the home agent. That is, the policy > entries are not generally applied on all traffic on the physical > interface(s) of the nodes, but rather only on traffic that enters > this tunnel. => this text is a bit misleading (it is the discutable SHOULD). the only real requirement, that I see, in the above paragraph is that the SAD entries for protecting return routability signaling should only be applied to the packet entering the MN-HA tunnel. how that is achieved is totally dependent on the implementation. infact many implementations dont even treat the MN-HA tunnel as an IPv6 tunnel interface. ie, there is no tunnel device. they just add an outer IPv6 header when they see they need to add one. => my concern is not the existence of an interface for the mobility MN-HA tunnel, it is the bad idea to apply the SPD lookup after the encapsulation: This makes use of per-interface security policy database entries [4], specific to the tunnel interface (the node's attachment to the tunnel [11]). (base draft, v21, 10.4.6). for heaven's sake, it is just a description. let more people implement it. and if they complain we can re-work this draft. I can support this in my implementation. lets get on with it and publish the draft. => I don't object the publication (in fact when I sent my comments I believe it was already sent to the RFC editor). But we should do better for the next version (get a working implementation based on existing code for instance). ---------------- (Bits discussion moved under issue #307.) ---------------- Jari Arkko writes: After the discussion I'd like to propose a resolution to this issue. It seems that after the weekend's discussion we seem to agree upon the following: * Formats on the wire are right. * There is an inconsistency between 11.3.2 and the tunnel interface policy lookup. Our disagreement is mainly about the processing. As has been noted, we have already used (on purpose!) enough weasel-wording to make it clear that we do not recommend a specific implementation. But the inconsistency needs to be solved, and it would also be useful to have a few words about other implementation strategies. The SHOULD that Francis doesn't like can be changed to talk about the desired outcome, and only point out with weaker words the use of the SPD rules. In addition, the base and ha-ipsec used MUST/SHOULD inconsistently. I think we can use MUST with the new formulation. In both documents, change "The security policy database entries MUST(SHOULD) be defined as if they were specifically for the IPv6 encapsulated tunnel interface between the mobile node and the home agent." => "When IPsec is used to protect return routability signaling or payload packets, this protection MUST only be applied to the return routability packets entering the IPv6 encapsulated tunnel interface between the mobile node and the home agent. This can be achieved, for instance, by defining the security policy database entries specifically for the tunnel interface." The 11.3.2 inconsistency can be solved by adding a statement in 11.3.2 about the need to determine outgoing interface (including tunnel) at an early step. Note: this is only partially about mobility processing, the real mobility actions come later as in the current version. But RFC 2401 requires SAD and SPD to be interface specific, so I think this can be pointed out. Also remember that this text begins with a disclaimer that we do not wish to require a specific implementation, as long as the output is the same. New item list in 11.3.2: o The packet is created by higher layer protocols and applications (e.g., by TCP) as if the mobile node were at home and Mobile IPv6 were not being used. o Determine the outgoing interface for the packet. (Note that the selection between reverse tunneling and route optimization may affect this.) <--- NEW o As part of outbound packet processing in IP, the packet is compared against the IPsec security policy database to determine what processing is required for the packet [4]. o If IPsec processing is required, the packet is either mapped to an existing Security Association (or SA bundle), or a new SA (or SA bundle) is created for the packet, according to the procedures defined for IPsec. o Since the mobile node is away from home, the mobile is either using reverse tunneling or route optimization to reach the correspondent node. ... ---------------- Francis Dupont writes: I'm fine with the two proposed resolutions... Please publish the drafts. ---------------- Santeri Paavolainen responds to Jari Arkko: > * Formats on the wire are right. I cannot completely agree with this one. In 3.4 the payload packets are at the MN end received as: IPv6 header (source = home agent, destination = care-of address) ESP header IPv6 header (source = correspondent node, destination = home address) Any protocol It is still not clear to me how an BITS implementation is going to choose the correct SA (remember; SA was negotiated for home address, not coa). I'd like the method and rationale (why it works) spelled out (in the draft). ---------------- Gabriel Montenegro responds to Jari Arkko: Just one minor observation on the new bullet in 11.3.2. Other than this (even ignoring my comment below), looks good. Jari Arkko wrote: > New item list in 11.3.2: > > o The packet is created by higher layer protocols and applications > (e.g., by TCP) as if the mobile node were at home and Mobile IPv6 > were not being used. > > o Determine the outgoing interface for the packet. (Note that > the selection between reverse tunneling and route optimization > may affect this.) <--- NEW "...may affect this..." Recommend making this a bit more explicit as to how it'll affect it (by being considered interfaces, thus adding to the list of potential candidates?). ---------------- Jari Arkko responds to Gabriel Montenegro: Ok. This is what I have now: o Determine the outgoing interface for the packet. (Note that the selection between reverse tunneling and route optimization may imply different interfaces, particularly if tunnels are considered interfaces as well.) ---------------- Gabriel Montenegro responds to Jari Arkko: yes, that does it. ---------------- Gabriel Montenegro writes: This issue is now closed as per Jari's recommendation (plus the minor edit). ---------------- The chairs write: After some consultation with Jari, we have come to the decision to close these issues and move on. We're not claiming we see unanimous support for all text in the drafts. That's ok. We sometimes forget we're not supposed to look for it. Jari, please publish the drafts. These topics can certainly be revisited later. But this is not the right time to continue to beat this horse cuz we risk waking it into a zombie every time we do so. ^_^ ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ----------------