Network Working Group Jari Arkko INTERNET-DRAFT Ericsson November 2001 Issues in Protecting MIPv6 Binding Updates 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working docuí ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute workí ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts may be found at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories may be found at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires May 20, 2001. Please send comments to the author or to Mobile IP working group. 2. Abstract The Mobile IP working group is currently searching for a security solution that enables semi-secure, weak authentication between IPv6 Mobile Nodes and Correspondent Nodes in the the global Internet. Subí sequent Binding Updates messages will then be cryptographically integrity protected to prevent abuse of the mechanisms for route optií mization. This memo assumes a suitable authentication mechanism exists, and discusses various alternatives on how the BUs can be proí tected. We note that there are multiple alternatives. In particular, the solution space is more fine grained than "Use IPsec for everyí thing" and "Don't Use IPsec At All". Fair amount of detail is necesí sary to explain how the solutions work, whether any standard extení sions are needed, what kind of APIs are needed between stack parts, what the implications are to piggybacking, how the solutions fit situí ations where strong authentication is also a requirement, and so on. 3. Contents 1. Status of this Memo..................................1 2. Abstract.............................................1 3. Contents.............................................1 J. Arkko Expires May 2002 [Page 1] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 4. Introduction.........................................2 5. Main Requirements....................................3 6. Solutions............................................4 6.1. Application Specific Protection......................6 6.2. Existing IPsec AH with a New Next Header Value.......6 6.3. IPsec AH with Policy Extensions......................8 6.4. Application Specific Protection with Optional IPsec..10 7. Piggybacking Binding Updates.........................11 7.1. Implications to Protecting BUs with IPsec............12 7.2. Implications to IPsec Protection of Other Traffic....12 7.3. Bandwidth Implications...............................12 7.4. QoS Implications.....................................14 7.5. Other Implications...................................15 7.6. Other Solutions to the Piggybacking Problem..........16 8. Comparison of Solutions..............................16 8.1. Requirements Fulfillment.............................17 8.2. Header Overhead......................................18 8.3. Computational Overhead...............................19 8.4. Memory and State Requirements........................20 8.5. IANA Requirements....................................21 8.6. Standardization Work.................................22 8.7. Evolution of Authentication Protocols................22 8.8. Error Situations.....................................23 8.9. Optimizations for Busy Servers.......................23 8.10. Address Ownership....................................24 8.11. Implementation Aspects...............................24 9. Conclusions..........................................25 10. Further Work.........................................27 11. Acknowledgements.....................................28 12. References...........................................28 13. Revision History.....................................29 4. Introduction The Mobile IP working group is currently searching for a security solution that enables weak authentication between IPv6 Mobile Nodes (MNs) and a Correspondent Nodes (CNs) in the the global Internet. It is necessary to accept less than perfect security in this situation, because strong authentication between previously unknown peers would require a global Public Key Infrastructure (PKI). With current state of the art, this is neither possible nor desirable. The purpose of the weak authentication mechanism is to establish a Binding Security Association (BSA) between the MN and the CN for the secure exchange of Binding Updates (BUs). The main content of such BSAs are the keying material derived as a part of the authentication mechanism. BUs will be cryptographically integrity protected to preí vent abuse of the mechanisms for route optimization. The main reason for creating such BSAs is actually optimization: after a possibly multi-round authentication protocol has been run, keying material can be created to enable subsequent protection using the BSA, avoiding the need to rerun the authentication. J. Arkko Expires May 2002 [Page 2] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 This memo assumes a suitable authentication mechanism exists, and disí cusses various alternatives on how the BUs can be protected. Furtherí more, we discuss how strong authentication can optionally be used in those situations where suitable trust infrastructure exists, such as inside corporate networks. Even if we discuss the relationship of the BU protection to authentií cation and key agreement, this memo relies only on the ability of these mechanisms to produce BSAs. Technical details of how they are performed are outside the scope of this memo and must be discussed elsewhere. The motivation for writing this memo is to provide a concrete set of proposals for BU integrity protection, in one document together with a comparison of their pros and cons. The memo is outlined as follows. In Chapter 5, we discuss a very high level set of requirements, without going to the details on exactly what weak authentication means as this is already discussed in [2]. In Chapter 6, we introduce the alternative ways on how we think the BUs can be protected. Chapter 7 is devoted to the discussion of how piggyí backing affects the solutions. Chapter 8 compares the alternatives against each other in terms of their security, efficiency, use of preí cious protocol numbers, requirements for new standardization work, and other criteria. Chapter 9 concludes with some of the main findings. In this memo we assume that the authentication mechanisms indeed proí duce BSAs and the optimization to not rerun authentication is a necesí sary one. (It isn't certain that this is the case, however. The matter is discussed elsewhere [22, 23].) 5. Main Requirements The main requirements that are relevant from the point of view of this memo are the following: >> R1: It MUST be possible to integrity protect BUs against in-transit modifications or forgery. >> R2: It MUST be possible to protect the BUs against replay attacks. (This is a requirement, though binding updates themselves contain a mechanism against replay attacks.) >> R3: It MUST NOT be possible for nodes to use their own BSAs to send BUs on the behalf of other nodes. >> R4: It SHOULD be possible to derive BSAs for BU integrity protecí tion from weak authentication. (While this draft assumes the BSAs are derived, we note that this is an optimization and therefore in general we do not require BSAs.) >> R5: It MUST be possible to derive BSAs for BU integrity protection from strong authentication. (By 'strong authentication' we mean mainly IKE, but other possibilities can also be considered.) J. Arkko Expires May 2002 [Page 3] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 >> R6: It SHOULD be possible to use alternative integrity algorithms. All implementations MUST implement one designated algorithm for interí operability reasons. This is a corollary of requirement 4 in [2]. Note that this requirement speaks of the actual BU protection. Authenticaí tion part needs also several mechanisms, as indicated by R4 and R5. Interestingly enough, this requirement set looks very different from that defined in [2]. This is mainly because in this memo we only coní sider the BU protection, and do not go to the details of what the requirements for the weak authentication are. However, we note that the possible inclusion of requirements R2 and R5 to [2] should be coní sidered. It seems clear that R2 is a requirement, while R5 is perhaps controversial, and should be discussed. 6. Solutions In this chapter we discuss various solutions for the protection of the BUs. We note that there are multiple alternatives. In particular, the solution space is more fine grained than "Use IPsec for everything" and "Don't Use IPsec At All". Furthermore, all the solutions have to be described in a fair amount of detail in order to make it clear exactly how they can work, and how they can work together with both weak and strong authentication, and the evolution of protocols for strong authentication. The alternative solutions that will be discussed are listed below: - Application specific protection, i.e. the use of the mechanism defined in the -14 version of the Mobile IPv6 draft [1]. - Existing IPsec AH with a new next header value for BUs. In this alternative we can use the current versions of IPsec AH and IP Secuí rity Architecture since BUs are not piggybacked to other packets. - IPsec AH with policy extensions. Certain extensions to the current requirements for security policy data bases and SA selectors are needed in order to protect BUs that are embedded in the Destinations Options header of packets possibly containing also other payloads. - Application specific protection with optional, additional IPsec proí tection. For instance, we use the -14 mechanism and the weak authentií cation in all situations, but apply also IPsec and IKE within a corpoí rate network. These four alternatives correspond the different philosophical approaches to the problem. The first alternative treats the Mobile IP security problem as a separate issue that should be solved indepení dently of other problems, and at exactly the manner that suits Mobile IP the best way. The second alternative tries to maximize reuse of existing solutions, while possibly making compromises on what kind of functionality can be offered. The third alternative also reuses existing solutions, but does not settle for compromises. Finally, the fourth approach looks upon the specific Mobile IP solutions and gení eral corporate network security solutions as complementary to each J. Arkko Expires May 2002 [Page 4] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 other. It doesn't seem possible to treat the above list completely indepení dently from the way the authentication is handled. For instance, it is possible to use strong authentication but there are several different ways how we can provide it. Therefore, the list below shows what kind of authentication mechanisms can be combined with the above solutions: - Nothing. It should still be possible to use unsecured BUs. - The sole use of a new weak authentication protocol. - The use of a new protocol capable of both weak and strong authentií cation. - The use of a new weak authentication protocol and an existing strong authentication protocol. If an existing protocol is used unmodified, this limits the BU protection mechanism to those supported by the authentication protocol already. In practice, only IPsec AH could be used for BU protection if the authentication protocol is kept as is. - The use of a new weak authentication protocol and an enhancement of an existing strong authentication protocol. This would allow both the use of IPsec AH and the application specific mechanism defined in the -14 draft [1]. Assuming multiple authentication methods can be used (e.g. nothing, weak, and strong), how does one know which one to choose? Currently, there doesn't seem to be any other answer to this than configuration. On a particular network, for instance, all machines could be configí ured to use only strong authentication. Making the selection becomes harder if multiple authentication methods need to be enabled simultaí neously. For instance, strong authentication is always required within a corporate network but to the rest of the world we allow also weak authentication. Typically, VPN-like mechanisms for representing polií cies on IP addresses and networks can be used here. In any case, we take the position here that some form of security MUST be applied to all BUs, and it is not permissible to turn off the BU security. In some recent discussions the use of very simple authentication techí niques such as return routability has been brought up. While this memo does not address that type of solutions we indicate that IPsec-based SAs are fundamentally limited to provide security only through shared secrets. This is the current assumption also in the -14 draft. It appears possible to use simpler types of security as well, such as some methods in Erik Nordmark's proposal [22]. If these simpler methí ods are found suitable, then neither the current -14 nor the IPsec models are appropriate. But as discussed earlier, the shared secrets are used as an optimization, and it remains to be seen if acceptable solutions can be found without this optimization. This is discussed more in depth in [22, 23]. J. Arkko Expires May 2002 [Page 5] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 6.1. Application Specific Protection In this mechanism, the Binding Update and its acknowledgement options are kept in the Destination Options header, and contain an SPI and an integrity check vector. (The options always contain a sequence number as well.) All operations on these security related fields are perí formed within the Mobile IP implementation itself, and no effects outí side the Destination Options header can be seen. Further details on this mechanism are described [1]. No specific user actions are needed in order to configure this mechaí nism. All BUs and their acknowledgements will be required protection, by the software taking care of the mobile IP functionality. In this mechanism, it would also be possible to allow both secured and unseí cured BUs during the deployment phase of secure Mobile IPv6. This would also have to be configured, either as an always allowed but optional security, or on a per network basis. However, we do not recí ommend this and propose that if this method is selected, it is made mandatory to use in all nodes employing Route Optimization. In the case that strong authentication is also desired for BUs, the configuration becomes much harder. There are no key distribution mechí anisms currently designed to key -14 BSAs. As the BUs are kept in the Destination Option header, no next protocol numbers are consumed by this mechanism, but an option number is coní sumed. It is possible to piggyback the BUs on regular TCP or other payload traffic, and there are no effects to upper layers. If this mechanism is used together with traffic flows that for other reasons use IPsec, the rules governing the addition and removal of the Destination Options must be constructed so that the Mobile IPv6 proí cessing offers the same packet for the IPsec AH ICV calculations. This doesn't seem to be a problem. The authentication and key agreement protocol can be run independent of the BUs, or even within the BU packets. It is not possible to use existing strong authentication protocols unchanged in this solution. 6.2. Existing IPsec AH with a New Next Header Value In this approach, the Binding Updates and their acknowledgements are sent in packets separate from actual payload traffic, with a new proí tocol number (or a UDP port). IPsec SAs are used for the BSAs. AH is used to protect the BUs, though the SAs are created using a weak authentication protocol and not IKE. The policy database for IPsec is set up so that packets destined to the particular host with the BU protocol number require the use of a particular SA. This SA is the one that was created for BU traffic to that host. Otherwise the packets are dropped. The weak authentication protocol creates the SAs when the Mobile IPv6 signaling needs them. J. Arkko Expires May 2002 [Page 6] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 Like all other IP and higher layer processing, IPsec policy matching is performed on the used home addresses rather than Care-of-Addresses (see section 10.1 in [1]). This means that a particular IPsec SA can be used even if the MN moves and changes its CoA, and that a particuí lar SPD entry can only be used by the right host. In this case the so called address ownership problem [10] does not exist, since the SPD entries and the SAs have been created only through the authentication protocol, and the SPD entries require the use of a specific address in a specific SA. A typical SPD would contain entries such as the ones below: 1. mn1 to here with proto=BU => use SA1 2. here to mn1 with proto=BU => use SA2 3. mn2 to here with proto=BU => use SA3 4. here to mn2 with proto=BU => use SA4 5. proto=BU => drop In this example the CN at address "here" has had a contact with two mobile nodes at addresses "mn1" and "mn2". Two pairs of SAs have been created to protect the signaling to these, SA1/SA2 and SA3/SA4. All BU traffic to these nodes is protected using these SAs, and any other BU traffic is simply dropped. (Note that as a mobile node sees a need to send BUs to another node, it first runs the authentication protocol which will establish these rules.) The organization of the SPD presented above is just one possible one. In this case an API is required to dynamically update the policy data base from the Mobile IP implementation. In an another type of organií zation, a single BU-related general policy rule would be sufficient, and the correct SAs would be picked with selectors. IPsec has the coní cept of "selectors", which are tied to each SA. The purpose of the selectors is to specify which SA to use within a set of SAs. A typical VPN policy, for instance, might say that all traffic must be encrypted with IPsec. However, since a host may communicate with several other hosts, one SA pair is not sufficient to under this general rule. Instead, a number of SA pairs are established, and the selectors are used to determine which particular SA to use for a particular destinaí tion address. These checks are applied to packets in both directions. In the case of protecting BUs in this alternative, the selectors of each SA would be set to the particular addresses used in the communií cations. In the example the selectors would correspond to checking that the e.g. packets sent through SA1 had "mn1" and "here" as their source and destination addresses, respectively. This organization would require the IPsec implementation to understand a new type of a policy entry, one that should not initiate IKE negotiations even if no SA exists. The user's configuration set-up is interesting. One alternative in doing this is to set up a specific Mobile IPv6 policy entry, but the policies could also be set automatically from the Mobile IPv6 softí ware, which would probably be easier in terms of configuration. In any case, the user can turn on or off the protection, and could also do so on a per-network or host basis. However, we propose that this be J. Arkko Expires May 2002 [Page 7] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 disallowed, and require Mobile IPv6 software to ensure that it the policies are set up so that they only allow either the use of IPsec, or force the BU packets to be dropped. Also, it would not be easy to allow security as an optional service since standard IPsec policy data bases always either demand or disallow security. A single protocol number is needed for the BUs in this alternative. The same number could be used for both BUs and their acknowledgements. No option numbers are needed. Given that the IPsec policy data base is set up to use the protocol number as a decision factor, it is not possible to send the BUs and payload data in the same packets. In this alternative, IPsec can be used also for other purposes, to protect the payload traffic. The policy database must be constructed so that the BU protection rules and other rules do not overlap. All authentication mechanisms are possible in this solution, including the use of existing protocols such as IKE [4]. It isn't necessary to modify the existing protocols. The Mobile IP implementation can look at the SPD when it needs to create a new SA. If a regular IKE-based rule already exists for the particular other host, the SA establishí ment is left to IKE. If not, the weak authentication protocol is run and an SA and the corresponding SPD entry are created. 6.3. IPsec AH with Policy Extensions In this approach, the current model used for representing BUs is retained, but IPsec policy rules are extended beyond the requirements of the current standard. The extension is necessary in order for it to be possible to represent rules about BUs in Destination Options. Curí rently, IPsec standard requires only the possibility to construct polí icy rules based on addresses, protocols (IPv6 next header numbers), and port numbers. The policy database for IPsec is set up in a manner similar to the previous alternative, except that the policies look at the options part, not the protocol numbers. That is, one of the SAs that have been created for the protection of the BUs must be used if the BU option appears in the packet, or otherwise the packets are dropped. The weak authentication protocol creates the SAs when the Mobile IPv6 signaling needs them. The concept of "selectors" also needs to be used. The selectors are tied to each SA, and their purpose is to specify which particular SA to use within a set of SAs. The selectors would be set to the particular addresses used in the communications. This prevents a node from sending other node's binding updates inside its own SA. Again, home addresses are used the policy matching. The user's configuration set-up in this alternative is similar to the previous alternative: the configuration could be done through an explicit Mobile IPv6 entry in the policy table, or automatically from the Mobile IPv6 software. The latter would probably be easier in terms of configuration. Again, we suggest the Mobile IPv6 software or the IPsec user interfaces don't allow accepting cleartext BUs. Otherwise, various different security policies can be set either globally or on a J. Arkko Expires May 2002 [Page 8] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 per-network or host basis. It would not be easy to allow security as an optional service. As the BUs are kept in the Destination Option header, no next protocol numbers are consumed by this mechanism, but an option number is coní sumed. It is possible to piggyback the BUs on regular TCP or other payload traffic, and there are no effects to upper layers. IPsec can be used also for other purposes, to protect the payload traffic. However, this requires the construction of the policy entries in a manner that takes in account the possibility that a packet matches both the BU rules, and some other rules, such as in the case of important TCP traffic that also happens to carry a piggybacked BU. Unlike in the case of separate protocol number, these is no easy way to avoid such overlap in this case. However, given the new, extended, policy rule specifications, these situations must be taken care of in the policies themselves, i.e. the user will dictate what kind of secuí rity will apply to e.g. BUs, TCP, and BUs piggybacked to TCP A typical SPD would contain entries such as the ones below: 1. neta to here with proto=TCP => IPsec with IKE 2. neta to here with proto=* and BU option => IPsec with weak authentication 3. here to neta with proto=TCP => IPsec with IKE 4. here to neta with proto=* and BU option => IPsec with weak authentication 5. * to here with proto=* and BU option => IPsec with weak authentication 6. here to * with proto=* and BU option => IPsec with weak authentication 7. * to here with proto=* => pass 8. here to * with proto=* => pass In this example the CN at address "here" allows traffic with the netí work "neta". Traffic that has TCP is protected with the normal IPsec means, regardless of whether there are possible Binding Updates (rules 1 and 3). Traffic that has only the BU option but no TCP, is protected using weak authentication (rules 2 4). For all other addresses, only the packets containing BU options are protected, regardless of upper layer protocol numbers (rules 5 and 6). As the CN communicates with MNs, the weak authentication protocol creí ates new entries under the given policy rule sets (2, 4, 5, and 6 in our example). The SAs have selectors that ensure the correct SA was used. The selectors would correspond to checking that the e.g. an address "hosta1" within "neta" uses its own SA, not someone else's SA. This means that the selectors for the SAs are more specific than the policy entries, as is described in 4.4.1 option a in [11]. For instance, assuming SAs have been created with hosts hosta1 and hosta2 within neta, the following SA entries and selectors would be found under the policy rules 2 and 4: 2: policy = neta to here with proto=* and BU option SA1: hosta1 to here with proto=* and BU option SA3: hosta2 to here with proto=* and BU option 4: policy = here to neta with proto=* and BU option SA2: here to hosta1 with proto=* and BU option J. Arkko Expires May 2002 [Page 9] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 SA4: here to hosta2 with proto=* and BU option The Mobile IP implementation requires an access to the IPsec SA database in this alternative. The SPD can stay static, but the IPsec implementation must understand that it may not e.g. start IKE negotií ations based on the "weak authentication" policy rules. 6.4. Application Specific Protection with Optional IPsec In this alternative, two different protection mechanisms are applied independently of each other. For instance, we use the -14 mechanism and the weak authentication in all situations, but apply additionally also IPsec and IKE where a suitable PKI exists, such as in corporaí tions. This may lead to the use of two security headers protecting partially the same packet. On the other hand the independence of the Mobile IP and IP security solutions relieves the need to extend policy rules, or to open APIs between the two stack parts. The Binding Update and its acknowledgement options are kept in the Destination Options header, and contain an SPI and an integrity check vector. All operations on these security related fields are performed within the Mobile IP implementation itself, and no effects outside the Destination Options header can be seen. Further details on this mechaí nism are described [1]. An independent protection is provided by staní dard IPsec/IKE means for the traffic specified in the SPD. Given that standard SPD granularity is used, the IPsec protection does not necesí sarily apply only to the BUs, but also to other traffic. This may, however, be in line with security requirements as we will discuss later. There are two aspects to the user configuration in this alternative. There are no specific actions needed to configure Mobile IP security. The IPsec security policies are in this alternative set up in a normal manner, by the user's manual configuration (the automatic procedures for creating SPD entries outlined in section 5.2 do not apply). An example of a configuration is presented below. In this example BU protection is on everywhere, and all traffic to and from network "neta" shall be protected with IPsec: MIP configuration: (empty, always on) IPsec SPD configuration: 1. neta to here => use IPsec/IKE 2. here to neta => use IPsec/IKE 3. * => pass As the BUs are kept in the Destination Option header, no next protocol numbers are consumed by this mechanism, but an option number is coní sumed. It is possible to piggyback the BUs on regular TCP or other payload traffic, and there are no effects to upper layers. However, the IPsec J. Arkko Expires May 2002 [Page 10] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 policies can't be expressed in enough detail to protect just the BUs. This solution allows the granularity of the weak BU protection and the strong protection to be different. That is, it isn't necessary to protect solely the BU packets. Typically, an organization that has a PKI and likes to protect their BU traffic would typically run strong security on all of their traffic (possibly excluding some flows, such as those to port 80). This means that while BU protection is applied only packets that contain the BUs, IPsec would typically be applied on all traffic. IKE or other IPsec authentication protocols would be run in order to create SAs upon the first contact of two peers, and all traffic - including weakly protected BUs - would run inside the IPsec tunnels between the peers. In a variant of this approach, the application layer protection could be turned off where IPsec is available, or turned off when IPsec becomes capable of protecting piggybacked BUs. 7. Piggybacking Binding Updates The Binging Updates are currently specified to be sent within the IPv6 Destination Options. As has been described above, there are some limií tations on how IPsec policies can be used to protect such options. There has been a discussion in the Working Group about the possibilií ties to rethink the position of the Binding Updates in the packets. Placed in its own separate packet, the protection of the Binding Updates would be easier with IPsec. However, in doing so we lose the ability to piggyback Binding Updates on payload packets, which may be an important function in reducing packet counts, contention for the physical medium, and so on. Also, if not allowed from the beginning it may be hard to add the piggybacking functionality later. Yet piggyí backing causes also problems, and could be seen as extra complexity. In order to understand the consequences of removing piggybacking, this chapter studies the consequences of either allowing or disallowing piggybacking. The following aspects will be studied: - Effects to the use of IPsec in the context of Binding Updates. - Effects to the use of IPsec of other traffic. - Effects to the amount of bandwidth consumed. - Effects to header compression on low-bandwidth links. - Effects to QoS mechanisms. It should also be noted that the term "piggybacking" can be understood in different ways. Here, we use it to mean end-to-end BU piggybacking to payload packets. Other possible meanings include link layer piggyí backing, and end-to-end generic piggybacking for not just BUs but all IPv6 packets. J. Arkko Expires May 2002 [Page 11] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 7.1. Implications to Protecting BUs with IPsec The use of piggybacking precludes the use of IPsec with current staní dards, as the granularity of the policy mechanisms does not allow sepí arating packets that have important options. As described in section 5.3, it is possible extend these mechanisms. (Implementors have also reported on the mailing list [19, 20] that they have made local (not visible on the wire) modifications to their implementations to allow piggybacking with IPsec. This is however posí sible only if you have access to the IPsec implementation.) 7.2. Implications to IPsec Protection of Other Traffic Note that the effects of piggybacking are more related to the transí port of two different items within one packet, than to the storage of one item within the options header. The current policy mechanisms are unable to handle multiple items with potentially differing security needs. Therefore, substituting options for a new intermediate header type doesn't by itself solve the policy problem. If piggybacking is needed, then policy conditions relating both to BUs and the payload traffic will be necessary, allowing users to dictate how the various combinations of these will be protected. If piggybacking isn't needed, a slightly simpler policy mechanism suffices, as it would only be necessary to match individual messages, not combinations of BUs and other traffic. (Current IPsec policy mechanisms would suffice if a separate protocol number (or port) was used for BUs; IPsec extensions would be needed if they still were contained in the Destination Options.) Does piggybacking have other effects to protecting the payload trafí fic, assuming either application layer protection or enhanced IPsec policy processing handles the BU protection? The enhanced policy proí cessing certainly allows the users to pick their own security polií cies. However, it is still possible that fundamental conflicts occur in how the user wants the traffic to be protected. For instance, in order to protect the BU part, AH would be needed but the payload trafí fic could need confidentiality protection through ESP. It appears that these conflicts can be handled by providing both AH and ESP protecí tion, as allowed by the current specifications [11]. Finally, it has also been suggested [9] that the use of piggybacking could be selected by the sender of the BU, based on the existing secuí rity policies. The sending node would select piggybacking only if no security headers are needed. Another idea taking this a bit further is that the the piggybacking could only be allowed if the security policy towards the other node requires all protocols to use the same SA [3]. 7.3. Bandwidth Implications The number of BUs sent by a MN varies, and in case it talks with seví eral CNs, each movement may generate similarly several BUs. In this sense the amount of space consumed by the BUs does matter. J. Arkko Expires May 2002 [Page 12] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 Sending the BUs as separate packets causes an immediate need to send an extra packet which implies a certain number of extra transferred bits. On LAN networks the effect of this is an extra 40 byte IPv6 header. This is probably not noticeable, unless a central server keeps a very large number of binding cache entries. In order for the extra overhead to reach a substantial fraction of the traffic of a central server, the server must receive much binding update traffic compared to the amount of traffic resulting from its transactions. For instance, consider a server that on average receives a BU on every tenth request and has request size of 100 and response size of 200 bytes. The overhead cause by extra BU messages for this server would be ((40+40)/10) / (100+300) = 2.7%. However, the most pressing issues in bandwidth conservation are probaí bly not in larger servers or LAN traffic but in hosts operating behind cellular or other highly constrained interfaces. There, an additional 40 bytes is a significant cost even if not sent often. But the estií mation of the difference between piggybacked and separated packet is harder since on these interfaces advanced header compression mechaí nisms and other techniques are typically used. As an example, we have considered the ROHC header compression schemes [12]. Its adoption in various cellular standards as a compression mechanism justifies its use as an example. The techniques in ROHC allow collapsing the IP and transport layer headers when they don't change or change predictably between packets. Interestingly, ROHC is capable of dealing with options as a difference that can be sent without requiring the full IPv6 header to be repeated. This means that when ROHC is used, piggybacked BUs only cause extra bandwidth usage that is close to proportional of the size of the BU headers. When a separate packet is sent with a new protocol number, the first time ROHC needs to send a full IPv6 header as well as the BU itself. Subsequent Binding Updates can be compressed, and the payload stream continues to be compressed independently of the new BU stream. Thereí fore, in the case of ROHC, piggybacking is in the long run roughly equivalent to the non-piggybacked case. There is a difference for the first packet, of roughly 40 bytes. At present, ROHC has special support for RTP, UDP, and some of the basic IPv6 extension headers. It compresses other extension headers in a generic way. ROHC will be able to compress the BUs partially or completely away regardless of whether they are in a separate header or inside the Destination Options [21]. While not directly relevant for the piggybacking discussion, we should note that ROHC supports both AH and ESP [12, section 5.8]. Small changes in these and other IPv6 extension headers can be sent as difí ferences. The DOCSIS PHS is another example of a compression mechanism. It uses bit masks to signal identical fields, and would appear to be able to work well both with at least non-piggybacked traffic, provided that J. Arkko Expires May 2002 [Page 13] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 separate contexts again would be held for BUs and other streams. DOCSIS also allowed more than one frame to be sent on a single transí mission opportunity. This allows non-piggybacked traffic to use the same opportunity, not changing the number of sent bits but reducing delay even if the BUs are sent separately. The use of header compression for Binding Updates is also affected by movements. Unless there is a context transfer between base stations, compression state of the BU sender is lost in any case at the time the BU is sent. BU receivers will still be able to use compression, howí ever. 7.4. QoS Implications When Mobile IP signaling and payload traffic are combined in the same packets Quality-of-Service (QoS) conflicts may occur, as the user may have wanted to assign different priorities to them. The relevance of this can be questioned, as the growth of the packets is only marginal and the packet could reasonably be expected to be tagged with the flow label of the payload regardless of the additional options. Also, the sender has the possibility to send packets separately if the QoS polií cies are in conflict. However, such separation is only possible for the sender and not for any of the routers in between. (The routers are in some architectures responsible for the QoS tasks.) A more serious QoS problem appears in cellular networks where specific channels have been allocated for the host to send and receive e.g. multimedia streams. Any TDM-like slot allocation scheme may need such QoS reservations. Such channels have been calculated to be able to carry exactly the stream (even taking in account ROHC and other header compression techniques) but nothing else. An additional signaling payí load appended to the stream would essentially force the packet to be dropped, or routed through best effort channels. In the case of coní versational services, the latter alternative would also in practice mean losing the whole packet, because it would be unlikely to arrive in time to be useful. As far as an individual cellular terminal is concerned, it can make smart decisions about when to piggyback and when to not. However, this option does not necessarily exist for the other end of the communicaí tions; a MN carelessly sending a piggybacked BU along a stream to its correspondent cellular host might cause the BU information and a frací tion of the stream to be lost. Specifically reserved tight channels are a fact of life. However, it is perhaps fair to note that making IP run inside them is already difí ficult even without piggybacked BUs. Header and other compression mechanisms produce variable length results, and the in the case of Mobile IP the channel reservation may have to take in account not just the BUs, but also other options. What is different, however, in the case of BUs is first of all their size - at least two dozen bytes - which may make it hard for them to fit the slack, and it is undesirí able to reserve so much extra space. Secondly, BUs are dynamically J. Arkko Expires May 2002 [Page 14] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 changing while e.g. Home Address options are other similar headers are static. Static headers in general are always compressed away, and in any case predicting their size is easier. Piggybacking may also interact with resource reservations at the IP layer, such as those performed by RSVP. 7.5. Other Implications It has been said that piggybacking is used today also as a facility to send the BUs at an appropriate time, conveniently along other traffic. The intent is to not send binding updates until it is proven that furí ther traffic to the Correspondent Node exist. On the other hand, it appears that this convenient mechanism can't be used all of the time, given that it only works in one direction, and does not allow for optimized routing of packets sent by the CN. For this reason typical implementations wait a while and send the BU in any case if no other traffic has appeared [19]. We also note that in both piggybacked and separate packet solutions we can achieve the same goals. A BU should be sent at a suitable time, specified in the standards or left to the optimization logic of varií ous implementations. With piggybacking, a BU can be attached to the packet that is destined to the CN. Without piggybacking, the appearí ance of a packet destined to the CN would trigger the sending of another packet along it. Similar functionality exists today on all IPv6 stacks to send address resolution messages and other control traffic, so it seems that it on most stacks it should be possible to generate new packets based upon seeing traffic to a particular destií nation. One difference between the piggybacked and the separate packet soluí tions is that in the latter we can not guarantee that the BU arrives at the CN before the payload packet. The BUs are used in the route optimization functionality - which is optional - and decided on a case-by-case anyway by implementations. Therefore, the payload traffic will get to the other end and back regardless of the BUs. If the sepí arate BUs are delayed behind the payload packets, it is possible that the payload response comes through an unoptimized route. However, let us assume that the first two packets along a router are going to be reordered. In the piggybacked solution this means that the regular packet gets to the destination first, following the packet that has the piggybacked BU. In this situation one packet needs to be routed through the home. In the non-piggybacked solution the BU and the first payload packet get reordered, and again one the result is that one packet needs to be routed through the home. Assuming packets are routed through the home works best, however, only when the MN - CN first contact each other and don't have an existing Binding Cache Entry. Where an entry exists, and the MN is now moving to another location, it becomes essential to be able to inform the CN as soon as possible, as otherwise packets may get lost to the previous location. As has been discussed earlier, it is also possible that the addition of the BUs may cause the packets to be routed differently, and may J. Arkko Expires May 2002 [Page 15] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 already imply delayed reception. On the other the BU packets - small packets - may easily get different treatment than the regular packets, making it slightly more likely that a reordering will occur. In coní clusion, there does not seem to be a fundamental difference in this regard. Firewalls and other similar devices should be able to process piggyí backed packets, even if they have BU options in them. If they do not let such traffic through they will also not let regular Mobile IP Home Address options through, blocking all traffic. If the BUs are sent in separate packets, the firewalls have to have rules to allow this trafí fic in. A similar situation to the BU problem appears in the case of RSVP and the Router Alert options [17]. In this case IPsec was not used and the option was kept as an option. As has been indicated elsewhere [23], it may be necessary to run some of the weak authentication protocols as a separate protocol/port rather than as a Destination Option, in order be able to pass suffií ciently long public key values. This does not have an effect to the piggybacking as such, because where such long public keys are needed, the BSA-based approach will be likely necessary and therefore the weak authentication and actual BUs can run in different protocols anyway. 7.6. Other Solutions to the Piggybacking Problem It has also been suggested that a more general purpose multi-payload IPv6 mechanism could be developed [13]. This would allow adding piggyí backing later in as an option, and could tackle the IPsec problems in a general way and without delaying the Mobile IPv6 standardization. One worry around this solution is that the Mobile IPv6 implementation may not have enough capabilities to direct the merging of packets. For instance, if the merging is implemented as a general IP layer function, it is not guaranteed that BUs get merged unless two packets are actually seen simultaneously. As the first packet may already be partially out from an interface, it is not clear that the function will see these packets early enough. However, it appears that this problem can be solved by having the Mobile IP code perform the merging when it detects a need to send a BU. A more serious problem in this solution comes from the partial deployí ment, which obviously can't be avoided as such multi-payload schemes are not a part of current IPv6. How does a node know when the receiver supports this feature and when not? It may be possible to use responses, errors, or the lack of these as an indication of the receiver's support. However, it is not clear what kind of implications this has for the additional messaging, start-up times, and so on. 8. Comparison of Solutions The following criteria are used in evaluating the pros and cons of the presented solutions: J. Arkko Expires May 2002 [Page 16] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 - Requirements fulfillment. For instance, do the solutions allow both weak and strong authentication? - The header overhead of the solution, and the number of extra packets required. - The computational overhead of the solution. (Note that public key cryptography, Diffie-Hellman, and other overhead related to authentií cation is not under discussion here. It is assumed that the user orgaí nizations select between the heavier strong authentication protocols and the lighter weak authentication protocols. The comparison of parí ticular authentication protocols such as BAKE [6], SUCV [7] and others [18] also isn't the subject of this memo.) - The memory and state requirements of the solution. - The necessity to allocate Destination Option or Next Header numbers from IANA. - The required standardization work. - Are the mechanisms future proof, as the current strong authenticaí tion protocols evolve to new ones (which is expected to happen with the Son-of-IKE effort). - Ability to handle error situations. - Ability to optimize behaviour for busy servers. - Ability to ensure that the right BSAs are used for the right BUs. - Implementation aspects. 8.1. Requirements Fulfillment Like the other alternatives, the application specific solution fulí fills the requirements for integrity protection and replay protection, the former through the -14 mechanisms and the latter through the BU replay counters. This alternative also allows the use of a new weak authentication proí tocol, or a new protocol capable of both weak and strong authenticaí tion. The use of an existing strong authentication protocol isn't directly possible, an enhancement of both the protocol standards and the implementation would be necessary. The enhancement necessary for e.g. IKE [4] would involve adding a new protocol along the side of AH and ESP with possible other parameters such as algorithm identií fiers. This would be an extension of the current IPsec DoI [5]. The -14 mechanisms can satisfy the requirement to be able to use difí ferent algorithms. However, at the moment [1] does not define even a single algorithm, let alone alternatives. J. Arkko Expires May 2002 [Page 17] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 The IPsec based alternatives fulfill the requirements for integrity protection and replay protection, both through AH mechanisms. Note that an additional layer of replay protection exists at the BU mesí sages. It isn't possible to remove the fields related to this, as IPsec provides only replay protection but not sequenced delivery. For the Mobile IP route optimization to work, sequenced delivery is also needed. Existing IPsec AH can use both weak and strong authentication protoí cols. There is no need to modify the strong authentication protocols, or the IPsec stack in order to make this possible. However, a local API must exist between the new weak authentication protocol and the IPsec implementation in order to set up suitable policy entries and SAs. IPsec AH with extended policy rules allows the use of a new weak authentication protocol, or a new protocol capable of both weak and strong authentication. The use of an existing strong authentication protocol isn't directly possible, an enhancement of both the protocol standards and the implementation would be necessary. The use of a new weak authentication protocol and an enhancement of an existing strong authentication protocol. The enhancement necessary for e.g. IKE [4] would involve an extension of the client identifiers to support the extended policies capable of differentiating IPv6 Destination Options. It is not possible to use existing strong authentication protocols unchanged in this solution. All IPsec AH based solutions satisfy the requirement on being able to use different algorithms. A set of standard, mandatory algorithms exists, as well as many optional ones. The use of both application specific and IPsec mechanisms fulfills the requirements for integrity protection and replay protection. Various combinations of authentication protocols could be used in this alternative, but one particular combination seems most suited. Namely, a new weak authentication protocol could be used to key exclusively the application specific protection of BUs, and an optional strong authentication protocol would build SAs that use IPsec around them. 8.2. Header Overhead In the application specific solution, the integrity protection related parts in the BUs contain the authentication data length, SPI, and authentication data fields. The length of the last field is not given, but assuming a typical 96 bit field is used, the total overhead from this is 17 bytes. IPsec AH-based solutions add the SPI, sequence number, next protocol, and MAC fields. The total number of additional bytes is 24. For the combined use of both application specific and AH mechanisms there is a fixed cost of 17 bytes in all BU messages. An additional cost of 24 bytes is applied to those messages that use also the J. Arkko Expires May 2002 [Page 18] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 IPsec/IKE-based security. Therefore, a total of 41 bytes overhead may be reached in the worst case. The number of packets in the application specific, extended IPsec, and combined alternatives are the same as piggybacking can be employed. In the use of existing IPsec AH there are N additional packets, where N is the number of BUs and their acknowledgements sent. 8.3. Computational Overhead The application specific scheme runs a cryptographic hash over specií fied fields, typically 62 bytes assuming there are no BU suboptions. The nature of the cryptographic hash hasn't been specified, but we can safely assume it is similar to mechanisms used elsewhere such as HMAC MD5. The number of bytes used in the input to the hash function has signifí icance, though the hash functions typically have some amount of static cost so that the computational overhead is not linear with respect to the number of input bytes. In one implementation of HMAC MD5, a four- fold increase in the size of the packet increased the amount of time spent by 33% (for small packets). The same implementation achieved speeds of around 60 Mbit/s, or 100,000 MACs/s for an input of size 62 bytes, on a Pentium 600 MHz machine. Increasing the size fourfold changed these numbers to 170 Mbit/s and 75,000 MACs/s. Similar numbers are also available for other implementations [14]. These numbers indicate that a relatively large number of BUs can be treated with typical computer systems; likely far more than is required for anything else except the busiest servers. On a smaller devices such as handheld cellular devices, the available power is much smaller but so is also the number of BUs that need to be treated; it is hard to imagine why a device with a constrained interí face towards the Internet would have to process even 1 BU/s. IPsec uses also standard cryptographic hash functions, which we assumed would also be used in the application specific protection. In contrast to the BU suboption, however, the hash is run over the whole packet. Assuming the size of a BU protocol running directly on top of IP would be roughly the same as in a BU option, the total number of input bytes would be 40 from the IPv6 header, 18 from the Home Address option, 24 from AH, plus 10 from the BU protocol, i.e. 92. These numbers imply that the pure cryptographic operations necessary in this alternative are roughly equivalent to those needed for BU proí tection in the application specific manner. In addition there are IPsec-related tasks such as policy matching and header processing which are harder to quantify. Implementations also differ much in this respect, as some may be using sequential searches and others trees. One good software-based IPsec implementation reports the speed of 65 Mbit/s with AH HMAC_MD5 in transport mode, on a Pentium 800 Mhz machine, and 82 MBit/s when policies were being checked but none of the packets needed security. The unsecured IP performance was 85 Mbit/s [14] on the same machine. J. Arkko Expires May 2002 [Page 19] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 In any case, these numbers again indicate sufficient capacity to deal with BUs under most normal circumstances, possibly with the exception of the busiest servers. A crucial factor is the amount of BU traffic vs. other traffic. Let us assume 10 KB regular traffic interrupted by a 0.1 KB BU, and a system that would handle 10 Mbit/s BUs. Even if the reference used above didn't describe the packet sizes used in the test, it seems safe to assume that a single CPU would be able to haní dle this load. But under these assumptions, the system would also be handling 1 GBit/s other traffic. If there's only 1 KB (one large packet) of traffic between the BUs, then this number would be 100 MBit/s. Application specific protection would allow easier treatment of policy processing and SA searches, as the Binding Cache Entries could be used to store the right BSA (or a small number of them, in case overlapping BSAs are allowed). This means that it would not be necessary to create an efficient data structure to make a fast search, as is the case in IPsec. The computational overhead for extended IPsec is similar to that of existing IPsec, except that now also the payload contents may be included in the hash calculations. Assuming the average original packet size of, say, 300 bytes, this makes the real packet size with all options and AH to be 352. This is also the input to the hash funcí tion. Given our earlier measurement data, it doesn't seem that the size of the packets matters as much as might be expected. Some increase in CPU demands will be seen, however. In the combined use of application specific and IPsec solutions, the computational overhead at the minimum is the same as in the applicaí tion specific protection, i.e. running a hash over 62 bytes. In case IPsec/IKE-based security is used in addition, then an additional secí ond hash needs to be calculated. Assuming again the 300 byte average original packet size, this amounts to running a hash over 369 bytes. Again, the size of the input to the hash operations does not seem to have significant importance. However, the number of operations is important and in this situation there are two. The two hashes are calí culated, however, only within the protected network communications. All IPsec-based approaches typically require calculating the MACs once the whole packet has been completed and formed. In contrast, the BU suboption method allows doing this somewhat earlier as the BU is being created. This may offer the advantage of being able to perform the cryptographic operation at the time of the movement, not at the time we are waiting to get some payload traffic to the peer. This may also be useful for a retransmission of a BU. 8.4. Memory and State Requirements In the application specific solution, a security association data structure is needed for every BSA established to protect the BUs. The J. Arkko Expires May 2002 [Page 20] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 current assumption is that the BSAs are unidirectional, but unlike the IPsec solution they could also be bidirectional and thereby halving the memory requirements. Note that there may in any case be multiple concurrent BSAs per each MN in order to allow for smooth rekeying. Each BSA must contain information about the used integrity key (typií cally at least 20 bytes), the SPI (4 bytes), lifetime (4 bytes), algoí rithm (under 1 byte) and an implementation dependent amount of adminí istrative information, such as pointers to Binding Cache entries, statistics, and other relevant information. Security association data structures are needed also for the IPsec SAs. IPsec SAs are a bit more general-purpose than application speí cific SAs, including for instance encryption keys, selectors, lifetime and statistics information, and other similar data. Typical implemení tations use memory in the order of, say, 400 bytes for each SA. An implementation optimized for memory usage could cut this down to around 170 bytes, most of which is spent on the IPv6 addresses needed for the destination and selector addresses. In addition to the SA information, the IPsec implementations (may) need to add policy entries related to each specific host. These need both memory, and execution time for each packet. Typical implementaí tions would perhaps use a similar amount of space for a policy entry as they do for an SA. On a MIP-specific solution, we didn't need this as the policy is hardcoded to the processing of the BUs. There isn't much information available on how large number of SAs and policy entries typical implementations support. Special hardware devices can support tens of thousands of simultaneous connections [15]. A central question is the support for a large number of SAs in typical server OS implementations. Smart implementations can provide logarithmic-time processing of security rules and SA databases [16], but some implementations may be built more around VPN access scenarios (small number of SAs) rather than end-to-end security towards multiple directions. There may be optimizations available for devices that do not want to support IPsec in general and only want to support it for BU protecí tion. In this case it is possible to eliminate execution time overhead for other packets, and to use the Binding Cache entries and BSAs as the sole packet matching mechanism. The memory and state requirements for combined application specific and IPsec alternative is (roughly) a sum of the requirements for the two mechanisms. 8.5. IANA Requirements The application specific solution requires a Destination Option number to be allocated for the BUs. The existing IPsec AH solution requires a new IPv6 next header value - a more valuable resource - to be allocated. J. Arkko Expires May 2002 [Page 21] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 With an extension to the IPsec policies, only the Destination Option value needs to be allocated. In the combined use of IPsec and the application specific mechanism the situation is the same, and only the Destination Option value needs to be allocated. 8.6. Standardization Work No standardization work outside the Mobile IP WG is needed for the application specific solution. However, if an existing strong authení tication protocol needs to be used also, then it needs to be extended. This likely needs IPsec WG involvement. Of course, strong authenticaí tion could also be built in to the Mobile IP specific protocols. In the use of existing IPsec, no standardization work outside the Mobile IP WG is needed. Even if strong authentication protocols need to be used, they can be used as is. The extension of IPsec to cover individual Destination Options would need an action from the IPsec WG for a small extension to both IPsec and its key management mechanisms. The combined use of application specific solution and IPsec requires no standardization actions, even if strong authentication is needed. All solutions relying on IPsec AH may suffer from the possible action in the IPsec WG to deprecate AH. This has been discussed from time to time, mainly under the argument of reducing the complexity of IPsec. If this happens it may be possible use ESP instead of AH [3]. 8.7. Evolution of Authentication Protocols Here we discuss the effects of evolving authentication protocols. Such evolution takes place on two fronts. First, as the weak authentií cation area is a new one, we can expect new and better protocols to appear for this purpose. Secondly, also the current strong authenticaí tion protocols and IPsec are under evolution, such as the work on Son- of-IKE which has been prompted by the complexity of IKE. The application specific solution can - if designed right - accommoí date new weak authentication protocols easily. It is necessary to proí vide a clean separation between the BU protection and the authenticaí tion protocol, but this should be easy. The application specific solution can also accommodate existing strong authentication, provided that they are extended to support the BU proí tection protocols. The ability of this solution to follow the evoluí tion of such strong authentication protocols depends heavily on the interest of their developers to retain non-IPsec support in the protoí col if it is extended, simplified, or redesigned. It is therefore not fully certain that new protocols also allow the same thing. J. Arkko Expires May 2002 [Page 22] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 The use of existing IPsec is more certain to be possible even if the keying protocols evolve. If IPsec is extended to cover also individual Destination Options, new keying protocols should also be able to do this. Unless there is a desire to simplify things, but one could expect that such simplification could be foreseen as the extension itself is discussed. The combined use of application specific protection and IPsec allows evolution both in the weak and in the strong authentication protocols. 8.8. Error Situations Application layer mechanisms in general have more context information available regarding various error situations than IP layer solutions. IPsec discards packets if they are in any way unexpected. The question regarding BU protection is if there are any situations where other treatment of BU protection error cases is needed than discarding. For instance, if the last message of an authentication protocol would happen to arrive after the first protected BU has been sent, IPsec would simply discard the packet while an application specific mechaí nism might store it in the anticipation of completing the authenticaí tion soon. It isn't clear how important this case is, however. There might also be some DoS implications on doing this. Another problem appears with weak authentication protocols that piggyí back the authentication / key agreement messages in the final BU that is sent from the MN to the CN. Here, the BSA should exist as the packet is being processed, but the BSA will actually be created only after looking a the authentication option in the packet. For the application specific security, it is easier to e.g. process BU subopí tions in a specific order, but for IPsec AH the processing happens at a predefined order. Some weak authentication schemes such as [6] do not have a problem with this, because they have specified an ordering that allows the BSA establishment to take place before the BSA is creí ated. Some others such as [18] make use of BU suboptions, making it harder to create an IPsec SA at the same time the option itself is being processed. The practical effects of this issue is that the use of IPsec forces either a separated authentication packet, or an orderí ing of the Destination Option and AH headers. 8.9. Optimizations for Busy Servers It is possible that on some busy servers the computation or memory loads exceed the capabilities of the hardware. It is possible though for server manufacturers to add a feature that enables the device to age BUs faster and/or refuse weak authentication and optimized routing if the load grows too high. The optimizations for IPsec are similar to those for application speí cific protection of BUs. The main optimization is reducing the number of BSAs, and the use of optimized routing. J. Arkko Expires May 2002 [Page 23] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 In the combined alternative, similar optimizations exist for the application specific protection as has been described earlier. For the additional IPsec protection, there aren't such possibilities. The security policies require the use of IPsec for the traffic within the part of the network that is expected to be protected. 8.10. Address Ownership In all alternatives, it is assumed that the authentication protocol somehow determines the right of a particular peer to claim ownership of a particular address. For instance, BAKE relies on the difficulty of an eavesdropper to simultaneously see messages along different paths to prove a weak form of address ownership [6]. An BSA is estabí lished after the determination is made. This is, however, not enough. It is also necessary to ensure that subí sequent communications do not violate the address ownership. For instance, a MN might establish a legitimate BSA with a CN, and then use this BSA to send a binding update for another MN. In the application specific solution, it is necessary to ensure that the BSA is used only with respect to the same Home Address that was used also for the authentication part. Currently, this hasn't been specified in the draft, but could easily be added. In the case of IPsec, the dynamic updates to the SPD and/or the selecí tors in the SAD must be used to create the same effect. The individí ual policy entries, or the selectors of each SA would be set to the particular addresses used in the communications. Note that like all other IP and higher layer processing, IPsec policy matching is perí formed on the used home addresses rather than Care-of-Addresses. This means that the given SA can only be used with the original Home Address. In the case of combined use of application specific and IPsec mechaí nisms, both solutions presented above are used together. 8.11. Implementation Aspects The application specific solution can be programmed in isolation from the rest of the IPv6 stack. No new APIs are needed for the security part. Security association lookup can be performed using the same data structures that are used for finding Binding Cache entries. (We do need to allow for multiple BSAs towards the same peer, but given that they would typically be just 1 or 2 it doesn't appear to require a very optimized search tree.) On the busiest servers, it might be necessary to provide some hardí ware-level acceleration mechanisms. Some existing hardware chips could be used for this purpose, though some other chips are more taií lored towards specific IPsec processing, and are not applicable. If IPsec is used, then an API is needed towards the SPD and/or the SAD, so that the Mobile IPv6 implementation can add/delete entries J. Arkko Expires May 2002 [Page 24] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 from them. It is also necessary to ensure that the IPsec implementation is capaí ble of handling large amounts of SPD and SAD entries efficiently, if the stack is going to be used in servers that have many clients. This may mean improving the SPD matching mechanisms and/or SAD lookup. In the case of normal IPsec processing, there doesn't exist a similar Binding Cache entry that was used in an optimized lookup in the applií cation specific solution. (However, there may be possibilities to optimize this even for IPSec when just BU protection but not general IPsec functionality is needed, as discussed in section 8.4.) IPsec implementations may take advantage of existing hardware chips, and their use in current and future products. IPsec implementations in general are more complex than providing just the -14 mechanisms. 9. Conclusions The purpose of this memo is to mainly list the solutions and their respective advantages and disadvantages. We do not make a recommendaí tion here to select a particular solution as some of the pros and cons are not easy to weight against each other. We hope, however, that this memo helps the Mobile IP Working Group to see the complete situaí tion, and reach a consensus on how the solutions weigh against each other. However, the author would like to offer a few observations: - It is crucial for the selection that we decide what the minimum level of security offered will be. If the WG wants to have security where keying material is not created at all, it appears that only application specific solutions are possible (possibly combined with IPsec). Note that the keying material generation in e.g. BAKE is intended to be an optimization, caching the knowledge that a certain type of return routability was verified. Without the keying material, a BAKE-like check needs to be performed for all BUs. - Another crucial decision is the 'philosophical approach' we want to take. The approaches are discussed in the beginning of chapter 6. - In header overhead, the application specific solution is the smallí est one, though the difference is not big (17 versus 24 bytes). If both application specific and IPsec mechanisms are used, the overhead is large but only when strong authentication is also applied. - Preliminary results regarding the effects of piggybacking indicate that typical header compression mechanisms result in similar bandwidth usage for both piggybacked and non-piggybacked cases. Essentially, the changing components of packets need to be sent. However, these results depend a lot on the particular situation, compression end-point locaí tion, and so on. Also, the effect for stationary BU receivers is difí ferent than for BU senders that may have to start with a new J. Arkko Expires May 2002 [Page 25] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 compression context after movements. It should be noted that there are complexity, QoS channel reservation, and other issues with piggyí backing so it is not clear that it is always desireable. - In particular, piggybacking makes cellular network channel reservaí tions hard and/or inefficient. Such reservations are necessary on some networks, and it is not possible to reserve space for occasional Mobile IP signaling in them. - Strong authentication should be allowed as an option for certain organizations. In those organizations, there is likely a need for securing other traffic as well, and it might be wise to consider not duplicating the configuration effort etc. for Mobile IP and other applications. - Adding strong authentication support to protocols such as BAKE may not be easy. Relatively complex PKI protocols have to be managed, some organizations would prefer legacy authentication schemes which would make even the PKI approach insufficient, etc. - IPsec allows easier evolution in the authentication protocols. For instance, organizations that require strong authentication could use legacy as well as PKI-based authentication through IPSRA solutions. The modification of e.g. IKE to support also the application specific protection is not a recommended approach. - It is possible to use IPsec for BU protection without modifications to the IPsec standards. However, Mobile IPv6 will have to be changed to use a separate protocol number for the BUs and not allow piggybackí ing. In this alternative, a new IPv6 protocol number (or UDP port) would have to be allocated, which can be considered a more valuable resource than the current Destination Option values. - It is also possible to extend IPsec policy mechanisms and then keep Mobile IPv6 unchanged. However, while the modifications are small there are currently a number of other things on the table in the IPsec WG, and therefore making these extensions might cause a delay. - There doesn't seem to be a huge performance difference among the solutions in the sense of cryptographic computations. Possible perforí mance differences can be found in the policy matching area, where IPsec needs to do work that is more straightforward in the application specific solution (though it still needs to be done). It is hard to quantify these, however, as the implementations differ in how effií ciently they have solved the issue. This is relevant mainly for very large servers with large Binding Caches. - Optimizations for busy servers are possible in all presented alterí natives. IPsec demands more memory per BSA, though. - Address ownership issues can be solved all of the presented alternaí tives. J. Arkko Expires May 2002 [Page 26] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 - IPsec is more complex to implement than the pure application speí cific solution. On the other hand, one can take advantage of existing hardware and software support on a number of products. This situation may continue in the future as well, as BU protection may not be in sufficiently high demand to force server vendors to have hardware supí port for it. - In complexity, the main focus should be paid to the key management parts rather than the IPsec or -14 parts, because that's where most complexity lies. An added complexity in the BU protection part may be justifiable if a larger complexity reduction can be achieved then on the key management part. 10. Further Work The author seeks feedback from the Mobile IP and security communities to verify that the presented solutions are complete, secure, and can be implemented. This memo discusses only the BU protection issue and leaves the weak authentication mechanisms to be discussed by other work. Likewise, we take no stand in the selection or future development of strong authení tication mechanisms such as IKE, Son-of-IKE, KINK, and others. The security between the Home Agent and the Mobile Node isn't covered in this memo, even if it also involves the use of Binding Updates. It is likely that strong security could be applied in this context, given that there the home and the mobile have a pre-arranged relationship. The current version of this memo discusses only the use of IPSec AH. It may be possible to use also ESP as is discussed in [3]. This might become necessary if we get an indication that the AH protocol would be deprecated (which is periodically discussed by the IPSec WG). Hiding the home address of mobile nodes hasn't been considered as a requirement for this work. There might be some possibilities for doing this through the placement of the BUs after an ESP header. However, this would need to be done for all traffic and not just the BUs. Also, what has been stated in this document about the policy rules and selectors that match the home address would no longer hold. Michael Thomas has suggested that existing strong authentication proí tocols such as IKE could be used as-is even for the weak authenticaí tion, by employing self-signed certificates. The main drawback of using exclusively these protocols for this purpose is that too many roundtrips would be required. The terminology used in the draft has been the subject of some discusí sion on the mailing list. In particular, the terms "piggybacking", "weak authentication", and "strong authentication" are not very accuí rate and can at times be misleading. Due to lack of time, I haven't yet included better suggestions in to this draft (I'm not even quite sure if there are better suggestions). J. Arkko Expires May 2002 [Page 27] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 11. Acknowledgements The author would like to thank Charlie Perkins, Michael Thomas, Pekka Nikander, Phil Roberts, Thomas Narten, Hesham Soliman, Glenn Morrow, Lars-Erik Jonsson, Erik Nordmark, Greg O'Shea, and members of the Mobile IP mailing list for extensive discussions about the issues on the mailing list. Credit for all solutions and their respective pros and cons is fully due to the participants in these discussions. 12. References [1] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-14.txt. Work In Progress, IETF, July 2001. [2] P. Nikander, D. Harkins, B. Patil, P. Roberts, E. Nordmark, T. Narten, A. Mankin, "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", draft-team-mobileip- mipv6-sec-reqts-00.txt. Work In Progress, IETF, July 2001. [3] M. Thomas, "ESP Protected Binding Updates", draft-thomas-mobileip- esp-bu-00.txt (unpublished). July, 2001. [4] D. Harkins and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998. [5] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [6] P. Nikander, C. Perkins, "Binding Authentication Key Establishment Protocol for Mobile IPv6", draft-perkins-bake-01.txt. Work In Progress, IETF, July 2001. [7] G. Montenegro, C. Castelluccia, "SUCV Identifiers and Addresses", draft-montenegro-sucv-01.txt. Work In Progress, IETF, July 2001. [8] M. Thomas, D. Oran, "Home Agent Cookies for Binding Updates", draft-thomas-mobileip-ha-cookies-00.txt. Work In Progress, IETF, July 2001. [9] J. Rajahalme, on the Mobile IP mailing list, August 21st, 2001. [10] P. Nikander, "An Address Ownership Problem in IPv6", draft-nikaní der-ipng-address-ownership-00.txt. Work In Progress, IETF, February 2001. [11] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol" RFC 2401, BBN Corp, @Home Network, November 1998. [12] C. Bormann et al, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, TZI/Uni Bremen, Matsushita, Univ. of Arizona, Ericsson, Cisco, Nokia, NTT DoCoMo, July 2001. J. Arkko Expires May 2002 [Page 28] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 [13] R. Elz, "The IPv6 Payload Header", Work In Progress, IETF, April, 1996. [14] SSH Communications Security, "SSH IPSEC Express Performance", http://www.ssh.com/products/ipsec/performance.cfm. [15] Netscreen, "Meeting the Security Needs of the Broadband Interí net", http://www.netscreen.com/products/ns1000_wpaper.html. [16] SSH Communications Security, "SSH IPSEC Express Specifications", http://www.ssh.com/products/ipsec/specs.cfm. [17] D. Katz, "IP Router Alert Option". RFC 2113, February 1997. [18] M. Roe et al. "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-mobileip-updateauth-01.txt. Work In Progress, IETF, November 2001. [19] R. Wakikawa, on the Mobile IP mailing list, October 4th, 2001. [20] F. Dupont, on the Mobile IP mailing list, October 4th, 2001. [21] Lars-Erik Jonsson, private communication, October 8th, 2001. [22] E. Nordmark, "Securing MIPv6 BUs using return routability", draft-nordmark-mobileip-bu3way-00.txt. Work In Progress, IETF, Novemí ber 2001. [23] J. Arkko, "Security Framework for Mobile IPv6 Route Optimizaí tion", draft-arkko-mipv6ro-secframework-00.txt. Work In Progress, IETF, November 2001. 13. Revision History The following modifications have been done since the -00 version: - Added text in 6.4 to indicate that it may be possible to disable the application specific protection where (and when) IPsec is available as suggested by Charlie Perkins. - Added new references for the non-SA models. - Added a discussion at the end of 8.3 on the need to run AH MACs for every packet, but being able to avoid that in the BU suboption model, as suggested by Vijay Devarapalli. - Added a discussion of BU suboption schemes being able make a faster SA/policy lookup. - Section 7.5 discusses the possibility that the weak authentication protocols would have to run outside DOs, and the effect (if any) it has on BU piggybacking. J. Arkko Expires May 2002 [Page 29] INTERNET-DRAFT MIPv6 BUSec 20 November 2001 - Changed configuration discussions under chapter 6 to remove the posí sibility of turning off security, as suggested by Erik Nordmark. - Added a discussion of various types of piggybacking, as suggested by Erik Nordmark. - Clarified the increase of CPU need as the packet size grows to apply only for small packets. - Clarified the BU and payload reordering impacts for MNs with estabí lished BCEs, as suggested by Erik Nordmark. 14. Author's Address Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland Phone: +358 40 5079256 (mobile) +358 9 2992480 (office) EMail: Jari.Arkko@ericsson.com J. Arkko Expires May 2002 [Page 30]