idnits 2.17.1 draft-chiappa-lisp-architecture-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 898 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 745 has weird spacing: '...a whole separ...' -- The document date (July 9, 2012) is 4306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-fuller-lisp-ddt-01 == Outdated reference: A later version (-01) exists of draft-chiappa-lisp-introduction-00 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-06) exists of draft-irtf-rrg-ilnp-arch-05 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group N. Chiappa 3 Internet-Draft Yorktown Museum of Asian Art 4 Intended status: Informational July 9, 2012 5 Expires: January 10, 2013 7 An Architectural Analysis of the LISP 8 Location-Identity Separation System 9 draft-chiappa-lisp-architecture-00.txt 11 Abstract 13 LISP upgrades the architecture of the IPvN internetworking system by 14 separating location and identity, current intermingled in IPvN 15 addresses. This is a change which has been identified by the IRTF as 16 a critically necessary evolutionary architectural step for the 17 Internet. In LISP, nodes have both a 'locator' (a name which says 18 _where_ in the network's connectivity structure the node is) and an 19 'identifier' (a name which serves only to provide a persistent handle 20 for the node). A node may have more than one locator, or its locator 21 may change over time (e.g. if the node is mobile), but it keeps the 22 same identifier. 24 One of the chief novelties of LISP, compared to other proposals for 25 the separation of location and identity, is its approach to deploying 26 this upgrade. In general, it is comparatively easy to conceive of 27 new network designs, but much harder to devise approaches which will 28 actually get deployed throughout the global network. LISP aims to 29 achieve the near-ubiquitous deployment necessary for maximum 30 exploitation of an architectural upgrade by i) minimizing the amount 31 of change needed (existing hosts and routers can operate unmodified); 32 and ii) by providing significant benefits to early adopters. 34 This document gives additional architectural insight into LISP, and 35 analyzes a number of aspects of LISP from a long-term perspective. 37 NOTE: This is an initial rough draft, a much better version will be 38 out shortly. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. This document may not be modified, 44 and derivative works of it may not be created, except to format it 45 for publication as an RFC or to translate it into languages other 46 than English. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on January 10, 2013. 60 Copyright Notice 62 Copyright (c) 2012 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction 78 2. Architectual Frameworks 79 2.1. 'Double-Ended' Approach 80 2.2. Critical State 81 2.3. Need for a Mapping System 82 2.4. Piggybacking of Control on User Data 83 3. Namespaces 84 3.1. LISP EIDs 85 3.1.1. Residual Location Functionality in EIDs 86 3.2. RLOCs 87 3.3. Overlapping Uses of Existing Namespaces 88 3.4. LCAFs 89 4. Fault Discovery/Handling 90 5. Scalability 91 5.1. Demand Loading of Mappings 92 5.2. Caching of Mappings 93 5.3. Amount of State 94 5.4. Scalability of The Indexing Subsystem 95 6. Security 96 6.1. Basic Philosophy 97 6.2. Design Guidance 98 6.2.1. Security Mechanism Complexity 99 6.3. Security Overview 100 6.4. Securing Mappings 101 6.5. Securing the xTRs 102 7. Robustness 103 8. Optimization 104 9. Open Issues 105 10. Additional Material 106 11. Acknowledgments 107 12. IANA Considerations 108 13. Security Considerations 109 14. References 110 14.1. Normative References 111 14.2. Informative References 112 Appendix A. RefComment 113 Appendix B. Glossary/Definition of Terms 114 Appendix C. Other Appendices 116 1. Introduction 118 This document begins by introducing some high-level architectural 119 frameworks which have proven useful for thinking about the LISP 120 location-identity separation system. It then discusses some 121 architectural aspects of LISP (e.g. its namespaces). The balance 122 (and bulk) of the document contains architectural analysis of the 123 LISP system; that is, it reviews from a long-term perspective various 124 aspects of that system; e.g. its scalability, security, robustness, 125 etc. 127 NOTE: This document assumes a fair degree of familiarity with LISP; 128 in particular, the reader should have a good 'high-level' 129 understanding of the overall LISP system architecture, such as is 130 provided by [Introduction], "An Introduction to the LISP System". 132 By "architecture" above, the restricted meaning used there is: 'How 133 the system is broken up into subsystems, and how those subsystems 134 interact; when does information flows from one to another, and what 135 that information is.' There is obviously somewhat more to 136 architecture (e.g. the namespaces of a system, their syntax and 137 semantics), and that remaining architectural content is covered here. 139 2. Architectual Frameworks 141 When considering the overall structure of the LISP system at a high 142 level, it has proven most useful to think of it as another packet- 143 switching layer, run on top of the original internet layer - much as 144 the Internet first ran on top of the ARPANET. 146 All the functions that a normal packet switch has to undertake - such 147 as ensuring that it can reach its neighbours, and they they are still 148 up - the devices that make up the LISP overlay also have to do, along 149 the 'tunnels' which connect them to other LISP devices. 151 There is, however, one big difference: the fanout of a typical LISP 152 ITR will be much larger than most classic physical packet switches. 153 (ITRs only need to be considered, as the LISP tunnels are all 154 effectively unidirectional, from ITR to ETR - the ETR needs to keep 155 no per-tunnel state, etc.) 157 LISP is, fundamentally, a 'tunnel' based system. Tunnel system 158 designs do have their issues (e.g. the high inter-'switch' fan-out), 159 but it's important to realize that they also can have advantages, 160 some of which are listed below. 162 2.1. 'Double-Ended' Approach 164 LISP may be thought of as a 'double-ended' approach to enhancing the 165 architecture, in that it uses pairs of devices, one at each end of a 166 communication stream. In particular, to interact with the population 167 of 'legacy' hosts (which will be, inevitably, the vast majority, in 168 the early stages of deployment) it requires a LISP device at both 169 ends of the 'tunnel'. 171 This is in distinction to, say, NAT systems, which only need a device 172 deployed at one end: the host at the 'other end' doesn't need a 173 matching device at its end to massage the packets, but can simply 174 consume them on its own, as they are fully normal packets. This 175 allows any site which deploys such a device to get the full benefit 176 whilst acting entirely on its own. [Wasserman] 178 The issue is not that LISP uses tunnels. Designs like HIP 179 ([RFC4423]) and ILNP ([ILNP]), which do not involve tunnels, inhabit 180 a similar space to tunnel-based designs like LISP, in that unless 181 both ends are upgraded - or there is a proxy at the un-upgraded end - 182 one doen't get any benefits. So it's really not the tunnel which is 183 the key aspect, it's the 'all at one end' part which is key. Whether 184 the system is tunnel, versus non-tunnel, is not that important. 186 However, the double-ended approach of LISP does have advantages, as 187 well as costs. To put it simply, the 'feature' of the alternative 188 approach, that there's only a box at one end, has a 'bug': there's 189 only a box at one end. There are things which such a design cannot 190 accomplish, because of that. To put it another way, does the fact 191 that the packet has only a single name in it, because it is a 192 'normal' packet, present a limitation? Put that way, it would seem 193 natural that it should. 195 To compile as complete list of such situations is beyond the scope of 196 this document, but one example is mobility with open connections. 198 It is also possible to use LISP to tunnel IPv6 traffic over IPv4 199 infrastructure, or vice versa, invisibly to the hosts on both ends. 201 In the longer term, having having tunnel boxes would allow us to wrap 202 packets in non-IP formats: perhaps to take direct advantage of the 203 capabilities of underlying switching fabrics (e.g. MPLS); perhaps to 204 deploy new carriage protocols, etc, where non-standard packet formats 205 will allow extended semantics. 207 2.2. Critical State 209 LISP does have 'critical state' in the network (i.e. state which, if 210 if lost, causes the communication to fail). However, because LISP is 211 designed as an overall system, 'designing it in' allows for a 212 'systems' approach to its state issues. In LISP, this state has been 213 designed to be maintained in an 'architected' way, so it does not 214 produce systemic brittleness in the way that the state in NATs does. 216 For instance, throughout the system, provisions have been made to 217 have redundant copies of state, in multiple devices, so that the loss 218 of any one device does not necessarily cause a failure of an ongoing 219 connection. 221 2.3. Need for a Mapping System 223 LISP does need to have a mapping system, which brings design, 224 implementation, configuration and operational costs. Surely all 225 these costs are a bad thing? However, having a mapping system have 226 advantages, especially when there is a mapping layer which has global 227 visibility (i.e. other entities know that it is there, and have an 228 interface designed to be able to interact with it). This is unlike, 229 say, the mappings in NAT, which are 'invisible' to the rest of the 230 network. 232 In fact, one could argue that the mapping layer is LISP's greatest 233 strength. Wheeler's Axiom* ('Any problem in computer science can be 234 solved with another level of indirection') indicates that the binding 235 layer available with the LISP mapping system will be of great value. 236 Again, it is not the job of this document to list them all - and in 237 any event, there is no way to forsee them all. 239 The author of this document has often opined that the hallmark of 240 great architecture is not how well it does the things it was designed 241 to do, but how well it does things it was never expected to have to 242 handle. Providing such a powerful and generic binding layer is one 243 sure way to achieve the sort of lasting flexibility and power that 244 leads to that outcome. 246 [Footnote *: This Axiom is often mis-attributed to Butler Lampson, 247 but Lampson himself indicated that it came from David Wheeler.] 249 2.4. Piggybacking of Control on User Data 251 LISP piggybacks control transactions on top of user data packets. 252 This is a technique that has a long history in data networking, going 253 back to the early ARPANET. [McQuillan] It is now apparently regarded 254 as a somewhat dubious technique, the feeling seemingly being that 255 control and user data should be strictly segregated. 257 It should be noted that _none_ of the piggybacking of control 258 functionality in LISP is _architecturally fundamental_ to LISP. All 259 of the functions in LISP which are performed with piggybacking could 260 be performed almost equally well with separate control packets. 262 The "almost" is solely because it would cause more overhead (i.e. 263 control packets); neither the response time, robustness, etc would 264 necessarily be affected - although for some functions, to match the 265 response time observed using piggybacking on user data would need as 266 much control traffic as user data traffic. 268 This technique is particularly important, however, because of the 269 issue identified at the start of this section - the very large fanout 270 of the typical LISP switch. Unlike a typical router, which will have 271 control interactions with only a few neighbours, a LISP switch could 272 eventually have control interactions with hundreds, or perhaps even 273 thousands (for a large site) of neighbours. 275 Explicit control traffic, especially if good response times are 276 desired, could amount to a great deal of overhead in such a case. 278 3. Namespaces 280 One of the key elements in any architecture, or architectural 281 analysis, are the namespaces involved: what are their semantics and 282 syntax, what are the kinds of things they name, etc. 284 LISP has two key namespace, EIDs and RLOCs, but it must be emphasized 285 that on an architectural level, neither the syntax, or, to a lesser 286 degree, the semantics, of either are absolutely fixed. There are 287 certain core semantics which are unchanging (such as the notion that 288 EIDs provide only identity, whereas RLOCs provide location), but as 289 we will see, there is a certain amount of flexibility available for 290 the long-term. 292 In particular, all of LISP's key interfaces always include an Address 293 Family Identifier (AFI) [AFI], so that new forms can be introduced at 294 any time the need is felt. Of course, in practise such an 295 introduction would not be a trivial exercise - but neither is is 296 impossibly painful, as is the case with IPv4's 32-bit addresses, 297 which are effectively impossible to upgrade. 299 3.1. LISP EIDs 301 A 'classic' EID is defined as a subset of the possible namespaces for 302 endpoints. [Chiappa] Like most 'proper' endpoint names, as proposed 303 there, they contain contain no information about the location of the 304 endpoint. EIDs are the subset of possible endpoint names which are: 305 fixed length, 'reasonably' short', binary (i.e. not intended for 306 direct human use), globally unique (in theory), and allocated in a 307 top-down fashion (to achieve the former) . 309 LISP EIDs are, in line with the general LISP deployment philosophy, a 310 reuse of something already existing - i.e. IPvN addresses. For 311 those used as in LISP as EIDs, LISP removes much (or, in some cases, 312 all) of the location-naming function of IPvN addresses. 314 In addition, the goal is to have EIDs name hosts (or, more properly, 315 their end-end communication stacks), whereas the other LISP namespace 316 group (RLOCs) names interfaces. The idea is not just to have two 317 namespaces (with different semantics), but also to use them to name 318 _different classes of things_ - classes which currently do not have 319 clearly differentiated names. This should produce even more 320 functionality. 322 3.1.1. Residual Location Functionality in EIDs 324 LISP retains, especially in the early stages of the deployment, in 325 many cases some residual location-naming functionality in EIDs, This 326 is to allow the packet to be correctly routed/forwarded to the 327 destination node, once it has been unwrapped by the ETR - and this is 328 a direct result of LISP's deployment philosophy (see [Introduction], 329 Section "Deployment"). 331 Clearly, if there are one or more unmodified routers between the ETR 332 and the desination node, those routers will have to perform a routing 333 step on the packet, for which it will need _some_ information as to 334 the location of the destination. 336 One can thus view such LISP EIDs, which retain 'stub' location 337 information, as 'addresses' (in the definition of the generic sense 338 of this term, as used here), but with the location information 339 restricted to a limited, local scope. 341 This retention of some location functionality in LISP EIDs, in some 342 cases, has led some people to argue that use of the name 'EID' is 343 improper. In response, it was suggested that LISP use the term 344 'LEID', to distinguish LISP's 'bastardized' EIDs from 'true' EIDs, 345 but this usage has never caught on. 347 It has also been suggested that one usage mode for LISP EIDs, in 348 existing software loads, is to assign them as the address on an 349 internal virtual interface; all the real interfaces would have RLOCs 350 only. [Templin] This would make such LISP EIDs functionally 351 equivalent to 'real' EIDs - they are names which are purely identity, 352 have no location information of any kind in them, and cannot be used 353 to make any routing decisions anywhere outside the host. 355 It is true that even in such cases, the EID is still not a 'pure' 356 EID, as it names an interface, not the end-end stack directly. 357 However, to do a perfect job here (or on separation of location and 358 identity) is impossible without modifying existing hosts (which are, 359 inevitably, almost always one end of an end-end communication) - and 360 that has been ruled out, for reasons of viable deployment. 362 The need for interoperation with existing unmodified hosts limits the 363 semantic changes one can impose, much as one might like to provide a 364 cleaner separation. (Future evolution can bring us toward that 365 state, however: see Section XXX.) 367 3.2. RLOCs 369 RLOCs are basically pure 'locators' [RFC1992], although their syntax 370 and semantics is restricted at the moment, because in practise the 371 only forms of RLOCs supported are IPv4 and IPv6. 373 3.3. Overlapping Uses of Existing Namespaces 375 3.4. LCAFs 377 --- Key-ID 378 --- Instance-IDs 380 4. Fault Discovery/Handling 382 Any global communication system must be robust, and to be robust, it 383 must be able to discover and handle problems. LISP's general 384 philosophy of robustness is usually to have overlapping, simple 385 mechanisms to discover and repair problems. 387 5. Scalability 389 As with robustness, any global communication system must be scalable, 390 and scalable up to almost any size. As previously mentioned, the 391 large fanouts to be seen with LISP, due to its 'overlay' nature, 392 present a special challenge. 394 One likely saving grace is that as the Internet grows, most sites 395 will likely only interact with a limited subset of the Internet; if 396 nothing else, the separation of the world into language blocks means 397 that content in, e.g. Chinese, will not be of interest to most of 398 the rest of the world. This tendency will help with a lot of things 399 which could be problematic if constant, full, N^2 connectivity were 400 likely on all nodes, for example the caching of mappings. 402 5.1. Demand Loading of Mappings 404 One question that many will have about LISP's design is 'why demand- 405 load mappings - why not just load them all'? It is certainly true 406 that with the growth of memory sizes, the size of the complete 407 database is such that one could reasonably propose keeping the entire 408 thing in each LISP device. (In fact, one proposed mapping system for 409 LISP, named NERD, did just that. [NERD]) 411 A 'pull'-based system was chosen over 'push' for several reasons; the 412 main one being that the issue is not just the pure _size_ of the 413 mapping database, but its _dynamicity_. Depending on how often 414 mappings change, the update rate of a complete database could be 415 relatively large. 417 It is especially important to realize that, depending on what 418 (probably unforseeable) uses eventually evolve for the 419 identity->location mapping capability, the update rate could be very 420 high indeed. E.g. if LISP is used for mobility, that will greatly 421 increase the update rate. Such a powerful and flexible tool is 422 likely be used in unforseen ways (Section 2.3), so it's unwise to 423 make a choice that would preclude any which raise the update rate 424 significantly. 426 Push as a mechanism is also fundamentally less desirable than pull, 427 since the control plane overhead consumed to load and maintain 428 information about unused destinations is entirely wasted. The only 429 potential downside is the delay required for the demand-loading of 430 information. 432 (It's also probably worth noting that many issues that some people 433 have with the mapping approach of LISP, such as the mapping database 434 size, etc are the same - if not worse - for push as they are for 435 pull.) 437 Also, for IPv4, as the address space becomes more highly used, it 438 will become more fragmented - i.e. there will tend to be more, 439 smaller, entries. For a routing table, which every router has to 440 hold, this is problematic. For a demand-loaded mapping table, it is 441 not bad. Indeed, this was the original motivation for LISP - 442 although many other useful and desirable uses for it have since been 443 enumerated (see [Introduction], Section "Applications"). 445 For all of these reasons, as long as there is locality of reference 446 (i.e. most ITRs will use only a subset of the entire set), it makes 447 much more sense to use the a pull model, than the classic push one 448 heretofore seen widely at the internetwork layer (and thus somewhat 449 novel to people who work at that layer). 451 It may well be that some sites (e.g. large content providers) may 452 need non-standard mechanisms - perhaps something more of a 'push' 453 model. This remains to be determined, but it is certainly feasible. 455 5.2. Caching of Mappings 457 It should be noted that the caching spoken of here is likely not 458 classic caching, where there is a fixed/limited size cache, and 459 entries have to be discarded to make room for newly needed entries. 460 The economics of memory being what they are, there is no reason to 461 discard mappings once they have been loaded (although of course 462 implementations are free to chose to do so, if they wish to). 464 This leads to another point about the caching of mappings: the 465 algorithms for management of the cache are purely a local issue. The 466 algorithm in any particular ITR can be changed at will, with no need 467 for any coordination. A change might be for purposes of 468 experimentation, or for upgrade, or even because of environmental 469 variations - different environments might call for different cache 470 management strategies. 472 The replacability of the cache management is the architectural aspect 473 of the design; the exact algorithm, which is engineering, is not. 475 5.3. Amount of State 477 -- Mapping cache size 478 --- Mention studies 479 -- Delegation cache size (in MRs) 480 --- Mention studies 481 -- Any others? 483 5.4. Scalability of The Indexing Subsystem 485 LISP initially used an indexing subsystem called ALT. [ALT] ALT was 486 relatively easy to construct from existing tools (GRE, BGP, etc), but 487 it had a number of issues that made it unsuitable for large-scale 488 use. ALT is now being superseded by DDT. [DDT] 490 The basic structure and operation of DDT is identical to that of 491 TREE, so the extensive simulation work done for TREE applies equally 492 to DDT, as do the conclusions drawn about TREE's superiority to ALT. 493 [Jakab] 495 From an architectural point of view, the main advantage of DDT is 496 that it enables client side caching of information about intermediate 497 nodes in the resolution hierarchy, and also enables direct 498 communication with them. As a result, DDT has much better scaling 499 properties than ALT. 501 The most important result of this change is that it avoids a 502 concentration of resolution request traffic at the root of the 503 indexing tree, a problem which by itself made ALT unsuitable for a 504 global-scale system. The problem of root concentration (and thus 505 overload) is almost unavoidable in ALT (even if masses of 'bypass' 506 links are created). 508 ALT's scalability also depends on enforcing an intelligent 509 organization that aincreases aggregation. Unfortunately, the current 510 backbone routing BGP system shows that there is a risk of an organic 511 growth of ALT, one which does not achieve aggregation. DDT does not 512 display this weakness, since its organization is inherently 513 hierarchical (and thus inherently aggregable). 515 The hierarchical organization of DDT also reduces the possibility for 516 a configuration error which interferes with the operation of the 517 network (unlike the situation with the current BGP DFZ). DDT 518 security mechanisms can also help produce a high degree of 519 robustness, both against misconfiguration, and deliberate attack. 520 The direct communication with intermediate nodes in DDT also helps to 521 quickly locate problems when they occur, resulting in better 522 operational characteristics. 524 Next, since in ALT mapping requests must be transmitted through an 525 overlay network, a significant share of requests can see 526 substantially increased latencies. Simulation results in the TREE 527 work clearly showed, and quantified, this effect. 529 The simulations also showed that the nodes composing the ALT and DDT 530 networks for a mapping database of full Internet size could have 531 thousands of neighbours. This is not an issue for DDT, but would 532 almost certainly have been problematic for ALT nodes, since handling 533 that number of simultaneous BGP sessions would likely to be 534 difficult. 536 6. Security 538 Security in LISP faces many of the same challenges as security for 539 other parts of the Internet: good security usually means work for the 540 users, but without good security, things are vulnerable. 542 The Internet has seen many very secure systems devised, only to see 543 them fail to reach wide adoption; the reasons for that are complex, 544 and vary, but being too much work to use is a common thread. It is 545 for this reason that LISP attempts to provide 'just enough' security 546 (see [Introduction], Section "Design-Security"). 548 The _good_ thing about the Internet is that it brings the world to 549 your doorstep - masses of information from all around the world are 550 instantly available on your computing device. The _bad_ thing about 551 the Internet is that it brings the world to your doorstep - including 552 legions of crackers, thieves, and general scum and villainy. Thus, 553 any node may be the target of fairly sophisticated attack - often 554 automated (thereby reducing the effort required of the attacker to 555 spread their attack as broadly as possible). 557 6.1. Basic Philosophy 559 To square this circle, of needing to have very good security, but of 560 it being to difficult to use very good security, the general concept 561 is for LISP to have a series of 'graded' security measures available, 562 with the 'ultimate' security mechanisms being very high-grade indeed. 564 The concept is to devise a plan in which LISP can simultaneously 565 attempt to have not just 'ultimate' security, but also one or more 566 'easier' modes, ones which will be easier to configure and use. This 567 'easier' mode can be both an interim system (with the full powered 568 system available for when it it needed), as well as the system used 569 in sections where security is less critical (following the general 570 rule that the level of any security should generally be matched to 571 what is being protected). 573 The challenge is to do this in a way that does not make the design 574 more complex, since it has to include both the 'full strength' 575 mechanism(s), and the 'easier to configure' mechanism(s). This is 576 one of the fundamental tradeoffs to struggle with: it is easy to 577 provide 'easier to configure' options, but that may make the overall 578 design more complex. 580 As far as making it hard to implement to begin with (also something 581 of a concern initially, although obviously not for the long term): we 582 can make it 'easy' to deploy initially by simply not implementing/ 583 configuring the heavy-duty security early on. (Provided, of course, 584 that the packet formats, etc, are all included in the design to begin 585 with.) 587 6.2. Design Guidance 589 In designed the security, there are a small number of key points that 590 will guide the design: 592 - Design lifetime 593 - Threat level 595 How long is the design intended to last? If LISP is successful, a 596 minimum of a 50-year lifetime is quite possible. (For comparison, 597 IPv4 is now 34 at the time of writing this, and will be around for at 598 least several decades yet, if not longer; DNS is 28, and will 599 probably last indefinitely.) 601 How serious are the threats it needs to meet? As mentioned above, 602 the Internet can bring the baddest actors anywhere to any location, 603 in a flash. Their sophistication level is rising all the time: as 604 the easier holes are plugged, they go after others. This will 605 inevitably eventually require the most powerful security mechanisms 606 available to counteract their attacks. 608 Which is not to say that LISP needs to be that secure _right away_. 609 The threat will develop and grow over a long time period. However, 610 the basic design has to be capable of being _securable_ to the 611 expanded degree that will eventually be necessary. However, 612 _eventually_ it will need to be as securable as, say, DNS - i.e. it 613 _can_ be secured to the same level, although people may chose not to 614 secure their LISP infrastructure as well as DNSSEC does. 616 In particular, it should be noted that historically many systems have 617 been broken into, not through a weakness in the algorithms, etc, but 618 because of poor operational mechanics. (The well-known 'Ultra' 619 breakins of the Allies were mostly due to failures in operational 620 procedure.) So operational capabilities intended to reduce the 621 chance of human operational failure are just as important as strong 622 algorithms; making things operationally robust is a key part of 623 'real' security. 625 6.2.1. Security Mechanism Complexity 627 Complexity is bad for several reasons, and should always be reduced 628 to a minimum. There are three kinds of complexity cost: protocol 629 complexity, implementation complexity, and configuration complexity. 630 We can further subdivide protocol complexity into packet format 631 complexity, and algorithm complexity. (There is some overlap of 632 algorithm complexity, and implementation complexity.) 634 We can, within some limits, trade off one kind of complexity for 635 others: e.g. we can provide configuration _options_ which are simpler 636 for the users to operate, at the cost of making the protocol and 637 implementation complexity greater. And we can make initial (less 638 capable) implementations simpler if we make the protocols slightly 639 more complex (so that early implementations don't have to implement 640 all the features of the full-blown protocol). 642 It's more of a question of some operational convenience/etc issues - 643 e.g. 'How easy will it be to recover from a cryptosystem 644 compromise'. If we have two ways to recover from a security 645 compromise, one which is mostly manual and a lot of work, and another 646 which is more automated but makes the protocol more complicated, if 647 compromises really are very rare, maybe the smart call _is_ to go 648 with the manual thing - as long as we have looked carefully at both 649 options, and understood in some detail the costs and benefits of 650 each. 652 6.3. Security Overview 654 First, there are two different classes of attack to be considered: 655 denial of service (DoS, i.e. the ability of an intruder to simply 656 cause traffic not to successfully flow) versus exploitation (i.e. the 657 ability to cause traffic to be 'highjacked', i.e. traffic to be sent 658 to the wrong location). 660 Second, one needs to look at all the places that may be attacked. 661 Again, LISP is a relatively simple system, so there are not that many 662 subsystems to examine. 664 -- Lookups 665 --- Nonces 666 -- Indexing 667 -- Mappings 669 6.4. Securing Mappings 671 Two approaches have been taking to securing the provision of 672 mappings. The first, which is of course not completely satisfactory, 673 is to secure the channel between the ITR and the entities involved in 674 providing mappings for it. The second is to secure the mappings 675 themselves, by signing them 'at birth' (much the same way in which 676 DNS Security operates). [RFC4033]. 678 Tie-in to space allocation security? 680 6.5. Securing the xTRs 682 --- Cache management 683 --- Unsoliticed Map-Replies are _very bad_ - must go through 684 mapping system to verify that the sender is authoritative for 685 that range of EIDs 687 7. Robustness 689 -- Depends on deployment as well as design 690 -- Replication 691 -- Overlapping mechanisms (ref redundancy as key for robustness) 693 8. Optimization 695 -- Philosophy 696 -- Piggybacking 697 -- 'Wiretapping' return mappings 698 --- Security is an issue on that 700 9. Open Issues 702 -- Provider lock-in for mapping database 703 -- Automated ETR synch 704 --- Liveness can be gathered now from some IGPs 705 -- EID reachability within a LISP Site 706 --- Existing problem with any border router 708 10. Additional Material 710 - An architectural document on LISP, starting with 711 a brief motivation and problem definition, then 712 a protocol overview, then more detailed discussion 713 of funtional elements, tradeoffs, etc. 715 - A more high level document covering what Loc/ID 716 separation is, why it's important, its history, 717 and then why LISP is a good solution. 719 - A 'potential future evolution' document, covering 720 what the impacts of LISP could/would be, and how it 721 might evolve in the future. 723 - Future work 724 -- Better ETR sync for mappings 725 -- Detect and deal with gonzo ETRs 727 - Long-term Advantages 728 -- Impossible to list all the long-term uses 729 --- Lampson's (sic - actually Wheeler's) Law 730 -- EID Address space utilization 731 -- Allows use of class E space (240/4) for RLOCs 732 -- Core routing overhead reduction 733 --- PI space 734 -- Easier introduction of new names-spaces 736 - Routing Evolution {not sure we want this? - JNC} 737 -- Some short term (TE, etc) 738 -- Biggest long-term improvement comes inside LISP core, 739 if we can get the network to that point 740 --- Withdrawal of EID routes in the LISP core 741 -- Support of non-LISP core is tricky (requires 742 route reconstitution) 744 - Long-term Evolution {Not sure we want this? Maybe it 745 should be a whole separate document. - JNC} 746 -- Evolution 747 --- Have a long term plan, but keep what's actually 748 done simple to begin with 749 --- Leave 'hooks' for long-term evolution 750 --- The Internet painted itself into a corner, 751 evolution-wise - LISP has opened a mouse-hole, but 752 we need to make sure it doesn't just lead to another 753 painted-in corner 754 -- Better indexing system (may be obsolete, now that 755 we have DDT?) 756 -- 'Ringfence' of xTRs provides natural boundary between 757 change domains 758 -- New namespaces (the semantic issues involved with 759 introducing new namespaces - initially RLOCs, but 760 potentially EIDs as well - the latter are 761 much harder as it changes host-host semantics) 762 -- Separation of host/host and router/router 763 interfaces / packet formats 764 -- More? 766 11. Acknowledgments 768 The author would like thank the core LISP group for their willingness 769 to allow him to add himself to their effort, and for their enthusiasm 770 for whatever assistance he has been able to provide. He would also 771 like to thank (in alphabetical order) Vina Ermagan, Vince Fuller, and 772 Joel Halpern for their careful review of, and helpful suggestions 773 for, this document. Grateful thanks also to Darrel Lewis for his 774 help with material on non-Internet uses of LISP, and to Vince Fuller 775 for help with XML. A final thanks is due to John Wrocklawski for the 776 author's organizational affiliation. 778 12. IANA Considerations 780 This document makes no request of the IANA. 782 13. Security Considerations 784 14. References 786 14.1. Normative References 788 [DDT] V. Fuller, D. Lewis, and D. Farinacci, "LISP 789 Delegated Database Tree", 790 draft-fuller-lisp-ddt-01.txt (work in progress), 791 March 2012. 793 [Introduction] J.N. Chiappa, "An Introduction to the LISP Location- 794 Identity Separation System", 795 draft-chiappa-lisp-introduction-00.txt (work in 796 progress), July 2012. 798 [AFI] IANA, "Address Family Indicators (AFIs)", Address 799 Family Numbers, January 2011, . 802 14.2. Informative References 804 [RFC1992] I. Castineyra, J. N. Chiappa, and M. Steenstrup, "The 805 Nimrod Routing Architecture", RFC 1992, August 1996. 807 [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, and 808 S. Rose, "DNS Security: Introduction and 809 Requirements", RFC 4033, March 2005. 811 [RFC4423] R. Moskowitz and P. Nikander, "Host Identity Protocol 812 (HIP) Architecture", RFC 4423, May 2006. 814 [ALT] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, 815 "LISP Alternative Topology (LISP-ALT)", 816 draft-ietf-lisp-alt-10.txt (work in progress), 817 December 2011. 819 [NERD] E. Lear, "NERD: A Not-so-novel EID to RLOC Database", 820 draft-lear-lisp-nerd-09.txt (work in progress), 821 April 2012. 823 [ILNP] R.J. Atkinson and S.N. Bhatti, "ILNP Architectural 824 Description", draft-irtf-rrg-ilnp-arch-05.txt (work 825 in progress), May 2012. 827 [Chiappa] J. N. Chiappa, "Endpoints and Endpoint Names: A 828 Proposed Enhancement to the Internet Architecture", 829 Personal draft (work in progress), 1999, 830 . 832 [Jakab] L. Jakab, A. Cabellos-Aparicio, F. Coras, D. Saucez, 833 and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to 834 Support the LISP Mapping System", in 'IEEE Journal on 835 Selected Areas in Communications', Vol. 28, No. 8, 836 pp. 1332-1343, October 2010. 838 [McQuillan] J. M. McQuillan, W. R. Crowther, B. P. Cosell, 839 D. C. Walden, and F. E. Heart, "Improvements in the 840 Design and Performance of the ARPA Network", 841 Proceedings AFIPS 1972 FJCC, Vol. 40, pp. 741-754. 843 [Templin] F. Templin, "LISP WG", LISP WG list 844 message, Message-ID: 39C363776A4E8C4A94691D2BD9D1C9A1 845 05B0AC71@XCH-NW-7V2.nw.nos.boeing.com, 13 846 March 2009,, . 849 [Wasserman] M. Wasserman, "IPv6 networking: Bad news for small 850 biz", IETF list message, Message-Id: 851 D11C4A34-7362-423E-A60E-476FC5D61D37@lilacglade.org, 852 5 April 2012, . 856 Appendix A. RefComment 858 Appendix B. Glossary/Definition of Terms 860 - Address 861 - Locator 862 - EID 863 - RLOC 864 - ITR 865 - ETR 866 - xTR 867 - PITR 868 - PETR 869 - MR 870 - MS 871 - DFZ 873 Appendix C. Other Appendices 875 -- Location/Identity Separation Brief History 876 -- LISP History 877 -- Old models (LISP 1, LISP 1.5, etc) 878 -- Different mapping distribution models (e.g. LISP-NERD) 879 -- Different mapping indexing models (LISP-ALT 880 forwarding/overlay model), 881 LISP-TREE DNS-based, LISP-CONS) 883 Author's Address 885 J. Noel Chiappa 886 Yorktown Museum of Asian Art 887 Yorktown, Virginia 888 USA 890 EMail: jnc@mit.edu