idnits 2.17.1 draft-arkko-mipv6-bu-security-01.txt: -(11): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(13): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding ** The Abstract section seems to be numbered -(35): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(37): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(39): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(41): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(42): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(43): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(45): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(99): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(106): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(107): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(112): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(126): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(128): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(132): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(133): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(152): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(161): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(163): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(167): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(170): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(191): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(199): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(200): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(201): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(206): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(212): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(216): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(226): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(243): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(245): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(248): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(253): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(259): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(272): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(276): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(279): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(282): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(287): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(291): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(297): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(310): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(324): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(349): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(351): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(358): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(361): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(371): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(395): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(404): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(405): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(433): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(445): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(459): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(467): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(487): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(495): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(505): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(506): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(508): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(532): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(558): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(560): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(567): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(586): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(592): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(593): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(599): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(604): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(620): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(622): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(623): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(626): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(628): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(632): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(640): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(657): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(660): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(662): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(679): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(692): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(700): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(708): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(719): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(729): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(731): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(738): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(740): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(744): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(750): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(763): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(773): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(775): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(780): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(783): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(788): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(808): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(812): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(816): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(825): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(834): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(848): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(868): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(869): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(871): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(882): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(896): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(901): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(902): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(907): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(910): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(916): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(922): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(978): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(984): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1000): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1012): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1029): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1046): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1054): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1056): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1062): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1081): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1082): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1083): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1088): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1090): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1098): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1114): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1141): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1143): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1165): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1167): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1171): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1172): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1173): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1177): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1178): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1180): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1204): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1205): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1214): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1218): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1222): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1233): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1249): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1252): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1262): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1263): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1266): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1284): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1286): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1293): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1298): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1312): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1315): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1333): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1342): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1343): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1346): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1349): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1373): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1384): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1388): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1392): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1395): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1398): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1402): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1419): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1439): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1440): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1445): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1447): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1493): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1511): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1530): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1533): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1558): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1567): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 183 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 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 30 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 642 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 821 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 142: '... >> R1: It MUST be possible to int...' RFC 2119 keyword, line 145: '... >> R2: It MUST be possible to pr...' RFC 2119 keyword, line 149: '... >> R3: It MUST NOT be possible fo...' RFC 2119 keyword, line 152: '... >> R4: It SHOULD be possible to d...' RFC 2119 keyword, line 157: '... >> R5: It MUST be possible to de...' (3 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...' == (637 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 (November 2001) is 8198 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 1466 looks like a reference -- Missing reference section? '22' on line 1529 looks like a reference -- Missing reference section? '23' on line 1533 looks like a reference -- Missing reference section? '1' on line 1463 looks like a reference -- Missing reference section? '10' on line 1493 looks like a reference -- Missing reference section? '4' on line 1474 looks like a reference -- Missing reference section? '11' on line 1497 looks like a reference -- Missing reference section? '19' on line 1523 looks like a reference -- Missing reference section? '20' on line 1525 looks like a reference -- Missing reference section? '9' on line 1491 looks like a reference -- Missing reference section? '3' on line 1471 looks like a reference -- Missing reference section? '12' on line 1500 looks like a reference -- Missing reference section? '21' on line 1527 looks like a reference -- Missing reference section? '17' on line 1517 looks like a reference -- Missing reference section? '13' on line 1505 looks like a reference -- Missing reference section? '6' on line 1480 looks like a reference -- Missing reference section? '7' on line 1484 looks like a reference -- Missing reference section? '18' on line 1519 looks like a reference -- Missing reference section? '5' on line 1477 looks like a reference -- Missing reference section? '14' on line 1508 looks like a reference -- Missing reference section? '15' on line 1511 looks like a reference -- Missing reference section? '16' on line 1514 looks like a reference -- Missing reference section? '8' on line 1487 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 25 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 November 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 May 20, 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......................6 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..10 60 7. Piggybacking Binding Updates.........................11 61 7.1. Implications to Protecting BUs with IPsec............12 62 7.2. Implications to IPsec Protection of Other Traffic....12 63 7.3. Bandwidth Implications...............................12 64 7.4. QoS Implications.....................................14 65 7.5. Other Implications...................................15 66 7.6. Other Solutions to the Piggybacking Problem..........16 67 8. Comparison of Solutions..............................16 68 8.1. Requirements Fulfillment.............................17 69 8.2. Header Overhead......................................18 70 8.3. Computational Overhead...............................19 71 8.4. Memory and State Requirements........................20 72 8.5. IANA Requirements....................................21 73 8.6. Standardization Work.................................22 74 8.7. Evolution of Authentication Protocols................22 75 8.8. Error Situations.....................................23 76 8.9. Optimizations for Busy Servers.......................23 77 8.10. Address Ownership....................................24 78 8.11. Implementation Aspects...............................24 79 9. Conclusions..........................................25 80 10. Further Work.........................................27 81 11. Acknowledgements.....................................28 82 12. References...........................................28 83 13. Revision History.....................................29 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. (It isn't certain that this is the case, however. The matter 135 is discussed elsewhere [22, 23].) 137 5. Main Requirements 139 The main requirements that are relevant from the point of view of this 140 memo are the following: 142 >> R1: It MUST be possible to integrity protect BUs against in-transit 143 modifications or forgery. 145 >> R2: It MUST be possible to protect the BUs against replay attacks. 146 (This is a requirement, though binding updates themselves contain a 147 mechanism against replay attacks.) 149 >> R3: It MUST NOT be possible for nodes to use their own BSAs to send 150 BUs on the behalf of other nodes. 152 >> R4: It SHOULD be possible to derive BSAs for BU integrity protec� 153 tion from weak authentication. (While this draft assumes the BSAs are 154 derived, we note that this is an optimization and therefore in general 155 we do not require BSAs.) 157 >> R5: It MUST be possible to derive BSAs for BU integrity protection 158 from strong authentication. (By 'strong authentication' we mean 159 mainly IKE, but other possibilities can also be considered.) 160 >> R6: It SHOULD be possible to use alternative integrity algorithms. 161 All implementations MUST implement one designated algorithm for inter� 162 operability reasons. This is a corollary of requirement 4 in [2]. Note 163 that this requirement speaks of the actual BU protection. Authentica� 164 tion part needs also several mechanisms, as indicated by R4 and R5. 166 Interestingly enough, this requirement set looks very different from 167 that defined in [2]. This is mainly because in this memo we only con� 168 sider the BU protection, and do not go to the details of what the 169 requirements for the weak authentication are. However, we note that 170 the possible inclusion of requirements R2 and R5 to [2] should be con� 171 sidered. It seems clear that R2 is a requirement, while R5 is perhaps 172 controversial, and should be discussed. 174 6. Solutions 176 In this chapter we discuss various solutions for the protection of the 177 BUs. We note that there are multiple alternatives. In particular, the 178 solution space is more fine grained than "Use IPsec for everything" 179 and "Don't Use IPsec At All". Furthermore, all the solutions have to 180 be described in a fair amount of detail in order to make it clear 181 exactly how they can work, and how they can work together with both 182 weak and strong authentication, and the evolution of protocols for 183 strong authentication. 185 The alternative solutions that will be discussed are listed below: 187 - Application specific protection, i.e. the use of the mechanism 188 defined in the -14 version of the Mobile IPv6 draft [1]. 190 - Existing IPsec AH with a new next header value for BUs. In this 191 alternative we can use the current versions of IPsec AH and IP Secu� 192 rity Architecture since BUs are not piggybacked to other packets. 194 - IPsec AH with policy extensions. Certain extensions to the current 195 requirements for security policy data bases and SA selectors are 196 needed in order to protect BUs that are embedded in the Destinations 197 Options header of packets possibly containing also other payloads. 199 - Application specific protection with optional, additional IPsec pro� 200 tection. For instance, we use the -14 mechanism and the weak authenti� 201 cation in all situations, but apply also IPsec and IKE within a corpo� 202 rate network. 204 These four alternatives correspond the different philosophical 205 approaches to the problem. The first alternative treats the Mobile IP 206 security problem as a separate issue that should be solved indepen� 207 dently of other problems, and at exactly the manner that suits Mobile 208 IP the best way. The second alternative tries to maximize reuse of 209 existing solutions, while possibly making compromises on what kind of 210 functionality can be offered. The third alternative also reuses 211 existing solutions, but does not settle for compromises. Finally, the 212 fourth approach looks upon the specific Mobile IP solutions and gen� 213 eral corporate network security solutions as complementary to each 214 other. 216 It doesn't seem possible to treat the above list completely indepen� 217 dently from the way the authentication is handled. For instance, it is 218 possible to use strong authentication but there are several different 219 ways how we can provide it. Therefore, the list below shows what kind 220 of authentication mechanisms can be combined with the above solutions: 222 - Nothing. It should still be possible to use unsecured BUs. 224 - The sole use of a new weak authentication protocol. 226 - The use of a new protocol capable of both weak and strong authenti� 227 cation. 229 - The use of a new weak authentication protocol and an existing strong 230 authentication protocol. If an existing protocol is used unmodified, 231 this limits the BU protection mechanism to those supported by the 232 authentication protocol already. In practice, only IPsec AH could be 233 used for BU protection if the authentication protocol is kept as is. 235 - The use of a new weak authentication protocol and an enhancement of 236 an existing strong authentication protocol. This would allow both the 237 use of IPsec AH and the application specific mechanism defined in the 238 -14 draft [1]. 240 Assuming multiple authentication methods can be used (e.g. nothing, 241 weak, and strong), how does one know which one to choose? Currently, 242 there doesn't seem to be any other answer to this than configuration. 243 On a particular network, for instance, all machines could be config� 244 ured to use only strong authentication. Making the selection becomes 245 harder if multiple authentication methods need to be enabled simulta� 246 neously. For instance, strong authentication is always required within 247 a corporate network but to the rest of the world we allow also weak 248 authentication. Typically, VPN-like mechanisms for representing poli� 249 cies on IP addresses and networks can be used here. In any case, we 250 take the position here that some form of security MUST be applied to 251 all BUs, and it is not permissible to turn off the BU security. 253 In some recent discussions the use of very simple authentication tech� 254 niques such as return routability has been brought up. While this memo 255 does not address that type of solutions we indicate that IPsec-based 256 SAs are fundamentally limited to provide security only through shared 257 secrets. This is the current assumption also in the -14 draft. It 258 appears possible to use simpler types of security as well, such as 259 some methods in Erik Nordmark's proposal [22]. If these simpler meth� 260 ods are found suitable, then neither the current -14 nor the IPsec 261 models are appropriate. But as discussed earlier, the shared secrets 262 are used as an optimization, and it remains to be seen if acceptable 263 solutions can be found without this optimization. This is discussed 264 more in depth in [22, 23]. 266 6.1. Application Specific Protection 268 In this mechanism, the Binding Update and its acknowledgement options 269 are kept in the Destination Options header, and contain an SPI and an 270 integrity check vector. (The options always contain a sequence number 271 as well.) All operations on these security related fields are per� 272 formed within the Mobile IP implementation itself, and no effects out� 273 side the Destination Options header can be seen. Further details on 274 this mechanism are described [1]. 276 No specific user actions are needed in order to configure this mecha� 277 nism. All BUs and their acknowledgements will be required protection, 278 by the software taking care of the mobile IP functionality. In this 279 mechanism, it would also be possible to allow both secured and unse� 280 cured BUs during the deployment phase of secure Mobile IPv6. This 281 would also have to be configured, either as an always allowed but 282 optional security, or on a per network basis. However, we do not rec� 283 ommend this and propose that if this method is selected, it is made 284 mandatory to use in all nodes employing Route Optimization. 286 In the case that strong authentication is also desired for BUs, the 287 configuration becomes much harder. There are no key distribution mech� 288 anisms currently designed to key -14 BSAs. 290 As the BUs are kept in the Destination Option header, no next protocol 291 numbers are consumed by this mechanism, but an option number is con� 292 sumed. It is possible to piggyback the BUs on regular TCP or other 293 payload traffic, and there are no effects to upper layers. 295 If this mechanism is used together with traffic flows that for other 296 reasons use IPsec, the rules governing the addition and removal of the 297 Destination Options must be constructed so that the Mobile IPv6 pro� 298 cessing offers the same packet for the IPsec AH ICV calculations. This 299 doesn't seem to be a problem. 301 The authentication and key agreement protocol can be run independent 302 of the BUs, or even within the BU packets. 304 It is not possible to use existing strong authentication protocols 305 unchanged in this solution. 307 6.2. Existing IPsec AH with a New Next Header Value 309 In this approach, the Binding Updates and their acknowledgements are 310 sent in packets separate from actual payload traffic, with a new pro� 311 tocol number (or a UDP port). IPsec SAs are used for the BSAs. AH is 312 used to protect the BUs, though the SAs are created using a weak 313 authentication protocol and not IKE. 315 The policy database for IPsec is set up so that packets destined to 316 the particular host with the BU protocol number require the use of a 317 particular SA. This SA is the one that was created for BU traffic to 318 that host. Otherwise the packets are dropped. The weak authentication 319 protocol creates the SAs when the Mobile IPv6 signaling needs them. 321 Like all other IP and higher layer processing, IPsec policy matching 322 is performed on the used home addresses rather than Care-of-Addresses 323 (see section 10.1 in [1]). This means that a particular IPsec SA can 324 be used even if the MN moves and changes its CoA, and that a particu� 325 lar SPD entry can only be used by the right host. In this case the so 326 called address ownership problem [10] does not exist, since the SPD 327 entries and the SAs have been created only through the authentication 328 protocol, and the SPD entries require the use of a specific address in 329 a specific SA. 331 A typical SPD would contain entries such as the ones below: 333 1. mn1 to here with proto=BU => use SA1 334 2. here to mn1 with proto=BU => use SA2 335 3. mn2 to here with proto=BU => use SA3 336 4. here to mn2 with proto=BU => use SA4 337 5. proto=BU => drop 339 In this example the CN at address "here" has had a contact with two 340 mobile nodes at addresses "mn1" and "mn2". Two pairs of SAs have been 341 created to protect the signaling to these, SA1/SA2 and SA3/SA4. All BU 342 traffic to these nodes is protected using these SAs, and any other BU 343 traffic is simply dropped. (Note that as a mobile node sees a need to 344 send BUs to another node, it first runs the authentication protocol 345 which will establish these rules.) 347 The organization of the SPD presented above is just one possible one. 348 In this case an API is required to dynamically update the policy data 349 base from the Mobile IP implementation. In an another type of organi� 350 zation, a single BU-related general policy rule would be sufficient, 351 and the correct SAs would be picked with selectors. IPsec has the con� 352 cept of "selectors", which are tied to each SA. The purpose of the 353 selectors is to specify which SA to use within a set of SAs. A typical 354 VPN policy, for instance, might say that all traffic must be encrypted 355 with IPsec. However, since a host may communicate with several other 356 hosts, one SA pair is not sufficient to under this general rule. 357 Instead, a number of SA pairs are established, and the selectors are 358 used to determine which particular SA to use for a particular destina� 359 tion address. These checks are applied to packets in both directions. 360 In the case of protecting BUs in this alternative, the selectors of 361 each SA would be set to the particular addresses used in the communi� 362 cations. In the example the selectors would correspond to checking 363 that the e.g. packets sent through SA1 had "mn1" and "here" as their 364 source and destination addresses, respectively. This organization 365 would require the IPsec implementation to understand a new type of a 366 policy entry, one that should not initiate IKE negotiations even if no 367 SA exists. 369 The user's configuration set-up is interesting. One alternative in 370 doing this is to set up a specific Mobile IPv6 policy entry, but the 371 policies could also be set automatically from the Mobile IPv6 soft� 372 ware, which would probably be easier in terms of configuration. In any 373 case, the user can turn on or off the protection, and could also do so 374 on a per-network or host basis. However, we propose that this be 375 disallowed, and require Mobile IPv6 software to ensure that it the 376 policies are set up so that they only allow either the use of IPsec, 377 or force the BU packets to be dropped. Also, it would not be easy to 378 allow security as an optional service since standard IPsec policy data 379 bases always either demand or disallow security. 381 A single protocol number is needed for the BUs in this alternative. 382 The same number could be used for both BUs and their acknowledgements. 383 No option numbers are needed. Given that the IPsec policy data base 384 is set up to use the protocol number as a decision factor, it is not 385 possible to send the BUs and payload data in the same packets. 387 In this alternative, IPsec can be used also for other purposes, to 388 protect the payload traffic. The policy database must be constructed 389 so that the BU protection rules and other rules do not overlap. 391 All authentication mechanisms are possible in this solution, including 392 the use of existing protocols such as IKE [4]. It isn't necessary to 393 modify the existing protocols. The Mobile IP implementation can look 394 at the SPD when it needs to create a new SA. If a regular IKE-based 395 rule already exists for the particular other host, the SA establish� 396 ment is left to IKE. If not, the weak authentication protocol is run 397 and an SA and the corresponding SPD entry are created. 399 6.3. IPsec AH with Policy Extensions 401 In this approach, the current model used for representing BUs is 402 retained, but IPsec policy rules are extended beyond the requirements 403 of the current standard. The extension is necessary in order for it to 404 be possible to represent rules about BUs in Destination Options. Cur� 405 rently, IPsec standard requires only the possibility to construct pol� 406 icy rules based on addresses, protocols (IPv6 next header numbers), 407 and port numbers. 409 The policy database for IPsec is set up in a manner similar to the 410 previous alternative, except that the policies look at the options 411 part, not the protocol numbers. That is, one of the SAs that have been 412 created for the protection of the BUs must be used if the BU option 413 appears in the packet, or otherwise the packets are dropped. The weak 414 authentication protocol creates the SAs when the Mobile IPv6 signaling 415 needs them. The concept of "selectors" also needs to be used. The 416 selectors are tied to each SA, and their purpose is to specify which 417 particular SA to use within a set of SAs. The selectors would be set 418 to the particular addresses used in the communications. This prevents 419 a node from sending other node's binding updates inside its own SA. 420 Again, home addresses are used the policy matching. 422 The user's configuration set-up in this alternative is similar to the 423 previous alternative: the configuration could be done through an 424 explicit Mobile IPv6 entry in the policy table, or automatically from 425 the Mobile IPv6 software. The latter would probably be easier in terms 426 of configuration. Again, we suggest the Mobile IPv6 software or the 427 IPsec user interfaces don't allow accepting cleartext BUs. Otherwise, 428 various different security policies can be set either globally or on a 429 per-network or host basis. It would not be easy to allow security as 430 an optional service. 432 As the BUs are kept in the Destination Option header, no next protocol 433 numbers are consumed by this mechanism, but an option number is con� 434 sumed. It is possible to piggyback the BUs on regular TCP or other 435 payload traffic, and there are no effects to upper layers. 437 IPsec can be used also for other purposes, to protect the payload 438 traffic. However, this requires the construction of the policy entries 439 in a manner that takes in account the possibility that a packet 440 matches both the BU rules, and some other rules, such as in the case 441 of important TCP traffic that also happens to carry a piggybacked BU. 442 Unlike in the case of separate protocol number, these is no easy way 443 to avoid such overlap in this case. However, given the new, extended, 444 policy rule specifications, these situations must be taken care of in 445 the policies themselves, i.e. the user will dictate what kind of secu� 446 rity will apply to e.g. BUs, TCP, and BUs piggybacked to TCP 448 A typical SPD would contain entries such as the ones below: 450 1. neta to here with proto=TCP => IPsec with IKE 451 2. neta to here with proto=* and BU option => IPsec with weak authentication 452 3. here to neta with proto=TCP => IPsec with IKE 453 4. here to neta with proto=* and BU option => IPsec with weak authentication 454 5. * to here with proto=* and BU option => IPsec with weak authentication 455 6. here to * with proto=* and BU option => IPsec with weak authentication 456 7. * to here with proto=* => pass 457 8. here to * with proto=* => pass 459 In this example the CN at address "here" allows traffic with the net� 460 work "neta". Traffic that has TCP is protected with the normal IPsec 461 means, regardless of whether there are possible Binding Updates (rules 462 1 and 3). Traffic that has only the BU option but no TCP, is protected 463 using weak authentication (rules 2 4). For all other addresses, only 464 the packets containing BU options are protected, regardless of upper 465 layer protocol numbers (rules 5 and 6). 467 As the CN communicates with MNs, the weak authentication protocol cre� 468 ates new entries under the given policy rule sets (2, 4, 5, and 6 in 469 our example). The SAs have selectors that ensure the correct SA was 470 used. The selectors would correspond to checking that the e.g. an 471 address "hosta1" within "neta" uses its own SA, not someone else's SA. 472 This means that the selectors for the SAs are more specific than the 473 policy entries, as is described in 4.4.1 option a in [11]. For 474 instance, assuming SAs have been created with hosts hosta1 and hosta2 475 within neta, the following SA entries and selectors would be found 476 under the policy rules 2 and 4: 478 2: policy = neta to here with proto=* and BU option 479 SA1: hosta1 to here with proto=* and BU option 480 SA3: hosta2 to here with proto=* and BU option 481 4: policy = here to neta with proto=* and BU option 482 SA2: here to hosta1 with proto=* and BU option 483 SA4: here to hosta2 with proto=* and BU option 485 The Mobile IP implementation requires an access to the IPsec SA 486 database in this alternative. The SPD can stay static, but the IPsec 487 implementation must understand that it may not e.g. start IKE negoti� 488 ations based on the "weak authentication" policy rules. 490 6.4. Application Specific Protection with Optional IPsec 492 In this alternative, two different protection mechanisms are applied 493 independently of each other. For instance, we use the -14 mechanism 494 and the weak authentication in all situations, but apply additionally 495 also IPsec and IKE where a suitable PKI exists, such as in corpora� 496 tions. This may lead to the use of two security headers protecting 497 partially the same packet. On the other hand the independence of the 498 Mobile IP and IP security solutions relieves the need to extend policy 499 rules, or to open APIs between the two stack parts. 501 The Binding Update and its acknowledgement options are kept in the 502 Destination Options header, and contain an SPI and an integrity check 503 vector. All operations on these security related fields are performed 504 within the Mobile IP implementation itself, and no effects outside the 505 Destination Options header can be seen. Further details on this mecha� 506 nism are described [1]. An independent protection is provided by stan� 507 dard IPsec/IKE means for the traffic specified in the SPD. Given that 508 standard SPD granularity is used, the IPsec protection does not neces� 509 sarily apply only to the BUs, but also to other traffic. This may, 510 however, be in line with security requirements as we will discuss 511 later. 513 There are two aspects to the user configuration in this alternative. 514 There are no specific actions needed to configure Mobile IP security. 515 The IPsec security policies are in this alternative set up in a normal 516 manner, by the user's manual configuration (the automatic procedures 517 for creating SPD entries outlined in section 5.2 do not apply). 519 An example of a configuration is presented below. In this example BU 520 protection is on everywhere, and all traffic to and from network 521 "neta" shall be protected with IPsec: 523 MIP configuration: 524 (empty, always on) 526 IPsec SPD configuration: 527 1. neta to here => use IPsec/IKE 528 2. here to neta => use IPsec/IKE 529 3. * => pass 531 As the BUs are kept in the Destination Option header, no next protocol 532 numbers are consumed by this mechanism, but an option number is con� 533 sumed. 535 It is possible to piggyback the BUs on regular TCP or other payload 536 traffic, and there are no effects to upper layers. However, the IPsec 537 policies can't be expressed in enough detail to protect just the BUs. 539 This solution allows the granularity of the weak BU protection and the 540 strong protection to be different. That is, it isn't necessary to 541 protect solely the BU packets. Typically, an organization that has a 542 PKI and likes to protect their BU traffic would typically run strong 543 security on all of their traffic (possibly excluding some flows, such 544 as those to port 80). This means that while BU protection is applied 545 only packets that contain the BUs, IPsec would typically be applied on 546 all traffic. IKE or other IPsec authentication protocols would be run 547 in order to create SAs upon the first contact of two peers, and all 548 traffic - including weakly protected BUs - would run inside the IPsec 549 tunnels between the peers. 551 In a variant of this approach, the application layer protection could 552 be turned off where IPsec is available, or turned off when IPsec 553 becomes capable of protecting piggybacked BUs. 555 7. Piggybacking Binding Updates 557 The Binging Updates are currently specified to be sent within the IPv6 558 Destination Options. As has been described above, there are some limi� 559 tations on how IPsec policies can be used to protect such options. 560 There has been a discussion in the Working Group about the possibili� 561 ties to rethink the position of the Binding Updates in the packets. 562 Placed in its own separate packet, the protection of the Binding 563 Updates would be easier with IPsec. However, in doing so we lose the 564 ability to piggyback Binding Updates on payload packets, which may be 565 an important function in reducing packet counts, contention for the 566 physical medium, and so on. Also, if not allowed from the beginning it 567 may be hard to add the piggybacking functionality later. Yet piggy� 568 backing causes also problems, and could be seen as extra complexity. 570 In order to understand the consequences of removing piggybacking, this 571 chapter studies the consequences of either allowing or disallowing 572 piggybacking. The following aspects will be studied: 574 - Effects to the use of IPsec in the context of Binding Updates. 576 - Effects to the use of IPsec of other traffic. 578 - Effects to the amount of bandwidth consumed. 580 - Effects to header compression on low-bandwidth links. 582 - Effects to QoS mechanisms. 584 It should also be noted that the term "piggybacking" can be understood 585 in different ways. Here, we use it to mean end-to-end BU piggybacking 586 to payload packets. Other possible meanings include link layer piggy� 587 backing, and end-to-end generic piggybacking for not just BUs but all 588 IPv6 packets. 590 7.1. Implications to Protecting BUs with IPsec 592 The use of piggybacking precludes the use of IPsec with current stan� 593 dards, as the granularity of the policy mechanisms does not allow sep� 594 arating packets that have important options. 596 As described in section 5.3, it is possible extend these mechanisms. 597 (Implementors have also reported on the mailing list [19, 20] that 598 they have made local (not visible on the wire) modifications to their 599 implementations to allow piggybacking with IPsec. This is however pos� 600 sible only if you have access to the IPsec implementation.) 602 7.2. Implications to IPsec Protection of Other Traffic 604 Note that the effects of piggybacking are more related to the trans� 605 port of two different items within one packet, than to the storage of 606 one item within the options header. The current policy mechanisms are 607 unable to handle multiple items with potentially differing security 608 needs. Therefore, substituting options for a new intermediate header 609 type doesn't by itself solve the policy problem. If piggybacking is 610 needed, then policy conditions relating both to BUs and the payload 611 traffic will be necessary, allowing users to dictate how the various 612 combinations of these will be protected. If piggybacking isn't 613 needed, a slightly simpler policy mechanism suffices, as it would only 614 be necessary to match individual messages, not combinations of BUs and 615 other traffic. (Current IPsec policy mechanisms would suffice if a 616 separate protocol number (or port) was used for BUs; IPsec extensions 617 would be needed if they still were contained in the Destination 618 Options.) 620 Does piggybacking have other effects to protecting the payload traf� 621 fic, assuming either application layer protection or enhanced IPsec 622 policy processing handles the BU protection? The enhanced policy pro� 623 cessing certainly allows the users to pick their own security poli� 624 cies. However, it is still possible that fundamental conflicts occur 625 in how the user wants the traffic to be protected. For instance, in 626 order to protect the BU part, AH would be needed but the payload traf� 627 fic could need confidentiality protection through ESP. It appears that 628 these conflicts can be handled by providing both AH and ESP protec� 629 tion, as allowed by the current specifications [11]. 631 Finally, it has also been suggested [9] that the use of piggybacking 632 could be selected by the sender of the BU, based on the existing secu� 633 rity policies. The sending node would select piggybacking only if no 634 security headers are needed. Another idea taking this a bit further is 635 that the the piggybacking could only be allowed if the security policy 636 towards the other node requires all protocols to use the same SA [3]. 638 7.3. Bandwidth Implications 640 The number of BUs sent by a MN varies, and in case it talks with sev� 641 eral CNs, each movement may generate similarly several BUs. In this 642 sense the amount of space consumed by the BUs does matter. 644 Sending the BUs as separate packets causes an immediate need to send 645 an extra packet which implies a certain number of extra transferred 646 bits. On LAN networks the effect of this is an extra 40 byte IPv6 647 header. This is probably not noticeable, unless a central server keeps 648 a very large number of binding cache entries. In order for the extra 649 overhead to reach a substantial fraction of the traffic of a central 650 server, the server must receive much binding update traffic compared 651 to the amount of traffic resulting from its transactions. For 652 instance, consider a server that on average receives a BU on every 653 tenth request and has request size of 100 and response size of 200 654 bytes. The overhead cause by extra BU messages for this server would 655 be ((40+40)/10) / (100+300) = 2.7%. 657 However, the most pressing issues in bandwidth conservation are proba� 658 bly not in larger servers or LAN traffic but in hosts operating behind 659 cellular or other highly constrained interfaces. There, an additional 660 40 bytes is a significant cost even if not sent often. But the esti� 661 mation of the difference between piggybacked and separated packet is 662 harder since on these interfaces advanced header compression mecha� 663 nisms and other techniques are typically used. As an example, we have 664 considered the ROHC header compression schemes [12]. Its adoption in 665 various cellular standards as a compression mechanism justifies its 666 use as an example. 668 The techniques in ROHC allow collapsing the IP and transport layer 669 headers when they don't change or change predictably between packets. 670 Interestingly, ROHC is capable of dealing with options as a difference 671 that can be sent without requiring the full IPv6 header to be 672 repeated. This means that when ROHC is used, piggybacked BUs only 673 cause extra bandwidth usage that is close to proportional of the size 674 of the BU headers. 676 When a separate packet is sent with a new protocol number, the first 677 time ROHC needs to send a full IPv6 header as well as the BU itself. 678 Subsequent Binding Updates can be compressed, and the payload stream 679 continues to be compressed independently of the new BU stream. There� 680 fore, in the case of ROHC, piggybacking is in the long run roughly 681 equivalent to the non-piggybacked case. There is a difference for the 682 first packet, of roughly 40 bytes. 684 At present, ROHC has special support for RTP, UDP, and some of the 685 basic IPv6 extension headers. It compresses other extension headers in 686 a generic way. ROHC will be able to compress the BUs partially or 687 completely away regardless of whether they are in a separate header or 688 inside the Destination Options [21]. 690 While not directly relevant for the piggybacking discussion, we should 691 note that ROHC supports both AH and ESP [12, section 5.8]. Small 692 changes in these and other IPv6 extension headers can be sent as dif� 693 ferences. 695 The DOCSIS PHS is another example of a compression mechanism. It uses 696 bit masks to signal identical fields, and would appear to be able to 697 work well both with at least non-piggybacked traffic, provided that 698 separate contexts again would be held for BUs and other streams. 700 DOCSIS also allowed more than one frame to be sent on a single trans� 701 mission opportunity. This allows non-piggybacked traffic to use the 702 same opportunity, not changing the number of sent bits but reducing 703 delay even if the BUs are sent separately. 705 The use of header compression for Binding Updates is also affected by 706 movements. Unless there is a context transfer between base stations, 707 compression state of the BU sender is lost in any case at the time the 708 BU is sent. BU receivers will still be able to use compression, how� 709 ever. 711 7.4. QoS Implications 713 When Mobile IP signaling and payload traffic are combined in the same 714 packets Quality-of-Service (QoS) conflicts may occur, as the user may 715 have wanted to assign different priorities to them. The relevance of 716 this can be questioned, as the growth of the packets is only marginal 717 and the packet could reasonably be expected to be tagged with the flow 718 label of the payload regardless of the additional options. Also, the 719 sender has the possibility to send packets separately if the QoS poli� 720 cies are in conflict. However, such separation is only possible for 721 the sender and not for any of the routers in between. (The routers are 722 in some architectures responsible for the QoS tasks.) 724 A more serious QoS problem appears in cellular networks where specific 725 channels have been allocated for the host to send and receive e.g. 726 multimedia streams. Any TDM-like slot allocation scheme may need such 727 QoS reservations. Such channels have been calculated to be able to 728 carry exactly the stream (even taking in account ROHC and other header 729 compression techniques) but nothing else. An additional signaling pay� 730 load appended to the stream would essentially force the packet to be 731 dropped, or routed through best effort channels. In the case of con� 732 versational services, the latter alternative would also in practice 733 mean losing the whole packet, because it would be unlikely to arrive 734 in time to be useful. 736 As far as an individual cellular terminal is concerned, it can make 737 smart decisions about when to piggyback and when to not. However, this 738 option does not necessarily exist for the other end of the communica� 739 tions; a MN carelessly sending a piggybacked BU along a stream to its 740 correspondent cellular host might cause the BU information and a frac� 741 tion of the stream to be lost. 743 Specifically reserved tight channels are a fact of life. However, it 744 is perhaps fair to note that making IP run inside them is already dif� 745 ficult even without piggybacked BUs. Header and other compression 746 mechanisms produce variable length results, and the in the case of 747 Mobile IP the channel reservation may have to take in account not just 748 the BUs, but also other options. What is different, however, in the 749 case of BUs is first of all their size - at least two dozen bytes - 750 which may make it hard for them to fit the slack, and it is undesir� 751 able to reserve so much extra space. Secondly, BUs are dynamically 752 changing while e.g. Home Address options are other similar headers are 753 static. Static headers in general are always compressed away, and in 754 any case predicting their size is easier. 756 Piggybacking may also interact with resource reservations at the IP 757 layer, such as those performed by RSVP. 759 7.5. Other Implications 761 It has been said that piggybacking is used today also as a facility to 762 send the BUs at an appropriate time, conveniently along other traffic. 763 The intent is to not send binding updates until it is proven that fur� 764 ther traffic to the Correspondent Node exist. On the other hand, it 765 appears that this convenient mechanism can't be used all of the time, 766 given that it only works in one direction, and does not allow for 767 optimized routing of packets sent by the CN. For this reason typical 768 implementations wait a while and send the BU in any case if no other 769 traffic has appeared [19]. 771 We also note that in both piggybacked and separate packet solutions we 772 can achieve the same goals. A BU should be sent at a suitable time, 773 specified in the standards or left to the optimization logic of vari� 774 ous implementations. With piggybacking, a BU can be attached to the 775 packet that is destined to the CN. Without piggybacking, the appear� 776 ance of a packet destined to the CN would trigger the sending of 777 another packet along it. Similar functionality exists today on all 778 IPv6 stacks to send address resolution messages and other control 779 traffic, so it seems that it on most stacks it should be possible to 780 generate new packets based upon seeing traffic to a particular desti� 781 nation. 783 One difference between the piggybacked and the separate packet solu� 784 tions is that in the latter we can not guarantee that the BU arrives 785 at the CN before the payload packet. The BUs are used in the route 786 optimization functionality - which is optional - and decided on a 787 case-by-case anyway by implementations. Therefore, the payload traffic 788 will get to the other end and back regardless of the BUs. If the sep� 789 arate BUs are delayed behind the payload packets, it is possible that 790 the payload response comes through an unoptimized route. However, let 791 us assume that the first two packets along a router are going to be 792 reordered. In the piggybacked solution this means that the regular 793 packet gets to the destination first, following the packet that has 794 the piggybacked BU. In this situation one packet needs to be routed 795 through the home. In the non-piggybacked solution the BU and the first 796 payload packet get reordered, and again one the result is that one 797 packet needs to be routed through the home. Assuming packets are 798 routed through the home works best, however, only when the MN - CN 799 first contact each other and don't have an existing Binding Cache 800 Entry. Where an entry exists, and the MN is now moving to another 801 location, it becomes essential to be able to inform the CN as soon as 802 possible, as otherwise packets may get lost to the previous location. 804 As has been discussed earlier, it is also possible that the addition 805 of the BUs may cause the packets to be routed differently, and may 806 already imply delayed reception. On the other the BU packets - small 807 packets - may easily get different treatment than the regular packets, 808 making it slightly more likely that a reordering will occur. In con� 809 clusion, there does not seem to be a fundamental difference in this 810 regard. 812 Firewalls and other similar devices should be able to process piggy� 813 backed packets, even if they have BU options in them. If they do not 814 let such traffic through they will also not let regular Mobile IP Home 815 Address options through, blocking all traffic. If the BUs are sent in 816 separate packets, the firewalls have to have rules to allow this traf� 817 fic in. 819 A similar situation to the BU problem appears in the case of RSVP and 820 the Router Alert options [17]. In this case IPsec was not used and the 821 option was kept as an option. 823 As has been indicated elsewhere [23], it may be necessary to run some 824 of the weak authentication protocols as a separate protocol/port 825 rather than as a Destination Option, in order be able to pass suffi� 826 ciently long public key values. This does not have an effect to the 827 piggybacking as such, because where such long public keys are needed, 828 the BSA-based approach will be likely necessary and therefore the weak 829 authentication and actual BUs can run in different protocols anyway. 831 7.6. Other Solutions to the Piggybacking Problem 833 It has also been suggested that a more general purpose multi-payload 834 IPv6 mechanism could be developed [13]. This would allow adding piggy� 835 backing later in as an option, and could tackle the IPsec problems in 836 a general way and without delaying the Mobile IPv6 standardization. 838 One worry around this solution is that the Mobile IPv6 implementation 839 may not have enough capabilities to direct the merging of packets. 840 For instance, if the merging is implemented as a general IP layer 841 function, it is not guaranteed that BUs get merged unless two packets 842 are actually seen simultaneously. As the first packet may already be 843 partially out from an interface, it is not clear that the function 844 will see these packets early enough. However, it appears that this 845 problem can be solved by having the Mobile IP code perform the merging 846 when it detects a need to send a BU. 848 A more serious problem in this solution comes from the partial deploy� 849 ment, which obviously can't be avoided as such multi-payload schemes 850 are not a part of current IPv6. How does a node know when the receiver 851 supports this feature and when not? It may be possible to use 852 responses, errors, or the lack of these as an indication of the 853 receiver's support. However, it is not clear what kind of implications 854 this has for the additional messaging, start-up times, and so on. 856 8. Comparison of Solutions 858 The following criteria are used in evaluating the pros and cons of the 859 presented solutions: 861 - Requirements fulfillment. For instance, do the solutions allow both 862 weak and strong authentication? 864 - The header overhead of the solution, and the number of extra packets 865 required. 867 - The computational overhead of the solution. (Note that public key 868 cryptography, Diffie-Hellman, and other overhead related to authenti� 869 cation is not under discussion here. It is assumed that the user orga� 870 nizations select between the heavier strong authentication protocols 871 and the lighter weak authentication protocols. The comparison of par� 872 ticular authentication protocols such as BAKE [6], SUCV [7] and others 873 [18] also isn't the subject of this memo.) 875 - The memory and state requirements of the solution. 877 - The necessity to allocate Destination Option or Next Header numbers 878 from IANA. 880 - The required standardization work. 882 - Are the mechanisms future proof, as the current strong authentica� 883 tion protocols evolve to new ones (which is expected to happen with 884 the Son-of-IKE effort). 886 - Ability to handle error situations. 888 - Ability to optimize behaviour for busy servers. 890 - Ability to ensure that the right BSAs are used for the right BUs. 892 - Implementation aspects. 894 8.1. Requirements Fulfillment 896 Like the other alternatives, the application specific solution ful� 897 fills the requirements for integrity protection and replay protection, 898 the former through the -14 mechanisms and the latter through the BU 899 replay counters. 901 This alternative also allows the use of a new weak authentication pro� 902 tocol, or a new protocol capable of both weak and strong authentica� 903 tion. The use of an existing strong authentication protocol isn't 904 directly possible, an enhancement of both the protocol standards and 905 the implementation would be necessary. The enhancement necessary for 906 e.g. IKE [4] would involve adding a new protocol along the side of AH 907 and ESP with possible other parameters such as algorithm identi� 908 fiers. This would be an extension of the current IPsec DoI [5]. 910 The -14 mechanisms can satisfy the requirement to be able to use dif� 911 ferent algorithms. However, at the moment [1] does not define even a 912 single algorithm, let alone alternatives. 914 The IPsec based alternatives fulfill the requirements for integrity 915 protection and replay protection, both through AH mechanisms. Note 916 that an additional layer of replay protection exists at the BU mes� 917 sages. It isn't possible to remove the fields related to this, as 918 IPsec provides only replay protection but not sequenced delivery. For 919 the Mobile IP route optimization to work, sequenced delivery is also 920 needed. 922 Existing IPsec AH can use both weak and strong authentication proto� 923 cols. There is no need to modify the strong authentication protocols, 924 or the IPsec stack in order to make this possible. However, a local 925 API must exist between the new weak authentication protocol and the 926 IPsec implementation in order to set up suitable policy entries and 927 SAs. 929 IPsec AH with extended policy rules allows the use of a new weak 930 authentication protocol, or a new protocol capable of both weak and 931 strong authentication. The use of an existing strong authentication 932 protocol isn't directly possible, an enhancement of both the protocol 933 standards and the implementation would be necessary. The use of a new 934 weak authentication protocol and an enhancement of an existing strong 935 authentication protocol. The enhancement necessary for e.g. IKE [4] 936 would involve an extension of the client identifiers to support the 937 extended policies capable of differentiating IPv6 Destination Options. 938 It is not possible to use existing strong authentication protocols 939 unchanged in this solution. 941 All IPsec AH based solutions satisfy the requirement on being able to 942 use different algorithms. A set of standard, mandatory algorithms 943 exists, as well as many optional ones. 945 The use of both application specific and IPsec mechanisms fulfills the 946 requirements for integrity protection and replay protection. 948 Various combinations of authentication protocols could be used in this 949 alternative, but one particular combination seems most suited. Namely, 950 a new weak authentication protocol could be used to key exclusively 951 the application specific protection of BUs, and an optional strong 952 authentication protocol would build SAs that use IPsec around them. 954 8.2. Header Overhead 956 In the application specific solution, the integrity protection related 957 parts in the BUs contain the authentication data length, SPI, and 958 authentication data fields. The length of the last field is not 959 given, but assuming a typical 96 bit field is used, the total overhead 960 from this is 17 bytes. 962 IPsec AH-based solutions add the SPI, sequence number, next protocol, 963 and MAC fields. The total number of additional bytes is 24. 965 For the combined use of both application specific and AH mechanisms 966 there is a fixed cost of 17 bytes in all BU messages. An additional 967 cost of 24 bytes is applied to those messages that use also the 968 IPsec/IKE-based security. Therefore, a total of 41 bytes overhead may 969 be reached in the worst case. 971 The number of packets in the application specific, extended IPsec, and 972 combined alternatives are the same as piggybacking can be employed. In 973 the use of existing IPsec AH there are N additional packets, where N 974 is the number of BUs and their acknowledgements sent. 976 8.3. Computational Overhead 978 The application specific scheme runs a cryptographic hash over speci� 979 fied fields, typically 62 bytes assuming there are no BU suboptions. 980 The nature of the cryptographic hash hasn't been specified, but we can 981 safely assume it is similar to mechanisms used elsewhere such as HMAC 982 MD5. 984 The number of bytes used in the input to the hash function has signif� 985 icance, though the hash functions typically have some amount of static 986 cost so that the computational overhead is not linear with respect to 987 the number of input bytes. In one implementation of HMAC MD5, a four- 988 fold increase in the size of the packet increased the amount of time 989 spent by 33% (for small packets). 991 The same implementation achieved speeds of around 60 Mbit/s, or 992 100,000 MACs/s for an input of size 62 bytes, on a Pentium 600 MHz 993 machine. Increasing the size fourfold changed these numbers to 170 994 Mbit/s and 75,000 MACs/s. Similar numbers are also available for other 995 implementations [14]. These numbers indicate that a relatively large 996 number of BUs can be treated with typical computer systems; likely far 997 more than is required for anything else except the busiest servers. On 998 a smaller devices such as handheld cellular devices, the available 999 power is much smaller but so is also the number of BUs that need to be 1000 treated; it is hard to imagine why a device with a constrained inter� 1001 face towards the Internet would have to process even 1 BU/s. 1003 IPsec uses also standard cryptographic hash functions, which we 1004 assumed would also be used in the application specific protection. In 1005 contrast to the BU suboption, however, the hash is run over the whole 1006 packet. Assuming the size of a BU protocol running directly on top of 1007 IP would be roughly the same as in a BU option, the total number of 1008 input bytes would be 40 from the IPv6 header, 18 from the Home Address 1009 option, 24 from AH, plus 10 from the BU protocol, i.e. 92. 1011 These numbers imply that the pure cryptographic operations necessary 1012 in this alternative are roughly equivalent to those needed for BU pro� 1013 tection in the application specific manner. In addition there are 1014 IPsec-related tasks such as policy matching and header processing 1015 which are harder to quantify. Implementations also differ much in this 1016 respect, as some may be using sequential searches and others trees. 1017 One good software-based IPsec implementation reports the speed of 65 1018 Mbit/s with AH HMAC_MD5 in transport mode, on a Pentium 800 Mhz 1019 machine, and 82 MBit/s when policies were being checked but none of 1020 the packets needed security. The unsecured IP performance was 85 1021 Mbit/s [14] on the same machine. 1023 In any case, these numbers again indicate sufficient capacity to deal 1024 with BUs under most normal circumstances, possibly with the exception 1025 of the busiest servers. A crucial factor is the amount of BU traffic 1026 vs. other traffic. Let us assume 10 KB regular traffic interrupted by 1027 a 0.1 KB BU, and a system that would handle 10 Mbit/s BUs. Even if the 1028 reference used above didn't describe the packet sizes used in the 1029 test, it seems safe to assume that a single CPU would be able to han� 1030 dle this load. But under these assumptions, the system would also be 1031 handling 1 GBit/s other traffic. If there's only 1 KB (one large 1032 packet) of traffic between the BUs, then this number would be 100 1033 MBit/s. 1035 Application specific protection would allow easier treatment of policy 1036 processing and SA searches, as the Binding Cache Entries could be used 1037 to store the right BSA (or a small number of them, in case overlapping 1038 BSAs are allowed). This means that it would not be necessary to create 1039 an efficient data structure to make a fast search, as is the case in 1040 IPsec. 1042 The computational overhead for extended IPsec is similar to that of 1043 existing IPsec, except that now also the payload contents may be 1044 included in the hash calculations. Assuming the average original 1045 packet size of, say, 300 bytes, this makes the real packet size with 1046 all options and AH to be 352. This is also the input to the hash func� 1047 tion. 1049 Given our earlier measurement data, it doesn't seem that the size of 1050 the packets matters as much as might be expected. Some increase in CPU 1051 demands will be seen, however. 1053 In the combined use of application specific and IPsec solutions, the 1054 computational overhead at the minimum is the same as in the applica� 1055 tion specific protection, i.e. running a hash over 62 bytes. In case 1056 IPsec/IKE-based security is used in addition, then an additional sec� 1057 ond hash needs to be calculated. Assuming again the 300 byte average 1058 original packet size, this amounts to running a hash over 369 bytes. 1060 Again, the size of the input to the hash operations does not seem to 1061 have significant importance. However, the number of operations is 1062 important and in this situation there are two. The two hashes are cal� 1063 culated, however, only within the protected network communications. 1065 All IPsec-based approaches typically require calculating the MACs once 1066 the whole packet has been completed and formed. In contrast, the BU 1067 suboption method allows doing this somewhat earlier as the BU is being 1068 created. This may offer the advantage of being able to perform the 1069 cryptographic operation at the time of the movement, not at the time 1070 we are waiting to get some payload traffic to the peer. This may also 1071 be useful for a retransmission of a BU. 1073 8.4. Memory and State Requirements 1075 In the application specific solution, a security association data 1076 structure is needed for every BSA established to protect the BUs. The 1077 current assumption is that the BSAs are unidirectional, but unlike the 1078 IPsec solution they could also be bidirectional and thereby halving 1079 the memory requirements. Note that there may in any case be multiple 1080 concurrent BSAs per each MN in order to allow for smooth rekeying. 1081 Each BSA must contain information about the used integrity key (typi� 1082 cally at least 20 bytes), the SPI (4 bytes), lifetime (4 bytes), algo� 1083 rithm (under 1 byte) and an implementation dependent amount of admin� 1084 istrative information, such as pointers to Binding Cache entries, 1085 statistics, and other relevant information. 1087 Security association data structures are needed also for the IPsec 1088 SAs. IPsec SAs are a bit more general-purpose than application spe� 1089 cific SAs, including for instance encryption keys, selectors, lifetime 1090 and statistics information, and other similar data. Typical implemen� 1091 tations use memory in the order of, say, 400 bytes for each SA. An 1092 implementation optimized for memory usage could cut this down to 1093 around 170 bytes, most of which is spent on the IPv6 addresses needed 1094 for the destination and selector addresses. 1096 In addition to the SA information, the IPsec implementations (may) 1097 need to add policy entries related to each specific host. These need 1098 both memory, and execution time for each packet. Typical implementa� 1099 tions would perhaps use a similar amount of space for a policy entry 1100 as they do for an SA. On a MIP-specific solution, we didn't need this 1101 as the policy is hardcoded to the processing of the BUs. 1103 There isn't much information available on how large number of SAs and 1104 policy entries typical implementations support. Special hardware 1105 devices can support tens of thousands of simultaneous connections 1106 [15]. A central question is the support for a large number of SAs in 1107 typical server OS implementations. Smart implementations can provide 1108 logarithmic-time processing of security rules and SA databases [16], 1109 but some implementations may be built more around VPN access scenarios 1110 (small number of SAs) rather than end-to-end security towards multiple 1111 directions. 1113 There may be optimizations available for devices that do not want to 1114 support IPsec in general and only want to support it for BU protec� 1115 tion. In this case it is possible to eliminate execution time overhead 1116 for other packets, and to use the Binding Cache entries and BSAs as 1117 the sole packet matching mechanism. 1119 The memory and state requirements for combined application specific 1120 and IPsec alternative is (roughly) a sum of the requirements for the 1121 two mechanisms. 1123 8.5. IANA Requirements 1125 The application specific solution requires a Destination Option number 1126 to be allocated for the BUs. 1128 The existing IPsec AH solution requires a new IPv6 next header value - 1129 a more valuable resource - to be allocated. 1131 With an extension to the IPsec policies, only the Destination Option 1132 value needs to be allocated. 1134 In the combined use of IPsec and the application specific mechanism 1135 the situation is the same, and only the Destination Option value needs 1136 to be allocated. 1138 8.6. Standardization Work 1140 No standardization work outside the Mobile IP WG is needed for the 1141 application specific solution. However, if an existing strong authen� 1142 tication protocol needs to be used also, then it needs to be extended. 1143 This likely needs IPsec WG involvement. Of course, strong authentica� 1144 tion could also be built in to the Mobile IP specific protocols. 1146 In the use of existing IPsec, no standardization work outside the 1147 Mobile IP WG is needed. Even if strong authentication protocols need 1148 to be used, they can be used as is. 1150 The extension of IPsec to cover individual Destination Options would 1151 need an action from the IPsec WG for a small extension to both IPsec 1152 and its key management mechanisms. 1154 The combined use of application specific solution and IPsec requires 1155 no standardization actions, even if strong authentication is needed. 1157 All solutions relying on IPsec AH may suffer from the possible action 1158 in the IPsec WG to deprecate AH. This has been discussed from time to 1159 time, mainly under the argument of reducing the complexity of IPsec. 1160 If this happens it may be possible use ESP instead of AH [3]. 1162 8.7. Evolution of Authentication Protocols 1164 Here we discuss the effects of evolving authentication protocols. 1165 Such evolution takes place on two fronts. First, as the weak authenti� 1166 cation area is a new one, we can expect new and better protocols to 1167 appear for this purpose. Secondly, also the current strong authentica� 1168 tion protocols and IPsec are under evolution, such as the work on Son- 1169 of-IKE which has been prompted by the complexity of IKE. 1171 The application specific solution can - if designed right - accommo� 1172 date new weak authentication protocols easily. It is necessary to pro� 1173 vide a clean separation between the BU protection and the authentica� 1174 tion protocol, but this should be easy. 1176 The application specific solution can also accommodate existing strong 1177 authentication, provided that they are extended to support the BU pro� 1178 tection protocols. The ability of this solution to follow the evolu� 1179 tion of such strong authentication protocols depends heavily on the 1180 interest of their developers to retain non-IPsec support in the proto� 1181 col if it is extended, simplified, or redesigned. It is therefore not 1182 fully certain that new protocols also allow the same thing. 1184 The use of existing IPsec is more certain to be possible even if the 1185 keying protocols evolve. If IPsec is extended to cover also individual 1186 Destination Options, new keying protocols should also be able to do 1187 this. Unless there is a desire to simplify things, but one could 1188 expect that such simplification could be foreseen as the extension 1189 itself is discussed. 1191 The combined use of application specific protection and IPsec allows 1192 evolution both in the weak and in the strong authentication protocols. 1194 8.8. Error Situations 1196 Application layer mechanisms in general have more context information 1197 available regarding various error situations than IP layer solutions. 1198 IPsec discards packets if they are in any way unexpected. The question 1199 regarding BU protection is if there are any situations where other 1200 treatment of BU protection error cases is needed than discarding. 1202 For instance, if the last message of an authentication protocol would 1203 happen to arrive after the first protected BU has been sent, IPsec 1204 would simply discard the packet while an application specific mecha� 1205 nism might store it in the anticipation of completing the authentica� 1206 tion soon. It isn't clear how important this case is, however. There 1207 might also be some DoS implications on doing this. 1209 Another problem appears with weak authentication protocols that piggy� 1210 back the authentication / key agreement messages in the final BU that 1211 is sent from the MN to the CN. Here, the BSA should exist as the 1212 packet is being processed, but the BSA will actually be created only 1213 after looking a the authentication option in the packet. For the 1214 application specific security, it is easier to e.g. process BU subop� 1215 tions in a specific order, but for IPsec AH the processing happens at 1216 a predefined order. Some weak authentication schemes such as [6] do 1217 not have a problem with this, because they have specified an ordering 1218 that allows the BSA establishment to take place before the BSA is cre� 1219 ated. Some others such as [18] make use of BU suboptions, making it 1220 harder to create an IPsec SA at the same time the option itself is 1221 being processed. The practical effects of this issue is that the use 1222 of IPsec forces either a separated authentication packet, or an order� 1223 ing of the Destination Option and AH headers. 1225 8.9. Optimizations for Busy Servers 1227 It is possible that on some busy servers the computation or memory 1228 loads exceed the capabilities of the hardware. It is possible though 1229 for server manufacturers to add a feature that enables the device to 1230 age BUs faster and/or refuse weak authentication and optimized routing 1231 if the load grows too high. 1233 The optimizations for IPsec are similar to those for application spe� 1234 cific protection of BUs. The main optimization is reducing the number 1235 of BSAs, and the use of optimized routing. 1237 In the combined alternative, similar optimizations exist for the 1238 application specific protection as has been described earlier. For the 1239 additional IPsec protection, there aren't such possibilities. The 1240 security policies require the use of IPsec for the traffic within the 1241 part of the network that is expected to be protected. 1243 8.10. Address Ownership 1245 In all alternatives, it is assumed that the authentication protocol 1246 somehow determines the right of a particular peer to claim ownership 1247 of a particular address. For instance, BAKE relies on the difficulty 1248 of an eavesdropper to simultaneously see messages along different 1249 paths to prove a weak form of address ownership [6]. An BSA is estab� 1250 lished after the determination is made. 1252 This is, however, not enough. It is also necessary to ensure that sub� 1253 sequent communications do not violate the address ownership. For 1254 instance, a MN might establish a legitimate BSA with a CN, and then 1255 use this BSA to send a binding update for another MN. 1257 In the application specific solution, it is necessary to ensure that 1258 the BSA is used only with respect to the same Home Address that was 1259 used also for the authentication part. Currently, this hasn't been 1260 specified in the draft, but could easily be added. 1262 In the case of IPsec, the dynamic updates to the SPD and/or the selec� 1263 tors in the SAD must be used to create the same effect. The individ� 1264 ual policy entries, or the selectors of each SA would be set to the 1265 particular addresses used in the communications. Note that like all 1266 other IP and higher layer processing, IPsec policy matching is per� 1267 formed on the used home addresses rather than Care-of-Addresses. This 1268 means that the given SA can only be used with the original Home 1269 Address. 1271 In the case of combined use of application specific and IPsec mecha� 1272 nisms, both solutions presented above are used together. 1274 8.11. Implementation Aspects 1276 The application specific solution can be programmed in isolation from 1277 the rest of the IPv6 stack. No new APIs are needed for the security 1278 part. Security association lookup can be performed using the same data 1279 structures that are used for finding Binding Cache entries. (We do 1280 need to allow for multiple BSAs towards the same peer, but given that 1281 they would typically be just 1 or 2 it doesn't appear to require a 1282 very optimized search tree.) 1284 On the busiest servers, it might be necessary to provide some hard� 1285 ware-level acceleration mechanisms. Some existing hardware chips 1286 could be used for this purpose, though some other chips are more tai� 1287 lored towards specific IPsec processing, and are not applicable. 1289 If IPsec is used, then an API is needed towards the SPD and/or the 1290 SAD, so that the Mobile IPv6 implementation can add/delete entries 1291 from them. 1293 It is also necessary to ensure that the IPsec implementation is capa� 1294 ble of handling large amounts of SPD and SAD entries efficiently, if 1295 the stack is going to be used in servers that have many clients. This 1296 may mean improving the SPD matching mechanisms and/or SAD lookup. In 1297 the case of normal IPsec processing, there doesn't exist a similar 1298 Binding Cache entry that was used in an optimized lookup in the appli� 1299 cation specific solution. (However, there may be possibilities to 1300 optimize this even for IPSec when just BU protection but not general 1301 IPsec functionality is needed, as discussed in section 8.4.) 1303 IPsec implementations may take advantage of existing hardware chips, 1304 and their use in current and future products. 1306 IPsec implementations in general are more complex than providing just 1307 the -14 mechanisms. 1309 9. Conclusions 1311 The purpose of this memo is to mainly list the solutions and their 1312 respective advantages and disadvantages. We do not make a recommenda� 1313 tion here to select a particular solution as some of the pros and cons 1314 are not easy to weight against each other. We hope, however, that 1315 this memo helps the Mobile IP Working Group to see the complete situa� 1316 tion, and reach a consensus on how the solutions weigh against each 1317 other. 1319 However, the author would like to offer a few observations: 1321 - It is crucial for the selection that we decide what the minimum 1322 level of security offered will be. If the WG wants to have security 1323 where keying material is not created at all, it appears that only 1324 application specific solutions are possible (possibly combined with 1325 IPsec). Note that the keying material generation in e.g. BAKE is 1326 intended to be an optimization, caching the knowledge that a certain 1327 type of return routability was verified. Without the keying material, 1328 a BAKE-like check needs to be performed for all BUs. 1330 - Another crucial decision is the 'philosophical approach' we want to 1331 take. The approaches are discussed in the beginning of chapter 6. 1333 - In header overhead, the application specific solution is the small� 1334 est one, though the difference is not big (17 versus 24 bytes). If 1335 both application specific and IPsec mechanisms are used, the overhead 1336 is large but only when strong authentication is also applied. 1338 - Preliminary results regarding the effects of piggybacking indicate 1339 that typical header compression mechanisms result in similar bandwidth 1340 usage for both piggybacked and non-piggybacked cases. Essentially, the 1341 changing components of packets need to be sent. However, these results 1342 depend a lot on the particular situation, compression end-point loca� 1343 tion, and so on. Also, the effect for stationary BU receivers is dif� 1344 ferent than for BU senders that may have to start with a new 1345 compression context after movements. It should be noted that there 1346 are complexity, QoS channel reservation, and other issues with piggy� 1347 backing so it is not clear that it is always desireable. 1349 - In particular, piggybacking makes cellular network channel reserva� 1350 tions hard and/or inefficient. Such reservations are necessary on some 1351 networks, and it is not possible to reserve space for occasional 1352 Mobile IP signaling in them. 1354 - Strong authentication should be allowed as an option for certain 1355 organizations. In those organizations, there is likely a need for 1356 securing other traffic as well, and it might be wise to consider not 1357 duplicating the configuration effort etc. for Mobile IP and other 1358 applications. 1360 - Adding strong authentication support to protocols such as BAKE may 1361 not be easy. Relatively complex PKI protocols have to be managed, some 1362 organizations would prefer legacy authentication schemes which would 1363 make even the PKI approach insufficient, etc. 1365 - IPsec allows easier evolution in the authentication protocols. For 1366 instance, organizations that require strong authentication could use 1367 legacy as well as PKI-based authentication through IPSRA solutions. 1368 The modification of e.g. IKE to support also the application specific 1369 protection is not a recommended approach. 1371 - It is possible to use IPsec for BU protection without modifications 1372 to the IPsec standards. However, Mobile IPv6 will have to be changed 1373 to use a separate protocol number for the BUs and not allow piggyback� 1374 ing. In this alternative, a new IPv6 protocol number (or UDP port) 1375 would have to be allocated, which can be considered a more valuable 1376 resource than the current Destination Option values. 1378 - It is also possible to extend IPsec policy mechanisms and then keep 1379 Mobile IPv6 unchanged. However, while the modifications are small 1380 there are currently a number of other things on the table in the IPsec 1381 WG, and therefore making these extensions might cause a delay. 1383 - There doesn't seem to be a huge performance difference among the 1384 solutions in the sense of cryptographic computations. Possible perfor� 1385 mance differences can be found in the policy matching area, where 1386 IPsec needs to do work that is more straightforward in the application 1387 specific solution (though it still needs to be done). It is hard to 1388 quantify these, however, as the implementations differ in how effi� 1389 ciently they have solved the issue. This is relevant mainly for very 1390 large servers with large Binding Caches. 1392 - Optimizations for busy servers are possible in all presented alter� 1393 natives. IPsec demands more memory per BSA, though. 1395 - Address ownership issues can be solved all of the presented alterna� 1396 tives. 1398 - IPsec is more complex to implement than the pure application spe� 1399 cific solution. On the other hand, one can take advantage of existing 1400 hardware and software support on a number of products. This situation 1401 may continue in the future as well, as BU protection may not be in 1402 sufficiently high demand to force server vendors to have hardware sup� 1403 port for it. 1405 - In complexity, the main focus should be paid to the key management 1406 parts rather than the IPsec or -14 parts, because that's where most 1407 complexity lies. An added complexity in the BU protection part may be 1408 justifiable if a larger complexity reduction can be achieved then on 1409 the key management part. 1411 10. Further Work 1413 The author seeks feedback from the Mobile IP and security communities 1414 to verify that the presented solutions are complete, secure, and can 1415 be implemented. 1417 This memo discusses only the BU protection issue and leaves the weak 1418 authentication mechanisms to be discussed by other work. Likewise, we 1419 take no stand in the selection or future development of strong authen� 1420 tication mechanisms such as IKE, Son-of-IKE, KINK, and others. 1422 The security between the Home Agent and the Mobile Node isn't covered 1423 in this memo, even if it also involves the use of Binding Updates. It 1424 is likely that strong security could be applied in this context, given 1425 that there the home and the mobile have a pre-arranged relationship. 1427 The current version of this memo discusses only the use of IPSec AH. 1428 It may be possible to use also ESP as is discussed in [3]. This might 1429 become necessary if we get an indication that the AH protocol would be 1430 deprecated (which is periodically discussed by the IPSec WG). 1432 Hiding the home address of mobile nodes hasn't been considered as a 1433 requirement for this work. There might be some possibilities for doing 1434 this through the placement of the BUs after an ESP header. However, 1435 this would need to be done for all traffic and not just the BUs. Also, 1436 what has been stated in this document about the policy rules and 1437 selectors that match the home address would no longer hold. 1439 Michael Thomas has suggested that existing strong authentication pro� 1440 tocols such as IKE could be used as-is even for the weak authentica� 1441 tion, by employing self-signed certificates. The main drawback of 1442 using exclusively these protocols for this purpose is that too many 1443 roundtrips would be required. 1445 The terminology used in the draft has been the subject of some discus� 1446 sion on the mailing list. In particular, the terms "piggybacking", 1447 "weak authentication", and "strong authentication" are not very accu� 1448 rate and can at times be misleading. Due to lack of time, I haven't 1449 yet included better suggestions in to this draft (I'm not even quite 1450 sure if there are better suggestions). 1452 11. Acknowledgements 1454 The author would like to thank Charlie Perkins, Michael Thomas, Pekka 1455 Nikander, Phil Roberts, Thomas Narten, Hesham Soliman, Glenn Morrow, 1456 Lars-Erik Jonsson, Erik Nordmark, Greg O'Shea, and members of the 1457 Mobile IP mailing list for extensive discussions about the issues on 1458 the mailing list. Credit for all solutions and their respective pros 1459 and cons is fully due to the participants in these discussions. 1461 12. References 1463 [1] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- 1464 mobileip-ipv6-14.txt. Work In Progress, IETF, July 2001. 1466 [2] P. Nikander, D. Harkins, B. Patil, P. Roberts, E. Nordmark, T. 1467 Narten, A. Mankin, "Threat Models introduced by Mobile IPv6 and 1468 Requirements for Security in Mobile IPv6", draft-team-mobileip- 1469 mipv6-sec-reqts-00.txt. Work In Progress, IETF, July 2001. 1471 [3] M. Thomas, "ESP Protected Binding Updates", draft-thomas-mobileip- 1472 esp-bu-00.txt (unpublished). July, 2001. 1474 [4] D. Harkins and D. Carrel, "The Internet Key Exchange", RFC 2409, 1475 November 1998. 1477 [5] D. Piper, "The Internet IP Security Domain of Interpretation for 1478 ISAKMP", RFC 2407, November 1998. 1480 [6] P. Nikander, C. Perkins, "Binding Authentication Key Establishment 1481 Protocol for Mobile IPv6", draft-perkins-bake-01.txt. Work In 1482 Progress, IETF, July 2001. 1484 [7] G. Montenegro, C. Castelluccia, "SUCV Identifiers and Addresses", 1485 draft-montenegro-sucv-01.txt. Work In Progress, IETF, July 2001. 1487 [8] M. Thomas, D. Oran, "Home Agent Cookies for Binding Updates", 1488 draft-thomas-mobileip-ha-cookies-00.txt. Work In Progress, IETF, July 1489 2001. 1491 [9] J. Rajahalme, on the Mobile IP mailing list, August 21st, 2001. 1493 [10] P. Nikander, "An Address Ownership Problem in IPv6", draft-nikan� 1494 der-ipng-address-ownership-00.txt. Work In Progress, IETF, February 1495 2001. 1497 [11] S. Kent, R. Atkinson, "Security Architecture for the Internet 1498 Protocol" RFC 2401, BBN Corp, @Home Network, November 1998. 1500 [12] C. Bormann et al, "RObust Header Compression (ROHC): Framework 1501 and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, TZI/Uni 1502 Bremen, Matsushita, Univ. of Arizona, Ericsson, Cisco, Nokia, NTT 1503 DoCoMo, July 2001. 1505 [13] R. Elz, "The IPv6 Payload Header", Work In Progress, IETF, April, 1506 1996. 1508 [14] SSH Communications Security, "SSH IPSEC Express Performance", 1509 http://www.ssh.com/products/ipsec/performance.cfm. 1511 [15] Netscreen, "Meeting the Security Needs of the Broadband Inter� 1512 net", http://www.netscreen.com/products/ns1000_wpaper.html. 1514 [16] SSH Communications Security, "SSH IPSEC Express Specifications", 1515 http://www.ssh.com/products/ipsec/specs.cfm. 1517 [17] D. Katz, "IP Router Alert Option". RFC 2113, February 1997. 1519 [18] M. Roe et al. "Authentication of Mobile IPv6 Binding Updates and 1520 Acknowledgments", draft-roe-mobileip-updateauth-01.txt. Work In 1521 Progress, IETF, November 2001. 1523 [19] R. Wakikawa, on the Mobile IP mailing list, October 4th, 2001. 1525 [20] F. Dupont, on the Mobile IP mailing list, October 4th, 2001. 1527 [21] Lars-Erik Jonsson, private communication, October 8th, 2001. 1529 [22] E. Nordmark, "Securing MIPv6 BUs using return routability", 1530 draft-nordmark-mobileip-bu3way-00.txt. Work In Progress, IETF, Novem� 1531 ber 2001. 1533 [23] J. Arkko, "Security Framework for Mobile IPv6 Route Optimiza� 1534 tion", draft-arkko-mipv6ro-secframework-00.txt. Work In Progress, 1535 IETF, November 2001. 1537 13. Revision History 1539 The following modifications have been done since the -00 version: 1541 - Added text in 6.4 to indicate that it may be possible to disable the 1542 application specific protection where (and when) IPsec is available as 1543 suggested by Charlie Perkins. 1545 - Added new references for the non-SA models. 1547 - Added a discussion at the end of 8.3 on the need to run AH MACs for 1548 every packet, but being able to avoid that in the BU suboption model, 1549 as suggested by Vijay Devarapalli. 1551 - Added a discussion of BU suboption schemes being able make a faster 1552 SA/policy lookup. 1554 - Section 7.5 discusses the possibility that the weak authentication 1555 protocols would have to run outside DOs, and the effect (if any) it 1556 has on BU piggybacking. 1558 - Changed configuration discussions under chapter 6 to remove the pos� 1559 sibility of turning off security, as suggested by Erik Nordmark. 1561 - Added a discussion of various types of piggybacking, as suggested by 1562 Erik Nordmark. 1564 - Clarified the increase of CPU need as the packet size grows to apply 1565 only for small packets. 1567 - Clarified the BU and payload reordering impacts for MNs with estab� 1568 lished BCEs, as suggested by Erik Nordmark. 1570 14. Author's Address 1572 Jari Arkko 1573 Oy LM Ericsson Ab 1574 02420 Jorvas 1575 Finland 1577 Phone: +358 40 5079256 (mobile) 1578 +358 9 2992480 (office) 1579 EMail: Jari.Arkko@ericsson.com