idnits 2.17.1 draft-arkko-mipv6-bu-security-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 600 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 947 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '... >> R1: It MUST be possible to int...' RFC 2119 keyword, line 144: '... >> R2: It MUST be possible to pro...' RFC 2119 keyword, line 148: '... >> R3: It MUST NOT be possible fo...' RFC 2119 keyword, line 151: '... >> R4: It SHOULD be possible to...' RFC 2119 keyword, line 156: '... >> R5: It MUST be possible to der...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '... ments of t...' == Line 13 has weird spacing: '...tribute work-...' == Line 17 has weird spacing: '...y other docum...' == Line 18 has weird spacing: '... any time....' == Line 21 has weird spacing: '... The list...' == (595 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2001) is 8201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 1412 looks like a reference -- Missing reference section? '1' on line 1409 looks like a reference -- Missing reference section? '18' on line 1465 looks like a reference -- Missing reference section? '10' on line 1439 looks like a reference -- Missing reference section? '4' on line 1420 looks like a reference -- Missing reference section? '11' on line 1443 looks like a reference -- Missing reference section? '9' on line 1437 looks like a reference -- Missing reference section? '3' on line 1417 looks like a reference -- Missing reference section? '12' on line 1446 looks like a reference -- Missing reference section? '21' on line 1473 looks like a reference -- Missing reference section? '19' on line 1469 looks like a reference -- Missing reference section? '17' on line 1463 looks like a reference -- Missing reference section? '13' on line 1451 looks like a reference -- Missing reference section? '6' on line 1426 looks like a reference -- Missing reference section? '7' on line 1430 looks like a reference -- Missing reference section? '5' on line 1423 looks like a reference -- Missing reference section? '14' on line 1454 looks like a reference -- Missing reference section? '15' on line 1457 looks like a reference -- Missing reference section? '16' on line 1460 looks like a reference -- Missing reference section? '8' on line 1433 looks like a reference -- Missing reference section? '20' on line 1471 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jari Arkko 3 INTERNET-DRAFT Ericsson 4 October 2001 6 Issues in Protecting MIPv6 Binding Updates 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or made obsolete by other documents at 18 any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as work in progress. 21 The list of current Internet-Drafts may be found at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories may be found at 25 http://www.ietf.org/shadow.html. 27 The distribution of this memo is unlimited. It is filed as , and expires March 1, 2001. Please 29 send comments to the author or to Mobile IP working group. 31 2. Abstract 33 The Mobile IP working group is currently searching for a security 34 solution that enables semi-secure, weak authentication between IPv6 35 Mobile Nodes and Correspondent Nodes in the the global Internet. Sub- 36 sequent Binding Updates messages will then be cryptographically 37 integrity protected to prevent abuse of the mechanisms for route opti- 38 mization. This memo assumes a suitable authentication mechanism 39 exists, and discusses various alternatives on how the BUs can be pro- 40 tected. We note that there are multiple alternatives. In particular, 41 the solution space is more fine grained than "Use IPsec for every- 42 thing" and "Don't Use IPsec At All". Fair amount of detail is neces- 43 sary to explain how the solutions work, whether any standard exten- 44 sions are needed, what kind of APIs are needed between stack parts, 45 what the implications are to piggybacking, how the solutions fit situ- 46 ations where strong authentication is also a requirement, and so on. 48 3. Contents 50 1. Status of this Memo..................................1 51 2. Abstract.............................................1 52 3. Contents.............................................1 53 4. Introduction.........................................2 54 5. Main Requirements....................................3 55 6. Solutions............................................4 56 6.1. Application Specific Protection......................5 57 6.2. Existing IPsec AH with a New Next Header Value.......6 58 6.3. IPsec AH with Policy Extensions......................8 59 6.4. Application Specific Protection with Optional IPsec..9 60 7. Piggybacking Binding Updates.........................11 61 7.1. Implications to Protecting BUs with IPsec............11 62 7.2. Implications to IPsec Protection of Other Traffic....11 63 7.3. Bandwidth Implications...............................12 64 7.4. QoS Implications.....................................13 65 7.5. Other Implications...................................14 66 7.6. Other Solutions to the Piggybacking Problem..........15 67 8. Comparison of Solutions..............................16 68 8.1. Requirements Fulfillment.............................17 69 8.2. Header Overhead......................................18 70 8.3. Computational Overhead...............................18 71 8.4. Memory and State Requirements........................20 72 8.5. IANA Requirements....................................21 73 8.6. Standardization Work.................................21 74 8.7. Evolution of Authentication Protocols................21 75 8.8. Error Situations.....................................22 76 8.9. Optimizations for Busy Servers.......................22 77 8.10. Address Ownership....................................23 78 8.11. Implementation Aspects...............................23 79 9. Conclusions..........................................24 80 10. Further Work.........................................26 81 11. Acknowledgements.....................................27 82 12. References...........................................27 83 13. Author's Address.....................................28 85 4. Introduction 87 The Mobile IP working group is currently searching for a security 88 solution that enables weak authentication between IPv6 Mobile Nodes 89 (MNs) and a Correspondent Nodes (CNs) in the the global Internet. It 90 is necessary to accept less than perfect security in this situation, 91 because strong authentication between previously unknown peers would 92 require a global Public Key Infrastructure (PKI). With current state 93 of the art, this is neither possible nor desirable. 95 The purpose of the weak authentication mechanism is to establish a 96 Binding Security Association (BSA) between the MN and the CN for the 97 secure exchange of Binding Updates (BUs). The main content of such 98 BSAs are the keying material derived as a part of the authentication 99 mechanism. BUs will be cryptographically integrity protected to pre- 100 vent abuse of the mechanisms for route optimization. The main reason 101 for creating such BSAs is actually optimization: after a possibly 102 multi-round authentication protocol has been run, keying material can 103 be created to enable subsequent protection using the BSA, avoiding the 104 need to rerun the authentication. 106 This memo assumes a suitable authentication mechanism exists, and dis- 107 cusses various alternatives on how the BUs can be protected. Further- 108 more, we discuss how strong authentication can optionally be used in 109 those situations where suitable trust infrastructure exists, such as 110 inside corporate networks. 112 Even if we discuss the relationship of the BU protection to authenti- 113 cation and key agreement, this memo relies only on the ability of 114 these mechanisms to produce BSAs. Technical details of how they are 115 performed are outside the scope of this memo and must be discussed 116 elsewhere. 118 The motivation for writing this memo is to provide a concrete set of 119 proposals for BU integrity protection, in one document together with a 120 comparison of their pros and cons. 122 The memo is outlined as follows. In Chapter 5, we discuss a very high 123 level set of requirements, without going to the details on exactly 124 what weak authentication means as this is already discussed in [2]. In 125 Chapter 6, we introduce the alternative ways on how we think the BUs 126 can be protected. Chapter 7 is devoted to the discussion of how piggy- 127 backing affects the solutions. Chapter 8 compares the alternatives 128 against each other in terms of their security, efficiency, use of pre- 129 cious protocol numbers, requirements for new standardization work, and 130 other criteria. Chapter 9 concludes with some of the main findings. 132 In this memo we assume that the authentication mechanisms indeed pro- 133 duce BSAs and the optimization to not rerun authentication is a neces- 134 sary one. 136 5. Main Requirements 138 The main requirements that are relevant from the point of view of this 139 memo are the following: 141 >> R1: It MUST be possible to integrity protect BUs against in-transit 142 modifications or forgery. 144 >> R2: It MUST be possible to protect the BUs against replay attacks. 145 (This is a requirement, though binding updates themselves contain a 146 mechanism against replay attacks.) 148 >> R3: It MUST NOT be possible for nodes to use their own BSAs to send 149 BUs on the behalf of other nodes. 151 >> R4: It SHOULD be possible to derive BSAs for BU integrity protec- 152 tion from weak authentication. (While this draft assumes the BSAs are 153 derived, we note that this is an optimization and therefore in general 154 we do not require BSAs.) 156 >> R5: It MUST be possible to derive BSAs for BU integrity protection 157 from strong authentication. (By 'strong authentication' we mean 158 mainly IKE, but other possibilities can also be considered.) 159 >> R6: It SHOULD be possible to use alternative integrity algorithms. 160 All implementations MUST implement one designated algorithm for inter- 161 operability reasons. This is a corollary of requirement 4 in [2]. Note 162 that this requirement speaks of the actual BU protection. Authentica- 163 tion part needs also several mechanisms, as indicated by R4 and R5. 165 Interestingly enough, this requirement set looks very different from 166 that defined in [2]. This is mainly because in this memo we only con- 167 sider the BU protection, and do not go to the details of what the 168 requirements for the weak authentication are. However, we note that 169 the possible inclusion of requirements R2 and R5 to [2] should be con- 170 sidered. It seems clear that R2 is a requirement, while R5 is perhaps 171 controversial, and should be discussed. 173 6. Solutions 175 In this chapter we discuss various solutions for the protection of the 176 BUs. We note that there are multiple alternatives. In particular, the 177 solution space is more fine grained than "Use IPsec for everything" 178 and "Don't Use IPsec At All". Furthermore, all the solutions have to 179 be described in a fair amount of detail in order to make it clear 180 exactly how they can work, and how they can work together with both 181 weak and strong authentication, and the evolution of protocols for 182 strong authentication. 184 The alternative solutions that will be discussed are listed below: 186 - Application specific protection, i.e. the use of the mechanism 187 defined in the -14 version of the Mobile IPv6 draft [1]. 189 - Existing IPsec AH with a new next header value for BUs. In this 190 alternative we can use the current versions of IPsec AH and IP Secu- 191 rity Architecture since BUs are not piggybacked to other packets. 193 - IPsec AH with policy extensions. Certain extensions to the current 194 requirements for security policy data bases and SA selectors are 195 needed in order to protect BUs that are embedded in the Destinations 196 Options header of packets possibly containing also other payloads. 198 - Application specific protection with optional, additional IPsec pro- 199 tection. For instance, we use the -14 mechanism and the weak authenti- 200 cation in all situations, but apply also IPsec and IKE within a corpo- 201 rate network. 203 These four alternatives correspond the different philosophical 204 approaches to the problem. The first alternative treats the Mobile IP 205 security problem as a separate issue that should be solved indepen- 206 dently of other problems, and at exactly the manner that suits Mobile 207 IP the best way. The second alternative tries to maximize reuse of 208 existing solutions, while possibly making compromises on what kind of 209 functionality can be offered. The third alternative also reuses 210 existing solutions, but does not settle for compromises. Finally, the 211 fourth approach looks upon the specific Mobile IP solutions and gen- 212 eral corporate network security solutions as complementary to each 213 other. 215 It doesn't seem possible to treat the above list completely indepen- 216 dently from the way the authentication is handled. For instance, it is 217 possible to use strong authentication but there are several different 218 ways how we can provide it. Therefore, the list below shows what kind 219 of authentication mechanisms can be combined with the above solutions: 221 - Nothing. It should still be possible to use unsecured BUs. 223 - The sole use of a new weak authentication protocol. 225 - The use of a new protocol capable of both weak and strong authenti- 226 cation. 228 - The use of a new weak authentication protocol and an existing strong 229 authentication protocol. If an existing protocol is used unmodified, 230 this limits the BU protection mechanism to those supported by the 231 authentication protocol already. In practice, only IPsec AH could be 232 used for BU protection if the authentication protocol is kept as is. 234 - The use of a new weak authentication protocol and an enhancement of 235 an existing strong authentication protocol. This would allow both the 236 use of IPsec AH and the application specific mechanism defined in the 237 -14 draft [1]. 239 Assuming multiple authentication methods can be used (e.g. nothing, 240 weak, and strong), how does one know which one to choose? Currently, 241 there doesn't seem to be any other answer to this than configuration. 242 On a particular network, for instance, all machines could be config- 243 ured to use only strong authentication. Making the selection becomes 244 harder if multiple authentication methods need to be enabled simulta- 245 neously. For instance, strong authentication is always required within 246 a corporate network but to the rest of the world we allow also weak 247 authentication. Typically, VPN-like mechanisms for representing poli- 248 cies on IP addresses and networks can be used here. 250 In some recent discussions the use of very simple authentication tech- 251 niques such as return routability has been brought up. While this memo 252 does not address that type of solutions we indicate that IPsec-based 253 SAs are fundamentally limited to provide security only through shared 254 secrets. This is the current assumption also in the -14 draft. It 255 appears possible to use simpler types of security as well, such as 256 some methods in Michael Roe's proposal [18]. If these simpler methods 257 are found suitable, then neither the current -14 nor the IPsec models 258 are appropriate. But as discussed earlier, the shared secrets are used 259 as an optimization, and it remains to be seen if acceptable solutions 260 can be found without this optimization. 262 6.1. Application Specific Protection 264 In this mechanism, the Binding Update and its acknowledgement options 265 are kept in the Destination Options header, and contain an SPI and an 266 integrity check vector. (The options always contain a sequence number 267 as well.) All operations on these security related fields are per- 268 formed within the Mobile IP implementation itself, and no effects out- 269 side the Destination Options header can be seen. Further details on 270 this mechanism are described [1]. 272 No specific user actions are needed in order to configure this mecha- 273 nism, beyond possibly turning security on. All BUs and their acknowl- 274 edgements will be required protection, by the software taking care of 275 the mobile IP functionality. In this mechanism, it would also be pos- 276 sible to allow both secured and unsecured BUs during the deployment 277 phase of secure Mobile IPv6. This would also have to be configured, 278 either as an always allowed but optional security, or on a per network 279 basis. 281 In the case that strong authentication is also desired for BUs, the 282 configuration becomes much harder. There are no key distribution mech- 283 anisms currently designed to key -14 BSAs. 285 As the BUs are kept in the Destination Option header, no next protocol 286 numbers are consumed by this mechanism, but an option number is con- 287 sumed. It is possible to piggyback the BUs on regular TCP or other 288 payload traffic, and there are no effects to upper layers. 290 If this mechanism is used together with traffic flows that for other 291 reasons use IPsec, the rules governing the addition and removal of the 292 Destination Options must be constructed so that the Mobile IPv6 pro- 293 cessing offers the same packet for the IPsec AH ICV calculations. This 294 doesn't seem to be a problem. 296 The authentication and key agreement protocol can be run independent 297 of the BUs, or even within the BU packets. 299 It is not possible to use existing strong authentication protocols 300 unchanged in this solution. 302 6.2. Existing IPsec AH with a New Next Header Value 304 In this approach, the Binding Updates and their acknowledgements are 305 sent in packets separate from actual payload traffic, with a new pro- 306 tocol number (or a UDP port). IPsec SAs are used for the BSAs. AH is 307 used to protect the BUs, though the SAs are created using a weak 308 authentication protocol and not IKE. 310 The policy database for IPsec is set up so that packets destined to 311 the particular host with the BU protocol number require the use of a 312 particular SA. This SA is the one that was created for BU traffic to 313 that host. Otherwise the packets are dropped. The weak authentication 314 protocol creates the SAs when the Mobile IPv6 signaling needs them. 315 Like all other IP and higher layer processing, IPsec policy matching 316 is performed on the used home addresses rather than Care-of-Addresses 317 (see section 10.1 in [1]). This means that a particular IPsec SA can 318 be used even if the MN moves and changes its CoA, and that a particu- 319 lar SPD entry can only be used by the right host. In this case the so 320 called address ownership problem [10] does not exist, since the SPD 321 entries and the SAs have been created only through the authentication 322 protocol, and the SPD entries require the use of a specific address in 323 a specific SA. 325 A typical SPD would contain entries such as the ones below: 327 1. mn1 to here with proto=BU => use SA1 328 2. here to mn1 with proto=BU => use SA2 329 3. mn2 to here with proto=BU => use SA3 330 4. here to mn2 with proto=BU => use SA4 331 5. proto=BU => drop 333 In this example the CN at address "here" has had a contact with two 334 mobile nodes at addresses "mn1" and "mn2". Two pairs of SAs have been 335 created to protect the signaling to these, SA1/SA2 and SA3/SA4. All BU 336 traffic to these nodes is protected using these SAs, and any other BU 337 traffic is simply dropped. (Note that as a mobile node sees a need to 338 send BUs to another node, it first runs the authentication protocol 339 which will establish these rules.) 341 The organization of the SPD presented above is just one possible one. 342 In this case an API is required to dynamically update the policy data 343 base from the Mobile IP implementation. In an another type of organi- 344 zation, a single BU-related general policy rule would be sufficient, 345 and the correct SAs would be picked with selectors. IPsec has the con- 346 cept of "selectors", which are tied to each SA. The purpose of the 347 selectors is to specify which SA to use within a set of SAs. A typical 348 VPN policy, for instance, might say that all traffic must be encrypted 349 with IPsec. However, since a host may communicate with several other 350 hosts, one SA pair is not sufficient to under this general rule. 351 Instead, a number of SA pairs are established, and the selectors are 352 used to determine which particular SA to use for a particular destina- 353 tion address. These checks are applied to packets in both directions. 354 In the case of protecting BUs in this alternative, the selectors of 355 each SA would be set to the particular addresses used in the communi- 356 cations. In the example the selectors would correspond to checking 357 that the e.g. packets sent through SA1 had "mn1" and "here" as their 358 source and destination addresses, respectively. This organization 359 would require the IPsec implementation to understand a new type of a 360 policy entry, one that should not initiate IKE negotiations even if no 361 SA exists. 363 The user's configuration set-up is interesting. One alternative in 364 doing this is to set up a specific Mobile IPv6 policy entry, but the 365 policies could also be set automatically from the Mobile IPv6 soft- 366 ware, which would probably be easier in terms of configuration. In any 367 case, the user can turn on or off the protection, and could also do so 368 on a per-network or host basis. However, it would not be easy to allow 369 security as an optional service since standard IPsec policy data bases 370 always either demand or disallow security. 372 A single protocol number is needed for the BUs in this alternative. 373 The same number could be used for both BUs and their acknowledgements. 374 No option numbers are needed. Given that the IPsec policy data base 375 is set up to use the protocol number as a decision factor, it is not 376 possible to send the BUs and payload data in the same packets. 378 In this alternative, IPsec can be used also for other purposes, to 379 protect the payload traffic. The policy database must be constructed 380 so that the BU protection rules and other rules do not overlap. 382 All authentication mechanisms are possible in this solution, including 383 the use of existing protocols such as IKE [4]. It isn't necessary to 384 modify the existing protocols. The Mobile IP implementation can look 385 at the SPD when it needs to create a new SA. If a regular IKE-based 386 rule already exists for the particular other host, the SA establish- 387 ment is left to IKE. If not, the weak authentication protocol is run 388 and an SA and the corresponding SPD entry are created. 390 6.3. IPsec AH with Policy Extensions 392 In this approach, the current model used for representing BUs is 393 retained, but IPsec policy rules are extended beyond the requirements 394 of the current standard. The extension is necessary in order for it to 395 be possible to represent rules about BUs in Destination Options. Cur- 396 rently, IPsec standard requires only the possibility to construct pol- 397 icy rules based on addresses, protocols (IPv6 next header numbers), 398 and port numbers. 400 The policy database for IPsec is set up in a manner similar to the 401 previous alternative, except that the policies look at the options 402 part, not the protocol numbers. That is, one of the SAs that have been 403 created for the protection of the BUs must be used if the BU option 404 appears in the packet, or otherwise the packets are dropped. The weak 405 authentication protocol creates the SAs when the Mobile IPv6 signaling 406 needs them. The concept of "selectors" also needs to be used. The 407 selectors are tied to each SA, and their purpose is to specify which 408 particular SA to use within a set of SAs. The selectors would be set 409 to the particular addresses used in the communications. This prevents 410 a node from sending other node's binding updates inside its own SA. 411 Again, home addresses are used the policy matching. 413 The user's configuration set-up in this alternative is similar to the 414 previous alternative: the configuration could be done through an 415 explicit Mobile IPv6 entry in the policy table, or automatically from 416 the Mobile IPv6 software. The latter would probably be easier in terms 417 of configuration. Again, the user can turn on or off the protection, 418 either globally or on a per-network or host basis. It would not be 419 easy to allow security as an optional service. 421 As the BUs are kept in the Destination Option header, no next protocol 422 numbers are consumed by this mechanism, but an option number is con- 423 sumed. It is possible to piggyback the BUs on regular TCP or other 424 payload traffic, and there are no effects to upper layers. 426 IPsec can be used also for other purposes, to protect the payload 427 traffic. However, this requires the construction of the policy entries 428 in a manner that takes in account the possibility that a packet 429 matches both the BU rules, and some other rules, such as in the case 430 of important TCP traffic that also happens to carry a piggybacked BU. 431 Unlike in the case of separate protocol number, these is no easy way 432 to avoid such overlap in this case. However, given the new, extended, 433 policy rule specifications, these situations must be taken care of in 434 the policies themselves, i.e. the user will dictate what kind of secu- 435 rity will apply to e.g. BUs, TCP, and BUs piggybacked to TCP 437 A typical SPD would contain entries such as the ones below: 439 1. neta to here with proto=TCP => IPsec with IKE 440 2. neta to here with proto=* and BU option => IPsec with weak authentication 441 3. here to neta with proto=TCP => IPsec with IKE 442 4. here to neta with proto=* and BU option => IPsec with weak authentication 443 5. * to here with proto=* and BU option => IPsec with weak authentication 444 6. here to * with proto=* and BU option => IPsec with weak authentication 445 7. * to here with proto=* => pass 446 8. here to * with proto=* => pass 448 In this example the CN at address "here" allows traffic with the net- 449 work "neta". Traffic that has TCP is protected with the normal IPsec 450 means, regardless of whether there are possible Binding Updates (rules 451 1 and 3). Traffic that has only the BU option but no TCP, is protected 452 using weak authentication (rules 2 4). For all other addresses, only 453 the packets containing BU options are protected, regardless of upper 454 layer protocol numbers (rules 5 and 6). 456 As the CN communicates with MNs, the weak authentication protocol cre- 457 ates new entries under the given policy rule sets (2, 4, 5, and 6 in 458 our example). The SAs have selectors that ensure the correct SA was 459 used. The selectors would correspond to checking that the e.g. an 460 address "hosta1" within "neta" uses its own SA, not someone else's SA. 461 This means that the selectors for the SAs are more specific than the 462 policy entries, as is described in 4.4.1 option a in [11]. For 463 instance, assuming SAs have been created with hosts hosta1 and hosta2 464 within neta, the following SA entries and selectors would be found 465 under the policy rules 2 and 4: 467 2: policy = neta to here with proto=* and BU option 468 SA1: hosta1 to here with proto=* and BU option 469 SA3: hosta2 to here with proto=* and BU option 470 4: policy = here to neta with proto=* and BU option 471 SA2: here to hosta1 with proto=* and BU option 472 SA4: here to hosta2 with proto=* and BU option 474 The Mobile IP implementation requires an access to the IPsec SA 475 database in this alternative. The SPD can stay static, but the IPsec 476 implementation must understand that it may not e.g. start IKE negoti- 477 ations based on the "weak authentication" policy rules. 479 6.4. Application Specific Protection with Optional IPsec 481 In this alternative, two different protection mechanisms are applied 482 independently of each other. For instance, we use the -14 mechanism 483 and the weak authentication in all situations, but apply additionally 484 also IPsec and IKE where a suitable PKI exists, such as in corpora- 485 tions. This may lead to the use of two security headers protecting 486 partially the same packet. On the other hand the independence of the 487 Mobile IP and IP security solutions relieves the need to extend policy 488 rules, or to open APIs between the two stack parts. 490 The Binding Update and its acknowledgement options are kept in the 491 Destination Options header, and contain an SPI and an integrity check 492 vector. All operations on these security related fields are performed 493 within the Mobile IP implementation itself, and no effects outside the 494 Destination Options header can be seen. Further details on this mecha- 495 nism are described [1]. An independent protection is provided by stan- 496 dard IPsec/IKE means for the traffic specified in the SPD. Given that 497 standard SPD granularity is used, the IPsec protection does not neces- 498 sarily apply only to the BUs, but also to other traffic. This may, 499 however, be in line with security requirements as we will discuss 500 later. 502 There are two aspects to the user configuration in this alternative. 503 First, it becomes necessary to configure the Mobile IP security which 504 is likely to consist of turning on/off the security protection. As 505 described in section 5.1, it may also be possible to to allow both 506 secured and unsecured BUs which would also have to be configured. The 507 IPsec security policies are in this alternative set up in a normal 508 manner, by the user's manual configuration (the automatic procedures 509 for creating SPD entries outlined in section 5.2 do not apply). 511 An example of a configuration is presented below. In this example BU 512 protection is on everywhere, and all traffic to and from network 513 "neta" shall be protected with IPsec: 515 MIP configuration: 516 - BU security: on for * 518 IPsec SPD configuration: 519 1. neta to here => use IPsec/IKE 520 2. here to neta => use IPsec/IKE 521 3. * => pass 523 As the BUs are kept in the Destination Option header, no next protocol 524 numbers are consumed by this mechanism, but an option number is con- 525 sumed. 527 It is possible to piggyback the BUs on regular TCP or other payload 528 traffic, and there are no effects to upper layers. However, the IPsec 529 policies can't be expressed in enough detail to protect just the BUs. 531 This solution allows the granularity of the weak BU protection and the 532 strong protection to be different. That is, it isn't necessary to 533 protect solely the BU packets. Typically, an organization that has a 534 PKI and likes to protect their BU traffic would typically run strong 535 security on all of their traffic (possibly excluding some flows, such 536 as those to port 80). This means that while BU protection is applied 537 only packets that contain the BUs, IPsec would typically be applied on 538 all traffic. IKE or other IPsec authentication protocols would be run 539 in order to create SAs upon the first contact of two peers, and all 540 traffic - including weakly protected BUs - would run inside the IPsec 541 tunnels between the peers. 543 7. Piggybacking Binding Updates 545 The Binging Updates are currently specified to be sent within the IPv6 546 Destination Options. As has been described above, there are some limi- 547 tations on how IPsec policies can be used to protect such options. 548 There has been a discussion in the Working Group about the possibili- 549 ties to rethink the position of the Binding Updates in the packets. 550 Placed in its own separate packet, the protection of the Binding 551 Updates would be easier with IPsec. However, in doing so we lose the 552 ability to piggyback Binding Updates on payload packets, which may be 553 an important function in reducing packet counts, contention for the 554 physical medium, and so on. Also, if not allowed from the beginning it 555 may be hard to add the piggybacking functionality later. Yet piggy- 556 backing causes also problems, and could be seen as extra complexity. 558 In order to understand the consequences of removing piggybacking, this 559 chapter studies the consequences of either allowing or disallowing 560 piggybacking. The following aspects will be studied: 562 - Effects to the use of IPsec in the context of Binding Updates. 564 - Effects to the use of IPsec of other traffic. 566 - Effects to the amount of bandwidth consumed. 568 - Effects to header compression on low-bandwidth links. 570 - Effects to QoS mechanisms. 572 7.1. Implications to Protecting BUs with IPsec 574 The use of piggybacking precludes the use of IPsec with current stan- 575 dards, as the granularity of the policy mechanisms does not allow sep- 576 arating packets that have important options. 578 As described in section 5.3, it is possible extend these mechanisms. 579 (Implementors have also reported on the mailing list [19, 20] that 580 they have made local (not visible on the wire) modifications to their 581 implementations to allow piggybacking with IPsec. This is however pos- 582 sible only if you have access to the IPsec implementation.) 584 7.2. Implications to IPsec Protection of Other Traffic 586 Note that the effects of piggybacking are more related to the trans- 587 port of two different items within one packet, than to the storage of 588 one item within the options header. The current policy mechanisms are 589 unable to handle multiple items with potentially differing security 590 needs. Therefore, substituting options for a new intermediate header 591 type doesn't by itself solve the policy problem. If piggybacking is 592 needed, then policy conditions relating both to BUs and the payload 593 traffic will be necessary, allowing users to dictate how the various 594 combinations of these will be protected. If piggybacking isn't 595 needed, a slightly simpler policy mechanism suffices, as it would only 596 be necessary to match individual messages, not combinations of BUs and 597 other traffic. (Current IPsec policy mechanisms would suffice if a 598 separate protocol number (or port) was used for BUs; IPsec extensions 599 would be needed if they still were contained in the Destination 600 Options.) 602 Does piggybacking have other effects to protecting the payload traf- 603 fic, assuming either application layer protection or enhanced IPsec 604 policy processing handles the BU protection? The enhanced policy pro- 605 cessing certainly allows the users to pick their own security poli- 606 cies. However, it is still possible that fundamental conflicts occur 607 in how the user wants the traffic to be protected. For instance, in 608 order to protect the BU part, AH would be needed but the payload traf- 609 fic could need confidentiality protection through ESP. It appears that 610 these conflicts can be handled by providing both AH and ESP protec- 611 tion, as allowed by the current specifications [11]. 613 Finally, it has also been suggested [9] that the use of piggybacking 614 could be selected by the sender of the BU, based on the existing secu- 615 rity policies. The sending node would select piggybacking only if no 616 security headers are needed. Another idea taking this a bit further is 617 that the the piggybacking could only be allowed if the security policy 618 towards the other node requires all protocols to use the same SA [3]. 620 7.3. Bandwidth Implications 622 The number of BUs sent by a MN varies, and in case it talks with sev- 623 eral CNs, each movement may generate similarly several BUs. In this 624 sense the amount of space consumed by the BUs does matter. 626 Sending the BUs as separate packets causes an immediate need to send 627 an extra packet which implies a certain number of extra transferred 628 bits. On LAN networks the effect of this is an extra 40 byte IPv6 629 header. This is probably not noticeable, unless a central server keeps 630 a very large number of binding cache entries. In order for the extra 631 overhead to reach a substantial fraction of the traffic of a central 632 server, the server must receive much binding update traffic compared 633 to the amount of traffic resulting from its transactions. For 634 instance, consider a server that on average receives a BU on every 635 tenth request and has request size of 100 and response size of 200 636 bytes. The overhead cause by extra BU messages for this server would 637 be ((40+40)/10) / (100+300) = 2.7%. 639 However, the most pressing issues in bandwidth conservation are proba- 640 bly not in larger servers or LAN traffic but in hosts operating behind 641 cellular or other highly constrained interfaces. There, an additional 642 40 bytes is a significant cost even if not sent often. But the esti- 643 mation of the difference between piggybacked and separated packet is 644 harder since on these interfaces advanced header compression 645 mechanisms and other techniques are typically used. As an example, we 646 have considered the ROHC header compression schemes [12]. Its adop- 647 tion in various cellular standards as a compression mechanism justi- 648 fies its use as an example. 650 The techniques in ROHC allow collapsing the IP and transport layer 651 headers when they don't change or change predictably between packets. 652 Interestingly, ROHC is capable of dealing with options as a difference 653 that can be sent without requiring the full IPv6 header to be 654 repeated. This means that when ROHC is used, piggybacked BUs only 655 cause extra bandwidth usage that is close to proportional of the size 656 of the BU headers. 658 When a separate packet is sent with a new protocol number, the first 659 time ROHC needs to send a full IPv6 header as well as the BU itself. 660 Subsequent Binding Updates can be compressed, and the payload stream 661 continues to be compressed independently of the new BU stream. There- 662 fore, in the case of ROHC, piggybacking is in the long run roughly 663 equivalent to the non-piggybacked case. There is a difference for the 664 first packet, of roughly 40 bytes. 666 At present, ROHC has special support for RTP, UDP, and some of the 667 basic IPv6 extension headers. It compresses other extension headers in 668 a generic way. ROHC will be able to compress the BUs partially or 669 completely away regardless of whether they are in a separate header or 670 inside the Destination Options [21]. 672 While not directly relevant for the piggybacking discussion, we should 673 note that ROHC supports both AH and ESP [12, section 5.8]. Small 674 changes in these and other IPv6 extension headers can be sent as dif- 675 ferences. 677 The DOCSIS PHS is another example of a compression mechanism. It uses 678 bit masks to signal identical fields, and would appear to be able to 679 work well both with at least non-piggybacked traffic, provided that 680 separate contexts again would be held for BUs and other streams. 682 DOCSIS also allowed more than one frame to be sent on a single trans- 683 mission opportunity. This allows non-piggybacked traffic to use the 684 same opportunity, not changing the number of sent bits but reducing 685 delay even if the BUs are sent separately. 687 The use of header compression for Binding Updates is also affected by 688 movements. Unless there is a context transfer between base stations, 689 compression state of the BU sender is lost in any case at the time the 690 BU is sent. BU receivers will still be able to use compression, how- 691 ever. 693 7.4. QoS Implications 695 When Mobile IP signaling and payload traffic are combined in the same 696 packets Quality-of-Service (QoS) conflicts may occur, as the user may 697 have wanted to assign different priorities to them. The relevance of 698 this can be questioned, as the growth of the packets is only marginal 699 and the packet could reasonably be expected to be tagged with the flow 700 label of the payload regardless of the additional options. Also, the 701 sender has the possibility to send packets separately if the QoS poli- 702 cies are in conflict. However, such separation is only possible for 703 the sender and not for any of the routers in between. (The routers are 704 in some architectures responsible for the QoS tasks.) 706 A more serious QoS problem appears in cellular networks where specific 707 channels have been allocated for the host to send and receive e.g. 708 multimedia streams. Any TDM-like slot allocation scheme may need such 709 QoS reservations. Such channels have been calculated to be able to 710 carry exactly the stream (even taking in account ROHC and other header 711 compression techniques) but nothing else. An additional signaling pay- 712 load appended to the stream would essentially force the packet to be 713 dropped, or routed through best effort channels. In the case of con- 714 versational services, the latter alternative would also in practice 715 mean losing the whole packet, because it would be unlikely to arrive 716 in time to be useful. 718 As far as an individual cellular terminal is concerned, it can make 719 smart decisions about when to piggyback and when to not. However, this 720 option does not necessarily exist for the other end of the communica- 721 tions; a MN carelessly sending a piggybacked BU along a stream to its 722 correspondent cellular host might cause the BU information and a frac- 723 tion of the stream to be lost. 725 Specifically reserved tight channels are a fact of life. However, it 726 is perhaps fair to note that making IP run inside them is already dif- 727 ficult even without piggybacked BUs. Header and other compression 728 mechanisms produce variable length results, and the in the case of 729 Mobile IP the channel reservation may have to take in account not just 730 the BUs, but also other options. What is different, however, in the 731 case of BUs is first of all their size - at least two dozen bytes - 732 which may make it hard for them to fit the slack, and it is undesir- 733 able to reserve so much extra space. Secondly, BUs are dynamically 734 changing while e.g. Home Address options are other similar headers are 735 static. Static headers in general are always compressed away, and in 736 any case predicting their size is easier. 738 Piggybacking may also interact with resource reservations at the IP 739 layer, such as those performed by RSVP. 741 7.5. Other Implications 743 It has been said that piggybacking is used today also as a facility to 744 send the BUs at an appropriate time, conveniently along other traffic. 745 The intent is to not send binding updates until it is proven that fur- 746 ther traffic to the Correspondent Node exist. On the other hand, it 747 appears that this convenient mechanism can't be used all of the time, 748 given that it only works in one direction, and does not allow for 749 optimized routing of packets sent by the CN. For this reason typical 750 implementations wait a while and send the BU in any case if no other 751 traffic has appeared [19]. 753 We also note that in both piggybacked and separate packet solutions we 754 can achieve the same goals. A BU should be sent at a suitable time, 755 specified in the standards or left to the optimization logic of vari- 756 ous implementations. With piggybacking, a BU can be attached to the 757 packet that is destined to the CN. Without piggybacking, the appear- 758 ance of a packet destined to the CN would trigger the sending of 759 another packet along it. Similar functionality exists today on all 760 IPv6 stacks to send address resolution messages and other control 761 traffic, so it seems that it on most stacks it should be possible to 762 generate new packets based upon seeing traffic to a particular desti- 763 nation. 765 One difference between the piggybacked and the separate packet solu- 766 tions is that in the latter we can not guarantee that the BU arrives 767 at the CN before the payload packet. The BUs are used in the route 768 optimization functionality - which is optional - and decided on a 769 case-by-case anyway by implementations. Therefore, the payload traffic 770 will get to the other end and back regardless of the BUs. If the sep- 771 arate BUs are delayed behind the payload packets, it is possible that 772 the payload response comes through an unoptimized route. However, let 773 us assume that the first two packets along a router are going to be 774 reordered. In the piggybacked solution this means that the regular 775 packet gets to the destination first, following the packet that has 776 the piggybacked BU. In this situation one packet needs to be routed 777 through the home. In the non-piggybacked solution the BU and the first 778 payload packet get reordered, and again one the result is that one 779 packet needs to be routed through the home. 781 As has been discussed earlier, it is also possible that the addition 782 of the BUs may cause the packets to be routed differently, and may 783 already imply delayed reception. On the other the BU packets - small 784 packets - may easily get different treatment than the regular packets, 785 making it slightly more likely that a reordering will occur. In con- 786 clusion, there does not seem to be a fundamental difference in this 787 regard. 789 Firewalls and other similar devices should be able to process piggy- 790 backed packets, even if they have BU options in them. If they do not 791 let such traffic through they will also not let regular Mobile IP Home 792 Address options through, blocking all traffic. If the BUs are sent in 793 separate packets, the firewalls have to have rules to allow this traf- 794 fic in. 796 A similar situation to the BU problem appears in the case of RSVP and 797 the Router Alert options [17]. In this case IPsec was not used and the 798 option was kept as an option. 800 7.6. Other Solutions to the Piggybacking Problem 802 It has also been suggested that a more general purpose multi-payload 803 IPv6 mechanism could be developed [13]. This would allow adding piggy- 804 backing later in as an option, and could tackle the IPsec problems in 805 a general way and without delaying the Mobile IPv6 standardization. 807 One worry around this solution is that the Mobile IPv6 implementation 808 may not have enough capabilities to direct the merging of packets. 809 For instance, if the merging is implemented as a general IP layer 810 function, it is not guaranteed that BUs get merged unless two packets 811 are actually seen simultaneously. As the first packet may already be 812 partially out from an interface, it is not clear that the function 813 will see these packets early enough. However, it appears that this 814 problem can be solved by having the Mobile IP code perform the merging 815 when it detects a need to send a BU. 817 A more serious problem in this solution comes from the partial deploy- 818 ment, which obviously can't be avoided as such multi-payload schemes 819 are not a part of current IPv6. How does a node know when the receiver 820 supports this feature and when not? It may be possible to use 821 responses, errors, or the lack of these as an indication of the 822 receiver's support. However, it is not clear what kind of implications 823 this has for the additional messaging, start-up times, and so on. 825 8. Comparison of Solutions 827 The following criteria are used in evaluating the pros and cons of the 828 presented solutions: 830 - Requirements fulfillment. For instance, do the solutions allow both 831 weak and strong authentication? 833 - The header overhead of the solution, and the number of extra packets 834 required. 836 - The computational overhead of the solution. (Note that public key 837 cryptography, Diffie-Hellman, and other overhead related to authenti- 838 cation is not under discussion here. It is assumed that the user orga- 839 nizations select between the heavier strong authentication protocols 840 and the lighter weak authentication protocols. The comparison of par- 841 ticular authentication protocols such as BAKE [6], SUCV [7] and others 842 [18] also isn't the subject of this memo.) 844 - The memory and state requirements of the solution. 846 - The necessity to allocate Destination Option or Next Header numbers 847 from IANA. 849 - The required standardization work. 851 - Are the mechanisms future proof, as the current strong authentica- 852 tion protocols evolve to new ones (which is expected to happen with 853 the Son-of-IKE effort). 855 - Ability to handle error situations. 857 - Ability to optimize behaviour for busy servers. 859 - Ability to ensure that the right BSAs are used for the right BUs. 861 - Implementation aspects. 863 8.1. Requirements Fulfillment 865 Like the other alternatives, the application specific solution ful- 866 fills the requirements for integrity protection and replay protection, 867 the former through the -14 mechanisms and the latter through the BU 868 replay counters. 870 This alternative also allows the use of a new weak authentication pro- 871 tocol, or a new protocol capable of both weak and strong authentica- 872 tion. The use of an existing strong authentication protocol isn't 873 directly possible, an enhancement of both the protocol standards and 874 the implementation would be necessary. The enhancement necessary for 875 e.g. IKE [4] would involve adding a new protocol along the side of AH 876 and ESP with possible other parameters such as algorithm identi- 877 fiers. This would be an extension of the current IPsec DoI [5]. 879 The -14 mechanisms can satisfy the requirement to be able to use dif- 880 ferent algorithms. However, at the moment [1] does not define even a 881 single algorithm, let alone alternatives. 883 The IPsec based alternatives fulfill the requirements for integrity 884 protection and replay protection, both through AH mechanisms. Note 885 that an additional layer of replay protection exists at the BU mes- 886 sages. It isn't possible to remove the fields related to this, as 887 IPsec provides only replay protection but not sequenced delivery. For 888 the Mobile IP route optimization to work, sequenced delivery is also 889 needed. 891 Existing IPsec AH can use both weak and strong authentication proto- 892 cols. There is no need to modify the strong authentication protocols, 893 or the IPsec stack in order to make this possible. However, a local 894 API must exist between the new weak authentication protocol and the 895 IPsec implementation in order to set up suitable policy entries and 896 SAs. 898 IPsec AH with extended policy rules allows the use of a new weak 899 authentication protocol, or a new protocol capable of both weak and 900 strong authentication. The use of an existing strong authentication 901 protocol isn't directly possible, an enhancement of both the protocol 902 standards and the implementation would be necessary. The use of a new 903 weak authentication protocol and an enhancement of an existing strong 904 authentication protocol. The enhancement necessary for e.g. IKE [4] 905 would involve an extension of the client identifiers to support the 906 extended policies capable of differentiating IPv6 Destination Options. 907 It is not possible to use existing strong authentication protocols 908 unchanged in this solution. 910 All IPsec AH based solutions satisfy the requirement on being able to 911 use different algorithms. A set of standard, mandatory algorithms 912 exists, as well as many optional ones. 914 The use of both application specific and IPsec mechanisms fulfills the 915 requirements for integrity protection and replay protection. 917 Various combinations of authentication protocols could be used in this 918 alternative, but one particular combination seems most suited. Namely, 919 a new weak authentication protocol could be used to key exclusively 920 the application specific protection of BUs, and an optional strong 921 authentication protocol would build SAs that use IPsec around them. 923 8.2. Header Overhead 925 In the application specific solution, the integrity protection related 926 parts in the BUs contain the authentication data length, SPI, and 927 authentication data fields. The length of the last field is not 928 given, but assuming a typical 96 bit field is used, the total overhead 929 from this is 17 bytes. 931 IPsec AH-based solutions add the SPI, sequence number, next protocol, 932 and MAC fields. The total number of additional bytes is 24. 934 For the combined use of both application specific and AH mechanisms 935 there is a fixed cost of 17 bytes in all BU messages. An additional 936 cost of 24 bytes is applied to those messages that use also the 937 IPsec/IKE-based security. Therefore, a total of 41 bytes overhead may 938 be reached in the worst case. 940 The number of packets in the application specific, extended IPsec, and 941 combined alternatives are the same as piggybacking can be employed. In 942 the use of existing IPsec AH there are N additional packets, where N 943 is the number of BUs and their acknowledgements sent. 945 8.3. Computational Overhead 947 The application specific scheme runs a cryptographic hash over speci- 948 fied fields, typically 62 bytes assuming there are no BU suboptions. 949 The nature of the cryptographic hash hasn't been specified, but we can 950 safely assume it is similar to mechanisms used elsewhere such as HMAC 951 MD5. 953 The number of bytes used in the input to the hash function has signif- 954 icance, though the hash functions typically have some amount of static 955 cost so that the computational overhead is not linear with respect to 956 the number of input bytes. In one implementation of HMAC MD5, a four- 957 fold increase in the size of the packet increased the amount of time 958 spent by 33%. 960 The same implementation achieved speeds of around 60 Mbit/s, or 961 100,000 MACs/s for an input of size 62 bytes, on a Pentium 600 MHz 962 machine. Increasing the size fourfold changed these numbers to 170 963 Mbit/s and 75,000 MACs/s. Similar numbers are also available for other 964 implementations [14]. These numbers indicate that a relatively large 965 number of BUs can be treated with typical computer systems; likely far 966 more than is required for anything else except the busiest servers. On 967 a smaller devices such as handheld cellular devices, the available 968 power is much smaller but so is also the number of BUs that need to be 969 treated; it is hard to imagine why a device with a constrained inter- 970 face towards the Internet would have to process even 1 BU/s. 972 IPsec uses also standard cryptographic hash functions, which we 973 assumed would also be used in the application specific protection. In 974 contrast to the BU suboption, however, the hash is run over the whole 975 packet. Assuming the size of a BU protocol running directly on top of 976 IP would be roughly the same as in a BU option, the total number of 977 input bytes would be 40 from the IPv6 header, 18 from the Home Address 978 option, 24 from AH, plus 10 from the BU protocol, i.e. 92. 980 These numbers imply that the pure cryptographic operations necessary 981 in this alternative are roughly equivalent to those needed for BU pro- 982 tection in the application specific manner. In addition there are 983 IPsec-related tasks such as policy matching and header processing 984 which are harder to quantify. Implementations also differ much in this 985 respect, as some may be using sequential searches and others trees. 986 One good software-based IPsec implementation reports the speed of 65 987 Mbit/s with AH HMAC_MD5 in transport mode, on a Pentium 800 Mhz 988 machine, and 82 MBit/s when policies were being checked but none of 989 the packets needed security. The unsecured IP performance was 85 990 Mbit/s [14] on the same machine. 992 In any case, these numbers again indicate sufficient capacity to deal 993 with BUs under most normal circumstances, possibly with the exception 994 of the busiest servers. A crucial factor is the amount of BU traffic 995 vs. other traffic. Let us assume 10 KB regular traffic interrupted by 996 a 0.1 KB BU, and a system that would handle 10 Mbit/s BUs. Even if the 997 reference used above didn't describe the packet sizes used in the 998 test, it seems safe to assume that a single CPU would be able to han- 999 dle this load. But under these assumptions, the system would also be 1000 handling 1 GBit/s other traffic. If there's only 1 KB (one large 1001 packet) of traffic between the BUs, then this number would be 100 1002 MBit/s. 1004 The computational overhead for extended IPsec is similar to that of 1005 existing IPsec, except that now also the payload contents may be 1006 included in the hash calculations. Assuming the average original 1007 packet size of, say, 300 bytes, this makes the real packet size with 1008 all options and AH to be 352. This is also the input to the hash func- 1009 tion. 1011 Given our earlier measurement data, it doesn't seem that the size of 1012 the packets matters as much as might be expected. Some increase in CPU 1013 demands will be seen, however. 1015 In the combined use of application specific and IPsec solutions, the 1016 computational overhead at the minimum is the same as in the applica- 1017 tion specific protection, i.e. running a hash over 62 bytes. In case 1018 IPsec/IKE-based security is used in addition, then an additional sec- 1019 ond hash needs to be calculated. Assuming again the 300 byte average 1020 original packet size, this amounts to running a hash over 369 bytes. 1022 Again, the size of the input to the hash operations does not seem to 1023 have significant importance. However, the number of operations is 1024 important and in this situation there are two. The two hashes are cal- 1025 culated, however, only within the protected network communications. 1027 8.4. Memory and State Requirements 1029 In the application specific solution, a security association data 1030 structure is needed for every BSA established to protect the BUs. The 1031 current assumption is that the BSAs are unidirectional, but unlike the 1032 IPsec solution they could also be bidirectional and thereby halving 1033 the memory requirements. Note that there may in any case be multiple 1034 concurrent BSAs per each MN in order to allow for smooth rekeying. 1035 Each BSA must contain information about the used integrity key (typi- 1036 cally at least 20 bytes), the SPI (4 bytes), lifetime (4 bytes), algo- 1037 rithm (under 1 byte) and an implementation dependent amount of admin- 1038 istrative information, such as pointers to Binding Cache entries, 1039 statistics, and other relevant information. 1041 Security association data structures are needed also for the IPsec 1042 SAs. IPsec SAs are a bit more general-purpose than application spe- 1043 cific SAs, including for instance encryption keys, selectors, lifetime 1044 and statistics information, and other similar data. Typical implemen- 1045 tations use memory in the order of, say, 400 bytes for each SA. An 1046 implementation optimized for memory usage could cut this down to 1047 around 170 bytes, most of which is spent on the IPv6 addresses needed 1048 for the destination and selector addresses. 1050 In addition to the SA information, the IPsec implementations (may) 1051 need to add policy entries related to each specific host. These need 1052 both memory, and execution time for each packet. Typical implementa- 1053 tions would perhaps use a similar amount of space for a policy entry 1054 as they do for an SA. On a MIP-specific solution, we didn't need this 1055 as the policy is hardcoded to the processing of the BUs. 1057 There isn't much information available on how large number of SAs and 1058 policy entries typical implementations support. Special hardware 1059 devices can support tens of thousands of simultaneous connections 1060 [15]. A central question is the support for a large number of SAs in 1061 typical server OS implementations. Smart implementations can provide 1062 logarithmic-time processing of security rules and SA databases [16], 1063 but some implementations may be built more around VPN access scenarios 1064 (small number of SAs) rather than end-to-end security towards multiple 1065 directions. 1067 There may be optimizations available for devices that do not want to 1068 support IPsec in general and only want to support it for BU protec- 1069 tion. In this case it is possible to eliminate execution time overhead 1070 for other packets, and to use the Binding Cache entries and BSAs as 1071 the sole packet matching mechanism. 1073 The memory and state requirements for combined application specific 1074 and IPsec alternative is (roughly) a sum of the requirements for the 1075 two mechanisms. 1077 8.5. IANA Requirements 1079 The application specific solution requires a Destination Option number 1080 to be allocated for the BUs. 1082 The existing IPsec AH solution requires a new IPv6 next header value - 1083 a more valuable resource - to be allocated. 1085 With an extension to the IPsec policies, only the Destination Option 1086 value needs to be allocated. 1088 In the combined use of IPsec and the application specific mechanism 1089 the situation is the same, and only the Destination Option value needs 1090 to be allocated. 1092 8.6. Standardization Work 1094 No standardization work outside the Mobile IP WG is needed for the 1095 application specific solution. However, if an existing strong authen- 1096 tication protocol needs to be used also, then it needs to be extended. 1097 This likely needs IPsec WG involvement. Of course, strong authentica- 1098 tion could also be built in to the Mobile IP specific protocols. 1100 In the use of existing IPsec, no standardization work outside the 1101 Mobile IP WG is needed. Even if strong authentication protocols need 1102 to be used, they can be used as is. 1104 The extension of IPsec to cover individual Destination Options would 1105 need an action from the IPsec WG for a small extension to both IPsec 1106 and its key management mechanisms. 1108 The combined use of application specific solution and IPsec requires 1109 no standardization actions, even if strong authentication is needed. 1111 All solutions relying on IPsec AH may suffer from the possible action 1112 in the IPsec WG to deprecate AH. This has been discussed from time to 1113 time, mainly under the argument of reducing the complexity of IPsec. 1114 If this happens it may be possible use ESP instead of AH [3]. 1116 8.7. Evolution of Authentication Protocols 1118 Here we discuss the effects of evolving authentication protocols. 1119 Such evolution takes place on two fronts. First, as the weak authenti- 1120 cation area is a new one, we can expect new and better protocols to 1121 appear for this purpose. Secondly, also the current strong authentica- 1122 tion protocols and IPsec are under evolution, such as the work on Son- 1123 of-IKE which has been prompted by the complexity of IKE. 1125 The application specific solution can - if designed right - accommo- 1126 date new weak authentication protocols easily. It is necessary to pro- 1127 vide a clean separation between the BU protection and the authentica- 1128 tion protocol, but this should be easy. 1130 The application specific solution can also accommodate existing strong 1131 authentication, provided that they are extended to support the BU pro- 1132 tection protocols. The ability of this solution to follow the evolu- 1133 tion of such strong authentication protocols depends heavily on the 1134 interest of their developers to retain non-IPsec support in the proto- 1135 col if it is extended, simplified, or redesigned. It is therefore not 1136 fully certain that new protocols also allow the same thing. 1138 The use of existing IPsec is more certain to be possible even if the 1139 keying protocols evolve. If IPsec is extended to cover also individual 1140 Destination Options, new keying protocols should also be able to do 1141 this. Unless there is a desire to simplify things, but one could 1142 expect that such simplification could be foreseen as the extension 1143 itself is discussed. 1145 The combined use of application specific protection and IPsec allows 1146 evolution both in the weak and in the strong authentication protocols. 1148 8.8. Error Situations 1150 Application layer mechanisms in general have more context information 1151 available regarding various error situations than IP layer solutions. 1152 IPsec discards packets if they are in any way unexpected. The question 1153 regarding BU protection is if there are any situations where other 1154 treatment of BU protection error cases is needed than discarding. 1156 For instance, if the last message of an authentication protocol would 1157 happen to arrive after the first protected BU has been sent, IPsec 1158 would simply discard the packet while an application specific mecha- 1159 nism might store it in the anticipation of completing the authentica- 1160 tion soon. It isn't clear how important this case is, however. There 1161 might also be some DoS implications on doing this. 1163 Another problem appears with weak authentication protocols that piggy- 1164 back the authentication / key agreement messages in the final BU that 1165 is sent from the MN to the CN. Here, the BSA should exist as the 1166 packet is being processed, but the BSA will actually be created only 1167 after looking a the authentication option in the packet. For the 1168 application specific security, it is easier to e.g. process BU subop- 1169 tions in a specific order, but for IPsec AH the processing happens at 1170 a predefined order. Some weak authentication schemes such as [6] do 1171 not have a problem with this, because they have specified an ordering 1172 that allows the BSA establishment to take place before the BSA is cre- 1173 ated. Some others such as [18] make use of BU suboptions, making it 1174 harder to create an IPsec SA at the same time the option itself is 1175 being processed. The practical effects of this issue is that the use 1176 of IPsec forces either a separated authentication packet, or an order- 1177 ing of the Destination Option and AH headers. 1179 8.9. Optimizations for Busy Servers 1181 It is possible that on some busy servers the computation or memory 1182 loads exceed the capabilities of the hardware. It is possible though 1183 for server manufacturers to add a feature that enables the device to 1184 age BUs faster and/or refuse weak authentication and optimized routing 1185 if the load grows too high. 1187 The optimizations for IPsec are similar to those for application spe- 1188 cific protection of BUs. The main optimization is reducing the number 1189 of BSAs, and the use of optimized routing. 1191 In the combined alternative, similar optimizations exist for the 1192 application specific protection as has been described earlier. For the 1193 additional IPsec protection, there aren't such possibilities. The 1194 security policies require the use of IPsec for the traffic within the 1195 part of the network that is expected to be protected. 1197 8.10. Address Ownership 1199 In all alternatives, it is assumed that the authentication protocol 1200 somehow determines the right of a particular peer to claim ownership 1201 of a particular address. For instance, BAKE relies on the difficulty 1202 of an eavesdropper to simultaneously see messages along different 1203 paths to prove a weak form of address ownership [6]. An BSA is estab- 1204 lished after the determination is made. 1206 This is, however, not enough. It is also necessary to ensure that sub- 1207 sequent communications do not violate the address ownership. For 1208 instance, a MN might establish a legitimate BSA with a CN, and then 1209 use this BSA to send a binding update for another MN. 1211 In the application specific solution, it is necessary to ensure that 1212 the BSA is used only with respect to the same Home Address that was 1213 used also for the authentication part. Currently, this hasn't been 1214 specified in the draft, but could easily be added. 1216 In the case of IPsec, the dynamic updates to the SPD and/or the selec- 1217 tors in the SAD must be used to create the same effect. The individ- 1218 ual policy entries, or the selectors of each SA would be set to the 1219 particular addresses used in the communications. Note that like all 1220 other IP and higher layer processing, IPsec policy matching is per- 1221 formed on the used home addresses rather than Care-of-Addresses. This 1222 means that the given SA can only be used with the original Home 1223 Address. 1225 In the case of combined use of application specific and IPsec mecha- 1226 nisms, both solutions presented above are used together. 1228 8.11. Implementation Aspects 1230 The application specific solution can be programmed in isolation from 1231 the rest of the IPv6 stack. No new APIs are needed for the security 1232 part. Security association lookup can be performed using the same data 1233 structures that are used for finding Binding Cache entries. (We do 1234 need to allow for multiple BSAs towards the same peer, but given that 1235 they would typically be just 1 or 2 it doesn't appear to require a 1236 very optimized search tree.) 1237 On the busiest servers, it might be necessary to provide some hard- 1238 ware-level acceleration mechanisms. Some existing hardware chips 1239 could be used for this purpose, though some other chips are more tai- 1240 lored towards specific IPsec processing, and are not applicable. 1242 If IPsec is used, then an API is needed towards the SPD and/or the 1243 SAD, so that the Mobile IPv6 implementation can add/delete entries 1244 from them. 1246 It is also necessary to ensure that the IPsec implementation is capa- 1247 ble of handling large amounts of SPD and SAD entries efficiently, if 1248 the stack is going to be used in servers that have many clients. This 1249 may mean improving the SPD matching mechanisms and/or SAD lookup. In 1250 the case of normal IPsec processing, there doesn't exist a similar 1251 Binding Cache entry that was used in an optimized lookup in the appli- 1252 cation specific solution. (However, there may be possibilities to 1253 optimize this even for IPSec when just BU protection but not general 1254 IPsec functionality is needed, as discussed in section 8.4.) 1256 IPsec implementations may take advantage of existing hardware chips, 1257 and their use in current and future products. 1259 IPsec implementations in general are more complex than providing just 1260 the -14 mechanisms. 1262 9. Conclusions 1264 The purpose of this memo is to mainly list the solutions and their 1265 respective advantages and disadvantages. We do not make a recommenda- 1266 tion here to select a particular solution as some of the pros and cons 1267 are not easy to weight against each other. We hope, however, that 1268 this memo helps the Mobile IP Working Group to see the complete situa- 1269 tion, and reach a consensus on how the solutions weigh against each 1270 other. 1272 However, the author would like to offer a few observations: 1274 - It is crucial for the selection that we decide what the minimum 1275 level of security offered will be. If the WG wants to have security 1276 where keying material is not created at all, it appears that only 1277 application specific solutions are possible (possibly combined with 1278 IPsec). Note that the keying material generation in e.g. BAKE is 1279 intended to be an optimization, caching the knowledge that a certain 1280 type of return routability was verified. Without the keying material, 1281 a BAKE-like check needs to be performed for all BUs. 1283 - Another crucial decision is the 'philosophical approach' we want to 1284 take. The approaches are discussed in the beginning of chapter 6. 1286 - In header overhead, the application specific solution is the small- 1287 est one, though the difference is not big (17 versus 24 bytes). If 1288 both application specific and IPsec mechanisms are used, the overhead 1289 is large but only when strong authentication is also applied. 1291 - Preliminary results regarding the effects of piggybacking indicate 1292 that typical header compression mechanisms result in similar bandwidth 1293 usage for both piggybacked and non-piggybacked cases. Essentially, the 1294 changing components of packets need to be sent. However, these results 1295 depend a lot on the particular situation, compression end-point loca- 1296 tion, and so on. Also, the effect for stationary BU receivers is dif- 1297 ferent than for BU senders that may have to start with a new compres- 1298 sion context after movements. It should be noted that there are com- 1299 plexity, QoS channel reservation, and other issues with piggybacking 1300 so it is not clear that it is always desireable. 1302 - In particular, piggybacking makes cellular network channel reserva- 1303 tions hard and/or inefficient. Such reservations are necessary on some 1304 networks, and it is not possible to reserve space for occasional 1305 Mobile IP signaling in them. 1307 - Strong authentication should be allowed as an option for certain 1308 organizations. In those organizations, there is likely a need for 1309 securing other traffic as well, and it might be wise to consider not 1310 duplicating the configuration effort etc. for Mobile IP and other 1311 applications. 1313 - Adding strong authentication support to protocols such as BAKE may 1314 not be easy. Relatively complex PKI protocols have to be managed, some 1315 organizations would prefer legacy authentication schemes which would 1316 make even the PKI approach insufficient, etc. 1318 - IPsec allows easier evolution in the authentication protocols. For 1319 instance, organizations that require strong authentication could use 1320 legacy as well as PKI-based authentication through IPSRA solutions. 1321 The modification of e.g. IKE to support also the application specific 1322 protection is not a recommended approach. 1324 - It is possible to use IPsec for BU protection without modifications 1325 to the IPsec standards. However, Mobile IPv6 will have to be changed 1326 to use a separate protocol number for the BUs and not allow piggyback- 1327 ing. In this alternative, a new IPv6 protocol number (or UDP port) 1328 would have to be allocated, which can be considered a more valuable 1329 resource than the current Destination Option values. 1331 - It is also possible to extend IPsec policy mechanisms and then keep 1332 Mobile IPv6 unchanged. However, while the modifications are small 1333 there are currently a number of other things on the table in the IPsec 1334 WG, and therefore making these extensions might cause a delay. 1336 - There doesn't seem to be a huge performance difference among the 1337 solutions in the sense of cryptographic computations. Possible perfor- 1338 mance differences can be found in the policy matching area, where 1339 IPsec needs to do work that is more straightforward in the application 1340 specific solution (though it still needs to be done). It is hard to 1341 quantify these, however, as the implementations differ in how effi- 1342 ciently they have solved the issue. This is relevant mainly for very 1343 large servers with large Binding Caches. 1345 - Optimizations for busy servers are possible in all presented alter- 1346 natives. IPsec demands more memory per BSA, though. 1348 - Address ownership issues can be solved all of the presented alterna- 1349 tives. 1351 - IPsec is more complex to implement than the pure application spe- 1352 cific solution. On the other hand, one can take advantage of existing 1353 hardware and software support on a number of products. This situation 1354 may continue in the future as well, as BU protection may not be in 1355 sufficiently high demand to force server vendors to have hardware sup- 1356 port for it. 1358 - In complexity, the main focus should be paid to the key management 1359 parts rather than the IPsec or -14 parts, because that's where most 1360 complexity lies. An added complexity in the BU protection part may be 1361 justifiable if a larger complexity reduction can be achieved then on 1362 the key management part. 1364 10. Further Work 1366 The author seeks feedback from the Mobile IP and security communities 1367 to verify that the presented solutions are complete, secure, and can 1368 be implemented. 1370 This memo discusses only the BU protection issue and leaves the weak 1371 authentication mechanisms to be discussed by other work. Likewise, we 1372 take no stand in the selection or future development of strong authen- 1373 tication mechanisms such as IKE, Son-of-IKE, KINK, and others. 1375 The security between the Home Agent and the Mobile Node isn't covered 1376 in this memo, even if it also involves the use of Binding Updates. It 1377 is likely that strong security could be applied in this context, given 1378 that there the home and the mobile have a pre-arranged relationship. 1380 The current version of this memo discusses only the use of IPSec AH. 1381 It may be possible to use also ESP as is discussed in [3]. This might 1382 become necessary if we get an indication that the AH protocol would be 1383 deprecated (which is periodically discussed by the IPSec WG). 1385 Hiding the home address of mobile nodes hasn't been considered as a 1386 requirement for this work. There might be some possibilities for doing 1387 this through the placement of the BUs after an ESP header. However, 1388 this would need to be done for all traffic and not just the BUs. Also, 1389 what has been stated in this document about the policy rules and 1390 selectors that match the home address would no longer hold. 1392 Michael Thomas has suggested that existing strong authentication pro- 1393 tocols such as IKE could be used as-is even for the weak authentica- 1394 tion, by employing self-signed certificates. The main drawback of 1395 using exclusively these protocols for this purpose is that too many 1396 roundtrips would be required. 1398 11. Acknowledgements 1400 The author would like to thank Charlie Perkins, Michael Thomas, Pekka 1401 Nikander, Phil Roberts, Thomas Narten, Hesham Soliman, Glenn Morrow, 1402 Lars-Erik Jonsson, Erik Nordmark, and members of the Mobile IP mailing 1403 list for extensive discussions about the issues on the mailing list. 1404 Credit for all solutions and their respective pros and cons is fully 1405 due to the participants in these discussions. 1407 12. References 1409 [1] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- 1410 mobileip-ipv6-14.txt. Work In Progress, IETF, July 2001. 1412 [2] P. Nikander, D. Harkins, B. Patil, P. Roberts, E. Nordmark, T. 1413 Narten, A. Mankin, "Threat Models introduced by Mobile IPv6 and 1414 Requirements for Security in Mobile IPv6", draft-team-mobileip- 1415 mipv6-sec-reqts-00.txt. Work In Progress, IETF, July 2001. 1417 [3] M. Thomas, "ESP Protected Binding Updates", draft-thomas-mobileip- 1418 esp-bu-00.txt (unpublished). July, 2001. 1420 [4] D. Harkins and D. Carrel, "The Internet Key Exchange", RFC 2409, 1421 November 1998. 1423 [5] D. Piper, "The Internet IP Security Domain of Interpretation for 1424 ISAKMP", RFC 2407, November 1998. 1426 [6] P. Nikander, C. Perkins, "Binding Authentication Key Establishment 1427 Protocol for Mobile IPv6", draft-perkins-bake-01.txt. Work In 1428 Progress, IETF, July 2001. 1430 [7] G. Montenegro, C. Castelluccia, "SUCV Identifiers and Addresses", 1431 draft-montenegro-sucv-01.txt. Work In Progress, IETF, July 2001. 1433 [8] M. Thomas, D. Oran, "Home Agent Cookies for Binding Updates", 1434 draft-thomas-mobileip-ha-cookies-00.txt. Work In Progress, IETF, July 1435 2001. 1437 [9] J. Rajahalme, on the Mobile IP mailing list, August 21st, 2001. 1439 [10] P. Nikander, "An Address Ownership Problem in IPv6", draft-nikan- 1440 der-ipng-address-ownership-00.txt. Work In Progress, IETF, February 1441 2001. 1443 [11] S. Kent, R. Atkinson, "Security Architecture for the Internet 1444 Protocol" RFC 2401, BBN Corp, @Home Network, November 1998. 1446 [12] C. Bormann et al, "RObust Header Compression (ROHC): Framework 1447 and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, TZI/Uni 1448 Bremen, Matsushita, Univ. of Arizona, Ericsson, Cisco, Nokia, NTT 1449 DoCoMo, July 2001. 1451 [13] R. Elz, "The IPv6 Payload Header", Work In Progress, IETF, April, 1452 1996. 1454 [14] SSH Communications Security, "SSH IPSEC Express Performance", 1455 http://www.ssh.com/products/ipsec/performance.cfm. 1457 [15] Netscreen, "Meeting the Security Needs of the Broadband Inter- 1458 net", http://www.netscreen.com/products/ns1000_wpaper.html. 1460 [16] SSH Communications Security, "SSH IPSEC Express Specifications", 1461 http://www.ssh.com/products/ipsec/specs.cfm. 1463 [17] D. Katz, "IP Router Alert Option". RFC 2113, February 1997. 1465 [18] M. Roe, "Authentication of Mobile IPv6 Binding Updates and 1466 Acknowledgments", draft-roe-mobileip-updateauth-00.txt. Work In 1467 Progress, IETF, August 2001. 1469 [19] R. Wakikawa, on the Mobile IP mailing list, October 4th, 2001. 1471 [20] F. Dupont, on the Mobile IP mailing list, October 4th, 2001. 1473 [21] Lars-Erik Jonsson, private communication, October 8th, 2001. 1475 13. Author's Address 1477 Jari Arkko 1478 Oy LM Ericsson Ab 1479 02420 Jorvas 1480 Finland 1482 Phone: +358 40 5079256 (mobile) 1483 +358 9 2992480 (office) 1484 EMail: Jari.Arkko@ericsson.com