I did a quick read of draft-ietf-mobileip-mipv6-ha-ipsec-04.txt and noticed a number of places where the document seems to call for processing that deviates from what RFCs 2401 and 2402 prescribe. Since 2401 is undergoing revision now, there is a chance to make changes, but some of the processing differences need to be discussed in more detail, to explain why there are no adverse security side effects. RFC 2402 has been revised and will go to IPsec WG last call VERY soon, and thus any changes relative to that spec must be made very soon, or risk being out of sync for some time. I have annotated the I-D text, in MS Word. In addition to the sort of issues raised above, I also made some changes or asked some questions that I think would help clarify the document. Please feel free to contact me with questions about my comments, and with response to the questions I raised. (document at http://www.piuha.net/~jarkko/publications/mipv6/issues/issue292.doc or at http://psg.com/~smb/draft-ietf-mobileip-mipv6-ha-ip.htm) -------------------------------- Vijay Devarapalli responds to Stephen Kent: Thanks for the in-depth review. A few quick answers.... The Home Adress Option appears before the IPsec header. At the receiving node, it is processed before the IPsec header is processed. Processing the Home Address Option means the IPv6 source address of the packet is replaced by the contents of the home address option. By the time the selector match is done, the implementation has to ensure that the home address is the source address of the packet. Similarly on the sending node, the SPD lookup should be done as if the source address of the packet is the home address. > o When a packet is matched against IPsec security policy or > selectors of a security association, an address appearing in a > Home Address destination option MUST be considered as the source > address of the packet. The above text does not mean IPsec code must be aware of the home address option. It says MIPv6 code in the kernel has to make sure that IPsec processing is applied as if the source address is the home address. Some of the current implementations handle this by adding the Home Address Option after IPsec processing. The argument is similar for Routing Header Type 2. Current MIPv6 implementations handle this by adding the routing header after IPsec processing is done (on the sending node) and processing the routing header before IPsec processing is done (in the receiving node). > o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the > protection of packets belonging to the return routability > procedure. A non-null encryption transform and authentication > algorithm MUST be applied.[why is encryption needed?] Return Routability procedure involves the mobile node proving to the corresspondent node that it owns both the Home Address and the Care-of Address. It exchanges two sets of messages (one from CoA and one from HoA, tunneled through the home agent) with the correspondent node. If an attacker is on the mobile node's link and the mobile node's current link is an unprotected wireless link, the attacker would able to see both sets of messages. He can then launch an attack. One can prevent the attack by making sure that the tunneled packets (through the Home Agent) are encrypted. Therefore it is required. You might then ask why isnt the use of tunnel mode ESP a MUST. This is because some public wireless links provide some kind of link level encryption which prevents attackers from observing the traffic on the link. When you see text like > The home agent MUST set the new care-of address as > the destination address of these packets, as if the destination > gateway address in the security association had changed It doesnt mean we want the IPsec code do this. It means MIPv6 code has to ensure this. Almost always MIPv6 exists in the kernel. Infact our mandate before starting to write this specification was to make as little changes to IPsec as possible (if possible nothing at all) It would be nice if IPsec is aware of the Home Address Option and Routing Header Type 2 just as how it is aware of Routing Header Type 0. But that can come later...... RFC 2402. > Routing (Type 0) -- The IPv6 Routing Header "Type 0" will > rearrange the address fields within the packet during > transit from source to destination. However, the contents > of the packet as it will appear at the receiver are known > to the sender and to all intermediate hops. Hence, the > IPv6 Routing Header "Type 0" is included in the > Authentication Data calculation as mutable but predictable. > The sender must order the field so that it appears as it > will at the receiver, prior to performing the ICV > computation. > o When the set of prefixes advertised by the home agent changes, > there is a need to configure new security policy entries, and > there may be a need to configure new security associations. It is > outside the scope of this specification to discuss automatic > methods for this, if new home addresses are required. > [sounds like too much magic is required here.] We dont know how to do it yet. There is no way for the Home Agent to verify if the mobile node is authorized for this new home addresses. If the Home Agent does not verify this, you can have a mobile node misbehaving with some other mobile node's home address. If the mobile node uses the same Interface Id for each home address it generates, the Home Agent can easily verify this. But if the mobile node uses RFC 3041 address, the Home Agent cannot verify if a particular home address belongs to a particular mobile node. There are a couple of proprietary solutions for this. I am aware of one. But they are not standardized. > o If replay protection is required, dynamic keying MUST be used. > IPsec can provide replay protection only if dynamic keying is > used. This may not always be possible, and manual keying would be > preferred in some cases. > [not very clear direction here.] IPsec also does not guarantee correct > ordering of packets, only that they have not been replayed. > Because of this, sequence numbers within the Mobile IPv6 messages > ensure correct ordering. However, if a home agent reboots and > loses its state regarding the sequence numbers, replay attacks > become possible. [huh? If the home agent reboots, the SAs go away ] The sequence numbers refer to the sequence numbers in the binding updates. They are stored in the binding cache. If the binding cache is in non volatile storage, the Home Agent rejects replayed binding updates after it reboots(even though the same manually created IPsec SA is used). > The use of a key management mechanism together > with IPsec can be used to prevent such replay attacks. [poor wording of these last two sentences.] If the binding cache is stored in volatile storage, replay attacks are possible with manual keying. A dynamic keying mechanism like IKE would have negotiated a new SA (with a different key) when the Home Agent reboots and comes up. Thats what the above paragraph is trying to convey. Storing the binding cache in non volative storage with manual keying provides reasonable replay protection without requiring IKE. -------------------------------- Stephen Kent responds to Vijay Devarapalli: > The Home Adress Option appears before the IPsec header. At the > receiving node, it is processed before the IPsec header is > processed. Processing the Home Address Option means the IPv6 > source address of the packet is replaced by the contents of the > home address option. By the time the selector match is done, the implementation has to ensure that the home address is the source > address of the packet. Similarly on the sending node, the SPD > lookup should be done as if the source address of the packet is > the home address. If I understand what you are saying, then this seems OK, i.e., if the IP v6 semantics will cause literal substitution of one address for another, then the processing by IPsec will occur after such substitutions and it is not a change to the existing IPsec processing. Is that right? > >> o When a packet is matched against IPsec security policy or >> selectors of a security association, an address appearing in a >> Home Address destination option MUST be considered as the source >> address of the packet. > > > The above text does not mean IPsec code must be aware of the home > address option. It says MIPv6 code in the kernel has to make sure > that IPsec processing is applied as if the source address is the > home address. Some of the current implementations handle this by > adding the Home Address Option after IPsec processing. OK. > The argument is similar for Routing Header Type 2. Current MIPv6 implementations handle this by adding the routing header after > IPsec processing is done (on the sending node) and processing the > routing header before IPsec processing is done (in the receiving node). OK. >> o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the >> protection of packets belonging to the return routability >> procedure. A non-null encryption transform and authentication >> algorithm MUST be applied.[why is encryption needed?] > > > Return Routability procedure involves the mobile node proving to > the corresspondent node that it owns both the Home Address and the > Care-of Address. It exchanges two sets of messages (one from CoA > and one from HoA, tunneled through the home agent) with the > correspondent node. If an attacker is on the mobile node's link > and the mobile node's current link is an unprotected wireless link, > the attacker would able to see both sets of messages. He can then > launch an attack. One can prevent the attack by making sure that > the tunneled packets (through the Home Agent) are encrypted. > Therefore it is required. OK. This should be said explicitly in the text. > You might then ask why isnt the use of tunnel mode ESP a MUST. > This is because some public wireless links provide some kind of > link level encryption which prevents attackers from observing the traffic on the link. > > When you see text like > >> The home agent MUST set the new care-of address as >> the destination address of these packets, as if the destination >> gateway address in the security association had changed > > > It doesnt mean we want the IPsec code do this. It means MIPv6 > code has to ensure this. Almost always MIPv6 exists in the kernel. > Infact our mandate before starting to write this specification was > to make as little changes to IPsec as possible (if possible nothing > at all) Great, but the text didn't convey this, so my concerns may just be wording issues, not technical concerns. > It would be nice if IPsec is aware of the Home Address Option and > Routing Header Type 2 just as how it is aware of Routing Header > Type 0. But that can come later...... > > RFC 2402. > >> Routing (Type 0) -- The IPv6 Routing Header "Type 0" will >> rearrange the address fields within the packet during >> transit from source to destination. However, the contents >> of the packet as it will appear at the receiver are known >> to the sender and to all intermediate hops. Hence, the >> IPv6 Routing Header "Type 0" is included in the >> Authentication Data calculation as mutable but predictable. >> The sender must order the field so that it appears as it >> will at the receiver, prior to performing the ICV >> computation. Whoops! You're right. My mistake. >> o When the set of prefixes advertised by the home agent changes, >> there is a need to configure new security policy entries, and >> there may be a need to configure new security associations. It is >> outside the scope of this specification to discuss automatic >> methods for this, if new home addresses are required. [sounds like too much magic is required here.] > > > We dont know how to do it yet. There is no way for the Home Agent > to verify if the mobile node is authorized for this new home > addresses. If the Home Agent does not verify this, you can have > a mobile node misbehaving with some other mobile node's home address. > If the mobile node uses the same Interface Id for each home address > it generates, the Home Agent can easily verify this. But if the > mobile node uses RFC 3041 address, the Home Agent cannot verify > if a particular home address belongs to a particular mobile node. > > There are a couple of proprietary solutions for this. I am aware > of one. But they are not standardized. I think this does sound like a problem. We don't want to promote proprietary solutions, yet you indicates that we don't have a standard solution and maybe no solution under some circumstances. Is that right? > > The sequence numbers refer to the sequence numbers in the binding > updates. They are stored in the binding cache. If the binding cache > is in non volatile storage, the Home Agent rejects replayed binding > updates after it reboots(even though the same manually created IPsec > SA is used). My comment still stands. Why would one assume that the binding cache is stored differently from the SAD (which contains SA sequence number info), and thus create the problem of SAs that are recovered after a crash, but binding sequence number are lost? > >> The use of a key management mechanism together >> with IPsec can be used to prevent such replay attacks. [poor wording of these last two sentences.] > > > If the binding cache is stored in volatile storage, replay attacks > are possible with manual keying. A dynamic keying mechanism like > IKE would have negotiated a new SA (with a different key) when the > Home Agent reboots and comes up. Thats what the above paragraph > is trying to convey. > > Storing the binding cache in non volative storage with manual > keying provides reasonable replay protection without requiring > IKE. I didn't get that sense from the text. At a minimum, better wording is needed to describe under what circumstances it is reasonable to expect this behavior. Moreover, one could make the same argument about IPsec sequence numbers, but the IPsec WG chose to not do so, so there may be a more fundamental design philosophy issue here. -------------------------------- Vijay Devarapalli responds to Stephen Kent: > If I understand what you are saying, then this seems OK, i.e., if > the IP v6 semantics will cause literal substitution of one address > for another, then the processing by IPsec will occur after such > substitutions and it is not a change to the existing IPsec > processing. Is that right? Right. >> Return Routability procedure involves the mobile node proving to >> the corresspondent node that it owns both the Home Address and the >> Care-of Address. It exchanges two sets of messages (one from CoA >> and one from HoA, tunneled through the home agent) with the >> correspondent node. If an attacker is on the mobile node's link >> and the mobile node's current link is an unprotected wireless link, >> the attacker would able to see both sets of messages. He can then >> launch an attack. One can prevent the attack by making sure that >> the tunneled packets (through the Home Agent) are encrypted. >> Therefore it is required. > > > > OK. This should be said explicitly in the text. This is in the base specification draft-ietf-mobileip-ipv6-21.txt. The MIPv6 specification and this are supposed to go together. We should probably reference the MIPv6 draft for this section. >> It would be nice if IPsec is aware of the Home Address Option and >> Routing Header Type 2 just as how it is aware of Routing Header >> Type 0. But that can come later...... >> >> RFC 2402. >> >>> Routing (Type 0) -- The IPv6 Routing Header "Type 0" will >>> rearrange the address fields within the packet during >>> transit from source to destination. However, the contents >>> of the packet as it will appear at the receiver are known >>> to the sender and to all intermediate hops. Hence, the >>> IPv6 Routing Header "Type 0" is included in the >>> Authentication Data calculation as mutable but predictable. >>> The sender must order the field so that it appears as it >>> will at the receiver, prior to performing the ICV >>> computation. >> >> > > Whoops! You're right. My mistake. We still have a problem with BITW IPsec implementation. It would be nice if IPsec were aware of Home Address Option and Routing Header Type 2. We thought we could take it up later. > >>> o When the set of prefixes advertised by the home agent changes, >>> there is a need to configure new security policy entries, and >>> there may be a need to configure new security associations. It is >>> outside the scope of this specification to discuss automatic >>> methods for this, if new home addresses are required. [sounds like too much magic is required here.] >> >> >> >> We dont know how to do it yet. There is no way for the Home Agent >> to verify if the mobile node is authorized for this new home >> addresses. If the Home Agent does not verify this, you can have >> a mobile node misbehaving with some other mobile node's home address. >> If the mobile node uses the same Interface Id for each home address >> it generates, the Home Agent can easily verify this. But if the >> mobile node uses RFC 3041 address, the Home Agent cannot verify >> if a particular home address belongs to a particular mobile node. >> >> There are a couple of proprietary solutions for this. I am aware >> of one. But they are not standardized. > > > > I think this does sound like a problem. We don't want to promote proprietary solutions, yet you indicates that we don't have a standard solution and maybe no solution under some circumstances. Is that right? No. This is not a problem for MIPv6. This does not affect the basic operation of the mobile node. Nor does it cause interoperability problems. This becomes a problem only when the prefix associated with the current home address is being deprecated and new prefixes are advertised on the home link. Basically renumbering on the home link. Currently a lot of IPv6 protocols break if renumbering happens There is a mechanism in the MIPv6 specification by which the Home Agent can inform the mobile node if there is any change in the set of IPv6 prefixes being advertised on the home link. When I said there are no solutions, I meant none standardised currently. I am sure, once MIPv6 becomes RFC, there will be solutions for handling renumbering and change in the home address. -------------------------------- Jari Arkko responds to Stephen Kent: Thanks for your comments! I think I have now addressed your comments in a new version of the draft, available at http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.html http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsecdiff-292.html Based on the discussion you already had with Vijay, we're suggesting some of the comments are either agreed to be non-issues or deferred to future documents. Here's are the main points: - HOA & RH2 & SPD checks. I think we agreed that this is not an issue, but given your comments this highlights the need to explain this better in the document. I've tried to do this now in section 4.2. - Tunnel encryption: I added text to 4.3 to explain why the tunnel encryption is needed for RR messages. - Inactive/stored in 4.2: I clarified the text. This is something that RFC 2401 doesn't do but the MIPv6 part of the stack should instruct the IPsec part to do. (For instance, by using an API to remove the SAs and then install them back later.) - Automatic methods to get security associations / policy entries for new home prefixes and addresses. Like Vijay said, this is an issue only upon getting new prefixes. Unfortunately, we do not have functionality in this first specification on how to do this except in a very limited sense. Section 11.4.3 of the base specification: "This specification assumes that any security associations and security policy entries that may be needed for new prefixes have been pre-configured in the mobile node. Note that while dynamic key management avoids the need to create new security associations, it is still necessary to add policy entries to protect the communications involving the home address(es). Mechanisms for automatic set-up of these entries are outside the scope of this specification." Of course, this doesn't mean that this is the state of affairs for ever. As Vijay indicated, some vendors have experimented with solutions in this space, so I would assume this will be a matter for standardization sooner or later. - AH and the "is possible to use" phrase. Yeah. Its not a very useful phrase. But note that it clearly says that we are not standardizing the use of AH. (Probably for the same reasons as you don't recommend it.) I happen to believe in explaining the use of a particular security mechanism in the context of an application in great detail. For this specification, we require mandatory support of ESP and we explain the details. However, in order to satisfy the small group of people who wanted to make everything very open and up to the users and implementers, and those who wanted to make it possible to use AH, we added the statement that AH may work as well. I have changed "is possible" to "may be possible" to make the intent more clear. That is, it could work but since the details have not been verified, the responsibility of trying something like that is on the user's side. - DES & the algorithms. Yes, it would be excellent if the IPsec RFCs are updated so that the algorithms move out of the specifications. It'll be easier to reference IPsec for some usage when (a) don't have to warn for DES and (b) can reference AES RFC -- any idea on when that is going to be done, by the way? - Changing the gateway destination address: it could either be an extension of the IPsec functions, or simply a change in the SAs, gotten through an API. This is indicated in the next paragraph in the -04 version already. - "What are the requirements in v1 context?" I'm not sure I understood your comment. The specific things that the mobile node needs to do are listed in the paragraph. (And we better not guess what IKEv2 does, since its not an RFC yet.) Were some of the listed things unclear? - Syntax for the SPD examples: we have invented a specific syntax here since we needed a textual representation. As far as I know, RFC 2401 does not have one -- but perhaps you know of some better format we could use? Is there a specific problem in the mapping between this syntax and 2401? I do admit that was a bad term, I've changed it to and explained a bit about it vs. 2401 in the text, see Section 5. And precedence = SPD entry ordering. - Your question whether the 5.2.4 text on MLD packets is inline with the ESPv2 rules on multicast: I'm not quite sure, but I think so. Remember that the tunnel mode SA between the mobile node and the home agent is unicast on the outside, even if it would carry multicast packets inside. - 5.2.4 comment on setting X to be either AH or ESP. No, the issue is not that we should settle on using either one. Rather, the issue is that we are using a specific tunnel mode SA (ESP) for the protection of traffic. However, inside this SA we might carry some other traffic. WHat we are pointing out here is that it doesn't make much sense to e.g. encapsulate ESP within ESP, and that it generally can lead to problems, or at least implementations don't typically deal well with too much nesting in the SPDs. Is there something we could do to the text to make it clearer? - IKE & replays. We are actually dealing already with the issue, raised by separate folks. This is related to the requirement level of IKE in the spec, and exactly what the effects are either way. We'll get back to you on later when we have some text to show on it! Hope this is sufficient - let us know if not. Thanks a lot again for your review! -------------------------------- Steven Kent writes: I have not had time to read your revisions, although the overall thrust of the responses seemed reasonable. I'm very busy right now so I can't say when I will have a chance to do the necessary review. maybe the security ADs will be able to deal with this without my input this time , and speed up the process. -------------------------------- -------------------------------- -------------------------------- --------------------------------