idnits 2.17.1 draft-lear-lisp-nerd-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1198. 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (April 11, 2008) is 5859 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-06 ** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. '7') (Obsoleted by RFC 5246) == Outdated reference: A later version (-05) exists of draft-fuller-lisp-alt-01 == Outdated reference: A later version (-04) exists of draft-meyer-lisp-cons-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Intended status: Experimental April 11, 2008 5 Expires: October 13, 2008 7 NERD: A Not-so-novel EID to RLOC Database 8 draft-lear-lisp-nerd-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 13, 2008. 35 Abstract 37 LISP is a protocol to encapsulate IP packets in order to allow end 38 sites to multihome without injecting routes from one end of the 39 Internet to another. This memo specifies a database and a method to 40 transport the mapping of EIDs to RLOCs to routers in a reliable, 41 scalable, and secure manner. Our analysis concludes that transport 42 of of all EID/RLOC mappings scales well to at least 10^8 entries. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. Base Assumptions . . . . . . . . . . . . . . . . . . . . . 3 48 1.2. What is NERD? . . . . . . . . . . . . . . . . . . . . . . 4 49 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 51 2.1. Database Updates . . . . . . . . . . . . . . . . . . . . . 5 52 2.2. Communications between ITR and ETR . . . . . . . . . . . . 6 53 2.3. Who are database authorities? . . . . . . . . . . . . . . 7 54 3. NERD Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 3.1. NERD Record Format . . . . . . . . . . . . . . . . . . . . 9 56 3.2. Database Update Format . . . . . . . . . . . . . . . . . . 10 57 4. NERD Distribution Mechanism . . . . . . . . . . . . . . . . . 10 58 4.1. Initial Bootstrap . . . . . . . . . . . . . . . . . . . . 10 59 4.2. Retrieving Changes . . . . . . . . . . . . . . . . . . . . 11 60 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 5.1. Database Size . . . . . . . . . . . . . . . . . . . . . . 12 62 5.2. Router Throughput Versus Time . . . . . . . . . . . . . . 14 63 5.3. Number of Servers Required . . . . . . . . . . . . . . . . 14 64 5.4. Security Considerations . . . . . . . . . . . . . . . . . 16 65 5.4.1. Use of Public Key Infrastructures (PKIs) . . . . . . . 17 66 5.4.2. Other Risks . . . . . . . . . . . . . . . . . . . . . 19 67 6. Why not use XML? . . . . . . . . . . . . . . . . . . . . . . . 19 68 7. Perhaps use a hybrid model? . . . . . . . . . . . . . . . . . 20 69 8. Deployment Issues . . . . . . . . . . . . . . . . . . . . . . 21 70 8.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 71 9. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 21 72 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 74 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 77 13.2. Informational References . . . . . . . . . . . . . . . . . 23 78 Appendix A. Generating and verifying the database signature 79 with OpenSSL . . . . . . . . . . . . . . . . . . . . 24 80 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 25 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 Intellectual Property and Copyright Statements . . . . . . . . . . 27 84 1. Introduction 86 Locator/ID Separation Protocol (LISP) [1] separates an IP address 87 used by a host and local routing system from the locators advertised 88 by BGP participants on the Internet in general, and in the default 89 free zone (DFZ) in particular. It accomplishes this by establishing 90 a mapping between globally unique endpoint identifiers (EIDs) and 91 routing locators (RLOCs). This reduces the amount of state change 92 that occurs on routers within the default-free zone on the Internet, 93 while enabling end sites to be multihomed. 95 In some mapping distribution approaches to LISP the mapping is 96 learned via data-triggered control messages between ingress tunnel 97 routers (ITRs) and egress tunnel routers (ETRs) through an alternate 98 routing topology [14]. In other approaches of LISP, the mapping from 99 EIDs to RLOCs is instead learned through some other means. This memo 100 addresses different approaches to the problem, and specifies a Not- 101 so-novel EID RLOC Database (NERD) and methods to both receive the 102 database and to receive updates. 104 NERD is offered primarily as a way to avoid dropping packets, the 105 underlying assumption being that dropping packets is bad for 106 applications and end users. Those who do not agree with this 107 underlying assumption may find that other approaches make more sense. 109 LISP and NERD are both currently experimental protocols. The NERD 110 database is specified in such a way that the methods used to 111 distribute or retrieve it may vary over time. Multiple databases are 112 supported in order to allow for multiple data sources. An effort has 113 been made to divorce the database from access methods so that both 114 can evolve independently through experimentation and operational 115 validation. 117 1.1. Base Assumptions 119 In order to specify a mapping it is important to understand how it 120 will be used, and the nature of the data being mapped. In the case 121 of LISP, the following assumptions are pertinent: 123 o The data contained within the mapping changes only on provisioning 124 or configuration operations, and is not intended to change when a 125 link either fails or is restored. Some other mechanism such as 126 the use of LISP Reachability Bits with mapping replies handles 127 healing operations, particularly when a tail circuit within an 128 service provider's aggregate goes down. NERD can be used as a 129 verification method to ensure that whatever operational mapping 130 changes an ITR receives are authorized. 132 o While weight and priority are defined, these are not hop-by-hop 133 metrics. Hence the information contained within the mapping does 134 not change based on where one sits within the topology. 135 o A purpose of LISP being to reduce control plane overhead by 136 reducing "rate X state" complexity, updates to the mapping will be 137 relatively rare. 138 o Because LISP and NERD are designed to ease interdomain routing, 139 their use is intended within the inter-domain environment. That 140 is, LISP is best implemented at either the customer edge or 141 provider edge, and there will be on the order of as many ITRs and 142 EID Prefixes as there are connections to Internet Service 143 Providers by end customers. 144 o As such, NERD cannot be the sole means to implement host mobility, 145 although NERD may be in used in conjunction with other mechanisms. 146 For instance, it would be possible for a mobile node to receive a 147 local address that is an EID and pass that to the correspondent 148 node, who could also make use of an EID. As such use of LISP in 149 this case would be transparent, and no mapping entries are changed 150 for mobility. 152 1.2. What is NERD? 154 NERD is a Not-so-novel EID to RLOC Database. It consists of the 155 following components: 157 1. a network database format; 158 2. a change distribution format; 159 3. a database retrieval/bootstrapping method; 160 4. a change distribution method. 162 The network database format is compressible. However, at this time 163 we specify no compression method. NERD will make use of potentially 164 several transport methods, but most notably HTTP [2]. HTTP has 165 restart and compression capabilities. It is also widely deployed. 167 There exist many methods to show differences between two versions of 168 a database or a file, UNIX's "diff" being the classic example. In 169 this case, because the data is well structured and easily keyed, we 170 can make use of a very simple format for version differences that 171 simply provides a list of EID/RLOC mappings that have changed using 172 the same record format as the database, and a list of EIDs that are 173 to be removed. 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [3]. 179 1.3. Glossary 181 The reader is once again referred to [1] for a general glossary of 182 terms related to LISP. The following terms are specific to this 183 memo. 185 Base Distribution URI: An Absolute-URI as defined in Section 4.3 of 186 [6] from which other references are relative. The base 187 distribution URI is used to construct a URI to an EID/RLOC mapping 188 database. If more than one NERD is known then there will be one 189 or more base distribution URIs associated with each (although each 190 such base distribution URI may have the same value). 192 EID Database Authority: The authority that will sign database files 193 and updates. It is the source of both. 195 The Authority: Shorthand for the EID Database Authority. 197 NERD: (N)ot-so-novel (E)ID to (R)LOC (D)atabase. 199 AFI Address Family Identifier. 201 Pull Model: An architecture where clients pull only the information 202 they need at any given time, such as when a packet arrives for 203 forwarding. 205 Push Model: An architecture in which clients receive an entire 206 dataset, containing data they may or may not require, such as 207 mappings for EIDs that no host served is attempting to send to. 209 Hybrid Model: An architecture in which some information is pushed 210 toward the receiver from a source and some information is pulled 211 by the receiver. 213 2. Theory of Operation 215 Operational functions are split into two components: database updates 216 and state exchange between ITR and ETR during a communication. 218 2.1. Database Updates 220 What follows is a summary of how NERDs are generated and updated. 221 Specifics can be found in Section 3. The general way in which NERD 222 works is as follows: 224 1. A NERD is generated by an authority that allocates provider 225 independent (PI) addresses (e.g., IANA or an RIR) which are used 226 by sites as EIDs. As part of this process the authority 227 generates a digest for the database and signs it with a private 228 key whose public key is part of an X.509 certificate. [10] That 229 signature along with a copy of the authority's public key is 230 included in the NERD. 231 2. The NERD is distributed to a group of well known servers. 232 3. ITRs retrieve an initial copy of the NERD via HTTP when they come 233 into service. 234 4. ITRs are preconfigured with a group of certificates whose private 235 keys are used by database authorities to sign the NERD. This 236 list of certificates should be configurable by administrators. 237 5. ITRs next verify both the validity of the public key and the 238 signed digest. If either fail validation, the ITR attempts to 239 retrieve the NERD from a different source. The process iterates 240 until either a valid database is found or the list of sources is 241 exhausted. 242 6. Once a valid NERD is retrieved, the ITR installs it into both 243 non-volatile and local memory. 244 7. At some point the authority updates the NERD and increments the 245 database version counter. At the same time it generates a list 246 of changes, which it also signs, as it does with the original 247 database. 248 8. Periodically ITRs will poll from their list of servers to 249 determine if a new version of the database exists. When a new 250 version is found, an ITR will attempt to retrieve a change file, 251 using its list of preconfigured servers. 252 9. The ITR validates a change file just as it does the original 253 database. Assuming the change file passes validation, the ITR 254 installs new entries, overwrites existing ones, and removes empty 255 entries, based on the content of the change file. 257 As time goes on it is quite possible that an ITR may probe a list of 258 configured neighbors for a database or change file copy. It is 259 equally possible that neighbors might advertise to each other the 260 version number of their database. Such methods are not explored in 261 depth in this memo, but are mentioned for future consideration. 263 2.2. Communications between ITR and ETR 265 [1] describes the basic approach to what happens when a packet 266 arrives at an ITR, and what communications between ITR and ETR take 267 place. NERD provides an optimistic approach to establishing 268 communications with an ETR that is responsible for a given EID 269 prefix. State must be kept, however, on an ITR to determine whether 270 that ETR is in fact reachable. It is expected that this is a common 271 requirement across LISP mapping systems, and will be handled in the 272 core LISP architecture. 274 2.3. Who are database authorities? 276 This memo does not specify who the database authority is. That is 277 because there are several possible operational models. In each case 278 the number of database authorities is meant to be small so that ITRs 279 need only keep a small list of authorities, similar to the way a name 280 server might cache a list of root servers. 282 o A single database authority exists. In this case all entries in 283 the database are registered to a single entity, and that entity 284 distributes the database. Because the EID space is provider 285 independent address space, there is no architectural requirement 286 that address space be hierarchically distributed to anyone, as 287 there is with provider-assigned address space. Hence, there is a 288 natural affinity between the IANA function and the database 289 authority function. 290 o Each region runs a database authority. In this case, provider 291 independent address space is allocated to either Regional Internet 292 Registries (RIRs) or to affiliates of such organizations of 293 network operations guilds (NOGs). The benefit of this approach is 294 that there is no single organization that controls the database. 295 It allows one database authority to backup another. One could 296 envision as many as ten database authorities in this scenario. 297 One drawback to this approach, however, is that any reference to a 298 region imposes a notion of locality, thus potentially diminishing 299 the split between locator and identifier. 300 o Each country runs a database authority. This could occur should 301 countries decide to regulate this function. While limiting the 302 scope of any single database authority as the previous scenario 303 describes, this approach would introduce some overhead as the list 304 of database authorities would grow to as many as 200, and possibly 305 more if jurisdictions within countries attempted to regulate the 306 function. There are two drawbacks to this approach. First, as 307 distribution of EIDs is driven to more local jurisdictions, an EID 308 prefix is tied even tighter to a location. Second, a large number 309 of database authorities will demand some sort of discovery 310 mechanism. 311 o Independent operators manage database authorities. This has the 312 appeals of being location independent, and enabling competition 313 for good performance. This method has the drawback of potentially 314 requiring a discovery mechanism. 316 The latter two approaches are not mutually exclusive. While this 317 specification allows for multiple databases, discovery mechanisms are 318 left as future work. 320 3. NERD Format 322 The NERD consists of a header that contains a database version and a 323 signature that is generated by ignoring the signature field and 324 setting the authentication block length to 0 (NULL). The 325 authentication block itself consists of a signature and a certificate 326 whose private key counterpart was used to generate the signature. 328 Records are kept sorted in numeric order with AFI plus EID as primary 329 key and mask length as secondary. This is so that after a database 330 update it should be possible to reconstruct the database to verify 331 the digest signature, which may be retrieved separately from the 332 database for verification purposes. 334 0 1 2 3 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Schema Vers=1 | DB Code | Database Name Size | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Database Version | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Old Database Version or 0 | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 | Database Name | 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | PKCS#7 Block Size | Reserved | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 | PKCS#7 Block containing Certificate and Signature | 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Database Header 356 The DB Code indicates 0 if what follows is an entire database or 1 if 357 what follows is an update. The database file version is incremented 358 each time the complete database is generated by the authority. In 359 the case of an update, the database file version indicates the new 360 database file version, and the old database file version is indicated 361 in the "old DB version" field. The database file version is used by 362 routers to determine whether or not they have the most current 363 database. 365 The database name is a domain name. This is the name that will 366 appear in the Subject field of the certificate used to verify the 367 database. The purpose of the database name is to allow for more than 368 one database. Such databases would be merged by the router. It is 369 important that an EID/RLOC mapping be listed in no more than one 370 database, lest inconsistencies arise. However, it may be possible to 371 transition a mapping from one database to another. During the 372 transition period, the mappings MUST be identical. When they are 373 not, the resultant behavior will be undefined. 375 The PKCS#7 [4] authentication block contains a DER encoded [5] 376 signature and associated public key. 378 3.1. NERD Record Format 380 As distributed over the network, NERD records appear as follows: 382 0 1 2 3 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Num. RLOCs | EID Mask Len | EID AFI | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | End point identifier | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Priority 1 | Weight 1 | AFI 1 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Routing Locator 1 | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Priority 2 | Weight 2 | AFI 2 | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Routing Locator 2 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Priority 3 | Weight 3 | AFI 3 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Routing Locator 3... | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Priority N and Weight N, and AFI N are associated with Routing 403 Locator N. There will always be at least one routing locator. The 404 minimum record size for IPv4 is 16 bytes. Each additional IPv4 RLOC 405 increases the record size by 8 bytes. The purpose of this format is 406 to keep the database compact, but somewhat easily read. The meaning 407 of weight and priority are described in [1]. The format of the AFI 408 is specified by IANA as "Address Family Numbers", with the exception 409 of how IPv6 EID prefixes are stored. 411 In order to reduce storage and transmission amounts for IPv6, only 412 the necessary number of bytes as specified by the prefix length are 413 kept in the record, rounded to the nearest four byte (word) boundary. 414 For instance, if the prefix length is /49, the nearest four-byte word 415 boundary would require that eight bytes are stored. IPv6 RLOCs are 416 represented as normal 128-bit IPv6 addresses. 418 3.2. Database Update Format 420 A database update contains a set of changes to an existing database. 421 Each AFI/EID/mask-length tuple may have zero or more RLOCs associated 422 with it. In the case where there are no RLOCs, the EID entry is 423 removed from the database. Records that contain EIDs and mask 424 lengths that were not previously listed are simply added. Otherwise, 425 the old record for the EID and mask length is replaced by the more 426 current information. The record format used by the a database update 427 is the same as described in Section 3.1. 429 4. NERD Distribution Mechanism 431 4.1. Initial Bootstrap 433 Bootstrap occurs when a router needs to retrieve the entire database. 434 It knows it needs to retrieve the entire database because either it 435 has none or an update too substantial to process, as might be the 436 case if a router has been out of service for a substantially lengthy 437 period of time. 439 To bootstrap the ITR appends the database name plus "/current/ 440 entiredb" to a Base Distribution URI and retrieves the file via HTTP. 441 For example, if the configured URI is 442 "http://www.example.com/eiddb/", and assuming a database name of 443 "nerd.arin.net", the ITR would request 444 "http://www.example.com/eiddb/current/nerd.arin.net/entiredb". 445 Routers MUST check the signature on the database prior to installing 446 it, and MUST check that the database schema matches a schema they 447 understand. Once a router has a valid database it MUST store that 448 database in some sort of non-volatile memory (e.g., disk, flash 449 memory, etc). 451 N.B., the host component for such URIs MUST NOT resolve to a LISP 452 EID, lest a circular dependency be created. 454 4.2. Retrieving Changes 456 In order to retrieve a set of database changes an ITR will have 457 previously retrieved the entire database. Hence it knows the current 458 version of the database it has. Its first step for retrieving 459 changes is to retrieve the current version of the database. It does 460 so by appending "current/version" to the base distribution URI and 461 retrieving the file. Its format is text and it contains the integer 462 value of the current database version. 464 Once an ITR has retrieved the current version it compares version of 465 its local copy. If there is no difference, then the router is up to 466 date and need take no further actions until it next checks. 468 If the versions differ, the router next sends a request for the 469 appropriate change file by appending "current/changes/" and the 470 textual representation of the version of its local copy of the 471 database to the base distribution URI. For example, if the current 472 version of the database is 1105503 and router's version is 1105500, 473 and the base URI and database name are the same as above, the router 474 would request 475 "http://www.example.com/eiddb/nerd.arin.net/current/changes/1105500". 477 The server may not have that change file, either because there are 478 too many versions between what the router has and what is current, or 479 because no such change file was generated. If the server has changes 480 from the routers version to any later version, the server SHOULD 481 issue an HTTP redirect to that change file, and the router SHOULD 482 retrieve and process it. Once it has done so, the router should then 483 repeat the process until it has brought itself up to date. It is 484 thus important for servers to expire old change files in the order in 485 which they were generated. 487 By way of convention, it is suggested that the URIs issued in 488 redirects be of the following form: 490 {base dist. URI}/{dbname}/{more-recent-version}/changes/ 491 {older-version} 493 where "base dist. URI" is the base distribution URI, "dbname" is the 494 name of the database, and each version is the textual representation 495 of the integer version value. 497 For example, if the current database version was 1105503 and a router 498 made a request for 499 "http://www.example.com/eiddb/nerd.arin.net/current/changes/1105400" 500 but there was no change file from 1105400 to 1105503, and the server 501 had a group of change files to make the router current, it would 502 issue a redirect to 503 "http://www.example.com/eiddb/nerd.arin.net/110450/changes/1105400" 504 that the router would then process. The router would then make a 505 request for 506 "http://www.example.com/eiddb/nerd.arin.net/current/changes/110450" 507 that the server would have. 509 While it is unlikely that database versions would wrap, as they 510 consists of 32 bit integers, should the event occur, ITRs MUST 511 attempt first to retrieve a change file when their current version 512 number is within 10,000 of 2^32 and they see a version available that 513 is less than 10,000. Barring the availability of a change file, the 514 ITR MUST still assume that the database version has wrapped and 515 retrieve a new copy. 517 5. Analysis 519 We will start our analysis by looking at how much data will be 520 transferred to a router during bootstrap conditions. We will then 521 look at the bandwidth required. Next we will turn our concerns to 522 servers. Finally we will ponder the effect of providing only 523 changes. 525 In the analysis below we treat the overhead of the database header as 526 insignificant (because it is). The analysis should be similar, 527 whether a single database or multiple databases are employed, as we 528 would assume that no entry would appear more than once. 530 5.1. Database Size 532 By its very nature the information to be transported is relatively 533 static and is specifically designed to be topologically insensitive. 534 That is, every ITR is intended to have the same set of RLOCs for a 535 given EID. While some processing power will be necessary to install 536 a table, the amount required should be far less than that of a 537 routing information database because the level of entropy is intended 538 to be lower. 540 For purposes of this analysis, we will assume that the world has 541 migrated to IPv6, as this increases the size of the database, which 542 would be our primary concern. However, to mitigate the size 543 increase, we have limited the size of the prefix transmitted. For 544 purposes of this analysis, we shall assume an average prefix length 545 of 64 bits. 547 Based on that assumption, Section 3.1 states that mapping information 548 for each EID/Prefix includes a group of RLOCs, each with an 549 associated priority and weight, and that a minimum record size with 550 IPv6 EIDs with at least one RLOC is 30 bytes uncompressed. Each 551 additional IPv6 RLOC costs 20 bytes. 553 +-----------+--------+--------+---------+ 554 | 10^n EIDs | 2 RLOC | 4 RLOC | 8 RLOC | 555 +-----------+--------+--------+---------+ 556 | 4 | 500 KB | 900 KB | 1.70 MB | 557 | 5 | 5.0 MB | 9.0 MB | 17.0 MB | 558 | 6 | 50 MB | 90 MB | 170 MB | 559 | 7 | 500 MB | 900 MB | 1.70 GB | 560 | 8 | 5.0 GB | 9.0 GB | 17.0 GB | 561 +-----------+--------+--------+---------+ 563 Database size for IPv6 routes with average prefix length = 64 bits 565 Table 1 567 Entries in the above table are derived as follows: 569 E * (30 + 20 * (R - 1 )) 571 where E = number of EIDs (10^n), R = number of RLOCs per EID. 573 Our scaling target is to accommodate 10^8 multihomed systems, which 574 is one order magnitude greater than what is discussed in [8]. At 575 10^8 entries, a device could be expected to use between 5 and 17 576 gigabytes of RAM for the mapping. No matter the method of 577 distribution, any router that sits in the core of the Internet would 578 require near this amount of memory in order to perform the ITR 579 function. Large enterprise ETRs would be similarly strained, simply 580 due to the diversity of of sites that communicate with one another. 581 The good news is that this is not our starting point, but rather our 582 scaling target, a number that we intend to reach by the year 2050. 583 Our starting point is more likely in the neighborhood of 10^4 or 10^5 584 EIDs, thus requiring between 500KB and 17 MB. 586 5.2. Router Throughput Versus Time 588 +-------------------+---------+--------+---------+-------+ 589 | Table Size (10^N) | 1mb/s | 10mb/s | 100mb/s | 1gb/s | 590 +-------------------+---------+--------+---------+-------+ 591 | 6 | 8 | 0.8 | 0.08 | 0.008 | 592 | 7 | 80 | 8 | 0.8 | 0.08 | 593 | 8 | 800 | 80 | 8 | 0.8 | 594 | 9 | 8,000 | 800 | 80 | 8 | 595 | 10 | 80,000 | 8,000 | 800 | 80 | 596 | 11 | 800,000 | 80,000 | 8,000 | 800 | 597 +-------------------+---------+--------+---------+-------+ 599 Number of seconds to process NERD 601 Table 2 603 The length of time it takes to process the database is significant in 604 models where the device acquires the entire table. During this 605 period of time, either the router will be unable to route packets 606 using LISP or it must use some sort of query mechanism for specific 607 EIDs as the rest it populates its table through the transfer. 608 Table 2 shows us that at our scaling target, the length of time it 609 would take for a router using 1 mb/s of bandwidth is about 80 610 seconds. We can measure the processing rate in small numbers of 611 hours for any transfer speed greater than that. The fastest 612 processing time shows us as taking 8 seconds to process an entire 613 table of 10^9 bytes and 80 seconds for 10^10 bytes. 615 5.3. Number of Servers Required 617 As easy as it may be for a router to retrieve, the aggregate 618 information may be difficult for servers to transmit, assuming the 619 information is transmitted in aggregate (we'll revisit that 620 assumption later). 622 +----------------+------------+-----------+------------+------------+ 623 | # Simultaneous | 10 Servers | 100 | 1,000 | 10,000 | 624 | Requests | | Servers | Servers | Servers | 625 +----------------+------------+-----------+------------+------------+ 626 | 100 | 720 | 72 | 72 | 72 | 627 | 1,000 | 7,200 | 720 | 72 | 72 | 628 | 10,000 | 72,000 | 7,200 | 720 | 72 | 629 | 100,000 | 720,000 | 72,000 | 7,200 | 720 | 630 | 1,000,000 | 7,200,000 | 720,000 | 72,000 | 7,200 | 631 | 10,000,000 | 72,000,000 | 7,200,000 | 720,000 | 72,000 | 632 +----------------+------------+-----------+------------+------------+ 634 Retrieval time per number of servers in seconds. Assumes average 635 10^8 entries with 4 RLOCs per EID and that each server has access to 636 1gb/s and 100% efficient use of that bandwidth and no compression. 638 Table 3 640 Entries in the above table were generated using the following method: 642 For 10^8 entries with four RLOCs per EID, the table size is 9.0GB, 643 per our previous table. Assume 1 Gb/s transfer rates and 100% 644 utilization. Protocol overhead is ignored for this exercise. Hence 645 a single transfer X takes 48 seconds and can get no faster. 647 With this in mind, each entry is as follows: 649 max(1X,N*X/S) 651 where N=number of transfers, X = 72 seconds, 652 and S = number of servers. 654 If we have a distribution model which every device must retrieve the 655 mapping information upon start, Table 3 shows the length of time in 656 seconds it will take for a given number of servers to complete a 657 transfer to a given number of devices. This table says, as an 658 example, that it would take 72,000 seconds (20 hours) for one million 659 ITRs to simultaneously retrieve the database from one thousand 660 servers. Should a cold start scenario occur, this number should be 661 of some concern. Hence it is important to take some measures both to 662 avoid such a scenario, and to ease the load should it occur. The 663 primary defense should be for ITRs to first attempt to retrieve their 664 databases from their peers or upstream providers. Secondary defenses 665 could include data sanity checks within ITRs, with agreed norms for 666 how much the database should change in any given update or over any 667 given period of time. As we will see below, dissemination of changes 668 is considerably less volume. 670 +----------------+-------------+---------------+----------------+ 671 | % Daily Change | 100 Servers | 1,000 Servers | 10,000 Servers | 672 +----------------+-------------+---------------+----------------+ 673 | 0.1% | 300 | 30 | 3 | 674 | 0.5% | 1500 | 150 | 15 | 675 | 1% | 3000 | 300 | 30 | 676 | 5% | 15,000 | 1500 | 150 | 677 | 10% | 30,000 | 3000 | 300 | 678 +----------------+-------------+---------------+----------------+ 680 Assuming 10 million routers and a database size of 9GB, resulting 681 hourly transfer times are shown in seconds, given number of servers 682 and daily rate of change. 684 Table 4 686 This table shows us that with 10,000 servers the average transfer 687 time with 1Gb/s links for 10,000,000 routers will be 300 seconds with 688 10% daily change spread over 24 hourly updates. For a 0.1% daily 689 change, that number is 3 seconds for a database of size 9.0GB. 691 The amount of change goes to the purpose of LISP. If its purpose is 692 to provide effective multihoming support to end customers, then we 693 might anticipate relatively few changes. If, on the other, service 694 providers attempt to make use of LISP to provide some form of traffic 695 engineering, we can expect the same data to change more often. We 696 can probably not conclude much in this regard without additional 697 operational experience. The one thing we can say is that different 698 applications of the LISP protocol may require new and different 699 distribution mechanisms. Such optimization is left for another day. 701 5.4. Security Considerations 703 Whichever the answer to our previous question, we must consider the 704 security of the information being transported. If an attacker can 705 forge an update or tamper with the database, he can in effect 706 redirect traffic to end sites. Hence, integrity and authenticity of 707 the NERD is critical. In addition, a means is required to determine 708 whether a source is authorized to modify a given database. No data 709 privacy is required. Quite to the contrary, this information will be 710 necessary for any ITR. 712 The first question one must ask is who to trust to provide the ITR a 713 mapping. Ultimately the owner of the EID prefix is most 714 authoritative for the mapping to RLOCs. However, were all owners to 715 sign all such mappings, ITRs would need to know which owner is 716 authorized to modify which mapping, creating a problem of O(N^2) 717 complexity. 719 We can reduce this problem substantially by investing some trust in a 720 small number of entities that are allowed to sign entries. If 721 authority manages EIDs much the same way a domain name registrar 722 handles domains, then the owner of the EID would choose a database 723 authority she or he trusts, and ITRs must trust each such authority 724 in order to map the EIDs listed by that authority to RLOCs. This 725 reduces the amount of management complexity on the ETR to retaining 726 knowledge of O(#authorities), but does require that each authority 727 establish procedures for authenticating the owner of an EID. Those 728 procedures needn't be the same. 730 There are two classic methods to ensure integrity of data: 732 o secure transport of the source of the data to the consumer, such 733 as Transport Layer Security (TLS) [7]; and 734 o provide object level security. 736 These methods are not mutually exclusive, although one can argue 737 about the need for the former, given the latter. 739 In the case of TLS, when it is properly implemented, the objects 740 being transported cannot easily be modified by interlopers or so- 741 called men in the middle. When data objects are distributed to 742 multiple servers, each of those servers must be trusted. As we have 743 seen above, we could have quite a large number of servers, thus 744 providing an attacker a large number of targets. We conclude that 745 some form of object level security is required. 747 Object level security involves an authority signing an object in a 748 way that can easily be verified by a consumer, in this case a router. 749 In this case, we would want the mapping table and any incremental 750 update to be signed by the originator of the update. This implies 751 that we cannot simply make use of a tool like CVS [9]. Instead, the 752 originator will want to generate diffs, sign them, and make them 753 available either directly or through some sort of content 754 distribution or peer to peer network. 756 5.4.1. Use of Public Key Infrastructures (PKIs) 758 X.509 provides a certificate hierarchy that has scaled to the size of 759 the Internet. The system is most manageable when there are few 760 certificates to manage. The model proposed in this memo makes use of 761 one current certificate per database authority. The three pieces of 762 information necessary to verify a signature, therefore, are as 763 follows: 765 o the certificate of the database authority, which can be provided 766 along with the database; 767 o the certificate authority's certificate; and 768 o A table of database names and distinguished names (DNs) that are 769 allowed to update them. 771 The latter two pieces of information must be very well known and must 772 be configured on each ITR. It is expected that both would change 773 very rarely, and it would not be unreasonable for such updates to 774 occur as part of a normal OS release process. 776 The tools for both signing and verifying are readily available. 777 OpenSSL [16] provides tools and libraries for both signing and 778 verifying. Other tools commonly exist. 780 Use of PKIs is not without implementation, operational complexity or 781 risk. The following risks and mitigations are identified with NERD's 782 use of PKIs: 784 If a NERD database authority private key is exposed: 786 In this case an attacker could sign a false database update, 787 either redirecting traffic, or otherwise causing havoc. In this 788 case, the NERD database administrator must revoke its existing key 789 and issue a new one. The certificate is added to a certificate 790 revocation list (CRL), which may be distributed with both this and 791 other databases, as well as through other channels. Because this 792 event is expected to be rare, and the number of database 793 authorities is expected to be small, a CRL will be small. When a 794 router receives a revocation, it checks it against its existing 795 databases, and attempts to update the one that is revoked. This 796 implies that prior to issuing the revocation, the database 797 authority MUST sign an update with the new key. Routers SHOULD 798 discard updates they have already received that were signed after 799 the revocation was generated. If a router cannot confirm that 800 whether the authority's certificate was revoked before or after a 801 particular update, it MUST retrieve a fresh new copy of the 802 database with a valid signature. 804 The private key associated with the CA that signed the Authority's 805 certificate is compromised: 807 In this case, it becomes possible for an attacker to masquerade as 808 the database authority. To ameliorate damage, the database 809 authority SHOULD revoke its certificate and get a new certificate 810 issued from a CA that is not compromised. Once it has done so, 811 the previous procedure is followed. The compromised certificate 812 can be removed during the normal operating system upgrade cycle. 814 An algorithm used if either the certificate or the signature is 815 cracked: 817 This is a catastrophic failure and the above forms of attack 818 become possible. The only mitigation is to make use of a new 819 algorithm. In theory this should be possible, but in practice has 820 proved very difficult. For this reason, additional work is 821 recommended to make alternative algorithms available. 823 The Database Authority loses its key or disappears: 825 In this case nobody can update the existing database. There are 826 few programmatic mitigations. If the database authority places 827 its private keys and suitable amounts of information escrow, under 828 agreed upon circumstances, such as no updates for three days, for 829 example, the escrow agent would release the information to a party 830 competent of generating a database update. 832 5.4.2. Other Risks 834 Because this specification does not require secure transport, if an 835 attacker prevents updates to an ITR for the purposes of having that 836 ITR continue to use a compromised ETR, the ITR could continue to use 837 an old version of the database without realizing a new version has 838 been made available. If one is worried about such an attack, a 839 secure channel such as SSL to a secure chain back to the database 840 authority should be used. It is possible that after some operational 841 experience, later versions of this format will contain additional 842 semantics to address this attack. 844 As discussed above, substantial risk would be a cold start scenario. 845 If an attacker found a bug in a common operating system that allowed 846 it to erase an ITR's database, and was able to disseminate that bug, 847 the collective ability of ITRs to retrieve new copies of the database 848 could be taxed by collective demand. The remedy to this is for 849 devices to share copies of the database with their neighbors, thus 850 making each potential requester a potential service. 852 6. Why not use XML? 854 Many objects these days are distributed as either XML pages or 855 something derived as XML [11], such as SOAP [12],[13]. Use of such 856 well known standards allows for high level tools and library reuse. 857 XML's strength is extensibility. Without a doubt XML would be more 858 extensible than a fixed field database. Why not, then, use these 859 standards in this case? There are two answers to this question. 860 First, the obvious concern is that XML is not known for efficiency of 861 data transport. Being based in text, an IPv4 address is expanded 862 from one octet to three octets, plus either an attribute and quotes 863 or element tags and end tags. Let us presume for the moment a very 864 simple schema that might cause a record to be represented as follows: 866 867 868 869 192.168.1.1 870 871 872 873 874 192.168.1.2 875 876 877 879 With white space removed the uncompressed XML represents 120 bytes 880 versus 20 bytes for the record specified in Section 3.1, representing 881 a five fold expansion. The expansion rate for IPv6 is a bit more 882 complex. Because the textual representation can be shortened, it's 883 hard to say exactly what length an IPv6 address would be. 885 The other concern about XML is that version 1.0 of the specification 886 is silent on the order of sibling elements. Specifications other 887 than the base specification state that order is significant. Order 888 is significant to LISP and NERD because once an update is applied to 889 the database it should be possible to verify the signature of the 890 entire database. Prior to applying the signature the XML generator 891 would need to ensure the order of information. That same sort would 892 be required of the router. This seems to add unnecessary fragility 893 to a critical system without much benefit. While there may indeed be 894 uses of an XML representation of the database, these uses are likely 895 to be outside of a router. 897 7. Perhaps use a hybrid model? 899 Perhaps it would be useful to use both a prepopulated database such 900 as NERD and a query mechanism (perhaps LISP+ALT, LISP-CONS [15], or 901 DNS) to determine an EID/RLOC mapping. One idea would be to receive 902 a subset of the mappings, say, by taking only the NERD for certain 903 regions. This alleviates the need to drop packets for some subset of 904 destinations under the assumption that one's business is localized to 905 a particular region. If one did not have a local entry for a 906 particular EID one would then make a query. 908 One approach to using DNS to query live would be to periodically walk 909 "interesting" portions of the network, in search of relevant records, 910 and caching them to non-volatile storage. While preventing resource 911 attacks, the walk itself could be viewed as an attack, if the 912 algorithm was not selective enough about what it thought was 913 interesting. A similar approach could be applied to LISP+ALT or 914 LISP-CONS by forcing a data-driven Map Reply for certain sites. 916 8. Deployment Issues 918 While LISP and NERD are intended as experiments at this point, it is 919 already obvious one must give serious consideration to circular 920 dependencies with regard to the protocols used and the elements 921 within them. 923 8.1. HTTP 925 In as much as HTTP depends on DNS, either due to the authority 926 section of a URI, or due to the configured base distribution URI, 927 these same concerns apply. In addition, any HTTP server that itself 928 makes use of provider independent addresses would be a poor choice to 929 distribute the database for these exact same reasons. 931 One issue with using HTTP is that it is possible that a middlebox of 932 some form, such as a cache, may intercept and process requests. In 933 some cases this might be a good thing. For instance, if a cache 934 correctly returns a database, some amount of bandwidth is conserved. 935 On the other hand, if the cache itself fails to function properly for 936 whatever reason, end to end connectivity could be impaired. For 937 example, if the cache itself depended on the mapping being in place 938 and functional, a cold start scenario might leave the cache 939 functioning improperly, in turn providing routers no means to update 940 their databases. Some care must be given to avoid such 941 circumstances. 943 9. Open Questions 945 Do we need to discuss reachability in more detail? This was clearly 946 an issue at the IST-RING workshop. There are two key issues. First, 947 what is the appropriate architectural separation between the data 948 plane and the control plane? Second, is there some specific way in 949 which NERD impacts the data plane? 951 Should we specify a (perhaps compressed) tarball that treads a middle 952 ground for the last question, where each update tarball contains both 953 a signature for the update and for the entire database, once the 954 update is applied. 956 Should we compress? In some initial testing of databases with 1, 5, 957 and 10 million IPv4 EIDs and a random distribution of IPv4 RLOCs, the 958 current format in this document compresses down by a factor of 959 between 35% and 36%, using Burrows-Wheeler block sorting text 960 compression algorithm (bzip2). The NERD used random EIDs with mask 961 lengths varying from 19-29, with probability weighted toward the 962 smaller masks. This only very roughly reflects reality. A better 963 test would be to start with the existing prefixes found in the DFZ. 965 10. Conclusions 967 This memo has specified a database format, an update format, a URI 968 convention, an update method, and a validation method for EID/RLOC 969 mappings. We have shown that beyond the predictions of 10^8 EID- 970 prefix entries, the aggregate database size would likely be at most 971 17GB. We have considered the amount of servers to distribute that 972 information and we have demonstrated the limitations of a simple 973 content distribution network and other well known mechanisms. The 974 effort required to retrieve a database change amounts to between 3 975 and 30 seconds of processing time per hour at at today's gigabit 976 speeds. We conclude that there is no need for an off box query 977 mechanism today, and that there are distinct disadvantages for having 978 such a mechanism in the control plane. 980 Beyond this we have examined alternatives that allow for hybrid 981 models that do use query mechanisms, should our operating assumptions 982 prove overly optimistic. Use of NERD today does not foreclose use of 983 such models in the future, and in fact both models can happily co- 984 exist. 986 We leave to future work how the list of databases is distributed, how 987 BGP can play a role in distributing knowledge of the databases, and 988 how DNS can play a role in aggregating information into these 989 databases. 991 We also leave to future work whether HTTP is the best protocol for 992 the job, and whether the scheme described in this document is the 993 most efficient. One could easily envision that when applied in high 994 delay or high loss environments, a broadcast or multicast method may 995 prove more effective. 997 11. IANA Considerations 999 This memo makes no requests of IANA. 1001 12. Acknowledgments 1003 Dino Farinacci, Patrik Faltstrom, Dave Meyer, Joel Halpern, Dave 1004 Thaler, Mohamed Boucadair, Robin Whittle, Max Pritikin, and Scott 1005 Brim were very helpful with their reviews of this work. Thanks also 1006 to the participants of the Routing Research Group and the IST-RING 1007 workshop held in Madrid in December of 2007 for their incisive 1008 comments. The astute will notice a lengthy References section. This 1009 work stands on the shoulders of many others' efforts. 1011 13. References 1013 13.1. Normative References 1015 [1] Farinacci, D., "Locator/ID Separation Protocol (LISP)", 1016 draft-farinacci-lisp-06 (work in progress), February 2008. 1018 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1019 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1020 HTTP/1.1", RFC 2616, June 1999. 1022 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1023 Levels", BCP 14, RFC 2119, March 1997. 1025 [4] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1026 1.5", RFC 2315, March 1998. 1028 [5] International Telecommunications Union, "Information technology 1029 - Open Systems Interconnection - The Directory: Public-key and 1030 attribute certificate frameworks", ITU-T Recommendation X.509, 1031 ISO Standard 9594-8, March 2000. 1033 [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1034 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1035 January 2005. 1037 13.2. Informational References 1039 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1040 Protocol Version 1.1", RFC 4346, April 2006. 1042 [8] Carpenter, B., "IETF Plenary Presentation: Routing and 1043 Addressing: Where we are today", March 2007. 1045 [9] Grune, R., Baalbergen, E., Waage, M., Berliner, B., and J. 1046 Polk, "CVS: Concurrent Versions System", November 1985. 1048 [10] International International Telephone and Telegraph 1049 Consultative Committee, "Information Technology - Open Systems 1050 Interconnection - The Directory: Authentication Framework", 1051 CCITT Recommendation X.509, November 1988. 1053 [11] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 1054 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, 1055 October 2000, . 1057 [12] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H. 1058 Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", W3C 1059 Working Draft soap12-part1, June 2002, 1060 . 1062 [13] Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., and H. 1063 Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", W3C Working 1064 Draft soap12-part2, June 2002, 1065 . 1067 [14] Farinacci, D., "LISP Alternative Topology (LISP-ALT)", 1068 draft-fuller-lisp-alt-01 (work in progress), November 2007. 1070 [15] Brim, S., "LISP-CONS: A Content distribution Overlay Network 1071 Service for LISP", draft-meyer-lisp-cons-03 (work in progress), 1072 November 2007. 1074 URIs 1076 [16] 1078 Appendix A. Generating and verifying the database signature with 1079 OpenSSL 1081 As previously mentioned, one goal of NERD was to use off-the-shelf 1082 tools to both generate and retrieve the database. To many, PKI is 1083 magic. This section is meant to provide at least some clarification 1084 as to both the generation and verification process, complete with 1085 command line examples. Not included is how you get the entries 1086 themselves. We'll assume they exist, and that you're just trying to 1087 sign the database. 1089 To sign the database, to start with, you need a database file that 1090 has a database header described in Section 3. Block size should be 1091 zero, and there should be no PKCS#7 block at this point. You also 1092 need a certificate and its private key with which you will sign the 1093 database. 1095 The OpenSSL "smime" command contains all the functions we need from 1096 this point forth. To sign the database, issue the following command: 1098 openssl smime -binary -sign -outform DER -signer yourcert.crt \ 1099 -inkey yourcert.key -in database-file -out signature 1101 -binary states that no MIME canonicalization should be performed. 1102 -sign indicates that you are signing the file that was given as the 1103 argument to -in. The output format (-outform) is binary DER, and 1104 your public certificate is provided with -signer along with your key 1105 with -inkey. The signature itself is specified with -out. 1107 The resulting file "signature" is then copied into to PKCS#7 block in 1108 the database header, its size in bytes is recorded in the PKCS#7 1109 block size field, and the resulting file is ready for distribution to 1110 ITRs. 1112 To verify a database file, first retrieve the PKCS#7 block from the 1113 file by copying the appropriate number of bytes into another file, 1114 say "signature". Next, zero this field, and set the block size field 1115 to 0. Next use the "smime" command to verify the signature as 1116 follows: 1118 openssl smime -binary -verify -inform DER -content database-file 1119 -out /dev/null -in signature 1121 Openssl will return "Verification OK" if the signature is correct. 1122 OpenSSL provides sufficiently rich libraries to accomplish the above 1123 within the C programming language with a single pass. 1125 Appendix B. Changes 1127 This section to be removed prior to publication. 1129 o 04: Analysis change: IPv6 RLOCs are 128 bits. While they can be 1130 shortened to 64 bits, that involves substantial ETR changes and 1131 expenditure of IPv6 networks, which is probably unnecessary, and 1132 can be left as a later optimization. Added an option of 1133 independent operators. Processed all but two of Dino's comments. 1134 Addressed Scott's comments. Removed existing work analysis. 1135 Saving that for another day. Clarified OpenSSL Appendix. 1136 o 03: Change dbname to a domain name, indicate that is what is in 1137 the subject of the X.509 certificate, and list editorial changes, 1138 update acknowledgments. 1139 o 02: Incorporate some of Dave Thaler's comments. Add 1140 authentication block detail. Modify analysis to take IPv6 into 1141 account, along with a more realistic number of RLOCs per EID. Add 1142 some comments about potential risks of a cold start. Add S/MIME 1143 example as appendix A and take out old ToDo. Provide some amount 1144 of compression of IPv6 addresses by limiting their size to 1145 significant bytes rounded to a four byte word boundary. 1146 o 01: Massive spelling correction, URI example correction. 1147 o 00: Initial Revision. 1149 Author's Address 1151 Eliot Lear 1152 Cisco Systems GmbH 1153 Glatt-com 1154 Glattzentrum, ZH CH-8301 1155 Switzerland 1157 Phone: +41 44 878 7525 1158 Email: lear@cisco.com 1160 Full Copyright Statement 1162 Copyright (C) The IETF Trust (2008). 1164 This document is subject to the rights, licenses and restrictions 1165 contained in BCP 78, and except as set forth therein, the authors 1166 retain all their rights. 1168 This document and the information contained herein are provided on an 1169 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1170 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1171 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1172 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1173 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1174 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1176 Intellectual Property 1178 The IETF takes no position regarding the validity or scope of any 1179 Intellectual Property Rights or other rights that might be claimed to 1180 pertain to the implementation or use of the technology described in 1181 this document or the extent to which any license under such rights 1182 might or might not be available; nor does it represent that it has 1183 made any independent effort to identify any such rights. Information 1184 on the procedures with respect to rights in RFC documents can be 1185 found in BCP 78 and BCP 79. 1187 Copies of IPR disclosures made to the IETF Secretariat and any 1188 assurances of licenses to be made available, or the result of an 1189 attempt made to obtain a general license or permission for the use of 1190 such proprietary rights by implementers or users of this 1191 specification can be obtained from the IETF on-line IPR repository at 1192 http://www.ietf.org/ipr. 1194 The IETF invites any interested party to bring to its attention any 1195 copyrights, patents or patent applications, or other proprietary 1196 rights that may cover technology that may be required to implement 1197 this standard. Please address the information to the IETF at 1198 ietf-ipr@ietf.org.