idnits 2.17.1 draft-fuller-lisp-alt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 655. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 661. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 13, 2007) is 6007 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft V. Fuller 4 Intended status: Experimental D. Meyer 5 Expires: May 16, 2008 Cisco 6 November 13, 2007 8 LISP Alternative Topology (LISP-ALT) 9 draft-fuller-lisp-alt-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 16, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a method of building an alternative, logical 43 topology for managing Endpoint Identifier to Routing Locator mappings 44 using the Locator/ID Separation Protocol. The logical network is 45 built as an overlay on the public Internet using existing 46 technologies and tools, specifically the Border Gateway Protocol and 47 the Generic Routing Encapsulation. An important design goal for 48 LISP-ALT is to allow for the relatively easy deployment of an 49 efficient mapping system while minimizing changes to existing 50 hardware and software. 52 Table of Contents 54 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 57 4. The LISP 1.5 model . . . . . . . . . . . . . . . . . . . . . . 7 58 5. LISP-ALT: Basic Overview . . . . . . . . . . . . . . . . . . . 8 59 5.1. EID Assignment - Hierarchy and Topology . . . . . . . . . 8 60 5.2. LISP-ALT Router . . . . . . . . . . . . . . . . . . . . . 9 61 5.3. Use of GRE tunnels between LISP-ALT Routers . . . . . . . 9 62 6. How LISP-ALT uses BGP . . . . . . . . . . . . . . . . . . . . 10 63 6.1. Sub-Address Family Identifier (SAFI) for LISP-ALT . . . . 10 64 6.2. Autonomous System Numbers (ASNs) in LISP-ALT . . . . . . . 11 65 7. EID-Prefix Aggregation . . . . . . . . . . . . . . . . . . . . 12 66 8. Connecting sites to the LAT . . . . . . . . . . . . . . . . . 13 67 8.1. ETRs originating information into the LAT network . . . . 13 68 8.2. ITRs Receiving Information from the LAT . . . . . . . . . 13 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 10.1. Apparent LISP-ALT Vunerabilities . . . . . . . . . . . . . 16 72 10.2. Survey of LISP-ALT Security Mechanisms . . . . . . . . . . 17 73 10.3. Leveraging Internet BGP Security mechanisms . . . . . . . 17 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 77 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 79 Intellectual Property and Copyright Statements . . . . . . . . . . 21 81 1. Requirements Notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Introduction 89 This document describes a method of building an alternative logical 90 topology for managing Endpoint Identifier to Routing Locator mappings 91 using the Locator/ID Separation Protocol [LISP]. This logical 92 topology uses existing technology and tools, specifically the Border 93 Gateway Protocol [RFC4271] and its multi-protocol extension 94 [RFC2858], along with the Generic Routing Encapsulation [RFC2784] 95 protocol to construct an overlay network of devices that advertise 96 EID-prefixes only. These Endpoint Identifier Prefix Aggregators hold 97 hierarchically-assigned pieces of the Endpoint Identifier space 98 (i.e., prefixes) and their next hops toward the network element which 99 is authoritative for Endpoint Identifier-to-Routing Locator mapping 100 for that prefix. Tunnel routers can use this overlay to make queries 101 against and respond to mapping requests made against the distributed 102 Endpoint Identifier-to-Routing Locator mapping database. Note the 103 database is distributed (as in [LISP]c and is stored in the ETRs. 105 Note that an important design goal of LISP-ALT is to minimize the 106 number of changes to existing hardware and/or software that are 107 required to deploy the mapping system. It is envisioned that in most 108 cases existing technology can be used to implement and deploy LISP- 109 ALT. Since the deployment of LISP-ALT adds new devices to the 110 network, existing devices not need changes or upgrades. They can 111 function as they are to realize an underlying and robust physical 112 topology. 114 The remainder of this document is organized as follows: Section 3 115 provides the definitions of terms used in this document. Section 4 116 outlines the basic LISP 1.5 model. Section 5 provides a basic 117 overview of the LISP Alternate Topology (or LAT) architecture, and 118 Section 6 describes how LAT uses BGP to propagate Endpoint Identifier 119 reachability over the overlay network. Section 7 describes the 120 construction of the LAT aggregation hierarchy, and Section 8 121 discusses how the elements of the LAT topology are connected to form 122 the overlay network. 124 3. Definition of Terms 126 LISP-ALT operates on two name spaces and introduces a new network 127 element, the EID Prefix Aggregators (see below). This section 128 provides high-level definitions of the LISP-ALT name spaces, network 129 elements, and message types. 131 The LISP Alternative Topology (LAT): The virtual overlay network 132 made up of Generic Routing Encapsulation (GRE) tunnels between EID 133 Prefix Aggregators. The Border Gateway Protocol (BGP) runs 134 between LISP-ALT routers and is used to carry reachability 135 information for EID prefixes. 137 Legacy Internet: The portion of the Internet which does not run LISP 138 and does not participate in LISP-ALT. 140 LISP-ALT Router: The devices which run on the LAT. The LAT is a 141 static topology built with GRE tunnels. LISP-ALT routers are 142 deployed in a hierarchy which matches the EID prefix allocation 143 hierarchy. LISP-ALT routers at each level in the this hierarchy 144 are responsible for aggregating all EID prefixes learned from 145 LISP-ALT routers logically "below" them and advertising summary 146 prefixes to the LISP-ALT routers logically "above" them. All 147 prefix learning and propagation between levels is done using BGP. 148 LISP-ALT routers at the lowest level, or "edge", of the LAT learn 149 EID prefixes either over a BGP or LISP TCP session to ETRs. See 150 Section 6 for details on how BGP is configured between the 151 different network elements. 153 The primary function of the LISP-ALT routers is to provide a 154 lightweight forwarding infrastructure for LISP control-plane 155 messages (Map-Request and Map-Reply), and to transport data 156 packets when the packet has the same destination address in both 157 the inner (encapsulating) destination and outer destination 158 addresses ((i.e., a Data Probe packet). 160 Endpoint ID (EID): A 32- or 128-bit value used in the source and 161 destination fields of the first (most inner) LISP header of a 162 packet. A packet that is emitted by a system contains EIDs in its 163 headers and LISP headers are prepended only when the packet 164 reaches an Ingress Tunnel Router (ITR) on the data path to the 165 destination EID. 167 In LISP-ALT, EID-prefixes MUST BE assigned in a hierarchical 168 manner (in power-of-two) such that they can be aggregated by LISP- 169 ALT routers. In addition, a site may have site-local structure in 170 how EIDs are topologically organized (subnetting) for routing 171 within the site; this structure is not visible to the global 172 routing system. 174 EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable 175 in the [RFC4632] sense. That is, an EID-Prefix aggregate is 176 defined to be a single contiguous power-of-two EID-prefix block. 177 Such a block is characterized by a prefix and a length. 179 Routing Locator (RLOC): An IP address of an egress tunnel router 180 (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID 181 maps to one or more RLOCs. Typically, RLOCs are numbered from 182 topologically-aggregatable blocks that are assigned to a site at 183 each point to which it attaches to the global Internet; where the 184 topology is defined by the connectivity of provider networks, 185 RLOCs can be thought of as Provider Aggregatable (PA) addresses. 186 Note that in LISP-ALT, RLOCs are not carried by the LISP-ALT 187 routers. 189 EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that 190 can be used to reach the EID. We use the term "mapping" in this 191 document to refer to a EID-to-RLOC mapping. 193 EID Prefix Reachability: An EID prefix is said to be "reachable" if 194 one or more of its locators are reachable. That is, an EID prefix 195 is reachable if the ETR (or its proxy) that is authoritative for a 196 given EID-to-RLOC mapping is reachable. 198 Default Mapping: A Default Mapping is a mapping entry for EID- 199 prefix 0.0.0.0/0. It maps to a locator-set used for all EIDs in 200 the Internet. If there is a more specific EID-prefix in the 201 mapping cache it overrides the Default Mapping entry. The Default 202 Mapping route can be learned by configuration or from a Map-Reply 203 message. 205 Default Route: A Default Route in the context of LISP-ALT is a EID- 206 prefix value of 0.0.0.0/0 which is advertised by BGP on top of the 207 LAT. The Default Route is used to realize a path for Data Probe 208 and Map-Request packets. 210 4. The LISP 1.5 model 212 As documented in [LISP], the LISP 1.5 model uses the same basic 213 query/response protocol machinery as LISP 1.0. In particular, LISP- 214 ALT provides two mechanisms for an ITR to obtain EID-to-RLOC mappings 215 (both of these techniques are described in more detail in 216 Section 8.2): 218 Data Probe: An ITR may send the first few data packets into the LAT 219 to minimize packet loss and to probe for the mapping; the 220 authoritative ETR will respond to the ITR with a Map-Reply message 221 when it receives the data packet over the LAT. Note that in this 222 case, the inner Destination Address (DA), which is an EID, is 223 copied to the outer DA and is routed over the LAT. 225 Map-Request: An ITR may also send a Map-Request message into the LAT 226 to request the mapping. As in the Data Probe case, the 227 authoritative ETR will respond to the ITR with a Map-Reply 228 message. In this case, the DA of the Map-Request MUST be an 229 EID.See [LISP] for the format of Map-Request and Map-Reply 230 packets. 232 Like LISP 1.0, EIDs are routable and can be used, unaltered, as the 233 source and destination addresses in IP datagrams. Unlike in LISP 234 1.0, LISP 1.5 EIDs are not routed on the public Internet; instead, 235 they are only routable over a separate, virtual topology referred to 236 as the LISP Alternative Virtual Network. This network is built as an 237 overlay on the public Internet using GRE tunnels to interconnect 238 LISP-ALT routers. BGP is run over these tunnels to propagate the 239 information needed to route Data Probes and Map-Request/Replies. 240 Importantly, while the ETRs are the source(s) of the unaggregated EID 241 prefix data, LISP-ALT uses existing BGP mechanisms to aggressively 242 aggregate this information. Note that ETRs are not required to 243 participate (or prevented from participating) in the LISP-ALT; they 244 may choose communicate their mappings to their serving LISP-ALT 245 router(s) at subscription time via configuration. ITRs are also not 246 required to (nor prevented from) participate in LISP-ALT. 248 5. LISP-ALT: Basic Overview 250 LISP-ALT is a hybrid push/pull architecture. Aggregated EID prefixes 251 are "pushed" among the LISP-ALT routers and, optionally, out to ITRs 252 (which may elect to receive the aggregated information, as opposed to 253 simply using a default mapping). Specific EID-to-RLOC mappings are 254 "pulled" by ITRs when they either send explicit LISP requests or data 255 packets on the alternate topology that result in triggered replies 256 being generated by ETRs. 258 The basic idea embodied in LISP-ALT is to use BGP, running over a GRE 259 overlay, to build the LAT reachability required to route Data Probes, 260 Map-Requests, and Map-Replies over the alternate topology. The LAT 261 RIB (BGP RIB) is comprised of EID prefixes (and associated next 262 hops). The LISP-ALT routers talk eBGP to each other in order to 263 propagate EID prefix update information, which is learned either over 264 eBGP connections from the authoritative ETR, or by configuration. 265 ITRs may also eBGP peer with one or more LISP-ALT routers in order to 266 route Data Probe packets or Map-Requests (more likely, an ITR will 267 have a default mapping pointing at one or more LISP-ALT routers). 269 In summary, the LISP-ALT uses BGP to propagate EID-prefix update 270 information used by ITRs and ETRs to forward Map-Requests, Map- 271 Replies, and Data Probes. This reachability is carried as IPv4 or 272 IPv6 NLRI without modification (since the EID space has the same 273 syntax as IPv4 or IPv6). LISP-ALT routers eBGP peer with one 274 another, forming the LAT. An LISP-ALT router near the edge learns 275 EID prefixes which are originated by authoritative ETRs, which either 276 eBGP peer with them or by configuration. LISP-ALT routers aggregate 277 EID prefixes, and forward Data Probes, Map-Requests, and Map-Replies. 279 5.1. EID Assignment - Hierarchy and Topology 281 EID-prefixes will be allocated to a LISP site by Internet Registries. 282 Multiple allocations may not be in power-of-2 blocks. But when they 283 are, they will be aggregated into one announcement EID-prefix. The 284 LAT topology will be setup in a tree-like structure hierarchy so 285 merge points in the tree can have proxy aggregation occur. By doing 286 this the LISP-ALT nodes higher in the hierarchy can carry less EID- 287 prefixes. 289 Since the LAT will not need to change due to subscription or policy 290 reasons, the topology can remain relatively static and aggregation 291 can be sustained. 293 Note: As the prototype develops, we will produce documented usage 294 guides on how best to build the LAT topology. 296 5.2. LISP-ALT Router 298 A LISP-ALT Router has the following functionality: 300 1. It can run at a minimum the eBGP part of the BGP protocol. 302 2. It can support a separate RIB which uses next-hop GRE tunnel 303 interfaces for forwarding Data Probes and Map-Requests. 305 3. It can also act as an ITR, as in a proxy-ITR capacity to support 306 non-LISP sites. 308 4. It can also act as an ETR, or an recursive or re-encapsulating 309 ITR to reduce mapping tables in site-based LISP routers. 311 An ITR or an ETR can talk to a LISP-ALT router without using a GRE 312 tunnel and a BGP peering connection. A LISP TCP connection can be 313 established between the LISP-ALT router and either the ITR or ETR for 314 reliably passing Data Probe or Map-Request packets. TBD, but its 315 just a BGP speaker in the LAT overlay. 317 5.3. Use of GRE tunnels between LISP-ALT Routers 319 By using GRE between LISP-ALT routers and running an eBGP connection 320 among them over the GRE tunnel interface makes each LISP-ALT hop an 321 AS-hop. By doing this each LISP-ALT router is using eBGP as a 322 Distance Vector protocol using an AS-path solely as a shortest-path 323 determination and loop-avoidance mechanism. All next-hops are on 324 tunnel interfaces so there is no IGP required resolve next-hops into 325 real next-hops because they are already resolved by the GRE tunnel 326 configuration. 328 This reduces Operational Expense (OPEX) because less protocols need 329 to be used on the overlay topology. Also, no coordination of tunnel 330 IP addresses are required since they are used locally by each LISP- 331 ALT device. So any addressing scheme (even using private addressing) 332 can be used for tunnel addressing. 334 In the case in which a single routing domain wants redundancy, there 335 is no requirement for the two or more LISP-ALT routers inside of the 336 domain need to peer with each other. The redundancy only need to be 337 present on peering connections across routing domains. This will 338 allow a lighter weight deployment and maintenance system for running 339 BGP. 341 6. How LISP-ALT uses BGP 343 As described in Section 8.2, an ITR may send either a Map-Request or 344 a data probe to find a given EID-to-RLOC mapping. The LAT provides 345 the infrastructure that allows these requests to reach the 346 authoritative ETR, and possibly for the reply to find its way back to 347 the requesting ITR (the ETR might choose to send the Map-Reply to the 348 requesting ITR's source-RLOC, bypassing the LAT). 350 The LISP-ALT routers propagate mapping information for use by ITRs 351 (when making Map-Requests or sending Data Probes), and ETRs (if the 352 ETR is configured to send Map-Replies back to the requesting ITR over 353 the LAT) using eBGP [RFC4271]. eBGP is run on the inter-LISP-ALT 354 router links, and and possibly between an edge LISP-ALT router and an 355 ETR or between an edge LISP-ALT router and an ITR. The LAT eBGP RIB 356 consists of aggregated EID prefixes and their next hops towards the 357 authoritative ETR for that EID prefix. 359 ITRs and ETRs may choose not to run an eBGP instance with a LISP-ALT 360 router. Each case is considered below. 362 ITR: An ITR will, whether it runs BGP with a LISP-ALT router or not, 363 will send either a Data Probe or a Map-Request a LISP-ALT router. 365 ETR: If an ETR runs BGP with a LISP-ALT router, it simply announces 366 its EID-prefix to its connected LISP-ALT routers. If the ETR is 367 not running BGP (i.e., it communicates with the LAT over a LISP 368 TCP connection), then the LISP-ALT router the ETR has a connection 369 with must route Map-Requests and Data Probes to the ETR as well as 370 get configured to advertise the ETR's EID-prefixes. Note that in 371 either case, the ETR may send the Map-Reply message back to the 372 ITR's source-EID on the LAT or to the ITR's source-RLOC (i.e., on 373 the underlying topology). 375 Finally, note that LISP-ALT requires no modification to the BGP 376 protocol, and is designed to be deployable without additional 377 protocol machinery. 379 6.1. Sub-Address Family Identifier (SAFI) for LISP-ALT 381 As defined by this document, LISP-ALT may be implemented using BGP 382 without modification. Given the fundamental operational difference 383 propagating global Internet routing information (the current, 384 dominant use of BGP) and managing the global EID-to-RLOC database 385 (the use of BGP proposed by this document), it may be desirable to 386 assign a new SAFI [RFC2858] to prevent operational confusion and 387 difficulties, including the inadvertent leaking of information from 388 one domain to the other. At present, this document does not require 389 the assignment of a new SAFI but the authors anticipate that 390 experimentation may suggest the need for one in the future. 392 6.2. Autonomous System Numbers (ASNs) in LISP-ALT 394 The primary use of BGP today is to define the global Internet routing 395 topology in terms of its participants, known as Autonomous Systems. 396 LISP-ALT specifies the use of BGP to create a global EID-to-RLOC 397 mapping database which, while related to the global routing database, 398 serves a very different purpose and is organized into a very 399 different hierarchy. Because LISP-ALT does use BGP, however, it uses 400 ASNs in the paths that are propagated among LISP-ALT routers. To 401 avoid confusion, it needs to be stressed that that these LISP-ALT 402 ASNs use a new numbering space that is unrelated to the ASNs used by 403 the global routing system. Exactly how this new space will be 404 assigned and managed will be determined during experimental 405 deployment of LISP-ALT. 407 7. EID-Prefix Aggregation 409 The LAT peering topology should be arranged in a tree-like fashion 410 (with some meshiness), both with redundancy to deal with crashes. We 411 assume that as long as the routers are up and running that the 412 underlying topology will provide alternative routes to the BGP 413 connection stay up between the LISP-ALT routers. 415 8. Connecting sites to the LAT 417 8.1. ETRs originating information into the LAT network 419 ETRs have two ways of originating EID information into the LAT: 421 Configuration: A LISP-ALT router may be configured with the EID- 422 prefix of the authoritative ETR, which is connected to the LISP- 423 ALT router via a LISP TCP connection [LISP]. This TCP connection 424 may be used to route Map-Requests to the ETR (if necessary), and 425 for the ETR to respond with Map-Replies. Of course, the LISP-ALT 426 router could also serve as a proxy for its TCP-connected ETRs. 427 Finally, depending on configuration and which prefixes an ETR is 428 authoritative for, an ETR may need to connect to more than one 429 LISP-ALT router to have all of its prefixes routed via the LAT. 431 eBGP: ETRs may originate information by participating in the LAT via 432 eBGP. In this case, The ETR advertises reachability for its EID 433 prefixes over this eBGP connection to the LISP-ALT routers. The 434 LISP-ALT routers propagate and aggregate this information into the 435 LAT. That is, here the ETR is simply a peer of a LISP-ALT router 436 at the edge of the LAT. A LISP-ALT router should aggregate the 437 received EID-prefixes (where possible). 439 8.2. ITRs Receiving Information from the LAT 441 In order to source Map-Requests to the LAT and receive Map-Replies 442 from the LAT, or to route a Data Probe packet over the LAT, each ITR 443 participating in the LAT establishes a connection to one or more 444 LISP-ALT routers. These connections can be either eBGP or TCP (as 445 described above). 447 In the case in which the ITR is running eBGP, the peer LISP-ALT 448 routers use these connections to advertise highly aggregated EID- 449 prefixes to the peer ITRs. The ITR then installs the received 450 prefixes into a forwarding table that is used to to send LISP Map- 451 Requests to the appropriate LISP-ALT router. In most cases, a LISP- 452 ALT router will send a default mapping to its client ITRs so that 453 they can send request for any EID prefix into the LAT. 455 In the case in which the ITR is connected to some set of LISP-ALT 456 routers without eBGP (i.e., over a LISP TCP connection), the ITR 457 sends Map-Requests to any of its connected LISP-ALT routers, and 458 receives Map-Replies from the LISP-ALT router that has the "shortest 459 path" to the authoritative ETR. 461 An ITR may also chose to send the first few data packets over the 462 LAT, in order to minimize packet loss and reduce mapping latency. In 463 this case, the data packet serves as a mapping probe (Data Probe), 464 and the ETR which receives the data packet (over the LAT) responds 465 with a Map-Reply that is either routed back over the LAT, or send to 466 the ITR's source-RLOC over the underlying topology. 468 In general, an ITR will establish connections only to LISP-ALT 469 routers at the "edge" of the LAT (typically two for redundancy) but 470 there may also be situations where an ITR would connect to other 471 LISP-ALT routers to receive alternate shorter path information about 472 a portion of the LAT topology of interest to it. This can be 473 accomplished by establishing a GRE tunnel between the ITR and the set 474 of LISP-ALT routers the ITR is interested in. This is a purely local 475 policy issue between the ITR and the LISP-ALT routers in question. 477 9. IANA Considerations 479 This document makes no request of the IANA. 481 10. Security Considerations 483 LISP-ALT shares many of the security characteristics of BGP. Its 484 security mechanisms are comprised of existing technologies in wide 485 operational use today. Securing LISP-ALT is much simpler than 486 securing BGP. 488 Compared to BGP, LISP-ALT routers are not topologically bound, 489 allowing them to be put in locations away from the vulnerable AS 490 border (unlike eBGP speakers). 492 10.1. Apparent LISP-ALT Vunerabilities 494 This section briefly lists of the apparent vulnerabilities of LISP- 495 ALT. 497 Mapping Integrity: Can you insert bogus mappings to black-hole 498 (create a DoS) or intercept LISP data-plane packets? 500 LISP-ALT router Availability: Can you DoS the LISP-ALT routers that 501 a given ETR connects to? Without access to its mappings, a site 502 is essentially unavailable. 504 ITR Mapping/Resources: Can you force an ITR or LISP-ALT router to 505 drop legitimate mapping requests by flooding it with random 506 destinations that it will have to query for. Further study is 507 required to see the impact of admission control on the overlay 508 network. 510 EID Map-Request Exploits for Reconnaissance: Can you learn about a 511 LISP destination sites' TE policy by sending legitimate mapping 512 requests messages and then observing the RLOC mapping replies? Is 513 this information useful in attacking or subverting peer 514 relationships? Note that LISP 1.0 has a similar data-plane 515 reconnaissance issue. 517 Scaling of LISP-ALT router (LAT) Resources: The overall capacity of 518 the LAT may be a subset of the available bandwidth of the 519 Internet. 521 UDP Map-Reply from ETR: If Map-Replies packets are sent directly 522 from the ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable 523 to various types of DoS attacks. 525 10.2. Survey of LISP-ALT Security Mechanisms 527 Explicit peering: The devices themselves can both prioritize 528 incoming packets as well as potentially do key checks in hardware 529 to protect the control plane. 531 Use of TCP to connect elements: This makes it difficult for third 532 parties to inject packets. 534 Use of HMAC Protected TCP Connections: HMAC is used to verify 535 message integrity and authenticity, making it nearly impossible 536 for third party devices to either insert or modify messages. 538 Message Sequence Numbers and Nonce Values in Messages: This allows 539 for devices to verify that the mapping-reply packet was in 540 response to the mapping-request that they sent. 542 10.3. Leveraging Internet BGP Security mechanisms 544 LISP-ALT's use of BGP allows for the LAT easily take advantage of BGP 545 security features designed for the Legacy Internet BGP. 547 For example, should either sBGP [I-D.murphy-bgp-secr] or soBGP 548 [I-D.white-sobgparchitecture] become widely deployed it expected that 549 LISP-ALT could use these mechanisms to provide authentication of EID- 550 to-RLOC mappings, and EID origination. 552 11. Acknowledgments 554 Many of the ideas described in this document developed during 555 detailed discussions with Scott Brim and Darrel Lewis, who made many 556 insightful comments on earlier versions of this document. 558 12. References 560 12.1. Normative References 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 566 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 567 March 2000. 569 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 570 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 572 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 573 Protocol 4 (BGP-4)", RFC 4271, January 2006. 575 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 576 (CIDR): The Internet Address Assignment and Aggregation 577 Plan", BCP 122, RFC 4632, August 2006. 579 12.2. Informative References 581 [I-D.murphy-bgp-secr] 582 Murphy, S., "BGP Security Analysis", 583 draft-murphy-bgp-secr-04 (work in progress), 584 November 2001. 586 [I-D.white-sobgparchitecture] 587 White, R., "Architecture and Deployment Considerations for 588 Secure Origin BGP (soBGP)", 589 draft-white-sobgparchitecture-00 (work in progress), 590 May 2004. 592 [LISP] Farinacci, D., Oran, D., Fuller, V., and D. Meyer, 593 "Locator/ID Separation Protocol (LISP)", 594 draft-farinacci-lisp-05.txt (work in progress), 595 November 2007. 597 Authors' Addresses 599 Dino Farinacci 600 Cisco 601 Tasman Drive 602 San Jose, CA 95134 603 USA 605 Email: dino@cisco.com 607 Vince Fuller 608 Cisco 609 Tasman Drive 610 San Jose, CA 95134 611 USA 613 Email: vaf@cisco.com 615 Dave Meyer 616 Cisco 617 Tasman Drive 618 San Jose, CA 95134 619 USA 621 Email: dmm@cisco.com 623 Full Copyright Statement 625 Copyright (C) The IETF Trust (2007). 627 This document is subject to the rights, licenses and restrictions 628 contained in BCP 78, and except as set forth therein, the authors 629 retain all their rights. 631 This document and the information contained herein are provided on an 632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 634 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 635 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 636 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Intellectual Property 641 The IETF takes no position regarding the validity or scope of any 642 Intellectual Property Rights or other rights that might be claimed to 643 pertain to the implementation or use of the technology described in 644 this document or the extent to which any license under such rights 645 might or might not be available; nor does it represent that it has 646 made any independent effort to identify any such rights. Information 647 on the procedures with respect to rights in RFC documents can be 648 found in BCP 78 and BCP 79. 650 Copies of IPR disclosures made to the IETF Secretariat and any 651 assurances of licenses to be made available, or the result of an 652 attempt made to obtain a general license or permission for the use of 653 such proprietary rights by implementers or users of this 654 specification can be obtained from the IETF on-line IPR repository at 655 http://www.ietf.org/ipr. 657 The IETF invites any interested party to bring to its attention any 658 copyrights, patents or patent applications, or other proprietary 659 rights that may cover technology that may be required to implement 660 this standard. Please address the information to the IETF at 661 ietf-ipr@ietf.org. 663 Acknowledgment 665 Funding for the RFC Editor function is provided by the IETF 666 Administrative Support Activity (IASA).